If you are sending a file to YouTube Live with FFmpeg, a sensible starting point for SDR 1080p at 60 fps is H.264 video at 17 Mbps, AAC stereo audio at 128 kbps, and a two-second keyframe interval. The command below is a test template, not a universal command for every source, encoder or FFmpeg build.
The stream key comes from YouTube Live Control Room and must remain private. Before relying on the command for an overnight or 24/7 channel, test representative movement, audio and connection conditions while watching YouTube's stream-health messages.
Confirm the source and target format
Start by deciding what you are actually sending. The example in this article assumes a video file with one video stream and an optional audio stream. It converts that source to 1920×1080 progressive video at 60 frames per second, using SDR-compatible H.264 encoding.
That is different from a camera, desktop capture, capture card or incoming network stream. Those sources need different input options, and they may already have a frame rate or resolution that you should preserve rather than replace. A camera input might require device-specific syntax. A network source might need reconnect or buffering options. A desktop capture may need a separate audio device.
The scale=1920:1080 part of the example also deserves attention. It forces the output dimensions, but it does not decide whether the source should be cropped, padded or stretched. If your source is 16:9, scaling to 1920×1080 is usually straightforward. If it is 4:3, vertical, anamorphic or already encoded with unusual pixel dimensions, inspect the result before going live.
You can examine a file with FFmpeg or another media information tool before building the command. Check whether it contains the streams you expect, whether the audio is present, and whether the source has interlaced video. The optional audio mapping in the example allows the command to continue when the first input has no audio, but that does not create audio. You will still need to decide what viewers should hear.
For a channel built around prerecorded material, source preparation matters as much as the command. A clean file with consistent dimensions and audio levels is easier to operate than a mixture of files that each need different filters. If your aim is a continuously repeating channel, the guidance in how to stream multiple videos continuously with FFmpeg concat covers a different part of the problem: keeping the input sequence running.
YouTube supports several live-ingest codecs and formats, but this article deliberately stays with the broadly understood SDR H.264 path. HDR is a separate configuration. YouTube's live encoder settings guidance should be checked before choosing a different codec, colour workflow or delivery format.
Use the 1080p60 bitrate starting point
For H.264 1080p60 live ingest, YouTube lists 6 Mbps as a minimum and 17 Mbps as a recommended bitrate in its settings guidance, checked in October 2026. The example uses the recommended 17 Mbps target. That number is not a command to send at 17 Mbps regardless of your connection. It is a starting point for a path that can sustain the encoded stream without repeated congestion.
| Item | Template value | Why it is there |
|---|---|---|
| Output size | 1920×1080 | The requested 1080p frame size |
| Frame rate | 60 fps | Smooth motion when the source and encoder can sustain it |
| Video codec | H.264 | The codec used by this example |
| Video bitrate | 17 Mbps | YouTube's listed recommended H.264 1080p60 starting point, checked in October 2026 |
| Minimum listed bitrate | 6 Mbps | YouTube's listed H.264 1080p60 minimum, checked in October 2026 |
| VBV buffer | 34 Mbps | A practical starting value in this template, not a separate YouTube requirement |
| Audio | AAC, 128 kbps, 44.1 kHz stereo | A common match for the documented stereo audio settings |
| Keyframe interval | 2 seconds | At 60 fps, this is 120 frames |
The upload connection needs practical headroom beyond the encoded stream's sustained rate. The video bitrate is not the only traffic involved, and a connection that reaches a nominal speed only briefly is not equivalent to one that remains stable during the broadcast. Run an upload test at the location and time where you expect to stream. If the path cannot sustain the target, reduce the output settings rather than allowing the connection to fail repeatedly.
The -maxrate 17M option keeps the configured video ceiling aligned with the target in this example. -bufsize 34M gives the rate-control system room to manage short-term variation. The buffer value is not a second YouTube recommendation, and it does not repair an inadequate upload connection. It is simply a useful starting value alongside this H.264 template.
You should also consider the visual material. A devotional image with slow movement may encode more easily than a fast game, sports footage or a detailed screen recording. The same nominal bitrate can produce different visible results. Test the material that resembles your real broadcast, not only a quiet sample file.
If YouTube reports that the bitrate is too high or unstable, the troubleshooting steps in YouTube says the bitrate is too high: how to fix the warning may help you separate an encoder setting from a network problem.
Set 60 fps and a two-second GOP
At 60 fps, two seconds contains 120 frames. That is why the command uses -g 120 and -keyint_min 120. The GOP, or group of pictures, describes the distance between keyframes. A keyframe is a complete reference picture from which later frames can be decoded more efficiently.
YouTube recommends a two-second keyframe interval and says the interval should not exceed four seconds, according to its live encoder guidance checked in October 2026. The command uses the shorter, clearer two-second setting. A different frame rate would require you to reconsider the number. For example, you should not copy -g 120 blindly into a 30 fps command and assume it still represents two seconds.
-sc_threshold 0 prevents scene-change detection from inserting extra keyframes in this template. That makes the interval more predictable, which is useful when you are trying to match the destination's expectations. It can also remove a useful automatic response to an abrupt scene change, so it is not a universal best setting for every production.
The fps=60 filter asks FFmpeg to produce 60 output frames per second. It does not make a 24 fps source contain genuinely new motion between its original frames. FFmpeg may duplicate or select frames to reach the requested output rate. If the source has real 60 fps motion, the result can preserve it. If not, the output may be 60 fps technically without looking like native 60 fps footage.
The keyframe setting also depends on the encoder's behaviour and the installed FFmpeg build. The command uses libx264, but that encoder may not be available in every build. If you switch to a hardware encoder, its option names and rate-control behaviour can differ. Confirm the encoder is installed and test the output rather than assuming that a command copied from another machine will behave identically.
For a simpler explanation of the destination-side setting, see how to set keyframes in OBS for YouTube Live. The controls are different in OBS, but the reason for keeping the keyframe interval predictable is similar.
Review the illustrative FFmpeg command
For a file source with video and optional audio, this is an illustrative SDR/H.264 command:
ffmpeg -re -i INPUT \
-map 0:v:0 -map 0:a:0? \
-vf "scale=1920:1080,fps=60,format=yuv420p" \
-c:v libx264 -preset veryfast \
-b:v 17M -maxrate 17M -bufsize 34M \
-g 120 -keyint_min 120 -sc_threshold 0 \
-pix_fmt yuv420p \
-c:a aac -b:a 128k -ar 44100 -ac 2 \
-f flv "rtmps://a.rtmp.youtube.com/live2/STREAM_KEY"
-re tells FFmpeg to read the file at approximately its normal playback speed rather than processing it as quickly as the computer allows. Without it, a file source can be consumed faster than real time, which is not what you want for a live broadcast. This flag is appropriate for a normal file source, but input handling for a live device or an already-live network source is different.
-i INPUT is the input filename. Replace it with the path to the file, quoting the path if it contains spaces. The two -map options select the first video stream and the first audio stream. The question mark after 0:a:0? makes the audio selection optional. That is convenient for a silent file, but YouTube still needs a valid output stream arrangement for the result you intend to publish.
The video filter scales the image, sets the output rate and requests the yuv420p pixel format. -pix_fmt yuv420p repeats that pixel-format choice at the encoder output. This is a common compatible choice for an SDR H.264 workflow. It does not automatically guarantee correct Rec. 709 metadata, correct colour levels or preservation of every source's appearance. Review the actual picture, especially if the source is HDR, interlaced or colour-managed in an unusual way.
-c:v libx264 selects the software H.264 encoder. -preset veryfast is a compromise between encoding complexity and compression efficiency. It is not a universal recommendation. A slower preset may use more processing time for similar output settings, while a faster preset may reduce CPU load with a different compression result. The right choice depends on the machine, the source and whether the encoder can maintain 60 fps without falling behind.
The audio options select AAC, stereo, 44.1 kHz and 128 kbps. YouTube lists AAC or MP3 as supported audio choices for RTMP or RTMPS and lists 128 kbps for stereo in its live encoder guidance, checked in October 2026. If your source contains no audio, decide whether silence is acceptable or whether you need to add and map another audio source.
FFmpeg's official documentation explains the general input, stream-mapping, filtering and output structure. Use it alongside the options shown here, because exact encoder availability and behaviour depend on the build you installed.
Add the YouTube RTMPS destination safely
The destination at the end of the command has two parts: YouTube's ingest address and your private stream key. The example uses the RTMPS address shown in the research template:
rtmps://a.rtmp.youtube.com/live2/STREAM_KEY
Replace STREAM_KEY only with the key displayed for your own stream in YouTube Live Control Room. Do not paste a real key into a tutorial, screenshot, public repository, chat message or support request. Anyone who obtains it may be able to send content to your channel. If you think it has been exposed, use YouTube's controls to reset or replace it before the next broadcast.
YouTube recommends RTMPS for live ingest. The key is included in the output URL here because FFmpeg needs one destination string, but keeping credentials in shell history or process listings can create an additional exposure. On a shared machine, consider how the command is stored and who can read it. Do not put a genuine key into a script that will be uploaded or shared.
The -f flv output format is used for this RTMPS workflow. It describes the container sent to the ingest endpoint; it does not mean that your source file must already be an FLV file. FFmpeg reads the input, applies the selected filters and encoders, then sends the resulting stream using the output format.
Before making the broadcast public, create an unlisted or test event where the available controls allow it. You can follow the practical checks in how to test a live stream without going public. This lets you verify the key, audio routing and picture without treating the first live transmission as the test bench.
Test audio and representative motion
A command that starts without an error is not necessarily producing a usable broadcast. Watch the local output if possible, and inspect the receiving preview in YouTube Live Control Room. Look for stretched pictures, unexpected cropping, dropped frames, silent audio, clipping and motion that appears less smooth than expected.
Test a section with movement similar to the real programme. For a bhajan or devotional channel, include the animated title, scrolling text or camera movement you expect to show. For a study channel, test screen changes and cursor movement. For local news, include lower thirds, transitions and any incoming clips. A still image can hide a rate-control or frame-pacing problem that becomes obvious during motion.
Listen with headphones as well as speakers. Confirm that the selected audio is the intended language or programme feed, that both stereo channels behave as expected, and that speech is not buried under music. A silent file may be valid input but still be a poor live source if viewers expect narration.
Check the source duration and end behaviour too. A normal file reaches its end and stops unless you deliberately arrange a loop or a sequence. If your goal is an always-on channel, do not assume that changing the video settings will make a finite input repeat. The article on FFmpeg YouTube loop streams ending instead of repeating addresses that separate failure mode.
YouTube automatically creates other playback versions for viewers, so the 1080p60 ingest is not the only format people may receive. That does not remove the need to send a stable source. It means that you should judge the ingest preview and the health indicators first, then check a viewer playback device if the audience uses phones, televisions or slower connections.
Check stream health and adjust
After the test begins, look at YouTube's stream-health information rather than relying only on the terminal output. Confirm that YouTube detects the expected resolution and frame rate, and watch for warnings about dropped frames, bitrate, connection stability or audio. Keep the test running long enough to expose the conditions that matter for your broadcast rather than stopping as soon as the preview appears.
If the encoder cannot maintain 60 fps, first determine whether the bottleneck is the CPU, the input, the filter chain or the network. A software H.264 encode may use substantial processing, particularly when scaling and converting every frame. A hardware encoder may reduce CPU work but requires a different configuration and may not expose the same options. Neither route can be selected responsibly without testing the installed system.
If the network is the problem, compare the sustained upload capacity with the chosen video rate and leave headroom. Lowering the video bitrate or output resolution may be more reliable than repeatedly reconnecting at an unstable rate. YouTube's guidance is to choose settings that fit the connection, test upload speed and monitor stream health. The recommended number is useful only when the complete path can support it.
If the picture is soft, inspect the original source before increasing the bitrate. Upscaling a low-resolution file to 1920×1080 changes the output dimensions but does not create missing detail. If the picture is jerky, compare the source frame rate, the FFmpeg logs and the detected output rate. If colours look wrong, investigate the source's colour space, transfer characteristics and metadata rather than assuming yuv420p has solved the issue.
Latency is the delay between capture or encoding and what a viewer sees. Lower-latency modes may reduce that delay while increasing the risk of buffering, and the FFmpeg command alone cannot promise a fixed end-to-end delay. Choose the YouTube latency setting with the audience and programme in mind, then test it from a normal viewer connection.
For overnight operation, the important question is what happens when something fails. A local computer can lose power, the input file can end, the connection can change, and the process can stop. StreamNeo removes the specific need to keep your own computer running by letting you upload a file, provide the YouTube stream key and have the broadcast run with monitoring and automatic restart, but you should still test the channel's content and YouTube settings before relying on it.
If you are building a larger always-on workflow on your own machine, how to build a 24/7 YouTube livestream with Docker and FFmpeg may be relevant. If the process fails overnight, keep a written recovery checklist rather than depending on memory; the 3am failure checklist covers the kinds of checks worth recording.
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
Can I use this command with a camera or desktop capture?
Not unchanged. The filter and encoding choices may still be useful, but camera and desktop inputs need different -i syntax, device permissions and audio mapping. Test the actual capture source and confirm that the encoder available in your FFmpeg build can maintain the selected frame rate.
Is 17 Mbps mandatory for 1080p60?
No. YouTube lists 17 Mbps as the recommended H.264 1080p60 bitrate and 6 Mbps as the minimum in its live encoder guidance, checked in October 2026. Use a rate the upload path and encoder can sustain, then watch YouTube's stream-health indicators during a representative test.
Why does the command use -g 120?
At 60 frames per second, 120 frames cover two seconds. YouTube recommends a two-second keyframe interval and says it should not exceed four seconds. If you change the frame rate, reconsider the GOP value rather than copying it automatically.
Where do I get the stream key?
Get it from YouTube Live Control Room for the channel and event you intend to use. Keep it private, do not publish it in commands or screenshots, and replace it through YouTube if it may have been exposed.