Start with YouTube's recommended bitrate for your codec, resolution, and frame rate, then configure FFmpeg for constant bitrate and a keyframe every two seconds. For a basic H.264 1080p30 stream, that means 14 Mbps video, 128 kbps AAC audio, and a 60-frame GOP.
The exact command depends on the encoder and the FFmpeg build installed on your machine. Treat the command below as a reproducible starting point, not a guarantee that every encoder will behave identically or that the stream will remain uninterrupted.
Choose the source and YouTube ingest settings
Before writing an FFmpeg command, decide what you are sending and which ingest details YouTube has given you. The bitrate is not a universal setting. It changes with the codec, resolution, and frame rate, and the correct GOP value changes with the frame rate.
For a straightforward SDR example, use H.264 video, AAC stereo audio, Rec. 709 colour, and 8-bit video. YouTube also documents H.265 and AV1 ingestion, but an H.264 example is easier to reproduce because libx264 is commonly available and its rate-control options are familiar. If your source is a devotional loop, lofi station, study timer, or local news sequence, check the actual output dimensions and frame rate rather than relying on the source file name.
You will need three values from YouTube Live Control Room:
- The ingest URL.
- The stream key, or stream name where the selected workflow uses one.
- The stream's scheduled or persistent configuration.
YouTube recommends RTMPS for encoder-based streaming. Its encoder guidance also specifies CBR, a recommended two-second keyframe interval, and a maximum interval of four seconds, as listed on YouTube Help in September 2026. Read the official YouTube encoder settings before a long broadcast because platform settings and supported formats can change.
A stream key is a credential. Do not place it in a screenshot, public tutorial, shared shell history, or a script that other people can read. If it is exposed, replace it in YouTube Studio before relying on the channel again.
For an always-on channel, also decide whether your source is a single file or a playlist. FFmpeg can read a file, but looping and reconnect behaviour are separate concerns from bitrate and keyframes. If your source is a pre-recorded programme, compare the operational implications with this guide to looping a video on YouTube Live, especially if the file must continue after it reaches the end.
Set CBR bitrate for the stream format
YouTube's recommended H.264 video bitrates are format-specific. The following figures are platform recommendations, not measurements of what every connection can sustain.
| H.264 format | YouTube-recommended video bitrate | Two-second GOP at the listed frame rate |
|---|---|---|
| 2160p60 | 50 Mbps | 120 frames |
| 2160p30 | 42 Mbps | 60 frames |
| 1440p60 | 34 Mbps | 120 frames |
| 1440p30 | 21 Mbps | 60 frames |
| 1080p60 | 17 Mbps | 120 frames |
| 1080p30 | 14 Mbps | 60 frames |
| 720p60 | 8 Mbps | 120 frames |
| 720p30 | 8 Mbps | 60 frames |
| 480p30 | 4 Mbps | 60 frames |
| 360p30 | 4 Mbps | 60 frames |
These values are the recommended H.264 rates listed by YouTube Help in September 2026. YouTube also lists separate minimums, so do not treat a recommended value as a hard minimum. For example, its table lists 6 Mbps as the H.264 minimum and 17 Mbps as the recommended rate for 1080p60.
Codec selection matters. For 1080p60, YouTube lists 12 Mbps as the recommended rate for AV1 or H.265 and 17 Mbps for H.264. For 1080p30, it lists 10 Mbps for AV1 or H.265 and 14 Mbps for H.264, as listed on YouTube Help in September 2026. Do not copy the H.264 number into an H.265 or AV1 command without checking the table for that mode.
In FFmpeg, a simple CBR-oriented x264 setup pins the target, minimum, and maximum video rates to the same value. It also supplies a buffer size. Those flags express the intended rate-control behaviour to the encoder, but the encoder still has its own implementation details.
For the 1080p30 example, use:
-b:v 14M -minrate 14M -maxrate 14M -bufsize 28M
The input connection must sustain the outgoing stream, including audio and protocol overhead. A fast speed test is useful, but it is not a substitute for a real test with the chosen resolution, frame rate, and motion. If the connection cannot sustain the selected format, reduce the resolution, frame rate, or bitrate. Increasing the target bitrate does not repair a weak uplink.
Audio is part of the stream even though it is not included in the video bitrate figure. YouTube's recommended advanced settings list stereo AAC at 128 kbps and 44.1 kHz, as listed on YouTube Help in September 2026. A still image with background music may use little video data at some moments, but the configured rate-control target still needs to be planned for the complete output rather than only the quiet sections.
Set a two-second GOP
A GOP is the group of pictures between keyframes. A keyframe, also called an intra frame, can be decoded without depending on earlier pictures. The frames between keyframes usually store changes from other frames, so the keyframe interval affects seeking, recovery, and how quickly a receiver can begin decoding a usable picture.
YouTube recommends a keyframe every two seconds and says not to exceed four seconds, as listed on YouTube Help in September 2026. Two seconds is the useful target for this setup. The calculation is simple:
GOP frames = frame rate × keyframe interval in seconds
At 30 frames per second, two seconds is 60 frames. At 60 frames per second, it is 120 frames. If you deliberately use 25 fps, the equivalent value is 50 frames. The number must follow the actual encoded frame rate, not the frame rate written in a production note.
For x264, the relevant starting options are:
-g 60 -keyint_min 60 -sc_threshold 0
-g 60 requests a maximum GOP size of 60 frames. -keyint_min 60 sets the minimum keyframe distance for encoders that honour that option, while -sc_threshold 0 prevents scene-change detection from introducing shorter GOPs in this example. That can make cadence easier to inspect, but it does not turn every encoder into x264.
Some encoders expose different names or interpret options differently. Hardware encoders may have their own keyframe, forced-IDR, or fixed-GOP controls. A build may also lack the encoder named in an example. Check the local encoder help before assuming that an option is available:
ffmpeg -h encoder=libx264
The FFmpeg codec documentation explains the general bitrate and GOP options, but the selected encoder's help is the more useful final check. If the encoder ignores an option, FFmpeg may still start while producing a cadence different from the one you intended.
An open GOP is a separate concern. YouTube's stream diagnostics can report an open GOP, and the health checks may also report that the GOP is too long. If the incoming stream produces those warnings, inspect the encoder's keyframe and open-GOP controls rather than changing the bitrate first.
Build the FFmpeg command
Here is an illustrative H.264 1080p30 command for a local file named INPUT. It has not been run as part of this guide, so you must adapt the input, encoder, output URL, and available hardware.
ffmpeg -re -i INPUT \\
-c:v libx264 -preset veryfast -tune zerolatency \\
-b:v 14M -minrate 14M -maxrate 14M -bufsize 28M \\
-g 60 -keyint_min 60 -sc_threshold 0 \\
-pix_fmt yuv420p \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "rtmps://INGEST_URL/STREAM_KEY"
Replace INPUT with the source file, INGEST_URL with the address supplied by YouTube, and STREAM_KEY with the protected key. The line breaks use a shell continuation character. On Windows Command Prompt, you may need to place the command on one line or use the shell's own continuation syntax.
The -re option asks FFmpeg to read a file at approximately its native playback rate instead of sending the file as quickly as the machine can process it. It is normally appropriate for a pre-recorded live source. It does not fix an input whose timestamps are already broken, and it does not by itself create a loop.
The libx264 setting is a choice, not a requirement. veryfast trades some compression efficiency for lower CPU demand, while zerolatency changes buffering behaviour. A slower preset may produce a different picture at the same target bitrate but can place more load on the processor. If the CPU cannot encode the selected format in real time, a theoretically correct bitrate and GOP configuration will not rescue the broadcast.
For 60 fps, change the GOP options to -g 120 -keyint_min 120, and choose the bitrate for the selected resolution and codec. A 1080p60 H.264 example would therefore start from 17 Mbps video, not the 14 Mbps 1080p30 value. Keep the output frame rate explicit if the input might vary, and confirm the resulting stream rather than assuming that the source metadata was preserved.
If libx264 is not present, list the encoders available in your build and inspect the one you intend to use. Hardware encoding can be preferable when CPU headroom is limited, but compare actual image quality, load, latency, and access to CBR and GOP controls. Do not assume that an option accepted by libx264 has the same effect on a hardware encoder.
Use RTMPS and protect the stream key
RTMPS is the practical starting protocol for this YouTube workflow. The address should come from YouTube Live Control Room rather than from a copied example, because the ingest address and stream key belong to the channel and selected configuration. YouTube's API documentation identifies RTMP, including RTMPS, as an ingest type and documents the live stream resource separately at Google for Developers.
Keep the key out of version control and avoid putting it in a public process listing where possible. A command line can be visible to other users on the same machine, depending on the operating system. A private environment variable or protected configuration file may be more suitable, but it still needs correct permissions and careful handling.
The protocol does not compensate for a failing source or an unstable host. If FFmpeg exits, the YouTube broadcast may stop receiving data. For an unattended channel, you need a tested restart strategy and monitoring, not only a command that worked once during the afternoon. If your priority is removing the need to leave a personal computer running, StreamNeo removes the repeated task of keeping the file and stream process alive locally: you upload the file, provide the YouTube key, and the broadcast runs with automatic monitoring and restart.
If you are keeping FFmpeg on your own machine, write down what happens when the input ends, the network drops, or the host reboots. A long-running channel can also develop timestamp and audio drift. The guide to audio out of sync on long streams covers symptoms that bitrate flags cannot solve.
Test representative audio and motion
Do not validate the stream with only a still image and silence. YouTube Help says tests should include audio and movement similar to the real broadcast, as listed on YouTube Help in September 2026. A devotional channel should test the vocal and instrumental balance it will actually use. A news loop should include its captions, transitions, and moving footage. A study channel should test both quiet sections and any animated timer or screen recording.
Run the test long enough to expose the conditions you care about. Watch the FFmpeg console for encoding speed, dropped frames, input warnings, and connection errors. The output should remain close to real time. If the encoder falls behind, the process may accumulate delay or fail to deliver the intended cadence.
Check these items during the test:
- The output resolution and frame rate match the selected YouTube settings.
- Audio is present, remains intelligible, and stays aligned with the picture.
- Motion does not cause sustained upload problems.
- The process does not consume all CPU, GPU, memory, or disk bandwidth.
- The stream continues when the source reaches a transition or loop point.
- YouTube receives the stream at the expected video and audio rates.
A short test that passes on a quiet office network may not represent an overnight broadcast. Test at the location and time where the channel will normally run, if possible. Wired Ethernet can be a useful troubleshooting choice for compatible equipment, but it is not an FFmpeg requirement.
If the stream keeps stopping, work through the input, encoder, network, and YouTube output separately. The FFmpeg YouTube stream troubleshooting guide is useful once you have captured the actual console error rather than guessing from the visible symptom.
Check YouTube stream health
YouTube Live Control Room reports whether the incoming stream is healthy and can identify problems that are not obvious from the local FFmpeg window. Check the health panel during the test and again after changing one setting at a time.
Relevant warnings include low or high bitrate, keyframes arriving too far apart, an open GOP, missing audio, missing video, and an unsupported video codec. The YouTube Live Streaming API documentation describes health-related fields such as gopSizeLong, gopSizeOver, openGop, and bitrateLow in its live stream documentation.
Use the warning to choose the next diagnostic step:
| YouTube observation | First thing to inspect |
|---|---|
| Bitrate low | Upload capacity, encoder output rate, and whether the process is keeping up |
| Bitrate high | The selected -b:v, -minrate, and -maxrate values |
| GOP too long | Actual frame rate, -g, encoder support, and keyframe mode |
| Open GOP | Encoder-specific closed-GOP or IDR settings |
| Missing audio | Input mapping, AAC availability, and audio timestamps |
| Unsupported codec | The selected encoder, pixel format, and YouTube's current codec table |
A warning can be caused by more than one setting. For example, a CPU-bound encoder may fail to maintain the intended frame rate, which then makes the measured keyframe cadence and bitrate look wrong. Change one variable, run another representative test, and record what changed.
Do not treat a green health indicator as a promise about the rest of the night. It describes what YouTube is receiving at that point. Keep local logs, check the source at transitions, and decide how you will notice a stopped process when nobody is watching the computer.
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 YouTube Live?
Start with YouTube's published recommendation for your codec, resolution, and frame rate. For H.264, the listed recommendations include 14 Mbps for 1080p30 and 17 Mbps for 1080p60, as listed on YouTube Help in September 2026. Reduce the format or bitrate if the available connection cannot sustain it reliably.
What should -g be for a two-second keyframe interval?
Multiply the encoded frame rate by two. Use -g 60 at 30 fps and -g 120 at 60 fps, provided the selected encoder honours the option. Confirm the result in YouTube's stream health information because encoder behaviour differs between implementations and FFmpeg builds.
Does setting -g 60 guarantee two-second keyframes?
No. It requests a GOP size for encoders that support and honour the standard option. Scene-change handling, open-GOP settings, hardware encoder controls, timestamps, and the installed build can affect the actual result, so test the incoming stream.
Can I use a different encoder from libx264?
Yes, if it is available in your FFmpeg build and supports the controls you need. Check that encoder's local help and compare its CPU or GPU load, latency, image quality at the selected bitrate, and CBR and GOP behaviour before using it for an unattended channel.