For a 1080p24 YouTube loop, use progressive 1920×1080 video, H.264, constant bitrate, and a two-second keyframe interval. Send it over RTMPS where your FFmpeg build and YouTube ingest endpoint support it, and include AAC stereo if the source has audio.
YouTube’s published H.264 bitrate table gives figures for 1080p30, not 1080p24. Its 5 Mbps minimum and 14 Mbps recommended values are useful context only; they are not a 24 fps prescription. The command shape below is configuration guidance, not a tested command or a guarantee that every input, encoder build, or channel will work unchanged.
Set progressive 1920×1080 at 24 fps
Begin with the properties of the stream You intend to send, not with a command copied from a different source type. The target is a progressive 1920×1080 frame at 24 frames per second, with square pixels. Progressive frames are complete images rather than alternating fields, and square pixels avoid a mismatch between stored dimensions and display shape. YouTube lists progressive scan and square pixel aspect ratio among its recommended advanced settings.
A file that is already 1920×1080 at 24 fps may need little or no conversion. A 720p clip, a 25 fps source, a still image, and a sequence of numbered images need different input handling. Scaling every source by habit can waste encoding work or change composition. If the source is not 16:9, decide whether to preserve the whole picture with padding or fill the frame by cropping. Padding leaves borders; cropping removes some of the original image. Neither is universally right for a devotional artwork, a landscape loop, or a news panel.
FFmpeg’s -r option can set an output frame rate, but its position matters. In general, options apply to the next input or output, so an output frame-rate option belongs with output settings. For image2 inputs, the demuxer’s -framerate option is the relevant way to define the input timing. Consult the FFmpeg command-line documentation and the image2 demuxer documentation for the options supported by your installed version.
Check what the encoded file actually reports before sending it live. A nominal 24 fps setting does not, by itself, establish that the source timestamps, conversion filters, and encoder produced the expected cadence. This is especially worth checking after converting from a different rate or building a video from still images. The Raspberry Pi FFmpeg loop setup guide is a useful companion if your setup also needs to run without a monitor.
Choose H.264, CBR and RTMPS where supported
H.264 is a practical baseline for an FFmpeg example because it is widely supported. YouTube’s live encoder guidance also lists HEVC and AV1, but availability depends on the encoder and the ingest path you can actually use. A newer codec is not automatically a better fit if it increases encoding load or makes it harder to confirm compatibility. Start with the format you can inspect and sustain.
YouTube recommends constant bitrate (CBR) for live encoding. In FFmpeg, the exact controls depend on the selected encoder. If the encoder exposes separate target and maximum bitrate or VBV buffer controls, set them consistently for the intended rate-control mode and inspect its own documentation. Do not assume that identical-looking options behave identically across encoders, or that a command written for libx264 is suitable for a hardware encoder.
RTMPS is the straightforward secure choice when YouTube supplies an RTMPS ingest URL and your installed build supports it. YouTube describes RTMPS as a secure extension to RTMP in its live encoder settings guidance. Use the endpoint shown in Live Control Room, rather than guessing or reusing an old address. The stream key belongs in the destination URL or the method your setup uses; keep it private and do not paste it into a public log or screenshot.
Other delivery methods have different requirements. HLS, for example, is not simply another spelling for an RTMP destination: its media packaging and latency characteristics differ. For a direct FFmpeg-to-YouTube live setup, use the ingest protocol and endpoint YouTube currently provides for the stream. If you are deciding whether to keep a local computer running or use another operating arrangement, the cost of running an old gaming PC as a 24/7 YouTube server helps frame the practical trade-offs without changing the encoding requirements.
Set a two-second keyframe interval
YouTube recommends a keyframe interval of two seconds and says not to exceed four seconds. At 24 frames per second, those intervals correspond to 48 frames and 96 frames respectively. A two-second GOP is therefore a direct translation of YouTube’s timing recommendation for this frame rate, not a claim that YouTube specifies a special 24 fps preset.
For an encoder that accepts GOP length in frames, -g 48 is the central setting to examine. Some encoders expose additional options for minimum keyframe spacing, scene-cut behaviour, or open versus closed GOPs. The exact option names and effects depend on the encoder. YouTube’s API health documentation flags long keyframe intervals and open GOP configuration as potential stream problems, so verify the actual encoder behaviour rather than relying only on the presence of -g in a command.
A fixed interval matters because a live receiver benefits from regular points at which it can begin decoding. A source with a scene cut every few seconds may trigger extra keyframes if scene-cut insertion is enabled; this can make the actual spacing differ from a simple fixed-GOP expectation. For a loop with fades, slowly moving artwork, or a static information screen, inspect the encoder’s output and health messages rather than assuming the content will force the desired pattern.
If you have previously run FFmpeg with a longer GOP, change one setting at a time and observe whether the warning clears. Do not compensate for a keyframe warning by raising bitrate without checking the message: bitrate and keyframe spacing address different conditions. The YouTube Live API health descriptions identify issues such as long keyframe intervals, unsupported codecs and open GOPs.
Add AAC stereo audio when the source has audio
If your loop includes music, speech, or environmental sound, map and encode the intended audio deliberately. YouTube lists AAC or MP3 for RTMP/RTMPS audio and recommends 128 kbps for stereo, with 44.1 kHz in its advanced guidance for stereo. AAC stereo is a straightforward baseline when the source has audio, but the input stream still needs to be selected and mapped correctly.
A command that only configures video can accidentally omit audio, choose the wrong audio stream, or fail when the source has no audio track. For a still image with a separate soundtrack, specify both inputs and map the soundtrack. For a video file with embedded audio, check whether its duration and loop point match the video. If the file ends before the picture or its timestamp behaviour differs, the live output may show a discontinuity or silence at the seam.
If the channel is intended to be silent, do not add an empty audio track merely because an example contains audio options. If it needs continuous music, listen through the join between the end and beginning of the loop. A fade that sounds acceptable in an editing preview can still click or cut off when repeated. YouTube’s stream-health indicators can flag missing or starved video, but they cannot tell you whether a musical transition is pleasing or whether the content is appropriate for your channel.
For standard-definition colour handling in a 1080p SDR loop, YouTube recommends Rec. 709 and 8-bit. Avoid describing a basic SDR command as an HDR configuration. HDR needs a separately supported source and encoding path; tagging ordinary footage differently does not create HDR detail.
Treat 1080p30 bitrate figures as a proxy only
The published YouTube live encoder table has a 1080p30 H.264 row and no 1080p24 row. As listed in YouTube Help in October 2026, that 1080p30 row gives 5 Mbps minimum and 14 Mbps recommended. Those numbers describe 30 fps. They are not YouTube’s official bitrate prescription for a 24 fps stream, and this article does not convert them into one.
For a 24 fps loop, bitrate is a practical choice that depends on motion, texture, encoder quality, and the available upload capacity. Slow-moving devotional artwork or a static local news panel may behave differently from foliage, rain, confetti, or a detailed camera shot. A lower frame rate can reduce the amount of motion information compared with 30 fps, but it does not make every 24 fps scene easy to encode. Fine detail and noise can still consume bits.
If you need a starting point for a trial, treat any value you choose as your own test setting, not as an official 24 fps recommendation. Keep the video rate and encoder’s maximum rate aligned where its controls permit, and test with movement similar to the actual loop. YouTube recommends testing before a live stream and checking stream health. The relevant question is whether your sustained upload capacity can carry the chosen stream reliably, with room for normal variation, not whether a one-off speed test briefly reached that number.
Do not use a general upload-only bitrate chart as a substitute for the live encoder table. The table is guidance for YouTube Live settings, while your network test helps assess your connection. Both are useful, but they answer different questions. If the stream health panel reports low bitrate or video starvation, check actual outgoing rate and available upload capacity before changing resolution or frame rate. Raising the target rate beyond what the connection sustains can make buffering worse rather than better.
Match the loop method to the source
There is no single loop input option that fits a still image, an image sequence, and an existing video. For a single still, image2 offers input frame-rate and repeat controls; place those input options before the corresponding -i. Its documented default input frame rate is 25, so do not assume a still will automatically be timed at 24 fps. A numbered sequence uses an image pattern and needs consistent dimensions and formats across its files.
For an existing video, the FFmpeg loop filter can repeat frames; loop=-1 means repeat indefinitely. An input loop option may also be available in the installed version, but its behaviour is not interchangeable with a filter in every situation. Check timestamps, audio duration, and the seam. A video that repeats its pictures without repeating or resetting its audio as intended is not a complete audio-visual loop.
An illustrative output shape is below. It is not a tested command, and it is not guaranteed to fit every FFmpeg build or YouTube stream. Replace the placeholders, choose source-specific looping and audio mapping, and confirm that your encoder accepts the listed options. Select the RTMPS endpoint from Live Control Room and keep the stream key secret.
ffmpeg [source-specific loop/input options] -i INPUT \\
-vf "scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,fps=24,format=yuv420p" \\
-c:v libx264 -preset veryfast -b:v VIDEO_RATE -maxrate VIDEO_RATE -bufsize VBV_SIZE \\
-g 48 -keyint_min 48 -sc_threshold 0 \\
[optional audio mapping and AAC encoding] \\
-f flv "rtmps://INGEST_URL/STREAM_KEY"
VIDEO_RATE and VBV_SIZE are placeholders, not proposed official values. The filter preserves the full picture by fitting it within the output and padding the remaining space; if that would look wrong for your artwork, choose an intentional crop or another aspect-ratio treatment. If the source is already a suitable 1080p24 image, unnecessary scaling can be omitted. Options such as -keyint_min and scene-cut settings should be checked against the selected encoder rather than copied blindly.
Test the loop and inspect stream health
Run a private or otherwise controlled test before committing the setup to an always-on channel. Use the same source type, audio, frame rate, and movement that the real stream will use. YouTube specifically recommends testing before starting a live stream and using movement and audio similar to the intended broadcast. A short test with a static frame is not a meaningful check for a loop of moving water, drifting clouds, or a music track with a long transition.
Watch both FFmpeg’s output and YouTube Live Control Room. The first can reveal connection failures and encoder errors; the latter reports what YouTube is receiving and whether its health checks see a problem. If there is no incoming video, confirm the RTMPS endpoint and stream key, then read the FFmpeg log for a rejected connection or unsupported option. Do not repeatedly publish the key while asking for help.
If health reports low bitrate, buffering, or video starvation, look at the sustained outgoing rate and upload headroom. If the warning names a codec, resolution, frame rate, or keyframe interval, compare the incoming stream with the intended settings and verify the actual encoded output. A warning is evidence about the received stream, not proof that a particular command line is correct or incorrect in isolation.
Inspect the loop seam visually and aurally. Confirm that the first and last frames do not flash, that motion does not jump unexpectedly, and that audio does not click, truncate, or fall silent. Source-specific timestamps and durations need validation; YouTube’s platform documentation does not promise that a repeated source file will look seamless. If you need FFmpeg to recover after interruptions on a local machine, consider the separate guide to keeping an FFmpeg stream running through power cuts in India. A restart strategy helps with a different failure mode from a cleanly encoded loop.
A local FFmpeg process also means the computer, power, connection, and process need to keep working. If those dependencies are the part that repeatedly fails overnight, StreamNeo removes the need to leave your own computer running by turning an uploaded file into a YouTube live stream; you still need to prepare a suitable file and check the channel’s live setup.
When the file and channel are ready, compare the operating options before settling on a method.
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 the recommended bitrate for a 1080p24 YouTube stream?
No. YouTube’s published H.264 table lists 14 Mbps as the recommended figure for 1080p30, alongside a 5 Mbps minimum; it does not provide a 1080p24 row. Treat those 30 fps figures as context, not as an official prescription for 24 fps.
What GOP value corresponds to a two-second keyframe interval at 24 fps?
Use 48 frames as the two-second interval calculation at 24 fps. YouTube recommends two seconds and says not to exceed four seconds, which corresponds to 96 frames at this frame rate. Confirm that the encoder is actually producing the expected keyframe behaviour.
Can I use one FFmpeg loop command for a still image and a video file?
Not without adapting the input handling. A still or image sequence uses image2 input options, while an existing video can be looped with a video loop filter or a supported input option. Check the installed FFmpeg version and test timestamps and audio at the join.
Does this configuration guarantee a healthy 24/7 stream?
No. It is a baseline for encoding and ingest configuration, not a guarantee of stream health or uptime. Test the actual loop, monitor YouTube’s incoming stream messages, and account for the reliability of the computer, power, and network if you run FFmpeg locally.