A variable frame rate file does not present frames at one steady interval; a live encoder and YouTube ingest are built around a configured output cadence. If the timestamps in your source do not fit that cadence, convert the video to a deliberate constant frame rate (CFR), then check the result and test the full live path.
There is no universal FFmpeg line that fixes every stream health warning. First identify the exact warning and the file’s properties, then choose a target rate that matches your event. The commands below are starting patterns for file conversion, not guaranteed presets for every source or live encoder.
Why variable timestamps can trigger a warning
A constant-frame-rate video has frames scheduled at regular intervals: at 30 fps, for example, the nominal interval is one thirtieth of a second. Variable-frame-rate (VFR) video can record frames at uneven intervals. That can be useful when a phone or screen recorder captures changes efficiently, but the file’s timestamps may not describe the steady cadence expected by your live output settings.
The encoder must turn a source into a sequence with predictable timing. Depending on its configuration and how it interprets the timestamps, it may have to wait, repeat or discard frames, or emit timing that does not match the stream key’s configured rate. YouTube can report a frame-rate or timestamp-related health issue when the incoming feed does not behave as expected. A VFR label alone, however, does not prove that VFR caused your warning.
Start with the full message shown in YouTube Live Control Room, including when it appeared. A frame-rate warning calls for a different investigation from a bitrate, keyframe, resolution, connection or timestamp warning. A green or yellow status alone is not enough to identify the cause. Keep the exact wording so you can compare it after making one change.
Inspect the source rather than guessing from its origin. A phone recording or screen capture is a common candidate for VFR, but it may also be CFR, and a CFR file can still be badly matched to your event. Record the dimensions, video and audio codecs, reported frame rate and, where available, average frame rate and time base. A media-information tool such as ffprobe can show these details; differing reported and average rates are a reason to investigate timing, not by themselves a diagnosis.
Choose the frame cadence for the event
Decide the output cadence from the YouTube event and the content, not from a rule that every file should become 30 fps. Check the stream key or encoder configuration first. If your event is configured for 30 fps, a 30 fps output is the natural target to test. If you have a genuine reason to use 60 fps, check that the source detail, encoder capacity and upload connection can sustain it.
A higher target rate can preserve smoother motion when the source supports it, but it asks the encoder and connection to carry more video information. A lower target rate reduces that demand but can make fast movement less fluid. Converting a source with fewer distinct frames to a substantially higher rate does not create new captured detail; frames may be repeated. Conversely, reducing a high-motion source can discard temporal information.
| Target choice | When it may suit | Trade-off to check |
|---|---|---|
| 30 fps | A standard-paced loop, devotional visuals, slides or a stream key set to 30 fps | Fast motion may look less smooth than at a higher source rate |
| 60 fps | Material with frequent motion, when the event and system are configured for it | More encoding and network demand; a lower-rate source may need repeated frames |
These are examples, not a prescription. The current YouTube live encoder settings list supported formats and recommendations that vary with codec, resolution and frame rate. Check the current guidance for the exact output you intend to send, and use a sustainable rate for your actual upload rather than treating a recommendation as a connection guarantee.
Also decide whether to normalise the file offline or convert during a live encode. Offline conversion takes time and creates another file to store, but lets you inspect playback and cadence before the event. Live conversion avoids a separate prepared file, but ties timing conversion to the running encoder; it also requires correct real-time input, audio, codec, rate control and destination configuration. If a quiet overnight loop matters more than avoiding an extra encode, a checked offline file is often easier to diagnose.
Convert with FFmpeg’s fps filter
FFmpeg’s fps video filter makes the intended cadence explicit. A basic offline pattern is:
ffmpeg -i input.mp4 -vf "fps=30" -c:v libx264 -preset medium -crf 18 -c:a aac -b:a 128k output-cfr.mp4
The filter schedules output video at 30 fps, dropping or duplicating frames as needed. Re-encoding the video is necessary because the frames and timestamps must be changed. The example uses H.264 and AAC for a file output, and the CRF setting is a quality-based file-encoding choice. It is an illustration, not a tested universal setting: replace the target cadence and encoding choices to suit the source, playback needs and your workflow. Consult the FFmpeg filter documentation for the fps filter’s options and behaviour.
Do not copy this command into a live pipeline without adapting it. A live transcode needs appropriate input handling, audio mapping, video and audio codecs, bitrate control, keyframe interval and a correctly configured RTMP or RTMPS destination. It must also match the event’s settings. A file encode’s CRF choice is not a substitute for choosing live bitrate behaviour. Do not publish or share a command containing your real stream key: treat that key as a credential.
If audio is important, listen to the converted file and check that sound remains in sync through the beginning, middle and end. Video timing conversion should not be confused with audio repair. If you need to change audio handling, do so deliberately and verify it separately rather than adding several untested timing options at once.
For a playlist, one converted clip is not enough evidence that the whole programme is consistent. Check each item’s frame cadence, dimensions and audio, as well as transitions. If you use FFmpeg to build a file playlist, the playlist looping guide is useful context for keeping a continuous sequence organised; it does not replace checking each source file’s timing.
Use CFR output mode appropriately
FFmpeg also offers output frame-rate synchronisation modes. With a clear output rate, -fps_mode cfr tells FFmpeg to drop or duplicate frames to achieve constant frame rate. An alternative illustrative file pattern is:
ffmpeg -i input.mp4 -c:v libx264 -r 30 -fps_mode cfr -c:a aac output-cfr.mp4
Here, the requested output rate and CFR mode are explicit, and the video is re-encoded. Exact behaviour depends on the FFmpeg version, output muxer and input timestamps. The official FFmpeg command documentation describes output synchronisation modes, including cfr and auto. If the goal is a guaranteed constant cadence, do not assume auto means CFR; its choice depends on muxer capabilities.
The fps filter and output CFR mode can both produce a regular cadence, but they express the choice in different places. The filter gives you a visible rate-conversion step in the video filter graph. The output mode controls frame synchronisation at output. Use one clear method, inspect the result, and avoid combining timing flags casually: overlapping controls can make it harder to tell which step changed frame timing.
If you are not sure which is appropriate, begin with the fps filter for a simple offline conversion because its target rate is easy to see in the command. Use output CFR mode when you understand the output-rate behaviour of your FFmpeg build and muxer. Check ffmpeg -version and available encoders on the machine where you will do the work; a command that names an encoder unavailable in that build will fail before it produces a file.
Why stream copy does not convert frame rate
Stream copy passes the compressed video packets through without decoding and re-encoding the video. It is useful when you want to remux or move compatible streams without changing their encoded picture data. It does not apply a video filter, rewrite the sequence into a newly encoded cadence, or turn VFR frames into CFR output.
That means a command using -c:v copy cannot also perform the fps filter’s frame conversion. If you try to combine them, FFmpeg cannot both preserve the original encoded video and alter its frame sequence through a filter. Remove stream copy for the video when actual cadence conversion is the task, and choose a video encoder instead. You may be able to copy audio in some workflows, but check format compatibility and synchronization rather than assuming it is safe.
This distinction matters when a quick remux appears attractive. A new container can change how metadata is represented, but it does not, on its own, make the source video’s frame cadence constant. If the exact warning is about an unsupported container or another property, remuxing may be relevant; if it is about uneven frame timing, inspect the output and perform a real video conversion where needed.
Check the output media properties
After conversion, inspect the resulting file rather than trusting that FFmpeg completed without an error. Check its width and height, codec, reported frame rate and average rate or time base if available. Confirm that the chosen output cadence is represented as intended, then play the file in a player that reports timing or frame details if you have one. A property report is useful evidence, but playback is still needed to catch judder, blank sections, frozen frames or audio drift.
Review several points, not just the first seconds: the opening, a section with representative motion, and the end. Pay particular attention to a long recording, a screen capture with pauses, or a source whose timing varied. Listen for sync drift and inspect cuts or transitions. If the file is part of a loop, check the hand-off between clips as well. The month-long loop encode checklist covers other file properties worth standardising before a long-running broadcast.
A report that says 30 fps is not proof that the live feed will be healthy. The file may be CFR while the live encoder sends a different rate, codec, bitrate or keyframe cadence. Conversely, a clean ingest does not guarantee every viewer’s local playback is smooth; their device and connection affect that experience. Treat the file check and live test as separate stages.
If the output is not what you expected, change one thing at a time. Re-check the command’s selected input stream, filter placement, encoder availability and output container. Preserve the source and write to a different output file so you can compare the converted version and return to the original if needed.
Match YouTube event settings and test
Match the live encoder to the event configuration and current YouTube guidance. In particular, check resolution, frame rate, video codec, bitrate mode and keyframe interval. YouTube’s encoder guidance lists H.264, H.265/HEVC and AV1 for RTMP/RTMPS video, AAC or MP3 audio, and CBR bitrate encoding; its keyframe recommendation is two seconds and it says the interval must not exceed four seconds. These settings can change, so check the official page before the event rather than relying on a copied command or an old note.
The same guidance gives different bitrate recommendations for different codec, resolution and frame-rate combinations. For instance, the listed H.264 recommendation for 1080p at 30 fps differs from its recommendation for 1080p at 60 fps. Choose the row for your actual output and ensure the connection can sustain the selected rate; a platform recommendation is not proof that your broadband upload will hold it through a full night. Avoid borrowing a bitrate from a different resolution or codec.
Run a representative test before making the stream public. YouTube recommends testing before going live, with movement and audio like those in the intended broadcast. Send the actual converted file or a representative playlist through the encoder settings you plan to use, then monitor the timestamped stream health messages. Also check playback from a viewer’s perspective if that is part of the problem: ingest health and what a viewer sees are related but distinct checks.
If the warning persists, compare the new message with the original and investigate the category it names. A continuing frame-rate message may indicate a mismatch in the encoder output or event configuration. A bitrate or keyframe warning asks for a different adjustment; a disconnect points towards the connection or encoder process. For a reconnecting FFmpeg feed, the Ubuntu logs and RTMP troubleshooting guide covers a separate failure pattern. Do not keep changing frame-rate flags when the evidence now points elsewhere.
When the repeated manual work of keeping a prepared file and its cadence consistent is the problem, StreamNeo removes that specific step by letting you upload the video once and run it as a 24/7 YouTube broadcast without keeping your computer on. You still need to prepare media and verify the event’s output and health messages; a different delivery method does not make a VFR diagnosis automatic.
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 convert VFR to CFR with FFmpeg for YouTube Live?
Use the fps filter with a chosen target rate and re-encode the video, or use a clear output CFR mode with a specified output rate. Select the rate from your event settings and source needs, then inspect and test the resulting feed. No single command fits every input and encoder configuration.
Why does YouTube Live warn about my frame rate?
The incoming cadence may not match the event’s configured rate, but the warning text and timing are the evidence to work from. Read the complete message in Live Control Room and check the source and live output properties. A VFR source is a possibility, not a diagnosis on its own.
Can I use -c:v copy with the FFmpeg fps filter?
No. Stream copy preserves the original compressed video and does not apply the filter or convert its frame cadence. For an actual frame-rate conversion, encode the video output and then verify the file.
If the converted file is CFR, is the live stream fixed?
Not necessarily. The encoder may send a different frame rate or have a bitrate, keyframe, resolution or connection problem. Test the full event configuration and use the new health message to decide what to investigate next.