Re-sampling H264 video to reduce frame rate while maintaining high image quality

A lot has changed since this posting in 2012. I am adding this answer for people like me who find this from the search engines. I had good luck with the following:

ffmpeg -y -i source.mp4 -r 25 -s 160x90 -c:v libx264 -b:v 3M -strict -2 -movflags faststart destination.mp4

Here’s a short explanation on what every parameter does:

• -y : overwrite output files without asking
• -i source.mp4 : input file name
• -r 25 : output frame rate (in frames per second)
• -s 160x90 : output frame size (in pixel) - inserts the scale video filter
• -c:v libx264 : output video encoder
  • -c:v is short for -codec:v and -vcodec
• -b:v 3M : video bitrate (in bit/s) passed to libx264 encoder
• -strict -2 : governs standards compliance; -2 allows experimental features - required to enable native FFmpeg AAC audio encoder in builds older than version 2015-12-05, see here, AAC is now the default audio encoder.
• -movflags faststart : move the index to the beginning of the output file (mov and mp4 format specific parameter)

For more details see the official documentation.

As Andy T indicated, you absolutely must re-encode the video, but that does not mean that the quality must be reduced in any noticeable manner.

First, ensure you are not using old software. Video codecs are a fast moving field with significant advanced every few weeks. x264 is currently the most advanced video encoder software available. It's probably what mplayer uses, but you can get the most recent real release from www.x264.nl

[Edit: HEVC and AV1 are now the most advanced technologies available. As I said, these are fast-moving fields!]

First, I would use VirtualDub to decompress to a lossless video type, which will make for a pretty large file. VirtualDub can also reduce the frame rate. See here.

Next, use this as the input to x264. I suggest you use helper software like Staxrip (put the most recent 32-bit 8-bits-per-channel x264 in StaxRip\Applications\x264.

If you want the absolute best quality with smallest file size where you are unlikely to notice the difference, use a command line like this (with x264):

x264 --preset placebo --tune film --crf 22 --level 4.1 --threads 1 --thread-input --sar 12:11 --output "<target>" "<source>"

Staxrip has options switch the preset to placebo, tune for film sources (assuming this isn't an animation of course), and to reduce thread count to 1.

You can change "--crf 22" to 21 for a larger, better quality video, but I've found CRF22 to be about the point where I have a very hard time noticing the difference, even when comparing frame-by-frame. Any change in the the other settings will probably reduce quality or increase file size without boost in quality. Increasing the number of threads will greatly improve encoding speed (on multi-core systems obviously), but will very slightly reduce quality (or in this case, because we are using CRF which is quality-based, will increase file size a little bit, like under 1% for 4 threads).

Most companies that encode video or that make products that encode video really have no idea what they are doing, and even if they did, they don't have the CPU power needed to do an encode with these settings, so in addition to the modest reduction in file size by frame rate reduction, you will also get a sharp drop in file size from using a smart encoder with the strictest settings.

If you want to make absolutely certain that the resulting video looks as close to VirtualDub's output as possible, no one can tell the difference using CRF17, but the file will be pretty large. You might as well just zip VirtualDub's output (well, not that bad!).