Video FPS: how to specify them in the brief and delivery
How to choose and document frames per second for capture, slow motion, editing, review, and campaign deliverables.
The team behind Polimake. We explore the intersection of technology, creativity, and automation.
FPS means frames per second
24, 25, 30, 50, or 60 fps indicates how many images are captured or displayed each second. The choice affects motion, slow motion, light, audio, editing, and delivery compatibility.
Do not choose FPS from a universal list. Begin with the market, channel, visual intent, and project master frame rate.
Three decisions that should not be confused
- Capture frame rate: how the camera records.
- Timeline frame rate: the editing and timecode base.
- Delivery frame rate: what each channel or display requires.
A shot may be captured at 50 fps and played slowly in a 25 fps timeline. That does not mean the entire campaign should be delivered at 50 fps.
Example specification
An agency produces interviews and B-roll for a European brand:
- master timeline: 25 fps;
- interviews with sound: 25 fps;
- B-roll intended for slow motion: 50 fps, played at 50%;
- synchronized audio: normal speed only;
- deliveries: confirm 25 fps with each publisher before export;
- record every exception on the camera report.
This is not a global rule. Other markets and projects may require 23.976, 24, 29.97, or 30 fps.
Operational risks
- Unplanned mixing may produce judder or duplicate frames.
- Higher FPS usually needs more light, data, and storage.
- Slow motion does not fix poorly planned movement.
- Changing the timeline rate later alters timecodes and feedback references.
- An export at a different rate may complicate change review.
Project documentation
Keep the master frame rate in the brief and beside the approved master. Record high-speed shots as exceptions and connect every export to its source timeline. Polimake can keep these specifications, versions, and deliveries connected to the client and campaign, preventing final_30fps from circulating without explanation.
Every revision comment should identify version and timecode. See how to give frame-specific feedback.