Are there only a few standard video frame rates?

Question

In modern digital video, can a video file be marked with any arbitrary frame rate? Or are only a few specific frame rates widely supported? By "modern" I mean software players like Quicktime, VLC, Roku, game consoles, etc. I'm curious both what the video standards themselves say are allowed frame rates and then what actually works in practice.

I understand that 24 fps, 25 fps, 30 fps, 50 fps, and 60 fps are widely supported standards. HandBrake also offers 5, 10, and 15; are those standard options? Could I use any FPS number I want? And what about the non-integer rates like 23.976 and 29.97; are they actually treated differently by software than 24 and 30? Also I see references to "variable frame rate" in H.264 streams; does that actually work and if so, what uses it?

My specific question is what the best way is to encode some 8mm film scans. The source is 16 fps, the 8mm film standard. Right now I'm doubling every other frame to bring it up to 24 fps which works OK, but I'm wondering why I can't just mark the video as 16 fps. FWIW I've produced H.264 mp4 files with Handbrake at 15 fps and found they only played back correctly in VLC. Mac Quicktime played them too fast, probably 24 fps.

Answer 1

There are several "standard" frame rates, but there are getting to be so many that supporting arbitrary framerates is easier than specifically supporting many specific ones. This is especially true for software players, like VLC.

More and more support exists for VARIABLE fps. (VFR, variable frame rate). This is where the interval between frames within the same video isn't a constant. Many video container file formats (like Matroska (.mkv) or MPEG-4 (.mp4, closely related to Apple's .mov)) don't even store a FPS number, but rather a time base (e.g. 1/30th of a second), and then each frame has a timestamp as a multiple of that time base. It just so happens that the interval between each frame is one or a small integer number of units of the time base in a CFR (constant frame rate) video.

