When Should I Convert a Product-Ad Delivery File to Constant Frame Rate Even If It Plays Correctly?

Distinguish source capture from delivery cadence

Phone recordings and other media can contain variable intervals between presented frames. An editor may handle those timestamps correctly even when the source does not have a fixed cadence.

A delivery file has its own timing properties. It should not automatically inherit every source characteristic, nor should it be converted merely because the original was captured on a phone.

FFmpeg documents frame-rate controls and timestamp-related processing. The fps filter can convert video to a specified constant frame rate by dropping or duplicating frames as needed.

That conversion changes the representation of motion. It does not repair inaccurate product geometry or establish that the original recording was synchronized.

Inspect presentation timestamps rather than the filename

Preserve the finished approved master. Inspect its stream information and the presentation timestamps of decoded frames using an appropriate media-inspection tool.

For a constant 30 fps cadence, consecutive frame presentation intervals are nominally about 33.33 milliseconds. Real timestamp representations can involve rational time bases and rounding, so do not demand identical decimal strings without considering the file's time base.

If frame intervals vary, record that observation. Then check whether the recipient actually requires constant frame rate. A variable-rate file that plays correctly and is accepted by the destination may not need conversion.

If the recipient requires CFR, create a separately named converted copy using a documented method. Do not simply rewrite metadata or assume that changing a displayed frame-rate value creates missing frames.

Hypothetical product demonstration delivery

Hypothetical illustration—not an executed FFmpeg conversion: a 15-second product demonstration contains a short phone-recorded segment and an edited graphic ending.

The merchant's local player displays the final file normally. However, a receiving editor requests a constant 30 fps delivery.

The proposed procedure first inspects the actual frame timestamps. If the file already has a suitable constant cadence, no additional conversion is justified solely by its source history.

If the delivery intervals are variable, a 30 fps test derivative is created. The reviewer compares action timing, duplicated or dropped frames, audio synchronization and the final duration.

No file was inspected, converted or accepted for this fictional scenario.

Verify motion and synchronization after conversion

Compare identifiable events at the beginning, middle and end of the original and converted versions. Review the exact product action, not only a smooth-looking player preview.

If the conversion introduces repeated frames or visible jumps, consider whether the required delivery cadence can be produced more appropriately from the editing timeline or higher-quality source.

Keep source-frame timing, output-frame cadence and audio synchronization as separate records. A CFR output can still have incorrect sound timing if the conversion pipeline mishandles timestamps.

The existing phone-VFR guide diagnoses audio drift. This article addresses the later delivery decision: whether an otherwise usable completed file must be represented with a fixed frame cadence for a particular recipient.

Record your own observations

The filled rows are illustrative examples. Use the blank row for your own files and observations.

Download the editable CSV worksheet

What the references establish

• FFmpeg Filters Documentation — fps: Documents constant-frame-rate conversion through frame dropping and duplication.
• FFmpeg Documentation: Documents frame-rate and timestamp handling in transcoding workflows.
• FFprobe Documentation: Documents inspection of media streams, frames and packet metadata.