For continuous YouTube streaming with FFmpeg, encode the outgoing live feed to YouTube’s current ingest settings rather than treating the job like an ordinary video export. For a 1080p30 live stream, YouTube’s published recommendation is 14 Mbps with H.264 or 10 Mbps with H.265/HEVC or AV1.
Those figures apply to the live ingest stream, not to a prerecorded loop file. YouTube does not publish a separate bitrate table for prerecorded loops or 24/7 broadcasts, so you should choose the live profile for your resolution, frame rate and codec, then test the complete route before leaving it unattended.
Start with the live-ingest profile
A continuous stream has three separate jobs. FFmpeg must read the source at real time, encode the outgoing video in a format YouTube accepts, and publish that feed through a connection that can remain healthy for as long as the broadcast runs. Looping the file solves only the first part.
YouTube’s current encoder guidance supports RTMP or RTMPS, H.264, H.265/HEVC or AV1 video, AAC or MP3 audio, and frame rates up to 60 fps. YouTube recommends RTMPS when it is available. The stream URL and stream key should come from the live event in YouTube Studio’s Live Control Room, rather than from a copied example.
Treat the stream key as a password. Do not place a real key in a public script, screenshot, tutorial or shared log. If it is exposed, reset it in YouTube Studio before starting the next broadcast. You can review YouTube’s current requirements in YouTube’s encoder settings and bitrates guidance.
For a normal SDR stream, YouTube’s advanced recommendations include progressive scan, square pixels, Rec. 709 and 8-bit video. Its guidance also recommends constant bitrate encoding and a keyframe every two seconds, with the interval not exceeding four seconds. These settings describe what FFmpeg sends to YouTube. They are not instructions for how to store your source file.
Bitrate recommendations by codec
The relevant decision is not simply “1080p needs this bitrate”. The codec is part of the decision. YouTube’s published table gives different recommended values for H.264 and for H.265/HEVC or AV1.
| Live output | Codec | Published minimum | Published recommendation |
|---|---|---|---|
| 1080p30 | H.264 | 5 Mbps | 14 Mbps |
| 1080p30 | H.265/HEVC or AV1 | 4 Mbps | 10 Mbps |
| 1080p60 | H.264 | 6 Mbps | 17 Mbps |
| 1080p60 | H.265/HEVC or AV1 | 4 Mbps | 12 Mbps |
| 720p30 | H.264 | 3 Mbps | 8 Mbps |
These are YouTube’s live-encoder figures, not upload-file recommendations and not a special table for 24/7 loops. A recommendation is also not a guarantee that every source, encoder or network route will look the same. A devotional video with a static background may appear clean at a lower rate than a local news loop with camera movement, scrolling text and frequent scene changes, but the platform’s published target remains the sensible starting point.
For 1080p30 H.264, use 14 Mbps when your encoder and upload connection can sustain it. For 1080p30 H.265/HEVC or AV1, use 10 Mbps when your FFmpeg build, hardware and YouTube ingest path support that choice. If you select H.264 because it is easier to encode or troubleshoot, do not keep the H.265 or AV1 bitrate simply because both options have the same resolution.
YouTube’s table also lists 1080p60 at 17 Mbps for H.264 and 12 Mbps for H.265/HEVC or AV1. A 60 fps output is not automatically better for a still image, a bhajan visualiser or a study timer. It produces more frames to encode and publish, so choose it when the source contains motion that benefits from the higher frame rate.
Resolution and frame rate change the target
Resolution determines how many pixels are sent in each frame. Frame rate determines how many frames are sent each second. Raising either one generally increases the amount of information the encoder must represent, although the actual result also depends on movement, texture, text and the codec.
A practical choice is to match the live output to the programme rather than the largest setting your source happens to offer. A 720p30 output may be adequate for a static radio-style visual and requires less upload capacity than 1080p30. A 1080p30 output is more suitable when small text, product detail or a presenter’s face must remain clear. A 1080p60 output has a larger published target and needs more processing and network headroom.
Set the frame rate explicitly when it matters. The keyframe interval is measured in frames by FFmpeg, so -g 60 represents two seconds only when the output is 30 fps. At 60 fps, two seconds is 120 frames. If you leave the frame rate to an input that does not match your assumption, a keyframe setting that looks correct in the command may not create the interval you intended.
You should also consider the source’s native characteristics. Converting a 24 fps film to 60 fps does not create new motion detail. It can increase work and produce repeated or interpolated frames, depending on the filter chain. Similarly, scaling a low-resolution source to 1080p does not restore detail. It only makes the output canvas larger.
For a deeper capacity comparison, see the practical discussion of upload speed for 4K and 60fps YouTube Live in India. The same principle applies at lower resolutions: measure outbound capacity, then choose the profile that leaves room for ordinary network variation.
A working FFmpeg template
The following is a starting template for a local file that should loop continuously into a 1080p30 H.264 live event. It uses a 14 Mbps video target, matching YouTube’s published 1080p30 H.264 recommendation.
ffmpeg -re -stream_loop -1 -i "input.mp4" \\
-c:v libx264 -preset veryfast -b:v 14M -maxrate 14M -bufsize 28M \\
-r 30 -g 60 -keyint_min 60 -sc_threshold 0 \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "rtmps://YOUTUBE_STREAM_URL/STREAM_KEY"
This is a template, not a command that can be assumed to work unchanged for every file or FFmpeg build. Replace the input path and the destination with the values from your own setup. Use the exact RTMPS destination shown by YouTube’s Live Control Room, and never publish a real stream key in an example.
The input-side options matter. -re asks FFmpeg to read at the source’s native rate instead of sending the file as quickly as the computer can process it. -stream_loop -1 tells FFmpeg to loop the input indefinitely. It does not restart a failed process, repair a broken connection, renew a YouTube event or prove that the source file can be read forever.
The output-side options select the live encoding profile. -c:v libx264 uses the software H.264 encoder included in many FFmpeg builds. -b:v, -maxrate and -bufsize establish a constant-bitrate style target. -r 30 makes the intended output frame rate explicit, while -g 60 and -keyint_min 60 set a two-second keyframe interval at 30 fps. -sc_threshold 0 prevents scene-change logic from moving keyframes away from the fixed cadence in this example.
Your available encoder may use a different H.264 implementation, or your machine may not have enough processing capacity for the selected preset and resolution. Watch CPU usage, encoder warnings and the YouTube preview during a representative test. A command that starts successfully can still fall behind after several minutes if the computer cannot encode in real time.
For H.265/HEVC or AV1, replace the video encoder and use the target selected from YouTube’s current table. The encoder name depends on your FFmpeg build and hardware. Do not copy an encoder name from a different computer without checking it with your installed build, for example by reviewing the output of ffmpeg -encoders.
Why the source-file bitrate is separate
A local MP4 and a live output are different things. The file may have been encoded with variable bitrate, a long keyframe interval, a codec YouTube does not accept for your intended route, or a frame rate that does not match the live event. FFmpeg can decode that file, loop it and create a new live feed with the required output settings.
If the source is already compatible, stream copying may reduce CPU use. In FFmpeg, -c copy avoids re-encoding. It also means that FFmpeg cannot change the video’s resolution, frame rate, bitrate, keyframe cadence or codec details. If any of those properties do not suit the YouTube ingest profile, copying is the wrong tool.
For example, a high-bitrate 1080p file does not automatically produce a correctly configured live stream. Its bitrate may vary considerably, and its keyframes may be several seconds apart. Conversely, a low-bitrate source cannot gain real detail simply because you encode the outgoing feed at 14 Mbps. The new stream can meet the transport target while still showing the limitations of the original material.
Inspect the source before choosing the command. Useful properties include width and height, frame rate, pixel format, audio sample rate, audio channel layout and codec. You can use ffprobe, which is distributed with FFmpeg, to examine a file without re-encoding it. Check the output rather than assuming that a filename or export preset tells the complete story.
For a loop-specific planning guide, see how to loop videos in a 24/7 YouTube livestream. The important distinction here is that looping controls how the programme repeats, while the output encoder controls what YouTube receives.
Audio, HDR and playback formats
The example uses AAC at 128 kbps and 44.1 kHz for stereo, matching YouTube’s advanced recommendations for that arrangement. YouTube also supports MP3 audio. If your source has silence, music or speech, listen to a test playback rather than judging the audio only from FFmpeg’s successful connection message.
If you need 5.1 audio, check the current YouTube guidance carefully. Its advanced recommendations support 5.1 with AAC for RTMP and RTMPS, with 48 kHz and 384 kbps recommended. Do not add multichannel settings to a stereo programme simply because the source file contains several tracks.
HDR requires a separate check. YouTube’s guidance recommends H.265 for HDR and states that AV1 is not supported for HDR. If your channel is SDR, Rec. 709 and 8-bit output are the simpler baseline. If your source is HDR, confirm the colour metadata, codec support and event requirements before selecting the command.
The live feed YouTube receives is not the only version viewers may watch. YouTube transcodes the incoming stream into playback versions for different devices and connections. Your FFmpeg process therefore does not need to create a separate 720p, mobile or low-bandwidth version for every viewer. It does need to send a valid, stable source feed at the selected ingest profile.
That transcoding step does not remove the need for a sensible input. Excessive compression, clipped audio, incorrect colour metadata or a frame rate conversion can still be visible after YouTube creates its playback versions. The platform can adapt delivery, but it cannot recover detail that was never present in the source.
Bandwidth and long-running stability
Calculate the total outbound requirement before starting. Include the video bitrate, audio bitrate and protocol overhead, then leave roughly 20 per cent headroom above the total streaming bitrate, following YouTube’s streaming tips. Use upload capacity, not download speed, as the decision point.
At a 14 Mbps video target, the connection must carry more than the video number alone. Audio and transport overhead still need room, and other users or applications may consume upload capacity. A shared office connection, home Wi-Fi activity, cloud backup or security camera can turn a stream that looked adequate during a quiet test into an unstable overnight broadcast.
Prefer a stable wired connection where practical. Test the actual computer, network path and destination rather than relying on a general speed-test result from another device. YouTube notes that a connectivity disruption can interrupt a live stream, so a large nominal speed does not by itself establish continuity.
Before making the event public, start FFmpeg early and check YouTube’s preview and stream-health messages. Use a representative section of the programme containing the motion, text and audio that viewers will actually receive. Watch for dropped frames, encoding lag, audio drift, reconnect messages and CPU pressure.
A single ffmpeg command is not an unattended operations plan. If the process exits, the source becomes unreadable, the computer restarts or the network drops, -stream_loop -1 cannot resolve the problem. A supervisor or restart policy, alerting and a deliberate recovery procedure belong outside the example command and depend on your operating system and deployment.
For a channel that should run while your computer is switched off, the operational problem is different from choosing the FFmpeg flags. StreamNeo removes the need to keep a local FFmpeg process and home connection running for an uploaded video, while still leaving you responsible for the programme, YouTube event and channel requirements.
If you configure a backup encoder, test it deliberately. YouTube’s guidance describes testing by stopping the primary encoder or disconnecting its Ethernet connection. That validates the configured arrangement; it does not prove that one FFmpeg process will reconnect or recover automatically after every failure.
A practical test sequence
First, prepare the YouTube event and copy its current stream URL and key into a protected local configuration. Do not hard-code the key into a script that will be committed to a repository or shared with a contractor. Confirm that the selected event uses the resolution, frame rate and latency choices you actually intend to test.
Next, inspect the source and decide whether it needs scaling, frame-rate conversion, audio conversion or full video re-encoding. Choose the codec and bitrate from YouTube’s live-ingest guidance. For 1080p30, that means 14 Mbps for H.264 or 10 Mbps for H.265/HEVC or AV1, subject to encoder support and available upload capacity.
Then run a representative section with -re and the loop option. Check that the output is real time, the keyframe cadence matches the frame rate, the audio remains synchronised and the machine has processing room. If the source has an unusually demanding scene, include it in the test rather than testing only a static opening screen.
Open the YouTube preview and inspect the actual playback on the channel or watch page. YouTube’s own advice is simple: test before starting the live stream. Treat this as a required stage, not as a check to perform only after viewers report a problem.
Finally, write down what happens when the process, network or computer stops. Decide who receives an alert, how the stream is restarted and how you will confirm that the event is live again. If the channel matters overnight, test the recovery method during a planned window instead of discovering its limitations after a failure.
For a broader operational example, the guide to setting up a 24/7 YouTube product demo stream in India is useful when the encoding decision is only one part of the channel 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
Does -stream_loop -1 make an FFmpeg stream outage-proof?
No. It loops the input when FFmpeg is still running and can still read the file. It does not repair a failed network connection, restart an exited process, recover a computer or resolve a YouTube event problem.
What bitrate should I use for 1080p30?
Use YouTube’s live-ingest recommendation for the codec you selected: 14 Mbps for H.264, or 10 Mbps for H.265/HEVC or AV1. These figures are for the outgoing live feed, not for the bitrate of a prerecorded loop file.
Do I need to encode separate versions for viewers?
No. YouTube transcodes the live feed into playback versions for viewers and devices. Your responsibility is to send a stable, valid ingest stream; the source should still have suitable detail, colour and audio because transcoding cannot restore missing information.
Will stream copy always use less CPU?
It avoids video re-encoding, so it can reduce CPU use, but it also prevents you from changing properties that YouTube may require, such as codec, bitrate, frame rate and keyframe cadence. Use it only after checking that the source already meets the selected live-ingest profile.