For a 720p60 H.264 playlist on Ubuntu, start with YouTube’s recommended 8 Mbps video bitrate, constant-rate encoding, a two-second keyframe interval and AAC stereo at 128 Kbps. At 60 frames per second, that interval converts to a 120-frame GOP; it is a calculation from YouTube’s guidance, not a separate YouTube rule.
The command below is a starting template, not a promise that every playlist, FFmpeg build or internet connection will work unchanged. Use the RTMPS destination and stream key shown in your own YouTube Live Control Room, test with the actual files, and check stream health before relying on an overnight broadcast.
Choose YouTube’s 720p60 H.264 starting settings
YouTube’s encoder guidance recommends 8 Mbps for H.264 video at 720p60, with 3 Mbps listed as a minimum. It recommends constant bitrate encoding, a two-second keyframe interval, and RTMPS where supported. For stereo audio, its guidance specifies AAC or MP3, with 128 Kbps and a 44.1 kHz sample rate as the recommended stereo settings. See YouTube’s live encoder settings for the current platform guidance.
Those figures describe encoder settings, not a guarantee that a particular Ubuntu machine or connection can sustain them. An 8 Mbps video stream also needs room for audio and network variation. Choose an upload connection that can reliably carry the encoded stream, and test it at the place and time you plan to broadcast. If that is not reliable, lower the stream quality or improve the connection rather than assuming the recommended figure will work everywhere.
| Setting | Practical starting point | What to check |
|---|---|---|
| Frame size and rate | 1280×720 at 60 fps | Whether the source motion benefits from 60 fps and the machine can encode it in real time |
| H.264 video rate | 8 Mbps recommended; 3 Mbps minimum | Source detail, motion and stable upload capacity |
| Rate control | CBR | Confirm the encoder is not producing large rate swings |
| Keyframe interval | 2 seconds | At 60 fps, use a 120-frame GOP |
| Audio | AAC stereo, 128 Kbps, 44.1 kHz | Listen for clipping, silence and sync problems |
| Ingest | RTMPS where supported | Use the exact destination and credentials displayed for this stream |
YouTube also lists compatibility characteristics such as progressive scan, square pixels, two B-frames, one reference frame, CABAC and Rec. 709 for SDR. Treat these as useful alignment targets for a compatible H.264 encode, not as settings that make an arbitrary source or FFmpeg build suitable automatically. For a broader view of channel-level settings, the recommended settings for a 24/7 YouTube stream are useful alongside this command-oriented guide.
Convert the interval into a GOP size
A keyframe interval is expressed in time in YouTube’s guidance, while FFmpeg’s -g option sets a maximum GOP size in frames. Multiply the frame rate by the interval in seconds: 60 frames per second × 2 seconds = 120 frames. That is why the template uses -g 120.
This calculation does not mean YouTube publishes “120 frames” as a separate requirement. It is simply how to express the two-second interval at 60 fps. The same arithmetic gives 240 frames for four seconds; YouTube says not to exceed a four-second interval, so do not set a longer GOP at 60 fps.
The template also sets -keyint_min 120 and disables scene-cut keyframes with -sc_threshold 0. These choices help keep keyframe placement regular instead of allowing scene changes to alter the cadence. They are practical encoder choices in the example, not additional YouTube rules. If you change the output frame rate, recalculate the GOP: a value suitable for 60 fps will not represent the same interval at another frame rate.
Get the RTMPS destination and channel-specific key
Open YouTube Studio and use the Live Control Room for the channel and broadcast you intend to run. Copy the server or ingest address and the stream key shown there. Use the secure RTMPS address when YouTube offers it for that stream. Do not copy a key from a tutorial or put a reusable credential into a public script, chat message, screenshot or support request.
Treat the key like a password: it authorises a broadcast to the associated channel or stream. Keep it out of shared files and command history where possible, and do not paste it into a message when asking someone to debug a command. If it is exposed, replace or reset it through YouTube’s controls before using it again. The exact screens and options can change, so verify the current destination in the account rather than relying on an old example.
In the command later in this article, the destination is deliberately a placeholder. Replace it locally with the full address and key provided in your own Live Control Room. Avoid sharing a version of the command that contains those credentials. If your workflow needs a saved script, arrange permissions so only the account that runs it can read the secret, and check that logs do not print the full destination.
Prepare the playlist and check FFmpeg
The concat demuxer is a straightforward way to play a list of local files in sequence. Create a text file such as playlist.txt in the format FFmpeg expects:
file '/home/you/videos/part-01.mp4'
file '/home/you/videos/part-02.mp4'
Use full paths while testing so the command does not depend on its working directory. The files should have matching streams and compatible properties, including codecs and time bases. A playlist that combines files with different stream layouts may not behave like a uniform sequence. If the source clips differ, inspect them and normalise them to a common output before relying on a concat run. The FFmpeg-user explanation of concat stream consistency is a useful example of this limitation; the FFmpeg documentation index points to the documentation for the installed version.
Check the local build before assuming the encoder exists:
ffmpeg -version
ffmpeg -encoders | grep libx264
If libx264 is absent, the command will fail at the video encoder option. FFmpeg packages differ, and online documentation is generated for current revisions; consult the help installed with your version if an option is unfamiliar. Also check that every path in the playlist exists and that the account running FFmpeg can read it.
Build the FFmpeg command
The following is a template for a playlist whose files are suitable for the concat demuxer and for an FFmpeg build with libx264. It scales each frame inside a 1280×720 canvas, preserves the source aspect ratio, sets a 60 fps output and converts to a common pixel format:
ffmpeg -re -stream_loop -1 -f concat -safe 0 -i playlist.txt \\
-vf "scale=1280:720:force_original_aspect_ratio=decrease,pad=1280:720:(ow-iw)/2:(oh-ih)/2,fps=60,format=yuv420p" \\
-c:v libx264 -preset veryfast -profile:v high -b:v 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 'rtmps://<your-ingest-address>/<your-channel-specific-key>'
Replace the placeholder destination with the value from your own Live Control Room before running it. Do not use the placeholder literally, and do not publish the completed command. -re reads the playlist at its natural rate rather than sending it as fast as the files can be read. -stream_loop -1 asks FFmpeg to repeat the input indefinitely. Remove or change that behaviour if you only intend a finite broadcast.
The filter fits video inside the target frame and pads unused space, so material with a different aspect ratio gains bars rather than being stretched. fps=60 requests a 60 fps output; conversion can duplicate or drop frames depending on the input. format=yuv420p selects a widely used output pixel format. Check the result visually, especially if the playlist contains portrait clips, unusual frame rates or content that should not be cropped.
The matching -b:v and -maxrate values are a common way to constrain the video rate when aiming for CBR, with -bufsize setting the rate-control buffer. These are template controls, not separate platform-mandated values. Encoder behaviour can differ by build and version, so observe the output and verify that the stream remains within the intended range. -preset veryfast is a trade-off between encoding effort and compression efficiency; if the machine cannot keep up, assess its load and the actual output before changing settings.
Set AAC stereo audio deliberately
The command uses -c:a aac -b:a 128k -ar 44100 -ac 2: AAC encoding, 128 Kbps, 44.1 kHz sampling and two output channels. That is a clear starting point for stereo material. If your files have no audio stream, FFmpeg may need an explicit silent audio source or a different mapping strategy; do not assume every playlist can produce audio simply because the output options request it.
Listen to the actual result, not just the source files. Check transitions between clips, channel balance, sudden loudness changes, silence and whether audio remains in sync with movement. A devotional playlist with a short silence at a join and a lecture with mismatched audio timing need different fixes. Normalising source files first may be more reliable than adding increasingly complex filters to a live command.
If you are streaming a spoken or radio-style sequence, plan how the playlist advances and what viewers see between items. The guide to streaming an Urdu radio station 24/7 on YouTube covers the broader programming side; this FFmpeg setup remains focused on the encode and ingest path.
Test with the real playlist before going live
Do not validate only by sending a short synthetic clip. Run a private or otherwise appropriate test using the real playlist, the same Ubuntu machine, the intended network connection and the actual YouTube destination. YouTube Help says, “Make sure to test before you start your live stream. Tests should include audio and movement in the video similar to what you'll be doing in the stream.” A moving sample with representative audio can expose issues that a static test frame cannot.
Let the test pass through clip boundaries and a playlist loop if the broadcast will repeat. Watch for missing or duplicated frames, bars or unwanted crop, audio discontinuities, incorrect aspect ratio, and whether the next item starts where expected. A varied playlist deserves more attention at transitions than a single uniform video. If a change to the source, filter, encoder or playlist is made, repeat the relevant test rather than assuming an earlier result still applies.
Check the stream’s status in YouTube’s Live Control Room as well as the FFmpeg terminal. Look for an incoming signal and any warnings about bitrate, resolution, frame rate or audio. Test the upload path at the location of the broadcast and leave headroom for network fluctuation. A connection test elsewhere or at a quiet time does not prove that the local route will remain steady overnight.
A useful test is long enough to observe how the machine behaves, but there is no universal duration that proves reliability. Watch CPU load, dropped or delayed output, network interruptions and the platform’s health indicators. If the test cannot sustain the intended settings, lower the output quality or address the bottleneck before scheduling a longer stream. For unattended operation, a process restart alone does not correct a source playlist that repeatedly fails at the same file.
Monitor stream health during broadcast
Keep FFmpeg’s output available to the person responsible for the channel, and check YouTube’s live health indicators during the initial part of the broadcast and after a meaningful change. A process can remain open while the platform receives an unhealthy signal, so a running terminal is not sufficient proof. Conversely, a warning can reflect a temporary network condition; check whether it continues and whether viewers are receiving a stable picture and sound.
For a channel expected to run unattended, decide in advance what will happen if FFmpeg exits, the connection drops or a file is unreadable. A restart can resume a process, but it cannot fix a malformed playlist or resolve a revoked key. Keep a way to reach the machine, protect the credential, and have a simple manual check for the Live Control Room. If the machine is expected to carry the stream overnight, test the whole arrangement under the conditions it will actually face.
If the problem is that the computer itself must stay on and connected for the broadcast, StreamNeo removes that specific burden by running an uploaded video as a YouTube live stream while your own computer is switched off. For a local FFmpeg setup, you remain responsible for the machine, process, network and recovery plan.
For a rotating playlist, process recovery is only one part of the setup: the file order and stream start behaviour matter as well. See how to set up a rotating playlist in FFmpeg for that adjacent workflow. Keep the credentials out of examples you share, and confirm the exact channel and scheduled broadcast before starting a production run.
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
Why does a 60 fps stream use -g 120?
YouTube recommends a two-second keyframe interval. At 60 frames each second, two seconds contains 120 frames, so -g 120 expresses that interval in FFmpeg’s frame-based GOP setting. It is a conversion of the time guidance, not a separately published 120-frame rule.
Can I set a longer GOP to reduce keyframes?
Do not exceed YouTube’s four-second keyframe interval. At 60 fps, four seconds is 240 frames, so a larger GOP would go beyond that ceiling. The template uses the two-second starting point instead.
Why does the concat playlist fail at a clip boundary?
The concat demuxer expects the inputs to have compatible streams, including codecs and time bases. Inspect the files and normalise them to consistent properties if they differ, then test the transition again with the real sequence.
Will this command work on every Ubuntu installation?
No. FFmpeg options, package builds and encoder availability vary, and the command assumes libx264 is enabled and that the playlist is suitable for concatenation. Check ffmpeg -version, inspect the available encoders, and test on the target machine before broadcasting.