Excepting the “ultrafast” preset, which does not use B-frames and was dropped from the charts as an extreme outlier, all of the presets created files that varied by less than 0.2% in bitrate. I did several two-pass 2500 kbps encodings using the x264 presets distributed with the x264 command line encoder (version 0.110.1820 fdcf2ae). The sequences are designed to torture video codecs: scenes include splashing water, flames, slow pans, detailed backgrounds and fast motion. All of these sequences are from lossless original sources, so we are not re-compressing the artifacts of another video codec. So I created a 720p video comprised of several popular video test sequences concatenated together. Given the large amount of source video we need to convert as part of the project, finding the optimal trade-off between encoding speed and quality with x264-based encoders ( x264 itself, FFmpeg, MEencoder, HandBrake, etc.) is important.

The open source x264 is widely considered the state of the art in H.264 encoders. As of today, this means using H.264-based video for best compatability and quality (although WebM might become an option in a year or two). I’m scoping a project that will require re-encoding a large training video library into HTML5 and Flash-compatible formats.

Ffmpeg h264 quality