For a pre-recorded 1920×1080 progressive video at 50 frames per second, a practical FFmpeg starting point is H.264 video, AAC stereo audio, constant-rate-style settings and a two-second keyframe interval. Pace the file in real time and send it to the ingest URL and stream key shown in YouTube Live Control Room.
YouTube does not publish a 1080p50 bitrate row. A setting such as 17 Mbps is an informed starting inference from its 1080p60 guidance, not a YouTube recommendation for 50 fps; test it with your own file and connection before relying on it.
Check the file before encoding
First establish what is actually in the file. A filename that includes “1080p50” is not proof that the stream contains 1920×1080 progressive video at a constant 50 fps, or that its audio is stereo. Mixed frame rates, variable frame rate, multiple audio tracks and HDR colour can all affect what FFmpeg should do.
Use FFprobe, distributed with FFmpeg, to inspect streams and format details. For example:
ffprobe -hide_banner -i input.mp4
Look for the video width and height, reported frame rate, pixel format and colour characteristics, and note the audio codec, sample rate, channel count and any alternate tracks. Treat these as clues to confirm, not a reason to blindly force conversions. If the file is HDR and you intend an SDR output, you need an intentional tone-mapping and colour workflow; simply changing a pixel format does not correctly convert HDR to SDR.
Decide which audio track belongs in the broadcast. A lecture file may contain a clean programme track and a commentary track, while a music compilation may carry stereo audio at a sample rate that differs from your intended output. Specify a track only after confirming its stream index. This avoids accidentally transmitting silence, an alternate language, or commentary that was not meant to go out.
YouTube’s encoder settings guidance covers supported formats and general live encoding recommendations. FFmpeg’s formats documentation and codec documentation explain the command-line and encoder options used below. The command is a template, not a tested configuration for every operating system or FFmpeg build.
Use H.264, AAC stereo and constrained rate control
For an ordinary SDR 1080p50 stream, H.264 video and AAC audio make a straightforward baseline. The example uses libx264, which is available only when FFmpeg has been built with that encoder. Check your own build with ffmpeg -encoders if FFmpeg reports that it cannot find libx264; option availability can vary.
YouTube calls for CBR, or constant bitrate, in its live encoder guidance. With FFmpeg’s libx264, -b:v, -maxrate and -bufsize are commonly used together for constrained-rate control. They are a useful starting configuration, but do not assume the combination reproduces a platform preset exactly on every build. Confirm the outgoing behaviour in a test stream and read YouTube’s stream-health feedback.
For audio, the template uses AAC at 128 kbps and stereo. YouTube lists AAC or MP3 as acceptable and gives general AAC recommendations including stereo at 128 kbps. Keep the source’s appropriate sample rate rather than resampling without a reason: the example uses 48 kHz, but that is a chosen output value, not a universal requirement for stereo. Confirm that the file’s chosen audio track is audible and properly synchronised after encoding.
Other listed codecs, including HEVC and AV1, may suit a workflow with compatible encoders and ingest support, but they add compatibility decisions. For a reader asking for a reproducible H.264 baseline, start with H.264 and change codec only when you have a concrete reason and have tested the complete path.
Set 1080p50 and calculate the two-second GOP
A frame rate of 50 frames per second means that two seconds of video contain 100 frames: 50 × 2 = 100. Therefore, -g 100 sets a GOP length of 100 frames, corresponding to the two-second keyframe spacing sought here. YouTube recommends a two-second keyframe frequency and says not to exceed four seconds.
The command also sets -keyint_min 100 and disables scene-change keyframes with -sc_threshold 0, making the intended cadence more consistent. These are libx264 options, so check encoder availability and confirm the result rather than assuming a different encoder interprets them the same way. At 50 fps, four seconds would be 200 frames; the chosen 100-frame interval stays at the requested two seconds.
-r 50 requests a 50 fps output. That is appropriate only if you have checked the input and deliberately want this output cadence. If the source is 25 fps, forcing 50 fps does not create new picture detail; FFmpeg may duplicate frames. Conversely, if the input’s timing is irregular, forcing a constant output cadence may require frame duplication or dropping. Preview representative motion and inspect the test broadcast before choosing to convert.
The template uses -pix_fmt yuv420p, a common SDR output pixel format for broad playback compatibility. It is not an HDR conversion method. For a file with a different bit depth, chroma format or colour range, confirm the desired output and conversions deliberately instead of treating this switch as a universal fix.
Choose a bitrate without a 1080p50 row
YouTube’s published H.264 table gives 14 Mbps for 1080p at 30 fps and 17 Mbps for 1080p at 60 fps. There is no 1080p50 row in that table. Using 17 Mbps as a starting point for 50 fps is a practical inference from the higher adjacent row, not a published target for 50 fps. The guidance page does not state a publication year; these figures were checked in 2026, which is an access date rather than a claimed publication date.
| Output listed in YouTube’s H.264 guidance | Listed recommended bitrate | How to apply it here |
|---|---|---|
| 1080p30 | 14 Mbps | Published row; useful lower adjacent reference |
| 1080p50 | No row | Choose and test a starting value; do not label it official guidance |
| 1080p60 | 17 Mbps | Published row; 17 Mbps at 50 fps is an inference from this higher adjacent reference |
The command below sets video bitrate, maximum rate and buffer to 17 Mbps, 17 Mbps and 34 Mbps respectively. Those are example choices, not YouTube-published 1080p50 settings. A static devotional image with a slow visualiser may need less than footage with fast movement, fine detail or changing scenes. Even if the encoder can use the chosen rate, your upload connection must sustain the complete stream reliably, with room for network variation and audio overhead.
Do not increase bitrate merely because a higher number looks safer. A rate that exceeds stable upload capacity can cause interruptions or poor health messages; a lower rate may be adequate for less demanding pictures. Run a representative private or unlisted test and compare the observed upload and stream-health feedback. If you need a different value, change it in measured steps and retest rather than treating the 50 fps inference as a fixed rule.
Pace the file in real time and select a transport
When the input is a file, -re asks FFmpeg to read it at its native rate, rather than processing it as fast as the computer can. For a live broadcast, the encoder needs to deliver media in real time: an hour of file content should take about an hour to send, not arrive in a burst. This is particularly important for prerecorded material that you want to present as a live channel.
YouTube lists RTMP and RTMPS in its supported ingest protocols. Prefer RTMPS when the endpoint YouTube gives you and your FFmpeg build support it. Do not assume support in every endpoint or build: use the current URL provided for the stream and check whether your local FFmpeg accepts the protocol. If the secure form fails, confirm the endpoint and build before changing other settings; follow YouTube’s current ingest instructions rather than guessing a URL.
The -f flv muxer is used for the RTMP workflow documented by FFmpeg. The example’s URL is deliberately a placeholder. Substitute the exact ingest URL from Live Control Room, preserving its path and using the key separately as shown in the next section. Do not paste a real key into a public script repository, screenshot or support post.
Copy the current ingest URL and key
Create or select the live stream in YouTube Live Control Room, then use the ingest URL and stream key presented for it. YouTube uses the key much like a password: it identifies the broadcast feed sent to the selected stream. Keep it private, and regenerate it in YouTube if it is exposed or you suspect someone else has access.
YouTube’s stream settings help explains the stream URL and key workflow. Names and layout in the Control Room can change, so rely on the current values displayed in your account rather than copying a URL from an old tutorial. A key from another stream, or a stale key after changing settings, can leave the Control Room waiting even while FFmpeg appears to connect.
Here is a template for the requested baseline. Replace INGEST_URL/STREAM_KEY with the exact combined endpoint format supplied for your stream; protect the resulting command because it contains the private key.
ffmpeg -re -i input.mp4 \
-c:v libx264 -preset veryfast -r 50 -pix_fmt yuv420p \
-b:v 17M -maxrate 17M -bufsize 34M \
-g 100 -keyint_min 100 -sc_threshold 0 \
-c:a aac -b:a 128k -ar 48000 -ac 2 \
-f flv "rtmps://INGEST_URL/STREAM_KEY"
-preset veryfast is an example speed choice: a slower preset can use more compute time, while a faster one may affect compression efficiency. The right setting depends on the machine and encoder, and this example does not assert a measured performance result. If the input contains multiple audio or video streams, choose streams explicitly after examining them with FFprobe rather than relying on automatic selection.
For unattended or round-the-clock channels, the encode command is only one part of the operating plan. A process exit, connection loss or bad key still needs attention. For issues caused by a long-running FFmpeg process, see this guide to a 24/7 stream stuck on one video from a VPS. If you are comparing file-loop approaches rather than encoding one event, the OBS media source loop guide covers a different workflow.
Test output and watch stream health
Do not make the first run the event itself. Start a private or unlisted test with picture and sound similar to the planned broadcast: include representative movement, scene changes and the loudest or most complex audio. Check that the Control Room receives video and audio, and that the picture is not stretched, cropped, unexpectedly repeated or colour-shifted.
Watch the stream-health messages while testing. YouTube recommends testing before the live stream and checking upload bitrate and health indicators. Confirm the configured bitrate is within the stable capacity available at the sending location; a speed test at another time is not a guarantee of sustained upload performance during the event. If the feed becomes unstable, compare its actual behaviour with the connection capacity and the Control Room messages before changing encoder options.
Troubleshoot in a deliberate order. First verify that the ingest URL and key match the selected stream, then check whether the connection reaches YouTube and whether the source file plays correctly. Next inspect output frame rate, audio selection, bitrate and keyframe cadence. Changing several options at once can hide the cause of a problem, so alter one area and run another representative test.
A file that streams smoothly once may still fail after an interruption or when the computer sleeps, loses network access or runs out of resources. For a 24/7 channel, decide who will notice a stopped process and how it will be restarted. If your workflow is a playlist on a Linux machine, the systemd and FFmpeg guide for an always-on channel discusses process supervision. If your actual source is continuous radio audio rather than a video file, this Telugu radio YouTube workflow addresses that distinct case.
There is no independent field test behind this command. Its settings are a documented-options template to validate against your file, local FFmpeg build, account’s current ingest details and network. YouTube’s recommendations are useful guardrails, but they do not certify a particular command or promise that a stream will be approved or remain online.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
What bitrate should I use for 1080p50 YouTube Live?
YouTube’s cited H.264 table lists 14 Mbps for 1080p30 and 17 Mbps for 1080p60, but no 1080p50 row. Treat 17 Mbps as a practical inference from the 60 fps row, then test against the visual complexity of your file and stable upload capacity. It is not a published 1080p50 target.
What is the two-second keyframe setting at 50 fps?
At 50 frames each second, two seconds contain 100 frames. Set -g 100 for that GOP length, and use a test stream to confirm the encoder behaves as intended. YouTube recommends a two-second keyframe frequency and says not to exceed four seconds.
Why does a file need -re for a live stream?
Without real-time pacing, FFmpeg can read and send a file faster than its playback duration. -re paces input so the encoded media is sent at the source rate for a live workflow. It is intended for file input and is not a general instruction to apply to every live capture source.
Should I always use RTMPS?
Prefer RTMPS when YouTube provides a compatible endpoint and your FFmpeg build supports it. YouTube lists RTMP and RTMPS, so support should be checked rather than assumed for every endpoint and build. Use the current ingest details in Live Control Room and test before the event.