An MP4 is the file FFmpeg reads; YouTube receives the single encoded live feed that FFmpeg sends. For an ordinary YouTube Live stream, choose one outgoing resolution and frame rate that your source, computer and connection can sustain. YouTube then creates different playback formats for viewers, so you do not normally need to send a separate feed for each viewing resolution.
The useful question is not how to make FFmpeg send every resolution, but which one feed is appropriate for this video and this connection. Set the scale, codec, bitrate and keyframe interval deliberately, then test the real feed in YouTube Studio before relying on it for an event or an overnight channel.
One feed in, several viewer formats out
“Different resolutions” can mean two things. You might want to choose whether your outgoing feed is, for example, 720p or 1080p. Or you might want viewers on different devices and connections to have different playback sizes. For the second goal, one normal live ingest is usually enough: YouTube says it automatically transcodes a live stream into multiple output formats for viewers. See YouTube’s live encoder settings and resolution guidance for its current explanation.
FFmpeg controls the feed sent to YouTube. Its scale filter can change the dimensions of that feed, and its encoder settings determine how the video and audio are packaged. That does not build a set of local adaptive-bitrate streams for YouTube playback. Sending multiple independent ingests is a different workflow and is not the ordinary way to make a single event available at more than one viewer resolution.
The path is straightforward: prepare an event in YouTube Studio, read the MP4 with FFmpeg at real-time pace, encode one output, and send that output to the stream URL using the key shown for the event. The stream URL and key are event credentials, not values to copy blindly from an old command. YouTube’s live streaming overview describes setting up a live stream; check the current Studio interface for the event-specific details.
Keep the key private. Do not publish it in a script repository, a public screenshot or a support post. If it is exposed, replace or reset it in YouTube Studio before using the event again. If you are deciding between an event-specific key and a reusable one, this guide to scheduled broadcasts and stream keys covers the operational distinction.
Choose a sustainable output size and frame rate
Start by inspecting the source rather than selecting the largest number in an encoder menu. Check its pixel dimensions, frame rate, display aspect ratio, and whether it contains the audio you expect. A 720p file enlarged to 1080p has more output pixels but no extra source detail. If the image has a fixed layout, such as a devotional poster with text and a small moving element, inspect the result at the intended output size; scaling can make fine text less legible.
Then compare the candidates against four practical constraints: source dimensions, motion, encoding load, and stable upload capacity. A 1080p feed can preserve more detail than 720p when the source contains that detail and the computer and connection can maintain it. A lower output setting may be a better choice for a mostly static lofi visual, a modest connection, or a computer that struggles to encode in real time. Higher frame rates can help represent faster motion, but are not automatically useful for a still image or a source that was made at a lower rate.
| Candidate output | When it may fit | Check before choosing |
|---|---|---|
| 720p at 30 fps | A modest source, mostly steady visuals, or a connection where headroom matters | Check that text and small details remain readable |
| 720p at 60 fps | Motion is important and source and encoder can maintain the frame rate | Confirm the source frame rate and YouTube’s current bitrate table |
| 1080p at 30 fps | A detailed landscape source with moderate motion | Test sustained upload and encoding load together |
| 1080p at 60 fps | A detailed source with faster motion and adequate capacity | Higher frame rate raises the bitrate target and work required |
These are comparison points, not prescriptions for every source. If the source is portrait, square, unusually wide, or HDR, do not force it into a conventional landscape SDR recipe without deciding how it should appear. YouTube’s codec and HDR requirements can change; consult the current encoder settings page when HDR or a less common format matters. If you are planning around capture quality as well as encoding, the 4K camera guide helps separate source capability from what the outgoing feed can actually preserve.
Scale MP4 inputs consistently
A filter such as scale=1920:-2 sets a width of 1920 pixels and lets FFmpeg calculate an even height while preserving the input’s aspect ratio. For a landscape source, that can be a convenient 1080-class output, but it does not guarantee a 16:9 frame: the output height follows the source shape. That is often preferable to stretching people, lettering or artwork.
For a smaller 16:9 landscape output, choose an appropriate width and let the height follow the source ratio. If your source is not 16:9 but you need a fixed 16:9 canvas, make an explicit choice between padding and cropping. Padding keeps the whole image and adds unused space; cropping fills the frame while removing part of the picture. Inspect where the content sits before cropping, especially when subtitles, a logo or a deity image is near an edge.
A basic scale filter does not create detail when enlarging a small input. For a source that already matches the target, unnecessary resizing can add processing without improving the feed. Conversely, downscaling a large source can reduce encoding work and bitrate demand. Choose the output dimensions once, then check the YouTube preview for the right shape, rather than changing dimensions in the middle of a programme without testing.
The following is an illustrative command template, not a tested universal recipe. It aims at an H.264/AAC 1080p, 30 fps SDR feed, using YouTube’s currently displayed H.264 bitrate recommendation for that combination. Replace the file, dimensions and destination with values appropriate to your source and event:
ffmpeg -re -stream_loop -1 -i "input.mp4" \\
-map 0:v:0 -map 0:a? \\
-vf "scale=1920:-2" \\
-c:v libx264 -preset veryfast -pix_fmt yuv420p \\
-b:v 14M -maxrate 14M -bufsize 28M -g 60 \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "$YOUTUBE_STREAM_URL"
The -map options select the first video stream and, if present, an audio stream. The question mark makes the audio mapping optional; it does not manufacture sound if the MP4 has no audio. If you expect music or narration, confirm the file actually contains the right track and listen to the preview. Remove -stream_loop -1 if the broadcast should end when the file finishes. -re reads a file at its native pace so it behaves as a live-style feed rather than being sent as fast as the computer can process it.
The example’s -g 60 is 60 frames per keyframe interval; at 30 fps that is two seconds. If you choose a different frame rate, adjust the GOP length to keep the interval near two seconds. The destination variable should contain the stream URL and key in the format required by the event. Treat the key as a secret and do not leave a real one in a shared shell history or published script.
Set H.264 and keyframes deliberately
YouTube accepts several ingest codecs, including H.264, H.265 and AV1 according to its current encoder guidance. H.264 with AAC is a common straightforward pattern for conventional SDR video and is the codec combination illustrated above. The command requires an FFmpeg build with libx264; if your installation does not include it, the command will fail at the encoder selection stage. Check your installed build and use an encoder it supports, while verifying that the chosen codec is accepted for your intended stream.
A keyframe is a reference point from which a decoder can reconstruct subsequent frames. YouTube recommends a two-second keyframe frequency and says not to exceed four seconds. In FFmpeg, -g sets the group-of-pictures interval in frames, so its time interval depends on output frame rate. At 30 fps, 60 frames represent two seconds; at 60 fps, the corresponding count is 120. Setting the same frame count at both rates would produce different timing.
The template uses -b:v and -maxrate to keep the video target and rate ceiling aligned, with -bufsize set as an encoder buffering parameter. You should not read those numbers as a guarantee of visual quality or a setting that suits every connection. Choose a bitrate from YouTube’s current table for the codec, resolution and frame rate, then confirm that the actual connection can sustain the total feed.
Use YouTube’s bitrate guidance as a starting point
The table below reproduces YouTube Help’s currently displayed H.264 recommendations for the listed combinations. The page has no visible publication date; it was accessed on 3 October 2026. These are encoder targets, not promises about image quality or playback, and YouTube says its recommendations depend on codec, resolution and frame rate.
| H.264 ingest format | YouTube Help bitrate recommendation |
|---|---|
| 720p at 30 fps | 8 Mbps |
| 720p at 60 fps | 8 Mbps |
| 1080p at 30 fps | 14 Mbps |
| 1080p at 60 fps | 17 Mbps |
| 1440p at 30 fps | 21 Mbps |
| 1440p at 60 fps | 34 Mbps |
These values are YouTube Help guidance accessed on 3 October 2026, not claims that every encoder, source or route will produce the same result. Check the current official bitrate and resolution table before configuring an event, particularly if you use H.265, AV1 or HDR. The figures above are specific to the H.264 combinations shown; do not carry them over as recommendations for another codec or a format absent from the table.
Upload capacity needs room beyond the video bitrate because audio and transport also consume bandwidth, and a connection varies over time. YouTube’s streaming tips recommend approximately 20 per cent upload headroom. Treat that as a planning margin, not a measurement of your particular route: if the line cannot sustain the selected feed with spare capacity, lower the resolution, frame rate or bitrate and test again. A single speed test is only a snapshot; wired connectivity and a test at the time and place of the broadcast provide more useful evidence.
For a small business loop or local notice board, legible text and stable motion may matter more than the largest output. For a study channel or ambience loop, the source may not benefit from a high frame rate. If your 24/7 use case depends on keeping a local computer powered and connected, account for that operating burden separately from quality settings; this comparison of VPS and managed streaming discusses the differing maintenance trade-offs.
Check pacing, sound and upload capacity
Use FFmpeg’s real-time input reading for a file-based live feed. Without pacing, a file can be processed faster than its recorded duration, which is not the same as sending a live programme. The loop option repeats a file indefinitely; a playlist or more involved broadcast schedule needs its own input and transition plan. If one file is meant to play once, omit the loop option and verify what should happen when it ends.
Listen to the actual encoded preview, not only the MP4 in a desktop player. Confirm that the audio track is present, that it is the intended mix, and that the start and end behave as expected. The example selects AAC audio at 128 kbps and 44.1 kHz as a workable command illustration, not a universal loudness target or guarantee. It makes no LUFS claim. YouTube supports AAC or MP3 audio over RTMP/RTMPS; if channel layout matters, check the current official requirements rather than assuming an input mix will be preserved as intended.
Observe CPU load and FFmpeg output while representative content is playing. Fast motion, animated overlays or filters may be more demanding than a static title card. Watch for encoder warnings, dropped frames or pacing drift, and compare the total outgoing rate with stable upload capacity. If the connection or computer is marginal, make one controlled change at a time—first reduce the outgoing resolution, frame rate or bitrate, then repeat the test—so you can identify which constraint was responsible.
A reliable feed also depends on what happens when the machine or internet link fails. For a 24/7 channel, a manually launched FFmpeg process on a home computer has different recovery needs from a managed operation. The guide to keeping a radio stream running after a power cut is relevant if local power and unattended recovery are part of your plan. StreamNeo removes the specific burden of leaving your own computer running for a file-based continuous feed: you upload the video, provide the YouTube key, and the broadcast runs with your computer off, with monitoring and automatic restarts if it drops.
Test the event before relying on it
In YouTube Studio, create or select the live event and copy its stream URL and key from the Live Control Room. Confirm the event is ready to receive an encoder. Start FFmpeg and allow time for YouTube’s preview and stream-health feedback to appear. Do not treat a successful command exit or a moving local terminal as evidence that viewers can see and hear the intended programme.
Test a representative section rather than only the opening seconds. Include the most demanding movement, the quietest and loudest audio, any title cards, and a point where the source changes scene. Look for the intended frame shape, readable text, expected sound, and stream-health messages. If YouTube reports instability or frames are dropped, reduce the load or improve the connection, then run another test at the revised settings.
YouTube explicitly advises testing before starting a live stream. If possible, do this in a private or otherwise suitable test event, following the options currently available in Studio. Test at the actual location and network you will use; a test from another room or another connection may not reveal the same upload limits. A stream that passes briefly can still encounter later congestion, so keep a way to monitor health during the event.
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
How do I stream an MP4 to YouTube Live with FFmpeg?
Create or select a live event in YouTube Studio, copy that event’s stream URL and key, then use FFmpeg to read the MP4 at real-time speed, encode it, and send it to that destination. Choose dimensions, frame rate, codec and bitrate that match the source and your sustained connection, and check the resulting preview and audio in Studio.
Do I need multiple FFmpeg feeds for viewers to choose different resolutions?
Usually not. YouTube says it transcodes a live ingest into multiple playback formats for viewers, so the ordinary setup sends one appropriately chosen incoming feed. Separate ingests are for a different broadcast requirement, not the normal way to provide viewer playback choices.
How do I change the stream resolution?
Change the dimensions in FFmpeg’s scale filter, then revisit the bitrate recommendation and encoder load for that resolution and frame rate. Preserve the source aspect ratio or deliberately choose padding or cropping, and test the resulting shape in YouTube’s preview before the event.
What should I do if stream health is unstable?
Compare the full outgoing feed with stable upload capacity and leave headroom; also check whether the computer is encoding in real time. Reduce one or more of resolution, frame rate or bitrate, then test again and watch the current health feedback rather than assuming a setting will work on every connection.