For a prerecorded YouTube upload, begin by keeping the frame rate at which the footage was recorded. Use FFmpeg to make a constant frame rate (CFR) output only when your workflow needs it, and choose the target deliberately: CFR conversion can duplicate or drop frames.
A YouTube playlist does not need every entry to share one frame rate. If by “playlist video” you mean a single compilation made from clips with different rates, that is a separate editing decision; inspect the source clips and decide how to handle their cadence before encoding.
CFR and the source frame rate
Frame rate is the number of frames shown over time. A source recorded at 25 frames per second (fps), for example, has a different cadence from one recorded at 30 fps. Some rates are fractional in practice: 23.98, 29.97 and 59.94 fps are familiar examples. The displayed number may be rounded, so check the file rather than assuming that “24” means exactly 24.
CFR means that frames are presented at a regular, constant rate throughout the output. A variable frame rate (VFR) file can instead have changing intervals between frames. That does not automatically make VFR a problem, but a downstream application or delivery workflow may require CFR. FFmpeg can produce CFR output at a requested rate; if the source cadence differs, it may repeat or omit frames to do so.
YouTube lists 24, 25, 30, 48, 50 and 60 fps as common rates, while accepting other rates as well. That list is not a ranking, and it does not mean one of those values is best for every video. A devotional recording captured at 25 fps and a study animation created at 30 fps have different source decisions to preserve.
Start by identifying the actual input properties. You can inspect a file with ffprobe, which is distributed with FFmpeg:
ffprobe -v error -select_streams v:0 \
-show_entries stream=avg_frame_rate,r_frame_rate,width,height,pix_fmt \
-of default=noprint_wrappers=1 input.mp4
The reported rate fields are useful clues, not a substitute for viewing a sample or understanding how the recording was made. If the file is VFR, average and nominal rates can differ. Keep a note of the source resolution, frame rate, and whether playback looks smooth before you change anything.
Why preserve the source rate for uploads
YouTube's upload guidance says to encode and upload at the rate used during recording. Its format recommendations include common rates as well as fractional ones, so do not round a 29.97 source to 30 simply because that number looks tidier. The official YouTube upload encoding recommendations are the right reference when preparing a prerecorded file; live-stream advice is a different topic.
Preserving cadence avoids a conversion that has no clear purpose. When a 25 fps source is converted to 30 fps, the output needs additional frame slots. FFmpeg can fill them by repeating frames. In the reverse direction, a 30 fps source converted to 25 fps needs fewer frames, so some are dropped. The resulting video can still be usable, but motion may look uneven, especially in a pan, a person moving across the frame, or fast instrumental performance.
For devotional or ambience footage, a static image over music may hide cadence changes more readily than a moving camera or dancer. That does not make a frame-rate change harmless: inspect the actual content, not only a title card. Similarly, repeating a lofi visual loop does not require a new frame rate if its original cadence already suits the final file.
Treat each item in a playlist as its own upload. One entry may come from a 24 fps animation and another from a 50 fps camera recording; playlist membership does not impose a shared technical rate. If you want a broader production workflow for a Hindi instrumental channel, the guide to building a 24/7 Hindi instrumental stream addresses the channel format rather than prescribing a common encode rate.
When a CFR output is useful
CFR makes sense when a receiving editor, playback system, or delivery specification explicitly asks for it, or when a source has irregular timestamps that cause a specific downstream problem. It can also be a practical choice when combining material into one file, provided you choose a target based on the footage and accept the cadence consequences. It is not a general quality enhancement switch.
Before converting, clarify the deliverable. If you are uploading separate playlist entries, there is usually no reason to convert them all to a shared rate merely for playlist consistency. If you are rendering one programme from mixed-rate clips, choose a rate that suits the principal footage and test the difficult transitions. A rate that suits a presenter shot may not suit fast motion elsewhere.
For genuinely mixed-rate sources, there is no universal answer in YouTube's source-matching advice. A 25 fps target might preserve one clip and require adjustment for another; 30 fps could make the opposite trade-off. Consider how much of the programme comes from each source, whether motion is sensitive, and whether the editing stage already produces a master at a chosen cadence. Document that choice so later exports do not silently change it again.
If no receiving requirement calls for conversion, preserve timestamps and source cadence where practical. If there is a requirement, create a short test output before encoding the whole programme. Watch motion at normal speed and listen for sync, since a conversion that appears acceptable in a still frame may not feel smooth during a long shot.
Prepare a command for the actual input
A starting command for an SDR H.264 MP4 encode is below. It is an example rather than a tested preset. Replace 30 with the source rate when preserving that rate, or with the deliberately selected target when CFR conversion is required. For fractional rates, use the exact rate reported for the source or intended output, such as 30000/1001, rather than casually rounding it.
ffmpeg -i input.mov -map 0:v:0 -map 0:a? \
-c:v libx264 -profile:v high -pix_fmt yuv420p \
-r 30 -fps_mode:v cfr -crf 18 -preset medium \
-c:a aac -b:a 384k -ar 48000 \
-movflags +faststart output.mp4
The options have distinct jobs. -map 0:v:0 selects the first video stream and -map 0:a? includes audio if present. libx264 encodes H.264 video; yuv420p selects a common 4:2:0 pixel format. -r 30 together with -fps_mode:v cfr requests a 30 fps CFR output during encoding. The illustrative CRF and preset are encoder choices, not values mandated by YouTube.
For an input whose true rate is 25 fps, use -r 25 if the intention is to keep that cadence. For a 29.97 source, a corresponding rational rate may be appropriate. Do not force the example's 30 merely because it appears in the command. FFmpeg options and supported modes can vary across installed builds; check the FFmpeg documentation and the manual for your version before relying on a particular syntax.
An alternative is an explicit filter such as -vf "fps=30". The fps filter converts to its requested rate, also by duplicating or dropping frames as needed. Use one clear conversion method, not several competing frame-rate controls layered together without knowing which one governs the result.
Do not use stream copy when the job is to convert frame cadence. With -c:v copy, FFmpeg copies encoded video packets rather than decoding and re-encoding frames. An output -r in a stream-copy workflow can signal a rate, but it does not perform the same frame transformation. If conversion is required, choose an encode or an appropriate filter path, and account for the extra processing and generation loss that re-encoding can entail.
Separate playlists from combined compilations
A playlist is a collection of separate uploaded videos. Those files can retain their own frame rates, just as they can have different durations and resolutions. A playlist is not one long video file, so do not batch-convert every entry simply to make the playlist appear technically uniform.
A compilation or continuous programme is different: it is one output assembled from several clips. FFmpeg's concat filter is appropriate when the clips need to be processed and re-encoded together. The concat demuxer may avoid re-encoding when the files are suitable and their streams line up, but it is not a way to fix mismatched cadence by itself. Consult FFmpeg's concat FAQ and test the joining method against your actual files.
For a compilation, inspect each clip's rate and decide which source material drives the viewing experience. If the clips vary, conversion to one output cadence entails repeats or drops in at least some material. A short test with a moving shot from each source is more informative than relying on the final frame-rate label alone.
Check whether frames were repeated or dropped
After encoding, inspect the output with ffprobe and confirm that the rate is what you intended. Then compare input and output duration and play representative sections. A file can report the desired CFR rate while still looking poor because the selected rate altered motion in a way you can see.
Look for judder in horizontal pans, uneven movement across cuts, and abrupt changes in the rhythm of motion. For a music channel, verify that audio and picture remain in sync near the start, middle and end of a longer piece. If a clip is mostly a still artwork, inspect any animated spectrum, camera movement or transitions rather than assuming that the still image proves the conversion succeeded.
Keep a short source excerpt and its test output together. Record the FFmpeg command and the file's reported input and output rates, so a later revision can be compared fairly. If a problem appears, test a shorter section with the same motion before changing the full programme. This makes it easier to distinguish a cadence issue from an unrelated encode, source, or audio-sync problem.
Encoding also takes time and compute. Re-encoding a long file to add no meaningful compatibility benefit can consume effort and introduce another opportunity for settings to drift. If you are troubleshooting high CPU use during an always-on workflow, the guide on why an FFmpeg stream can use all available CPU discusses the separate workload question; this article's commands are for preparing an upload, not a live encoder configuration.
SDR encode choices around frame rate
Frame rate is only one part of an upload. YouTube's upload recommendations call for MP4 and H.264, progressive scan, High Profile, two consecutive B-frames, a closed GOP, CABAC, variable bitrate, and 4:2:0 chroma. Follow the current YouTube encoding recommendations for the complete specification, rather than treating a short command as a complete compliance checklist.
For SDR, YouTube recommends BT.709 colour characteristics and 48 kHz audio. Match colour metadata to the actual master; adding a tag that does not describe the footage is not a colour correction. The YouTube colour-space guidance explains how colour information may be interpreted, so use it when deciding whether metadata needs attention.
YouTube publishes reference upload bitrates, but says there is no required bitrate limit for uploads. For SDR 1080p, its reference is 8 Mbps at standard rates of 24, 25 or 30 fps, and 12 Mbps at 48, 50 or 60 fps. These are platform recommendations, not guarantees of quality or mandatory settings; choose an encode appropriate to the source and review the result. Higher resolution and different frame-rate classes have their own guidance on the official page.
Do not import live-stream settings into a prerecorded upload command. YouTube's live guidance discusses constant bitrate and live keyframe behaviour; upload recommendations use variable bitrate and do not prescribe a required bitrate limit. If you are planning the broader always-on setup rather than making an upload file, the hardware guide for YouTube streaming covers a different set of decisions.
When the source file is ready and you want it to run continuously without leaving your computer on, StreamNeo removes that particular always-on playback burden: upload the video, add your YouTube stream key, and the broadcast can keep running with monitoring and restart handling. It is for YouTube, and it does not replace checking that the file itself has the frame rate, audio and colour you intended.
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
Should I use 30 fps for every YouTube playlist video?
No. YouTube's guidance is to use the recording's frame rate, and playlists can contain separate entries at different rates. Use a common target only when a specific workflow requires it, and understand what conversion will do to motion.
How do I force constant frame rate in FFmpeg?
When encoding, set the intended output rate and use a CFR method supported by your FFmpeg build, such as -r with -fps_mode:v cfr, or the fps filter. CFR may duplicate or drop frames, so inspect motion and sync after a test encode rather than judging only by the output metadata.
Does -r convert frame rate if I use stream copy?
Not in the same way as an encode. With stream copy, FFmpeg does not decode and rebuild the frame sequence, so -r can signal a rate without creating the needed repeated or dropped frames. Use re-encoding or a filter when actual frame-rate conversion is required.
Does a YouTube playlist require all videos to have the same rate?
No. A playlist groups separate uploads and does not itself define a shared frame rate. If you are joining clips into one compilation, select an output cadence for that file and test the mixed-rate footage before producing the full version.