For an ordinary SDR 1080p30 source, a sensible FFmpeg starting point is H.264 video at YouTube’s recommended 14 Mbps, AAC stereo audio at 128 kbps and 44.1 kHz, with a two-second keyframe interval. Use RTMPS where available, pace file input in real time, and leave upload capacity above the stream’s target bitrate.
Those settings are not universal and they cannot make every setup interruption-proof. Your source resolution, frame rate, encoder, sustained upload capacity, shared network and intended run length all affect the right configuration, so treat the command below as an auditable starting point rather than a guarantee.
Confirm the source and YouTube requirements
Start by identifying what FFmpeg is actually going to send. A 1080p30 file, a 1080p60 game capture, a 720p devotional loop and a live camera feed do not have the same requirements. Bitrate and GOP values must follow the output you intend to publish, not simply the strongest settings your computer can produce.
For H.264, YouTube’s current encoder guidance lists 14 Mbps for 1080p30, 17 Mbps for 1080p60, and 8 Mbps for both 720p30 and 720p60. These are YouTube recommendations, not independent performance benchmarks, and they should be checked against the current YouTube encoder settings and bitrate table before you configure a long-running channel.
| Intended H.264 output | YouTube recommended video bitrate | Initial GOP calculation at two seconds |
|---|---|---|
| 720p30 | 8 Mbps | 60 frames |
| 720p60 | 8 Mbps | 120 frames |
| 1080p30 | 14 Mbps | 60 frames |
| 1080p60 | 17 Mbps | 120 frames |
The table is useful for choosing a starting point, but it does not mean that a 1080p30 recommendation can be transferred to another resolution, frame rate or codec. YouTube also lists HEVC and AV1 for some ingest workflows, while the example in this article uses H.264 because it is a broadly understood FFmpeg path. If you change codec or use HDR, check the current YouTube guidance rather than copying the H.264 example unchanged.
Inspect the file before broadcasting. The important details include width, height, frame rate, pixel format, scan type and audio layout. A file described as 30 fps may contain a variable frame rate, and an input with unusual audio sampling or interlacing may need conversion before it becomes a predictable live output.
For a file-based channel, also decide whether the video is meant to run once, loop, or feed a longer playlist. A single input ending will end the FFmpeg process unless you build a loop or another form of input handling around it. Streaming settings cannot keep an input alive after the file has finished.
If your material is a set of old talks or presentations, first check whether re-broadcasting old webinars as an always-on lead channel fits the content and rights you hold. For a music, prayer or ambience station, the same principle applies: make the source and its audio characteristics clear before selecting a bitrate.
Use RTMPS where available
RTMPS is the practical transport choice for the illustrative command because YouTube recommends it where available. It sends the stream through an encrypted connection and uses the ingest address supplied in YouTube Live Control Room. Do not type a guessed server address into a script and assume it is still correct.
Create or open the live stream in YouTube, copy the ingest URL and paste the stream key into your command or secret store. A stream key should be treated like a password. Avoid publishing it in a screenshot, committing it to a public repository or placing it in a shared document that does not need access.
The basic output shape is:
ffmpeg -re -i input.mp4 \
-c:v libx264 -preset veryfast -b:v 14M -maxrate 14M -bufsize 28M \
-pix_fmt yuv420p -g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 128k -ar 44100 -ac 2 \
-f flv "rtmps://YOUTUBE_INGEST_URL/YOUR_STREAM_KEY"
This is an output-option sketch, not a tested command for every computer or FFmpeg build. Replace both placeholders with values from YouTube Live Control Room, confirm that your build includes libx264, and check that the selected protocol is supported by the installed FFmpeg version.
The -f flv output format is commonly used for RTMP-family publishing. It does not mean that your source file must be an FLV file. FFmpeg decodes the input, applies the selected video and audio encoders, and sends the resulting live output through the chosen transport.
RTMPS also has practical limits. It is still dependent on the local connection, upstream route and YouTube ingest availability. Choosing RTMPS does not replace a network test, and it does not recover a failed process or a revoked stream key.
Set H.264 and constant bitrate deliberately
YouTube’s guidance calls for constant bitrate, commonly abbreviated as CBR. In FFmpeg, however, setting -b:v 14M alone is not the same as proving that the encoder will behave as strict CBR in every scene. Target bitrate, maximum bitrate, buffer size and encoder-specific rate-control settings interact, so inspect the selected encoder’s behaviour.
In the example, -b:v 14M sets the intended video bitrate for the 1080p30 starting point. -maxrate 14M limits the stated peak rate, while -bufsize 28M supplies an illustrative rate-control buffer. The buffer value is not presented as a YouTube requirement. A different encoder, hardware implementation or FFmpeg build may interpret these options differently.
The -preset veryfast option is also not a universal answer. With libx264, slower presets generally give the encoder more time to make compression decisions, while faster presets reduce CPU work and may require more bitrate for a similar picture. For a continuous channel, a preset that your machine can sustain matters more than a preset that looks attractive on paper.
Run a representative test with the same resolution, frame rate, overlays and motion that the real channel will use. A mostly still temple image can be easy to encode, while a moving background, scrolling news panel or busy music visualiser can create much more work. Watch CPU use, encoding lag and dropped frames rather than judging only by whether the command starts.
Upload capacity needs its own margin. YouTube’s streaming tips recommend leaving 20% headroom above the total outgoing stream bitrate. At a 14 Mbps video setting, you still need room for audio and for variation in the connection, so a connection advertised with a matching number is not a comfortable basis for an unattended stream. Shared Wi-Fi, other household users, cloud backups and mobile-network variation can reduce the capacity available to FFmpeg.
Measure sustained upload performance at the location where the encoder will run. Advertised download speed is not a substitute for upload testing. If the connection cannot hold the selected output with the recommended headroom, reduce the output configuration or move the encoder to a more suitable connection rather than hoping a short speed test will cover a full night.
For a comparison of the other costs around a long-running file stream, see cloud service pricing for 24/7 prerecorded streaming. The relevant question is not only the headline bitrate, but also whether the chosen method leaves you with a manageable operating process.
Use a two-second keyframe interval
YouTube recommends a keyframe frequency of two seconds and says not to exceed four seconds. A keyframe, or I-frame, is a frame that can be decoded without depending on preceding frames. The interval affects how quickly a viewer or downstream process can begin decoding a new section of the stream.
At 30 frames per second, two seconds corresponds to 60 frames, which is why the example uses -g 60. -keyint_min 60 sets the minimum interval for the illustrative x264 configuration, while -sc_threshold 0 discourages scene changes from creating a different keyframe pattern. These options are encoder-specific controls, so confirm the actual behaviour of the encoder you select.
A two-second GOP is not a promise that every output will contain precisely identical keyframe spacing. Frame rate conversion, variable-frame-rate input, scene-change logic and hardware encoder settings can affect the result. The useful practice is to choose a fixed output frame rate, set the encoder’s keyframe controls explicitly and inspect the resulting stream during testing.
Do not lengthen the GOP simply because it reduces the frequency of keyframes. Longer intervals can make joining and recovery less convenient, and YouTube’s stated ceiling still applies to the ingest guidance. Do not copy -g 60 to a 60 fps output either: at two seconds, the initial calculation is 120 frames.
If the source is already a clean 30 fps progressive file, preserving that frame rate is usually simpler than converting it without a reason. If it is 60 fps, either publish it as 60 fps using the matching YouTube recommendation or deliberately convert it to 30 fps after considering motion and encoder load.
Set AAC stereo audio
The example encodes audio as AAC stereo with -b:a 128k -ar 44100 -ac 2. YouTube’s guidance recommends 128 kbps stereo audio at 44.1 kHz. This is a practical starting point for a devotional loop, spoken programme, study channel or ambience stream where two-channel audio is enough.
The audio settings must match the material. If your source is mono speech, creating a stereo output does not add information, but it can provide the expected two-channel delivery format. If the source contains 5.1 audio, do not silently treat the stereo command as a surround workflow. YouTube’s guidance has separate audio recommendations for 5.1 and notes that AAC is required for 5.1 over RTMP or RTMPS.
Check for clipping before going live. A file can have acceptable video settings and still produce a tiring broadcast if the audio is distorted, too quiet or interrupted by unexpected channel changes. Listen to a representative section that includes speech, music and the quietest material in the intended programme.
A live capture may also carry microphone noise, room echo or inconsistent levels. FFmpeg can filter audio, but filtering adds another configuration layer that should be tested separately. Do not add filters merely because a command on the internet includes them. First establish a stable encode with the audio you actually need.
Sampling rate conversion is another reason to inspect the input. The command explicitly requests 44.1 kHz, so FFmpeg will produce that output even if the source uses another rate. That can be appropriate for the YouTube target, but it should be included in your test rather than assumed harmless for every source.
For a file-based audio channel, the input can be just as important as the encoder. The guide on streaming podcast MP3 files to YouTube Live using FFmpeg in India is relevant when your source is primarily spoken audio rather than a finished video programme.
Match frame rate, GOP and input pacing
The command’s -g 60 only makes sense alongside a 30 fps output. Keep the frame rate, GOP calculation and source conversion aligned. If you output at 25 fps, a two-second initial GOP calculation would be 50 frames. If you output at 60 fps, it would be 120 frames.
You can make the output frame rate explicit when needed, but do not add a conversion without understanding its effect. A file with a stable native frame rate may not need one. A mixed playlist may need normalisation so that the encoder does not repeatedly switch timing characteristics between items.
The -re option has a specific purpose here. With a file input, it asks FFmpeg to read the file at approximately its native playback rate instead of sending it as quickly as the computer can decode it. Without real-time pacing, a prerecorded file can be delivered too quickly and the broadcast will not behave like a live programme.
Do not automatically apply -re to a real-time capture device. A camera, screen capture or other live input is already producing data in real time, and unnecessary pacing can create the wrong behaviour. FFmpeg’s command-line documentation explains the option and its relationship to input handling.
A looping file needs separate logic from pacing. You may use a loop-capable input arrangement or an external process that starts the next item, but whichever method you choose must handle the transition. Test the point where one file ends, because an otherwise stable encoder can still stop when its input reaches end-of-file.
For longer unattended operation, FFmpeg’s full documentation includes an RTMP FIFO example with recovery options such as -attempt_recovery 1 and -recovery_wait_time 1. These options attempt recovery from certain temporary output failures; they do not guarantee recovery from every network outage, input failure, process crash, credential problem or YouTube interruption. Pair recovery attempts with logs, process supervision and an alert that somebody will actually see.
Test the output and monitor the live stream
Do not use the first overnight run as your test. Start with a private or unlisted broadcast and include the real file, audio, overlays, output resolution and network path. Confirm that YouTube receives the stream, that the picture is not being unexpectedly scaled, and that the audio remains present after the initial connection.
YouTube’s live control room reports stream health and messages that can help separate an encoding problem from a network problem. Monitor those messages during the test instead of relying only on FFmpeg’s terminal output. A command can continue running while the picture is delayed, frames are being dropped or the available upload rate is insufficient.
Keep a record of what you changed. Note the input file, output resolution, frame rate, encoder, bitrate, preset, audio settings and observed warnings. An auditable preset makes troubleshooting possible: if a problem appears after changing the file or connection, you can identify which variable moved.
Check the encoder side as well. Look for sustained encoding lag, dropped frames, increasing queues, CPU or hardware-encoder saturation, and errors around reconnects. If the machine falls behind, changing the keyframe interval will not necessarily solve it. You may need a faster preset, a lower output resolution, a different encoder, fewer overlays or a separate encoding machine.
Check the network side separately. YouTube recommends 20% upload headroom, but a single speed test does not describe a shared connection over many hours. A wired connection can remove one source of wireless variation when the computer and network equipment support it, but a cable cannot create upstream capacity that the internet connection does not provide.
Plan for the end of the input and the end of the archive. YouTube says streams under 12 hours are automatically archived in its encoder setup guidance. That statement describes automatic archiving behaviour; it should not be treated as a general maximum live-duration rule. If preserving an archive matters for a longer run, keep a separate local recording or check YouTube’s current archive requirements before relying on the live replay.
When the main difficulty is keeping a file running after your own computer is switched off, StreamNeo removes the need to leave FFmpeg running locally: upload the video, provide the YouTube stream key, and the cloud broadcast can be monitored and restarted automatically if it drops. It remains your responsibility to check the source, rights, stream settings and current YouTube requirements.
Choose the operating method around the real constraint
FFmpeg is a good fit when you want direct control over the command, already have a machine that can encode continuously, and are comfortable reading logs. It is also useful when you need a repeatable script for a known input format. The trade-off is that you own the process supervision, machine power, network path, reconnect behaviour and alerting.
A local computer is not automatically the cheapest or simplest option for a 24/7 channel. It must remain powered, avoid sleep or updates at inconvenient times, sustain the encoder load and remain connected to the internet. If the channel is important overnight, test what happens after a router restart, a brief connection loss and an unexpected FFmpeg exit.
A cloud workflow can reduce the need to keep your own computer on, but it does not remove the need to prepare a valid source or verify YouTube’s ingest requirements. Compare the operating method against your actual constraint: encoder capacity, sustained upload, local power reliability, need for logs, playlist behaviour, latency and archive expectations.
If you are comparing FFmpeg with a graphical setup, the best OBS settings for a 24/7 YouTube live stream covers the same broad decisions through OBS controls rather than a command line. Neither tool is universally better. The right choice is the one you can test, supervise and repair when the channel behaves differently from the plan.
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
Is 14 Mbps always the best FFmpeg bitrate for YouTube?
No. It is YouTube’s recommended H.264 video bitrate for an SDR 1080p30 starting point, not a universal value. Change it when the resolution, frame rate or ingest codec changes, and make sure the connection can sustain the total output with YouTube’s recommended headroom.
Should I use -re for every FFmpeg live stream?
Use -re for a file input that must be played at its normal rate. Do not add it automatically to a real-time camera or capture input, because that input is already arriving in real time.
Does a two-second GOP prevent interruptions?
No. Two seconds is YouTube’s recommended keyframe frequency, and -g 60 is the corresponding starting calculation for 30 fps. It does not protect against network loss, encoder overload, process failure, input problems or platform interruptions.
Can I leave a YouTube live stream running indefinitely?
Do not infer a general maximum duration from the archive guidance. YouTube documents automatic archiving for streams under 12 hours, but a longer run has separate archive considerations, so check the current official guidance and keep a separate recording if the archive is important.