A variable frame rate (VFR) file can be streamed to YouTube with FFmpeg, but first decide whether you want to preserve its uneven frame timing or convert it to a fixed output cadence. These are separate choices: pacing a file in real time is not the same as synchronising or converting frames in the output.
The exact options depend on your FFmpeg build, source and encoder, so treat any command as a starting structure rather than a universal recipe. Check the installed build’s help, match the stream to YouTube’s current ingest guidance, and test while watching Live Control Room’s stream-health messages.
Why variable frame rate needs care
A constant frame rate (CFR) video has frames spaced at regular intervals. A VFR video may have different intervals between frames: for example, a screen recording can use fewer frames while the screen is still and more when something moves. The nominal frame-rate figure shown by a media tool does not necessarily describe every frame’s timestamp interval.
That irregularity is not automatically a fault. It can be a sensible way to represent the source. Trouble tends to arise when a later step assumes evenly spaced frames, or when timestamps are altered without understanding what they mean. Symptoms such as judder, repeated or missing-looking frames, or audio that drifts over time can have several causes; changing a frame-rate flag before identifying the cause may make matters worse.
Start by inspecting the file rather than inferring its timing from its filename or the application that created it. Record the video and audio streams, their time bases and reported frame-rate information, and examine timestamps if your tools expose them. Compare a section with little motion to one with more motion. You are looking for evidence about the source cadence, not a reason to force every source into a single setting.
Also separate file timing issues from the rest of the delivery path. Encoder load, a constrained upload connection, an unsupported codec setting or a YouTube ingest warning can all affect playback. If the underlying concern is a long-running broadcast, the practical monitoring questions overlap with this guide to watching a 24/7 stream remotely, but frame timestamps still need their own diagnosis.
Decide what cadence the output should have
Before changing FFmpeg options, state your goal. You can try to preserve the source’s irregular timestamps and cadence, or deliberately produce a fixed output cadence. These are different workflows, and neither is the right answer for every file or channel.
Preserving irregular timing avoids choosing a target cadence that might require duplicating or dropping frames. It can be appropriate when you want the source’s timing retained and the rest of your output path accepts it. It does not mean YouTube will reproduce every source detail exactly, nor does it remove the need to check ingest compatibility and playback.
A fixed cadence gives the outgoing video regular frame intervals, which may be the intended delivery format for your encoder or stream configuration. But converting to that cadence can involve duplicating or dropping frames, or another deliberate resampling choice. The result depends on the chosen output rate, source timestamps, filters and FFmpeg behaviour. Select it because that is the desired output, not as a generic cure for any VFR symptom.
Keep audio in view as well. Frame timing and audio timestamps are related parts of a media timeline, but a video cadence change is not a general-purpose audio-drift repair. If sound gradually falls out of sync, investigate timestamps, sample handling, encoding and the source before adding a frame-rate conversion. The diagnostic steps in this guide to fixing audio drift in a long rain-sounds stream can help you keep that issue distinct from video pacing.
Input pacing and output synchronisation are different
Input pacing controls how quickly FFmpeg reads its input. Output synchronisation controls how video frames and timestamps are handled as FFmpeg writes a stream. They affect different stages of the process. Changing one does not make the other decision for you.
For a file that should be sent in real time, FFmpeg’s -re input option reads at the input’s native frame rate; the documented equivalent is -readrate 1. In other words, it paces reading of the file. It does not turn a variable-rate source into constant-rate video. A file can be read in real time and still carry irregular frame timing.
An output synchronisation setting addresses how FFmpeg handles frames at the output. If your purpose is to retain source timing, choose a supported mode that fits that intent. If your purpose is fixed cadence, choose the appropriate conversion behaviour deliberately, and decide whether a filter or output-rate setting is part of that plan. Options that duplicate, drop or resample frames do not merely pace the input.
This distinction is useful when troubleshooting. If a file runs ahead or behind wall-clock time, inspect the input reading and pacing path. If individual frames appear uneven, inspect timestamps and output synchronisation. If the YouTube preview reports an ingest problem, check the video and network settings as well. A single symptom can have multiple explanations; avoid changing several independent controls at once.
Use -re or -readrate only where appropriate
For a file-based source that must be delivered in real time, -re is often the concise way to request native-rate input reading. FFmpeg also documents -readrate 1 as its equivalent. These are input options, so put the pacing option before the corresponding -i in the command structure. Confirm syntax in your installed build rather than assuming an example from a different FFmpeg release applies unchanged.
Do not apply file pacing blindly to a live capture device or an input that is already arriving in real time. Its source may already control how data arrives; adding a limiter without checking the specific input’s guidance can cause a separate problem. The research behind this article did not test every kind of live input, so verify the documentation for your source and installed build.
For a file that loops or forms part of a continuous playlist, distinguish the pacing of each input from playlist construction and restart behaviour. FFmpeg’s concat workflow, for example, has its own considerations around compatible streams and timestamps. The separate guide to running a YouTube playlist with FFmpeg’s concat demuxer is relevant if your source is a sequence of files rather than one input. It does not replace deciding how the output video cadence should be handled.
Choose output synchronisation settings deliberately
FFmpeg’s project documentation describes -fps_mode[:stream_specifier] as an output, per-stream video synchronisation and frame-rate setting. That makes it the area to investigate when deciding how the output should handle frames. The project’s 2022 documentation change also marked the older global -vsync option as deprecated. Since that record is not the live manual for every installed version, check the current help output on your own system.
A passthrough-style choice may be appropriate when the aim is to preserve irregular source timing, provided the build and output path support it. A conversion choice may instead be appropriate when you have intentionally selected a fixed cadence. The names and accepted values are version-sensitive; do not copy an option value from a tutorial without checking ffmpeg -h full and the help for your installed build.
Avoid adding -r or an fps filter simply because the input is VFR. These can be part of a planned conversion, but they can also change timing by duplicating or dropping frames. Decide the intended output cadence first, then select the mechanism and verify its behaviour on a representative segment. Make one change at a time so that a result can be attributed to the setting you changed.
The following command is an illustrative structure for a file input, not an execution-tested recipe. In particular, confirm the fps_mode syntax and value, encoder availability, protocol support, stream-key URL format and compatibility with your Live Control Room configuration before using it:
ffmpeg -re -i input.mp4 \\
-map 0:v:0 -map '0:a?' \\
-c:v libx264 -pix_fmt yuv420p -fps_mode:v passthrough \\
-c:a aac \\
-f flv "$YOUTUBE_RTMPS_URL/$STREAM_KEY"
Here -re is for reading a file in real time; -fps_mode:v passthrough is an example of the separate output choice. The sample intentionally does not set a fixed output rate or bitrate. You must choose those based on your intended cadence, resolution, encoder and current YouTube guidance, as well as the capacity of your upload connection. The command does not demonstrate rate control or keyframe configuration, which you still need to set appropriately for the chosen stream.
Check your FFmpeg version and supported options
Run ffmpeg -version and note the version and build configuration before adapting an example. Builds can differ in available encoders, protocols and option support. A command that works on one system may fail on another, particularly when it relies on an option introduced or changed across versions.
Then inspect the available command help, including ffmpeg -h full, and check the help relevant to the output options and encoder you plan to use. Look for whether -fps_mode is supported, which values are accepted, and whether the selected video encoder is present. Treat old examples using -vsync as version-sensitive rather than assuming the older syntax is correct for the build you have.
Inspect the input’s stream metadata and timestamps as well. Do not assume a reported average or nominal frame rate proves that all frame intervals are equal. If your media inspection tool can show packet or frame timestamps, compare them over a representative section and note where there are gaps, irregular intervals or unexpected discontinuities.
Keep a record of the input, FFmpeg version, command and output symptom during tests. If a test changes from VFR preservation to a fixed cadence, record that change explicitly. This is more useful than collecting several commands copied from different sources, particularly when a stream fails overnight and you need to reproduce what was running.
Match the current YouTube ingest settings
YouTube’s live encoder guidance lists RTMP and RTMPS ingest, H.264, H.265 (HEVC) and AV1 video, frame rates up to 60 fps, constant bitrate encoding, and AAC or MP3 audio. It recommends a keyframe frequency of two seconds and says not to exceed four seconds. Check the current YouTube Live encoder settings before configuring a stream, because the published guidance can change and the right bitrate depends on codec, resolution and frame rate.
For example, YouTube’s published H.264 guidance gives different bitrate figures for 720p30 and 1080p60. Its AV1 and H.265 figures differ from the H.264 rows too. Do not lift a number from one row and treat it as a universal target. Select the row that matches the codec, resolution and frame rate you intend to send, then consider whether your actual upload connection can sustain it with headroom.
| Example output | H.264 minimum / recommended | AV1 or H.265 minimum / recommended |
|---|---|---|
| 720p30 | 3 / 8 Mbps | 2 / 6 Mbps |
| 720p60 | 3 / 8 Mbps | 2 / 6 Mbps |
| 1080p30 | 5 / 14 Mbps | 4 / 10 Mbps |
| 1080p60 | 6 / 17 Mbps | 4 / 12 Mbps |
These figures are the examples shown in YouTube’s encoder guidance as accessed on 3 October 2026; check the current page for changes. They are not a recommendation to choose the highest resolution or frame rate your encoder can produce. A stable, appropriately configured stream is more useful than a nominally higher setting that your connection cannot sustain.
YouTube recommends RTMPS, a secure extension to RTMP that encrypts data into and through Google’s servers. Use an RTMPS ingest URL when it is available for your stream, and keep the stream key private. The YouTube Help guidance for streaming over RTMPS explains the protocol; use the URL and key shown for the current broadcast in Live Control Room rather than assuming a copied endpoint is right for every setup.
Test and monitor the ingest, not just the command
Before relying on a configuration, make a representative test stream. YouTube says tests should include audio and movement similar to what you expect in the broadcast. A static desktop or silent clip is a poor substitute for a devotional programme with music, a local news loop with motion, or an ambience channel with a continuous soundtrack.
During the test, check the outgoing preview and Live Control Room’s stream-health messages. Verify that the expected video and audio are present, that the ingest reports no relevant warning, and that the selected codec, resolution and cadence match what you configured. Monitor the stream rather than treating a successful FFmpeg process launch as proof that the entire path is healthy.
If playback stutters or drifts, narrow the cause before adjusting frame-rate options. Check the timestamps and the intended output cadence; check encoder load and whether the chosen encoder is working as expected; check the upload connection and whether it is stable; then compare codec, resolution, bitrate and keyframe interval with the current YouTube guidance. A health warning about ingest calls for a different response from an output timestamp problem.
For a 24/7 channel, also consider what happens after the test: a file can finish, a connection can drop, or a process can stop. Those are continuity and monitoring questions, not proof that VFR handling is wrong. If you are deciding between leaving a computer running and using another operating approach, this breakdown of the cost of running a 24/7 stream on a MacBook Air can help frame that separate decision. It does not change the need to validate the stream’s ingest and timing.
When the file, command and channel are ready, choose an operating approach that fits how much monitoring and recovery work you want to handle yourself.
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
Does -re convert VFR video to CFR?
No. -re paces reading of an input file at its native frame rate, and is equivalent to -readrate 1. Output frame synchronisation or conversion is a separate decision; use the settings supported by your FFmpeg build for the cadence you intend.
Should I add -r to every VFR input?
No. An output-rate setting can be part of a deliberate conversion, but it may change timing through frame duplication or dropping. Decide whether you want to preserve irregular source timing or produce a fixed cadence before selecting an output option or filter.
Can I use the sample command unchanged?
No. It is an illustrative, untested starting structure for a file input. Check your installed FFmpeg version and option support, confirm the encoder and RTMPS URL and key, and configure output rate control and keyframes for your chosen YouTube settings.
What should I check if the YouTube preview stutters?
Check stream-health messages first, then distinguish timing issues from encoder load, upload instability and settings that do not match current ingest guidance. Test again with representative audio and movement, changing one relevant factor at a time rather than assuming a frame-rate flag is the cause.