Frame count, and the rate it needs
A frame count is how many frames come out of a run. It converts into seconds only with a frame rate, and several releases in this register publish the count and leave the rate unstated. As of 2026-09-22.
| Use | Works without a rate |
|---|---|
| Comparing two frame counts | Yes |
| Estimating memory | Yes, roughly |
| Planning a shot length | No |
| Assembling a timeline | No |
Inclusion rule. Uses of a bare frame count. A use that fails without a rate is listed, because it is the use readers arrive with. Order. From the uses that survive without a rate to the ones that do not.
1Frames are the honest unit for memory
Activation memory scales with the number of frames held at once, so a memory table labelled in frames is internally consistent. One repository here labels its configurations that way throughout.
That makes the omission of a rate coherent rather than careless. Frames are what the model works in; seconds are what a viewer experiences.
2Published rates vary too much to assume
Rates stated in this register include fifteen, sixteen, twenty-four and thirty frames a second. A register that assumed twenty-four would be wrong about several rows and would not say so.
So a count stays a count. Anyone needing seconds has to find the rate in the code rather than in the entry.
3How the length column is filled here
Three families publish frames with no rate anywhere, three publish frames and seconds without naming a rate, five publish a rate, two publish seconds only and two publish no length at all.
Rates stated in the register run from fifteen to thirty frames a second, which is why counts stay counts. A register that assumed a convention would be wrong about several rows and would not say which.
A reading note, not an entry: no vendor value appears on this page. Where the register records this term for a particular release, it is on the length column and on that family's own page. Nearby terms: Frame rate, Clip length.