Security-camera footage with near-duplicate frames dropped would be an obvious use-case for VFR. Even moreso if it's being compressed with a simplistic video codec that doesn't take good advantage of temporal redundancy (with inter (p and b) frames). (play around with ffmpeg -vf mpdecimate to drop near-dup frames. Use -vsync 2 if outputting to mp4, because for some reason it isn't the default for that muxer, but it is for mkv.)

Another case is modern smartphones. For example, my brother's Moto G (2nd gen) records VFR videos. It lowers the frame rate when the sensor needs more light. Some of the output from running mediainfo on an mp4 created by the phone's software, recorded indoors:

Bit rate                                 : 9 999 Kbps
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Rotation                                 : 90°
Frame rate mode                          : Variable
Frame rate                               : 16.587 fps
Minimum frame rate                       : 14.985 fps
Maximum frame rate                       : 30.030 fps

Playback of a single VFR video stream is not hard. The software just gets the next frame ready to display, sleeps until it should be displayed, then wakes up and displays it.

Things get a bit more complicated when you take into account the fact that humans can only see video frames when a monitor displays them. VFR monitors exist, but are still rare. (google for g-sync freesync).

Changing the displayed image while it's being scanned out to the monitor results in ugly tearing of the video (commonly seen when playing a game with vsync off). This limits a player to changing the displayed image at 50 or 60Hz. (CRTs support arbitrary vrefresh rates, within a range, but it's complicated to cook up modes with all the timings correct, so most people just used a few fixed refresh rates. And now people have LCDs which only support a fixed refresh rate anyway. Until freesync monitors are more widespread anyway. I'm really looking forward to that. :)

So with video frame rates that aren't a multiple or a factor of the monitor refresh rate, some frames will be displayed for 3 monitor refreshes, and some for 2, for example, even if the video is meant to be at a constant 25FPS (on a 60Hz monitor).

Things get more complicated when you want to work with multiple clips and fade between them, or picture-in-picture, or various other effects. It's a LOT easier to write video editting software if you can assume that all the clips have a new frame at the same time. (They force clip alignment to snap to whole frames).

This is why NLEs (like kdenlive or pitivi, to pick random Free software examples), are more likely to force you to a fixed FPS, and drop/duplicate frames from your clips to make them match that frame rate. The CFR you choose can be arbitrary, but it typically has to be constant for the whole "project".

(Do any NLEs fully work with VFR clips, and produce VFR output in that case?)

So in summary, once we have variable-sync monitors and OSes, the only thing holding us back will be video editting, I guess. And broadcasting, since apparently CFR is a big deal for that, too?

In case you're wondering, the 29.970 (actually 30000/1001) and 23.976 (actually 24000/1001, from telecining) annoying non-integer frame rates are the fault of color NTSC. search for 1.001. If only they'd been willing to risk a few B&W sets not being able to handle an extra 0.1% frequency for the audio subcarrier, the world would have been spared this nonsense. (I think I saw another article somewhere that made it sound more like many sets would have been fine, but they weren't sure about perfect compat. Wikipedia makes it sound like no sets would have handle a 0.1% higher audio subcarrier. IDK the facts.)

Annoying frame rates are one of the lesser sins of broadcasting, though. It's really interlacing that's been the bane of video quality on modern (all pixels lit at once) screens, and that wouldn't have changed. I still don't get why interlacing was kept around for HDTV. Why was 1080i60 was ever defined, instead of using 720p60 to get the same temporal resolution for sports and stuff? It's similar to 1920x540p60, but with a stupid vertical offset between odd and even fields that requires a lot of computation on the receiving end to make it not look horrible.

edit:

For your use-case, I'd absolutely suggest archiving at the native FPS. Don't throw away any information by dropping frames. Don't dup frames and make your files bigger (or make your h.264 encoder spend more time noticing the duplicates and outputting a frame full of skip macroblocks that only takes 20 bytes for the whole frame).

In the future when we hopefully all have freesync displays that can play any framerate, you'll want to undo your pullup to 24fps so your video plays more smoothly! Or if freesync somehow doesn't catch on, or the display that comes after LCDs is CFR, then rate conversion is probably best done at playback time anyway. It's not like 24fps even plays perfectly on a 60Hz monitor. (I don't visually notice the fact that some frames are displayed for 3 * 1/60th while some are displayed for 2 * 1/60th, but it's true).

If you're having problems with Quicktime, then IDK. Maybe make sure Handbrake is making files with the right framerate set in the h.264 bitstream, as well as the container. (Yes, h.264 headers can apparently store a frame rate, separate from what the container says. See the docs for mkvmerge --fix-bitstream-timing-information. And try using it with --default-duration 16fps to make an mkv file. Then mux that back to mp4 and see if that fixes quicktime?) Or maybe there's a way to do it with mp4 tools in the first place. See for example: https://askubuntu.com/questions/370692/how-to-change-the-framerate-of-a-video-without-reencoding

I can guarantee that arbitrary frame rate mp4 is valid, and even variable framerate mp4 is valid. If Quicktime plays it wrong, it could well be Quicktime's fault. Or maybe Handbrake's fault for making the file wrong. I usually just use ffmpeg directly, because I'm a command line ninja.

Answer 2

By history 24 FPS come from kino (movies). The film was in phototape and the speed was selected to make movements smooth.

25 FPS come from the frequency of power in Europe , 50 Hz (50 FPS is from same source, but actually double it). Actually TV in Europe was 50 FPS but half frames, they are interlaced

30 FPS come from the frequency of power in USA, 60 Hz (60 FPS is from same source, but actually double it). Actually TV in USA was 60 FPS but half frames, they are interlaced

16 FPS is not so wide spread as standard for professional purposes, so maybe thats the reason it is not in use in most of current software. Moreover such FPS will not "smooth" enough the fast movement. I have one crazy idea how you can make 16 FPS to match better 24. Juts get every even and odd frames and make something like average between them :)

Answer 3

To answer your question - yes, you can generally encode a video file in any frame rate you'd like. (Though some software may choose to limit you to make the software simpler.) The question is will the delivery format you choose support it, and will the playback device support it?

If you have 8mm film at 16 fps, I'd encode it at 16 fps if I knew the playback devices I wanted to support could handle it. If not, I'd probably use software that supported optical flow (sometimes called motion estimation) to encode it at 24 fps, which is likely the nearest frame rate likely to be supported by encoding software, decoding software, and most playback hardware.

Software (or hardware) that supports optical flow will generate in-between frames based on the motion of objects in your video. Rather than either repeating a frame or even blending 2 frames, it generates a new frame that is usually pretty close to what would have actually been recorded had you recorded at the output frame rate.

Answer 4

There are set television and film video standards that most videos conform to. A computer can often display video from multiple framerates, however some TVs may have trouble with odd-ball frame rates as they may use more specialized display circuitry. Even on a computer, the frame rate actually displayed may not match up with that of the video file, depending on the supported refresh rates of the monitor.

Yes, the non-integer frame rates are displays differently. They are known as drop frame and they exist primarily for legacy reasons. When played back, one frame is dropped (from timecode) every so often in order to make up the time difference and the frames are spread at the proper rate to keep it smooth. This more has to do with sync stuff in legacy formats though and preventing sync issues that are no longer relevant.

You can use non-standard frame rates and it should play back fine on PCs but it will not conform to standard video for things like Bluray and may not play back well on some TVs. (And even on those it works on, it will likely do a pull down in real time to conform to a standard frame rate, where as a pulldown done in advance would likely result in better quality.)

Answer 5

Your question is not about common rates, it is about what rate you should use to digitize your movie. The answer: you should use the original rate if possible, because you want to preserve the source in digital form. Then you can convert it to whatever frame rate you need for viewing. In the olden times it would usually mean 24fps for theatrical presentation and 29.97fps, interlaced for video. Nowadays you can do almost anything, but you need to have a good source, that matches the original as cleanly as possible.

Answer 6

Now when we have VRR (G-sync and Freesync) it is not such a problem (works in mpv natively), but yes, there are standard frame rates used by DCI (Digital Cinema Initiatives), it is 24000/1001, 24.000, 60000/1001, 60.000, 50 interlaced PAL, 30000/1001, 30.000, 120.000 and 120000/1001. That is all. Now, of course you should preserve the original frame rate. But are you sure it actually what you think it is?

Answer 7

A few other notes. First, 48 fps is becoming more popular and common thanks to The Hobbit and now YouTube's support for the framerate. Secondly, 30 fps is usually actually 29.97 fps and 60 is usually about 59.94.