A phone video with variable frame rate (VFR) can behave unpredictably in an OBS workflow if the timing of its frames does not match what your project or playback path expects. To make a constant-frame-rate (CFR) file, inspect the clip, choose a rate that suits the source and project, then transcode it with FFmpeg’s CFR mode or fps filter and check the result.
This is not the same as OBS remuxing. Remuxing changes a recording’s container for compatibility; it does not perform the frame-scheduling conversion needed to make VFR footage CFR.
Why phone videos can use variable frame rate
A video is made of frames displayed for particular durations. With CFR, the frames follow a consistent schedule. With VFR, those durations can vary. Apple’s QuickTime format documentation describes a variable-frame-rate indication based on whether video sample display durations vary; that is a format-level description, not a claim that every phone or clip uses VFR. Apple’s QuickTime format documentation
Phone camera apps may adapt recording behaviour to conditions such as available light or the way a clip is captured. The important practical point is not to infer the timing mode from the phone model, operating system, or file extension. Two clips made on the same phone can still need checking individually, and some phone footage will already be CFR.
VFR is not inherently defective. It can represent a recording’s timing efficiently, and ordinary playback may look fine. The question is whether the file’s varying frame durations cause trouble in the specific edit, playback, or OBS path you plan to use. Convert only when you have a reason, rather than treating every phone video as a problem.
Also keep frame rate separate from bitrate. Frame rate describes how video frames are scheduled; bitrate describes how much data is used over time. A file can have a variable frame rate and a constant bitrate, or the reverse. Changing a bitrate setting does not make a VFR clip CFR.
How variable frame rate affects an OBS workflow
OBS may ingest and display a clip that has VFR timing, but behaviour can depend on the source file, decoder, media source settings, and the rest of the project. A clip can appear smooth in one player and show judder, uneven motion, or timing differences when looped or combined with other sources. Audio sync issues are possible in a workflow, but VFR alone does not prove that it is the cause.
For a one-off source, the first useful test is practical: add the original to the intended OBS scene, watch it for long enough to notice motion and listen for sync, and record a short sample if that matches your normal workflow. If the file already behaves correctly, conversion may add work without solving anything. If it does not, make a test conversion rather than repeatedly changing OBS settings at random.
A conversion can alter the frame sequence. FFmpeg’s CFR operation may duplicate or drop frames to fit the chosen schedule, so the output is not a promise to preserve every source frame as-is. Depending on the source motion and the target rate, a viewer may notice repeated frames or skipped moments. Check the result with actual content, not just a property panel.
If the clip will be part of a longer looping programme, check the converted file in context. OBS’s source settings, loop point, audio path, and other scene elements can contribute to what you hear and see. The guide to looping videos in OBS and choosing MP4 or MKV covers the separate container and looping considerations; it should not be read as a CFR conversion guide.
Check the source video’s frame-rate behaviour
Start with the actual file, not a generalisation about phones. Use a media inspection tool that reports frame-rate mode or examine the frame timing with a tool that can expose timestamps. A summary field may show a nominal or average frame rate without clearly identifying how durations vary, so do not treat one displayed number as definitive proof of CFR.
FFmpeg’s ffprobe can show stream-level fields useful for an initial check. For example, run ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,width,height,r_frame_rate,avg_frame_rate -of default=noprint_wrappers=1 input.mp4. Replace input.mp4 with your file name. This reports stream properties, including two rate fields, but the output should be treated as a clue rather than a universal VFR verdict: interpretations depend on the file and the fields alone may not describe every timestamp.
For a more detailed assessment, inspect packet or frame timestamps with FFmpeg tools, or use a graphical media analyser that explicitly reports frame-rate mode. The aim is to learn whether frame presentation times vary, not merely whether the file is H.264, MP4, or labelled with a particular rate. Keep the original untouched so you can compare playback and return to it if the conversion introduces unwanted motion or sync behaviour.
Write down the source dimensions, audio streams, duration, and any reported rate information. These details help you choose an output path and notice unexpected changes later. If the file has multiple audio tracks or subtitles, decide whether they need to remain in the converted file; a basic video conversion command may not preserve every stream unless you request appropriate mapping.
Choose a target frame rate
There is no universal target rate for all phone footage. Choose a rate that is appropriate to the source and the OBS project it will enter. If you already have a project with an established frame-rate setting, use that as a starting point, while considering whether the source motion and intended playback suit it. When there is no project setting to follow, decide based on the clip’s observed timing and how it will be used rather than picking an arbitrary number.
CFR conversion fits frames to a fixed schedule. If the chosen rate is above or below the source’s effective timing, frames can be duplicated or dropped. A higher output rate does not restore motion detail that was never captured, and a lower one can discard temporal detail. Review a section with movement, such as a person walking or a camera pan, because still frames can hide the effect.
| Decision | What to consider | Practical check |
|---|---|---|
| Match an existing OBS project | Keep the source and project cadence aligned where sensible | Confirm the project’s video settings and test the clip in a scene |
| Use a rate close to the source behaviour | Avoid unnecessary cadence changes | Inspect frame timing and compare motion before and after |
| Pick for an intended final programme | Consider other clips and the sequence they form | Test representative footage, not only one still or short segment |
The table is a way to organise a choice, not a claim that one option suits every file. If a project combines phone footage with other material, consider how all sources should look together. For a continuous stream, the frame-rate decision belongs alongside the broader OBS setup; the Ubuntu continuous-stream walkthrough is useful for that wider context, but it does not replace checking this clip’s timing.
Convert with FFmpeg’s CFR mode or fps filter
FFmpeg documents two relevant ways to request CFR output. Its output -fps_mode cfr mode duplicates and drops frames as needed to reach the requested constant frame rate. Its fps filter performs the same basic kind of scheduling conversion to a specified rate. See the current FFmpeg documentation and FFmpeg filters documentation for syntax and details, as these are living documents.
A command should reflect the file and output you actually need. In particular, choose the rate deliberately, specify a suitable video encoder and output container, and consider how audio streams should be copied or encoded. These choices affect compatibility and quality, and they are not determined by the fact that the source is VFR. Do not copy a command blindly if you do not know what its stream mapping or codec options do.
A schematic example of the two CFR approaches is:
ffmpeg -i input.mp4 -vf "fps=TARGET_RATE" -c:v libx264 -c:a aac output.mp4
or, where you want to use output frame-rate mode instead of the filter:
ffmpeg -i input.mp4 -r TARGET_RATE -fps_mode cfr -c:v libx264 -c:a aac output.mp4
TARGET_RATE is a placeholder, not text to leave in a runnable command. Replace it with the rate you chose, using the syntax FFmpeg accepts. These examples use a common combination of video and audio encoders but are not universal prescriptions: you may need different codecs, stream mapping, audio handling, or a different container. In particular, check whether the input has audio tracks you want to preserve and whether the chosen output format is suitable for your next step.
Avoid applying both approaches casually. Pick a method, then inspect what FFmpeg produces. The fps filter makes the rate conversion explicit in the filter chain; output CFR mode is another documented mechanism. Consult FFmpeg’s current option documentation for the version you have installed and confirm the command’s output rather than assuming the options had the intended effect.
If you prefer not to use a command line, use a graphical converter whose export settings explicitly offer constant frame rate or a fixed frame-rate output. Check that the setting controls frame scheduling, not only a label in metadata. A GUI can make stream and codec choices easier to see, but the same trade-off remains: it may duplicate or drop frames, and you still need to verify the result. FFmpeg is a documented route and paid software is not required for this task.
Verify the converted file before importing it into OBS
First inspect the output’s properties with the same tool you used for the source. Check that the output is reported as CFR if the tool provides a frame-rate mode field, and review the reported rate and duration. A fixed rate field on its own is not conclusive when the analyser cannot report mode, so combine this check with timestamp-aware inspection where available.
Then play the entire converted clip, or at least the full duration if it is short enough for your workflow, with audio enabled. Pay attention to motion that crosses the frame, cuts, and the final portion of the file. Listen for audio that drifts relative to visible action, and compare the duration with the source. A duration difference or a cadence change is a reason to investigate, not automatic proof of failure: conversion changes frame scheduling and the chosen output settings may affect streams differently.
Finally, import the converted file into the actual OBS scene and test it as it will be used. Check the media source’s start, loop behaviour, and audio routing where relevant. If this is for a channel that runs continuously, a short preflight is especially useful before leaving a new asset in rotation overnight. Keep both files until you have checked the OBS result and are satisfied with the sound and movement.
For channel planning beyond this single conversion, the guide to making a 24/7 stream from pre-recorded videos addresses the broader workflow. It is still worth keeping file preparation distinct from stream continuity: a well-converted clip does not by itself test the computer, connection, scene, or audio chain.
When OBS remuxing helps—and when it does not
OBS remuxing is useful when a recording is in a container that another application handles poorly and you want to convert it to a more compatible container, such as MP4. The OBS Standard Recording Output Guide describes remuxing in that compatibility context. It concerns the container around media streams, rather than the schedule of video frames.
If the issue is that a VFR file needs a fixed frame schedule, remuxing alone is not the required operation. A remux does not describe duplicating or dropping frames to achieve CFR. Use a transcode/export operation with an explicit CFR setting, then verify the resulting frame timing and playback. Renaming a file extension is not a substitute either; it changes neither the container structure nor the frame schedule.
Keep the two jobs separate in your troubleshooting notes: use remuxing for a container compatibility problem, and use CFR conversion when you specifically need fixed frame timing. If both problems exist, address both intentionally and check the resulting file after each relevant operation. This avoids attributing a playback change to the wrong step.
If your work extends from preparing clips to sending an always-on channel, the continuous YouTube streaming bitrate guide covers a different part of the workflow. StreamNeo can remove the need to leave your own computer running once a prepared file and channel are ready, but that does not change the need to make and verify a suitable CFR export when your OBS workflow calls for one.
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 every phone video need to be converted to CFR?
No. Phone videos do not all use VFR, and OBS does not necessarily fail with every VFR file. Inspect and test the clip in your actual workflow; convert when timing behaviour is a problem or a fixed schedule is a specific requirement.
Does changing the container remove variable frame rate?
No. Remuxing changes the container, which can help with compatibility, but it is not the same as rescheduling frames. For CFR, use an explicit frame-rate conversion or export setting and verify the output.
Will FFmpeg keep every frame exactly as recorded?
Not necessarily. FFmpeg’s documented CFR modes can duplicate or drop frames to meet the requested schedule. Watch moving sections and listen for sync after conversion so you can judge whether the chosen rate suits the clip.
Which frame rate should I choose?
Use the source timing and the intended OBS project as your reference; there is no single correct rate for every phone video. Consider how the footage will look alongside other sources, then test the result before replacing the original.