A YouTube playlist does not tell you the original frame rate of its videos. Inspect the actual source file or production master first; when you know the recording rate, YouTube recommends encoding and uploading at that same rate.
If a constant output cadence is needed, FFmpeg’s fps filter can convert it, but conversion may duplicate or drop frames. Output -r behaves differently depending on whether you encode or streamcopy, so it is not a general metadata correction.
Inspect the source before choosing a rate
Start with the video file you own or intend to encode, rather than the playlist page. A straightforward first check with FFprobe is:
ffprobe -v error -select_streams v:0 -show_entries stream=avg_frame_rate,r_frame_rate -of default=noprint_wrappers=1 input.mp4
This asks FFprobe to report two frame-rate fields for the first video stream. Replace input.mp4 with your file name. The command is an inspection example, not a report about any particular video. You can also examine the production project or recording settings if they tell you how the images were captured.
You may see values such as 30000/1001, which is a rational representation of a rate, not a decimal typo. Keep the rational form when you set a filter. For example, 30000/1001 is different from exactly 30; whether that difference matters depends on the source cadence, duration, and intended edit. Do not round a measured value just to make it look familiar.
The two fields in the command are not interchangeable proof of every frame’s timing. r_frame_rate is a nominal rate reported for a stream, while avg_frame_rate reflects an average. In variable-frame-rate footage, neither value alone necessarily describes the exact spacing between every frame. If they disagree, inspect timestamps and consider how the source was made before selecting a conversion.
A file can also have a frame rate different from the recording project’s setting after editing or export. For example, an editor may have placed footage recorded at one cadence into a timeline set to another and rendered a new file. In that case, the file’s timestamps describe the material you are now encoding, while the original recording information explains how its motion was sampled. Decide which source you are matching: the production master, or a previously rendered export.
For a playlist assembled from several files, inspect each item you plan to process. One clip’s rate is not evidence for another clip’s rate. If you are building a continuous channel, the playlist-order guidance for OBS reruns may help with sequence, but ordering does not establish a clip’s frame cadence.
Why playlist labels are not evidence
A playlist is a viewing and organisation layer, not a record of how each video was captured. Its title, description, resolution label, or position beside other uploads cannot establish the source frame rate. A 1080p label tells you about image dimensions, not how many unique images were recorded or how they are timestamped.
There is another complication: what you watch on YouTube is a processed playback version. YouTube may offer playback representations with properties different from the file originally uploaded. A playlist’s public presentation therefore is not a reliable substitute for inspecting your source or production master. If you only have a copy obtained from the platform, treat its measured timing as the timing of that copy; do not assume it reconstructs every property of the original upload.
This matters when you are preparing a set of devotional videos, a lofi station, or a local news loop. A channel operator might see several clips playing smoothly in a browser and infer that they all share one standard rate. Smooth playback cannot prove that. The source might use a constant cadence, a variable cadence, or a cadence changed during a previous export.
YouTube lists 24, 25, 30, 48, 50, and 60 frames per second as common upload rates, and its troubleshooting guidance also discusses rates such as 23.98, 29.97, and 59.94. These are examples, not a menu from which to guess. See YouTube’s recommended upload encoding settings and its upload troubleshooting guidance for current official information.
If a playlist contains a 24 fps animation, a 25 fps studio recording, and a 30 fps news segment, forcing all three to one rate changes how at least some of them are sampled. That may be the right delivery decision for a particular workflow, but it is a conversion decision, not an inference from the playlist. First identify the source of each file and then decide whether a common output cadence serves your programme.
Preserve the known source rate where possible
YouTube’s advice for recorded content is to encode and upload at the frame rate at which it was recorded. If the source file already has the cadence you intend to deliver, and your editing or encoding path preserves its timestamps, avoid converting it just because another rate seems more familiar. The official upload encoding guidance is the basis for matching a known recording rate, not for choosing an arbitrary customary value.
“Match the source” needs a little care. It means preserve the cadence established by the recording and source timestamps where you can, not blindly copy a number from one metadata field. If the file is variable-frame-rate, it does not have one identical time gap between every frame. Converting it to constant frame rate can be useful for a particular editor or delivery path, but doing so necessarily resamples the timing.
Consider a simple case: your source and desired output both use 25 frames per second, and the rest of your workflow can pass that timing through unchanged. There is no frame-rate reason to introduce a conversion. If a second clip is truly 30000/1001 and you must place it in a 25 fps programme, that is a deliberate conversion with possible motion consequences. The choice should follow the project’s delivery needs, not a belief that one of those rates is inherently better for YouTube.
For a long-running live channel made from recorded segments, check transitions as well as individual files. A playlist can advance from one rate to another without an obvious issue in a short preview, yet cadence changes can be noticeable in pans, scrolling text, or moving faces. If you choose to convert all items to a single output rate, test representative motion from each source first. Smooth static imagery can hide a conversion problem that is clear in a camera pan.
Frame-rate matching is separate from bitrate, resolution, and audio configuration. If an otherwise stable live video stutters, frame conversion may not be the cause. Check playback and encoding symptoms independently; the advice on stuttering in an OBS 4K 60 fps stream addresses a different set of possible causes. Do not change the source cadence simply because the live preview is choppy without first identifying where the problem occurs.
Use the fps filter when you need conversion
FFmpeg’s fps video filter is the explicit choice when you need constant-frame-rate output at a chosen cadence. It works from presentation timestamps and selects frames for the output timeline, copying some input frames and duplicating or dropping others as needed. It also creates output timestamps for that cadence. The FFmpeg fps filter documentation describes its options and behaviour.
An illustrative command is:
ffmpeg -i input.mp4 -vf "fps=30000/1001" -c:v libx264 -crf 18 -c:a copy output.mp4
Here the filter requests a constant rate of 30000/1001. The video is encoded with the specified video codec and quality setting, while audio is copied in this example. These choices are illustrative only: codec, quality, audio handling, container, and output rate depend on your project. Substitute the rate you have a reason to use, and do not treat 18 as a universal quality target.
A common workflow is to inspect first, decide whether conversion is needed, encode with an explicit filter only if it is, and inspect the result. That sequence avoids a command-line habit becoming a substitute for understanding the material. If the intended output is the source cadence, no filter may be needed at all; if a fixed cadence is required, write it visibly in the filter so you can review and reproduce the decision.
For a playlist with several inputs, each file can require a different choice. You may filter every input to a common cadence when the programme requires it, or preserve their individual source rates if your playback and packaging path supports that. Test a short section before making a full set of output files. A short sample lets you compare motion and verify that your command has the intended effect without waiting for an entire programme to encode.
Do not confuse a video fps filter with changing playback speed. The filter resamples which images represent points on the output timeline; it is not normally a command to make the whole clip run faster or slower. If timing is wrong, investigate timestamps, edit decisions, or synchronization separately. Audio copy in the illustrative command does not itself fix an audio-video timing issue introduced elsewhere in the workflow.
What conversion does to motion
If the output cadence differs from the input, FFmpeg must represent the motion using a different set of frame times. When the output has more samples in a period than the input provides, some input images may be repeated. When it has fewer, some input images are omitted. Neither operation creates genuinely new captured detail or restores frames that are absent from the source.
The visibility of that resampling depends on the relationship between the rates and the content. Repeated frames can make movement appear to pause briefly; dropped frames can make it appear less fluid. Slow pans, a person crossing the frame, a scrolling ticker, or a rotating graphic are useful things to inspect. A still devotional image with a small animated lamp may conceal effects that become apparent in footage with continuous motion.
A conversion between rates with a simple relationship can distribute repeats or drops in a regular pattern, while other relationships can make the spacing less even. The practical point is not that every conversion will look bad: it is that a different output cadence necessarily changes sampling, and you should assess the result rather than assume a number alone guarantees smoothness.
After encoding, use FFprobe again to check the output stream fields, then review playback near the beginning, middle, and end. Check that duration has not changed unexpectedly, that motion remains acceptable, and that audio stays in sync. Metadata confirms what the output reports; listening and viewing tell you whether the result behaves properly. If the source was variable rate, compare timestamps rather than relying only on a single displayed average.
For a live playlist, confirm the transition between files too. Individual files can each appear acceptable in isolation while a cadence change at a cut looks abrupt. This is especially relevant for text-heavy local news loops, where a moving ticker gives you an immediate visual reference. If an FFmpeg process itself exits or the broadcast stops, that is a separate operational issue; see the guide to restarting an FFmpeg YouTube stream after a process crash.
-r is not a metadata repair switch
FFmpeg’s output -r option depends on how the video is handled. During video encoding, an output -r can make the encoder produce a constant rate by duplicating or dropping frames. During streamcopy, where packets are passed through rather than decoded and re-encoded, -r signals a frame rate to the muxer and does not alter the frame data. FFmpeg’s documentation change on -r behaviour distinguishes these cases.
That distinction is why -r is not a generic metadata-only fix. In an encoding workflow it can change frame sampling; in streamcopy it does not convert the underlying video into a new cadence. If the rate you signal does not fit the actual timestamp-derived rate, the resulting file may be invalid or report misleading timing. Do not add -r 30 simply to make a probe output look tidy.
| Workflow | What -r does |
When to consider it |
|---|---|---|
| Video encoding | Requests output cadence; frames may be duplicated or dropped | When you intentionally want that encoded output rate and have checked the result |
| Streamcopy | Signals a rate to the muxer; frame data is not resampled | Only when the signalled value accurately reflects the stream timing and container needs |
Explicit fps filter with encoding |
Resamples by timestamps to a constant cadence before encoding | When a deliberate constant-rate conversion is required |
These are different tools for different operations. If you need to convert, make the conversion explicit with fps and encode the video. If you need to preserve the existing compressed video, streamcopy may be appropriate, but do not claim that it changes cadence. If you merely need to correct a display or container issue, identify the actual cause instead of changing frame-rate signalling without evidence.
When a streamcopy output has timing problems, re-check the source timestamps, container, and muxing workflow. Re-encoding may be required to produce a genuinely different cadence, but it brings its own quality and processing trade-offs. Keep a copy of the source, document the selected output rate, and verify the produced file before using it in an unattended playlist.
A practical check before a long playlist run
Treat the first export as a test, not as proof that every item in a playlist is ready. Pick a representative clip with motion, run the intended command, and inspect both the FFprobe output and visible playback. Confirm that the output duration is plausible, that audio and video remain aligned, and that the chosen cadence is what you meant to create. If the source contains multiple frame-rate segments, a single average may hide that complexity.
Keep the original file unchanged and save the command or preset used for the converted copy. If the result is poor, you can compare it against the source and change one decision at a time: the filter rate, the encoding configuration, or the editing timeline. Avoid changing several variables at once, because that makes it harder to identify what caused a difference.
An always-on channel adds an operational question beyond the file itself: how will the programme keep running after the finished asset is prepared? If the recurring pain is leaving a computer running overnight and recovering the broadcast after a drop, StreamNeo can run an uploaded video as a YouTube live stream while your computer is switched off. It does not determine the right frame rate for your material, so inspect and prepare the source before you rely on the finished file.
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
What frame rate should I use for a YouTube video?
If you know the rate at which the video was recorded, YouTube recommends encoding and uploading at that same rate. Inspect the actual source or production master first; do not infer a rate from a playlist, resolution, or familiar default. Conversion is a separate decision when your workflow needs a different constant cadence.
How do I check a video’s frame rate with FFmpeg?
Use ffprobe to inspect the video stream’s avg_frame_rate and r_frame_rate, for example with the command shown above. Those fields can differ, particularly when timestamps vary, so treat them as a starting point rather than definitive evidence of every frame interval. Check source context and timestamps when the reported values do not agree.
Should I use -r or -vf fps?
Use the fps filter when you need an explicit timestamp-based conversion to constant frame rate, then encode and review the output. Output -r can affect frame sampling during encoding, but in streamcopy it signals a rate to the muxer without changing frame data. It is not a universal metadata correction.
Will converting the rate make a video smoother?
Not necessarily. Conversion duplicates or drops frames to fit the requested cadence, and that can make motion appear uneven depending on the source and rate relationship. Test footage with movement and check the output before adding it to a long-running playlist.