How to Create Broadcast Quality Video with MainConcept H.264 Encoder V1.0
At MainConcept, our team is already working on porting the plugin to run natively on the latest Apple Macs using the M1 chipset based on ARM architecture. Having this universal solution available will allow the huge community running DaVinci Resolve on macOS to work with the MainConcept Codec Plugin on future generations of Apple computers. Want to learn more? Read the datasheet or download the free demo today.
MainConcept H 264 Encoder V1 0 Download Pc
UPDATE: While you're strongly encouraged to actually read this article and learn about the various settings and tradeoffs, many people just want to download the settings. With that in mind, you can download VideoEncoderSettings-202103.zip which has the article's settings in a form suitable for importing into HandBrake with x264, which we currently use, as well as Compressor with x264Encoder, which we used back in 2012 when this article was first written.
So, we start with bitrates which match the most common link speeds, then leave 20% headroom for protocol overhead (which can be as much as 16% on ADSL) and contention during busy times. Assuming 80% of peak link performance has long been a good real-world guide, and US FCC data from 2011 confirms that's still the case (see chart). We then only use 80% of the remaining 80% (so just 64% of the original advertised link speed), leaving the extra 20% as "bitrate headroom" to allow the video to download safely ahead of what the target bitrate needs on average, to cover bitrate fluctuations and spikes during hard-to-encode parts of the video, such as rapid motion. Again, experience shows 80% is a good, safe but not overly conservative choice (some assume as much as 90% is safe, while Netflix seems to use a conservative75%).
Internet link speeds continue to rise rapidly, so while our chosen bitrates are higher than some other video web sites, for quality's sake, they're still quite reasonable. Based on Akamai data from 2010, the average real-world downloading speed (after protocol overhead) is already 8+ Mbps in Japan, South Korea and Hong Kong, 4.6 Mbps in the USA and Canada, somewhere around 4 Mbps in Western Europe, 2.9 Mbps in Australia and 2.6 Mbps in Russia. Even 3G cellphone networking is around 2 Mbps on average, although it's highly variable. The average American can therefore already view the 720p high-definition versions of our videos without waiting, and the average Australian or Russian the 480p versions. The average insuch statistics is skewed by the high speeds, of course, since it's an exponential curve, but even so, about one third of Internet connections in modern countries are over 5 Mbps real-world downloading speed, which is enough for the 720p HQ versions, and 70% are over 2 Mbps and therefore can definitely view the 480p versions without waiting. Even in Australia, where broadband speed is more uneven and the average lags behind most modern countries, government statistics from 2011 indicate 89% of users can view the 360p versions without any waiting (1.5+ Mbps link speed), and 45% can instantly view the full 1080p versions (8+ Mbps link speed).
The choice of video encoder software has an extremely large impact on final quality, probably more than any other choice except bitrate. We use and recommend the excellent, open-source x264 encoder, which is essentially the gold standard of H.264 video encoding today, and has been for several years. Since 2006, x264 has consistently won the annual MSU MPEG-4 AVC/H.264 Video Codecs Comparison competition every year, along with numerous other codec comparisons and reviews. Its nearest rival is generally the MainConcept H.264 encoder used in applications such as Adobe Media Encoder and Microsoft Expression Encoder. While MainConcept is also a very good encoder, x264 reliably produces slightly better quality at any given target bitrate, both subjectively (IMHO) and as objectively measured by whatever metric is being used in the comparison (PSNR, SSIM etc).
x264 is also fast, with SIMD vector instructions used for most primitive operations, along with good multi-threading which achieves a near-linear speedup during the second encoding pass on multi-core and multi-processor systems (video encoding is naturally a highly parallel problem, of course, which makes parallelizing it pretty easy). x264 is very fast for a software encoder, and actually competitive with dedicated encoding hardware if fast settings are used, while achieving better quality. We, of course, use much slower settings to achieve the highest possible quality, but we still appreciate the speed of x264.
Single-pass, variable-bitrate encoding is fast and produces reasonably good quality, but the single pass means the encoder must guess what might be coming in the future and make reasonable allowances "just in case", since the encoder isn't psychic and doesn't know the content of the rest of the video. It won't know one part is a particularly easy scene, while another part is a hard scene to encode, so easy-to-encode scenes tend to get too many bits relative to the harder scenes, where those bits would have done more good.
With 2-pass encoding, the encoder makes an entire pass through the video before writing a single bit to the output file, precisely in order to learn exactly where the bits would be spent most effectively (which scenes are the hard ones etc). Unless you're in a high-volume situation where reducing the encoding time really matters, or a live situation where you can't know what's coming, if you can afford to wait, the longer encoding time of 2-pass variable-bitrate encoding is definitely worth it and results in significantly better quality.
The H.264 profile is a compatibility issue. It defines the capabilities required of the player, that is, which features of the full H.264 format the player must support in order to play the file. Naturally, the encoder can't use any features which the player isn't guaranteed to have, so using a higher profile uses more features to give better quality at the same target bitrate, but prevents some older or lower-end players from playing the file altogether...
Limiting the peak bitrate is a necessary evil, required in order to limit the severity of spikes and overruns of the target bitrate during hard-to-encode sections of the video, such as rapid motion. Video codecs like H.264 naturally vary the bitrate over the course of the video to dedicate more bits to the frames that need them most, which is critical to achieving high quality. In a web playback scenario, however, whether it's adaptive streaming or the more usual progressive download while playing, we can't let the bitrate fluctuate too wildly, because severe spikes or sustained overruns of the target bitrate might cause playback to pause (for buffering), and pausing is much worse from an end user's point of view than a bit of blurring during a high-motion scene.
432p-1080p: double the target bitrate with a 1.5-second buffer (1.5x peak bitrate), which is generous on the assumption our 20% bitrate headroom will cover most spikes and general fluctuations, so only really problematic, sustained overruns need to be clipped by the encoder (at a loss of quality).
PAUSING RISK: The settings for 432p-1080p are fairly generous and probably cause almost no spike clipping for most content at the encoder level, leaving only our 20% bitrate headroom. If anything, we're leaning slightly towards better overall quality at the risk of possible pausing for buffering on the very slowest links within each link-speed range. If the user was to jump into the middle of the video and land in a high-motion scene which temporarily uses double the target bitrate, the player would start playback then suddenly pause and have to wait while it buffered. A setting of something like 1.5x the target bitrate and a 1-second buffer would be a safer, more conservative setting, although even that wouldn't completely prevent the "jump into high-motion scene" risk, which is almost unavoidable, really.
x264's default is a simple hexagon, but it's widely acknowledged that x264's implementation of uneven multi-hexagon search is one of its biggest advantages over other encoders, and usually achieves within 0.5% of full exhaustive search. The quality-oriented presets, including the x264Encoder QuickTime plug-in's "optimized" presets, all use uneven multi-hexagon search.
As mentioned above, in the end, high-quality video encoding at lowish bitrates is all about finding areas of similarity and reusing them. The larger the search area, the more likely the encoder will find a good match, leaving a less complex residual image to be encoded and therefore producing better quality at the given target bitrate, but the larger search will also take much longer to run. High-definition material benefits from a larger search range more than lower resolutions, naturally, because the same camera or object movement covers more pixels in a high-resolution situation. x264's default is 16 pixels, but note that for uneven multi-hexagon search the search pattern is changed and iterated at several different levels, so the range isn't literally 16 pixels exactly.
Motion-vector refinement controls how much time and effort the encoder should put into macroblock partitioning decisions and final motion-vector refinement for H.264's quarter-pixel motion vectors. A more thorough evaluation of the possible final motion vectors will find better matches, producing better motion vectors, leading to a less complex residual image left to encode after motion compensation, and therefore better quality at the given target bitrate. Naturally, a more thorough evaluation will also take a lot longer during encoding. Ultimately, this setting and the previous two (search pattern and search range) are where the "rubber meets the road" in terms of the quality-vs-encoding-time tradeoff. This is where we pay for the higher quality of our encodings.