For a prerecorded 720p60 video, FFmpeg can pace playback in real time, encode it as H.264, and send it to YouTube Live over RTMPS. YouTube’s H.264 guidance lists 8 Mbps as the recommended bitrate for 720p60 and 3 Mbps as the minimum; neither figure guarantees a successful stream or a particular picture quality.
The settings YouTube recommends for the incoming stream are separate from whether your computer can encode the file at 60 frames per second in real time. You need to check both: configure the output to suit YouTube, then test whether the chosen machine and source can sustain that output without falling behind.
Choose the frame rate and bitrate trade-off
This topic is often confused with 4K settings. The requested output here is 1280×720 at 60 frames per second, not 3840×2160. A 4K30 or 4K60 stream is a different ingest format with different bitrate requirements and encoding workload, so do not copy a 4K bitrate or resolution into a 720p command simply because the source file is higher resolution.
At the same resolution, 60 frames per second can represent faster movement more smoothly than 30 frames per second. That can matter for gameplay, fast camera pans, dance, or sports. A devotional visual with a mostly still image, a study loop, or a slow-moving ambience scene may gain little from 60fps; 30fps can be a reasonable choice if the source was authored that way. Converting a 30fps source to 60fps does not create the missing motion detail.
Bitrate is the amount of encoded video data sent each second. Raising it gives the encoder more room to describe detail and movement, but it also increases the sustained upload requirement. It does not repair a soft or noisy source, and it does not make a weak connection stable. YouTube’s current encoder guidance lists a bitrate target for the output format; treat it as an ingest recommendation, not a promise that the viewer will see a pristine image.
Before choosing, look at what the source actually contains: its dimensions, frame rate, motion, and audio. If your material is 720p30 and mostly static, preserving its native frame rate may be simpler than forcing 60fps. If it is genuine 720p60 with movement, outputting at 60fps avoids discarding temporal detail. The practical guide to FFmpeg bitrate and keyframe settings is useful context, but always check YouTube’s current guidance for the format you intend to send.
Set the 1280×720 video format
For 720p output, the encoded frame should be 1280 pixels wide and 720 pixels high. FFmpeg can resize larger or smaller input with a scale filter. If the source has a different aspect ratio, a simple scale may stretch or crop it depending on the filter; inspect the result rather than assuming the image will retain its shape. A letterbox or crop approach may be preferable for unusual source proportions, but the right choice depends on the original framing.
A useful command pattern is below. It is an adaptable example, not a tested command. Replace the endpoint and key placeholders with the values shown in YouTube Live Control Room, and confirm that the installed FFmpeg build includes libx264 and the filters used here.
ffmpeg -re -i input.mp4 \\
-vf "scale=1280:720,fps=60,format=yuv420p" \\
-c:v libx264 -preset veryfast -b:v 8M -minrate 8M -maxrate 8M -bufsize 16M \\
-g 120 -keyint_min 120 -sc_threshold 0 \\
-c:a aac -b:a 128k -ar 44100 -ac 2 \\
-f flv "YOUR_RTMPS_URL/YOUR_STREAM_KEY"
The -re input option paces a file at its native rate rather than allowing FFmpeg to read and transmit it as quickly as the machine can process it. The fps=60 filter asks for 60 output frames per second; if the source is not 60fps, FFmpeg must duplicate or otherwise derive frames to meet that output cadence. The format=yuv420p filter selects a broadly compatible pixel format for the H.264 output.
This command uses a direct scale to 1280×720. Check for distortion if your input is not 16:9. If preserving aspect ratio is more important than filling the full frame, adapt the filter to fit the image and add padding, or prepare the media in an editor before streaming. Examine the rendered output with representative content: a one-colour test card will not reveal whether faces, subtitles, or fine textures have been altered.
If the file is already encoded at the intended dimensions and frame rate, a stream-copy approach might avoid a new encode. But do not assume that matching resolution alone is enough. Confirm codec, pixel format, timestamps, keyframe spacing, audio format, and container compatibility before depending on it. The simplest, safer test for a new setup is to encode a short representative section and inspect YouTube’s ingest diagnostics.
Use YouTube’s H.264 bitrate recommendation
For H.264 at 720p60, YouTube’s encoder settings list 8 Mbps as the recommended video bitrate and 3 Mbps as the minimum. These are the official values available in the source documentation checked on 3 October 2026. Recheck the YouTube encoder settings page before a real broadcast because platform guidance can change.
The example command sets -b:v, -minrate, and -maxrate to 8 Mbps, with a 16 Mbps buffer. This is a common way to express a CBR-style target in FFmpeg, but it is not proof that every encoder build behaves identically or that the resulting stream will be accepted without issue. Encoder settings and observed output should be checked in the actual test stream.
Do not equate the minimum recommendation with a sensible target for every clip. A low-motion image may encode more efficiently than a busy one, while detailed textures, confetti, foliage, or fast movement can be harder to represent cleanly at the same rate. Equally, setting a higher bitrate than recommended will not necessarily improve what viewers receive if upload capacity is inconsistent or the source itself is poor.
The upload connection must sustain the full outgoing stream, including audio and transport overhead, with room for normal variation. If the connection is shared with household video calls, backups, or other uploads, those competing transfers can cause trouble even when a speed test looked healthy at another time. Run a test under conditions similar to the planned broadcast and watch the YouTube stream-health panel rather than judging by a brief successful connection.
For a 24/7 channel, include continuity and scheduling in the decision too. A setting that looks good during a short clip can behave differently during overnight operation, particularly if the upload path or source playback process is not supervised. The discussion of moving a continuous stream away from a PC covers the broader operational question without changing the bitrate requirements of the ingest.
Configure libx264, rate control, and keyframes
libx264 is FFmpeg’s software encoder for H.264 when it is available in the build. In the example, -preset veryfast selects a faster encoding preset. Faster presets generally reduce the amount of computation needed, with a possible trade-off in compression efficiency: at a given bitrate, the image may differ from output made using a slower preset. The preset does not change YouTube’s recommended ingest bitrate.
YouTube’s guidance calls for constant bitrate (CBR) and recommends a two-second keyframe interval, with no interval longer than four seconds. In the example, -g 120 corresponds to 120 frames per keyframe at 60fps, which is two seconds. -keyint_min 120 and -sc_threshold 0 are included to make the interval more regular by limiting shorter scene-change keyframes. The precise effect depends on encoder behaviour and the build, so inspect the resulting stream if a strict cadence matters.
The paired bitrate constraints in the command are intended to approximate a CBR output. In ordinary use, “CBR” does not mean that every encoded frame is identical in size; it means the encoder targets a stable stream rate over time. If you change the frame rate, do not blindly keep the same GOP frame count: a 120-frame interval is two seconds at 60fps but four seconds at 30fps. Keep the intended interval in seconds in mind.
YouTube may flag an ingest problem even if FFmpeg reports that it connected. Its Live Streaming API diagnostics include checks such as low bitrate, unsupported codecs, multiple audio or video streams, and a keyframe interval that is too long. A connection is only one part of a healthy live feed; watch the diagnostics while testing.
If you use OBS rather than FFmpeg for another stage of your workflow, the distinction between rate modes is similar: the practical discussion of CBR or VBR for YouTube Live explains why a stable ingest target is commonly preferred. Do not copy encoder controls between applications without checking what each control means.
Set SDR colour and progressive output
The example’s format=yuv420p sets a widely supported pixel format, but it does not by itself convert every HDR source into correct SDR colour. If your file is HDR, has unusual colour metadata, or uses an atypical range, inspect the source and decide whether an explicit colour conversion is needed. An incorrect conversion can make a stream look washed out, crushed, or oddly saturated even when resolution and bitrate are correct.
Progressive video displays each frame as a complete image rather than as alternating interlaced fields. Most current online video sources are progressive. If the input is interlaced, simply forcing an output frame rate may produce combing or awkward motion; deinterlacing may be required. Check a moving scene, especially diagonal edges and scrolling text, before trusting the result.
Keep the number of audio and video streams simple unless there is a deliberate reason to send more. YouTube’s diagnostics may call out multiple streams. The command maps the first input’s usual audio automatically under default selection, but files with several audio tracks or unusual layouts may need explicit -map options. Listen to the actual output, not just the source file, and make sure it is not silent, distorted, or out of sync.
AAC stereo is a straightforward audio choice for this workflow. The example encodes at 128 kbps, 44.1 kHz, two channels, matching YouTube’s listed stereo audio guidance. If the source contains mono speech, converting it to stereo does not add spatial information; consider whether preserving the source layout better serves the programme, while ensuring YouTube receives a supported stream.
Send the stream over RTMPS
YouTube recommends RTMPS, the encrypted form of RTMP, for the standard ingest workflow. Open Live Control Room, create or select the broadcast, and copy the RTMPS server URL and stream key shown for it. The exact URL and key are account-specific; do not paste a guessed address from an old command or another channel.
The final argument in FFmpeg combines the endpoint with the stream key in the form expected by the selected server. Confirm the syntax shown by YouTube and adapt the example accordingly. Keep the key private in the same way you would treat a password: anyone with access to it may be able to send video to your broadcast. Avoid putting it in a public script, screenshot, or support post, and regenerate it if it is exposed.
FFmpeg documents real-time file input with -re and output through the FLV muxer to an RTMP endpoint in its protocol documentation. That is the basis for using -f flv in the pattern above. YouTube’s RTMPS-specific endpoint should be used for the actual YouTube destination; this is not a reason to send the key to an arbitrary endpoint.
There are other ingest methods for specialised workflows, but they are not interchangeable with this simple command. For instance, YouTube’s HLS ingestion documentation describes a segment-based workflow with its own media packaging requirements and typically higher latency than RTMP-based ingest. For an FFmpeg file-to-live setup that uses FLV output, RTMPS is the more direct path.
Test encoding speed and stream health separately
A correct command can still fail as a real-time job if the computer cannot encode quickly enough. When FFmpeg reads at real time with -re, it must process the video and audio at least as quickly as they are presented. The fact that a machine can eventually render a file is not evidence that it can encode 60 frames each second while also maintaining the connection and other tasks.
This is why YouTube’s recommended settings and your computer’s capability are separate questions. The 8 Mbps recommendation describes the H.264 ingest target for 720p60; it says nothing about a particular processor, graphics card, FFmpeg build, or source complexity. Do not infer that a computer can encode 720p60 in real time from the recommendation, and do not treat a successful short test as a guarantee of an uninterrupted overnight broadcast.
Run a representative test before scheduling the stream. Use a clip with similar motion, detail, and audio to the material you will broadcast, and let it run long enough to reveal whether FFmpeg falls behind, drops frames, or reports encoding errors. Watch YouTube’s stream-health messages and confirm that the received resolution, frame rate, audio, and keyframe cadence are what you intended. YouTube recommends testing with representative movement and sound before an event.
If the machine cannot keep pace, first reduce avoidable workload: close applications doing heavy work, verify the input is not being scaled unnecessarily, and try a faster preset while checking the picture. If the source does not need 60fps, retaining its native 30fps can reduce work. Changing frame rate may also change the correct GOP frame count, so recalculate it from the desired time interval. Do not solve an encoding problem by increasing bitrate; that does not make encoding faster and can make upload demands harder.
A service that takes an uploaded file and keeps a channel running while your computer is off can remove the need to maintain a local encoding session; StreamNeo is relevant when the particular pain is keeping that computer running and restarting a dropped file-based stream. It is YouTube-only, so you should still prepare a suitable source file, supply your channel’s stream key, and check the live output and YouTube’s requirements yourself.
If your plan is an ongoing sequence rather than one file, prepare the queue and transitions as carefully as the encoding. For a sequence of recorded programmes, the guide to an automated episode queue for YouTube Live in India discusses continuity considerations that sit alongside these output settings.
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
Should I use 60fps if my source is 30fps?
You can ask FFmpeg to output 60fps, but it cannot restore motion captured between the source’s original frames. For a mostly static loop, 30fps may be adequate and lighter to process; preserve 60fps when the source genuinely contains useful 60fps motion and you can test the real-time encode.
Is 8 Mbps a guarantee of good quality or a working stream?
No. It is YouTube’s recommended H.264 video bitrate for 720p60, not a guarantee of visual quality, approval, or stable delivery. Source quality, encoder output, upload consistency, and stream health all affect the result.
Can I use -c:v copy instead of libx264?
Possibly, if the file’s video stream already meets the intended codec, dimensions, frame rate, pixel format, keyframe interval, and timing requirements. Check the audio and container compatibility as well, then test the ingest; matching resolution alone is not sufficient evidence.
What should I check when FFmpeg connects but YouTube reports a problem?
Look at YouTube’s stream-health messages for bitrate, codec, stream count, or keyframe warnings, and compare those with FFmpeg’s output and the actual media properties. A successful connection only confirms that data reached an endpoint; it does not establish that the video and audio are healthy.