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.
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.