For FFmpeg YouTube Live at 1080p30, choose the ingest codec first, then set output and bitrate to match YouTube’s guidance for that codec. For a playlist, you also need to pace file playback in real time and verify that the source clips can be combined into the output format you intend to send.
The bitrate is an encoder target, not a promise of visual quality. A clean, low-motion source and a noisy clip with fine detail can look different at the same ingest rate; the actual result depends on the material, the encoding path and the connection carrying the stream.
Choose the ingest codec before the command
YouTube’s current live encoder guidance gives different 1080p30 bitrate recommendations for H.264, AV1 and H.265. H.264 is the conventional choice when you need a widely supported encoder and a straightforward FFmpeg workflow. AV1 or H.265 may be appropriate if your FFmpeg build and available hardware or software encoder support them and you have checked the corresponding YouTube settings.
| Ingest codec | YouTube minimum at 1080p30 | YouTube recommended at 1080p30 | Practical consideration |
|---|---|---|---|
| H.264 | 5 Mbps | 14 Mbps | A common option with broad encoder availability; the recommended target is higher. |
| AV1 | 4 Mbps | 10 Mbps | Confirm that your installed FFmpeg build can encode it in real time. |
| H.265 | 4 Mbps | 10 Mbps | Check encoder support and the codec-specific YouTube instructions before use. |
These are YouTube ingest recommendations, not measurements of the original video file and not a guarantee of the quality viewers will see. The ingest target describes what your encoder sends to YouTube. Source quality describes the detail, motion, compression artefacts and colour present in the clips before you encode them. Encoding a poor-quality or heavily compressed source at a higher target cannot restore detail that is not there.
For a first command-line setup, H.264 is often the easiest path to reason about because the common libx264 encoder is available in many FFmpeg builds. That is not a claim that it is best for every machine. A hardware encoder may suit a computer that cannot keep up with software encoding, while AV1 or H.265 is only practical if the specific encoder is supported and sustains the chosen output in real time.
If your playlist contains devotional music, ambience or other material you did not create, codec choice does not address rights. Check the source and permissions before sending it live; the blog’s guide to copyright-safe livestream music choices is relevant to that separate question.
Set a consistent 1920×1080 progressive output at 30 fps
The output you send should be 1920×1080, progressive, with a 30 fps frame rate if that is the target you have selected in YouTube Live Control Room. In FFmpeg, -s 1920x1080 sets the output dimensions and -r 30 requests the output frame rate. These options do not make every source clip native 1080p or 30 fps; they cause the encoder to produce an output on that canvas and cadence.
A playlist can mix clips with different dimensions, frame rates, pixel formats and audio layouts. Before relying on one command, inspect each input with a media probe such as ffprobe, or otherwise check its properties. A 720p clip upscaled to 1080p remains a 720p source in terms of captured detail. A 24 fps clip converted to 30 fps may require duplicated or interpolated frames depending on processing; it does not acquire motion information that was never recorded.
If all clips have compatible streams and timestamps, a concat demuxer can read them in order. When formats differ, you may need to decode, scale, set frame rate and re-encode, rather than simply copying compressed streams. Re-encoding adds CPU or GPU work and another lossy compression stage. Stream-copying avoids that encoding work, but is conditional on input compatibility and does not itself normalise picture, sound or timing.
Keep square pixels and progressive output for a conventional SDR baseline. If the source is interlaced, has unusual pixel aspect ratio, or uses HDR colour, do not assume that changing only the output size and frame rate produces the intended result. Decide how to transform it and check a local sample first. The examples in this article are a command shape, not a tested recipe for arbitrary media.
For a channel built around prerecorded material, the practical workflow matters as much as the output settings. The example of a 24/7 storytelling channel using prerecorded video can help frame the editorial and playlist side; the encoding work still needs to be validated against your own files.
Match the bitrate to the selected codec
For H.264 at 1080p30, YouTube lists 14 Mbps as its recommended target and 5 Mbps as its minimum. For AV1 and H.265, the corresponding figures are 10 Mbps recommended and 4 Mbps minimum. Use the row for the codec you have chosen, and check YouTube’s live encoder page again before a broadcast because platform guidance can change.
In an FFmpeg H.264 command, -b:v 14M sets a video bitrate target. The illustrative use of -minrate 14M and -maxrate 14M aims to constrain the rate around that target, while -bufsize 28M gives the rate control a buffer. FFmpeg encoder behaviour depends on the chosen encoder and version; verify the documentation for the installed build instead of assuming that a group of similarly named options has identical meaning for every codec.
Do not read a recommended ingest bitrate as a source-quality threshold. A clip with grain, confetti, foliage or fast camera movement can be harder to encode than a still image or a quiet gradient. Your encoder may also struggle to maintain the desired rate if the computer is overloaded, and the connection must carry the outgoing video and audio continuously. A setting that looks sensible on paper is not evidence that your particular source and network will behave well.
For an always-on channel, make the test representative. Include the busiest motion in the playlist and listen to the loudest or most complex audio passage. If you lower a bitrate to fit a constrained connection, compare the result on YouTube rather than judging only the FFmpeg log. If upload capacity is marginal, first reduce avoidable competing network traffic or choose an appropriate output target; do not assume a single bitrate is suitable for every connection.
A locally operated setup also means the computer running FFmpeg, the process and its internet connection must remain available. If keeping that machine on overnight is the part likely to fail, StreamNeo removes that specific burden by turning an uploaded file into a YouTube live stream that runs with your own computer switched off; it is not an FFmpeg playlist workflow, so use it only if that different operating model suits your channel.
Configure CBR and two-second keyframes
YouTube recommends constant bitrate (CBR) for the live video and a keyframe interval of two seconds, not exceeding four seconds. At 30 frames per second, two seconds corresponds to a 60-frame interval. In an H.264 example, -g 60 sets the GOP length, and -keyint_min 60 requests a matching minimum interval. The -sc_threshold 0 option disables scene-cut keyframes for this example’s regular interval; check the encoder’s own documentation and behaviour before treating it as universal.
A command fragment for the H.264 case might look like this:
-c:v libx264 -preset veryfast -r 30 -s 1920x1080 \
-b:v 14M -minrate 14M -maxrate 14M -bufsize 28M \
-g 60 -keyint_min 60 -sc_threshold 0 -pix_fmt yuv420p
This is an illustrative starting shape, not a guarantee of constant-rate behaviour or a fit for every source file and network. The veryfast preset is a workload/encoding-efficiency choice for libx264; slower presets can require more processing, and whether any preset keeps up depends on the machine and source. If encoding falls behind, inspect the encoder’s output and system load, then choose a workable setting and retest.
A two-second GOP is not the same as a two-second playlist segment. It governs where the video encoder places keyframes, which are useful reference points for decoding and stream handling. It does not make transitions between files seamless. Clips with different timestamps, audio layouts or encodings may produce a pause, discontinuity or other change at a join, so inspect joins in a test broadcast.
YouTube’s advanced encoder recommendations also include CABAC, two B-frames and one reference frame for H.264. These are codec-specific encoder details rather than settings to copy blindly into another codec’s command. If you set profile or B-frame options manually, make sure the selected FFmpeg encoder accepts them and that they do not conflict with your desired real-time performance.
Set SDR colour and audio deliberately
For a conventional SDR stream, use Rec. 709 colour, 8-bit video and a compatible pixel format such as yuv420p. These settings describe the output signal; they do not correct an incorrectly tagged or badly converted source. If the source material is HDR or uses a different colour space, decide whether a deliberate conversion is needed rather than merely labelling it Rec. 709.
YouTube’s documented audio baseline is AAC stereo at 128 Kbps and 44.1 kHz. In FFmpeg, the corresponding options in a typical AAC command are -c:a aac -b:a 128k -ar 44100 -ac 2. That assumes your source has audio and that stereo output is appropriate. If some playlist items are silent or have different channel layouts, determine whether to provide silence, map streams consistently or handle those inputs separately; a generic audio mapping may not work for every item.
Pay attention to levels and transitions as well as codec parameters. A playlist can have clips recorded at different loudness levels, and a codec setting will not even them out. Listen through a representative sequence on headphones or speakers, check for clipped peaks and unexpected silence, and make any needed audio processing explicit. Keep a copy of the original files so that changes can be reviewed rather than baked irreversibly into source media.
Build the playlist and send it in real time over RTMPS
The FFmpeg concat demuxer reads a text file of input paths in sequence. A simple playlist.txt can contain:
file 'clip-01.mp4'
file 'clip-02.mp4'
The concat demuxer documentation explains its input requirements and the -safe option. Use the default safety behaviour where it works. Only consider -safe 0 for a playlist you control and understand, since it relaxes path checks; do not point a live process at untrusted playlist content. If the files do not meet concat’s requirements, re-encode or prepare compatible inputs rather than expecting the demuxer to repair them.
-stream_loop -1 repeats an input indefinitely, while -re paces file reading at the input’s native rate. These solve different problems: looping determines whether the input repeats, and pacing stops a file source from being read as quickly as the computer can process it. Put input options before the relevant -i, as in the shape below. Check the FFmpeg command-line documentation and concat demuxer documentation for the version installed on your machine.
ffmpeg -re -stream_loop -1 -f concat -safe 0 -i playlist.txt \
-c:v libx264 -preset veryfast -r 30 -s 1920x1080 \
-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 -ac 2 \
-f flv 'RTMPS_URL_WITH_STREAM_KEY'
Treat this as an example of option placement and overall structure, not as a command verified for your files. Adapt stream mapping, colour tags, scaling, timestamps, optional audio and encoder parameters to the actual inputs and FFmpeg build. The -f flv output is used for this live-publishing command shape; the RTMPS URL and stream key must come from your own YouTube Live Control Room session, not from a copied example.
YouTube recommends RTMPS, and its stream setup guidance explains how to obtain the stream details. Keep the stream key private: do not leave it in a public script repository, screenshot, terminal recording or shared chat. If it is exposed, use the controls in Live Control Room to replace or manage it. A guide to adding a YouTube stream key in another workflow is useful context for handling the credential, though the FFmpeg destination syntax is different.
Test and monitor before leaving it unattended
Start with a private or unlisted test in YouTube Live Control Room, using clips representative of the actual playlist. Check the stream health indicators and messages there, and play the received stream back to examine the picture, sound and file joins. A command returning no immediate error only tells you that FFmpeg started; it does not establish that the stream is healthy or that the audience will receive the intended output.
Before the test, confirm that every playlist file is readable, the order is correct, and there are no accidental gaps or unsuitable clips. Check dimensions, frame rate, codec, audio presence and timestamps. Watch a passage with motion and listen to a passage with the most demanding audio. Then leave the test running long enough to learn whether encoding and upload remain steady, without treating one successful test as a guarantee of future network behaviour.
On the sending computer, watch FFmpeg’s logs for dropped or delayed frames, encoder errors and reconnection messages. Observe CPU or hardware-encoder load and confirm that other traffic is not consuming the connection. YouTube recommends checking the upload bitrate and stream health; there is no single headroom factor that makes all home or business connections safe for an always-on broadcast. Plan for variability rather than assuming the advertised connection speed is continuously available upload capacity.
For a 24/7 process, decide what happens after a reboot, a power cut, an FFmpeg error or an internet interruption. A local process needs a restart plan and someone able to investigate when the logs show a failure. If you are building a local Linux service, the systemd setup guide for a 24/7 YouTube stream covers a separate operational part of keeping a process running; it does not remove the need to check the stream itself.
Do not leave an unattended stream until you have reviewed a complete loop and tested recovery steps. Keep the source files and playlist backed up, document the working command without exposing the stream key, and note which FFmpeg version and encoder options you used. Re-check YouTube’s current settings and the installed FFmpeg documentation when changing codec, resolution or input files.
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 FFmpeg settings do I need for YouTube Live at 1080p 30fps?
First select the ingest codec and use YouTube’s current codec-specific target; its guidance lists H.264 at 14 Mbps recommended and AV1 or H.265 at 10 Mbps recommended for 1080p30. Set progressive 1920×1080 at 30 fps, CBR, a two-second keyframe interval, SDR colour where appropriate and AAC stereo audio to the documented baseline. Test against your own files and connection rather than treating those targets as a quality guarantee.
How do I loop a playlist on YouTube Live with FFmpeg?
Use a concat playlist for ordered files, then apply -stream_loop -1 to repeat the input and -re to pace file reading in real time. These options do not make incompatible clips compatible or guarantee seamless joins. Validate the files and test the actual playlist in YouTube Live Control Room.
Should I use H.264, AV1 or H.265?
Choose the codec your FFmpeg build can encode reliably in real time and that you can configure to match YouTube’s current guidance. YouTube lists a higher recommended bitrate for H.264 than for AV1 or H.265 at this output, but that does not establish which codec will look better for your particular source or run better on your machine. Test the encoder and material you actually plan to use.
Does a higher ingest bitrate make a low-quality source look better?
Not by itself. The ingest bitrate limits or targets the data sent to YouTube; it cannot recreate detail that is absent from the source or undo its existing compression artefacts. Inspect the source and compare an actual test stream before changing the target.