Use this rate control mode if you are targeting a specific output file size, and if output quality from frame to frame is of less importance. This is best explained with an example. Your video is 10 minutes (600 seconds) long and an output of 200 MiB is desired. Since bitrate = file size / duration:
While -preset chooses the best possible settings for you, you can overwrite these with the x264-params option, or by using the libx264 private options (see ffmpeg -h encoder=libx264). This is not recommended unless you know what you are doing. The presets were created by the x264 developers and tweaking values to get a better output is usually a waste of time.
best bitrate for 1080p h264 vs x264
Download: https://urluss.com/2vzB56
This will effectively "target" -crf 23, but if the output were to exceed 1 MBit/s, the encoder would increase the CRF to prevent bitrate spikes. However, be aware that libx264 does not strictly control the maximum bit rate as you specified (the maximum bit rate may be well over 1M for the above file). To reach a perfect maximum bit rate, use two-pass.
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).
UPDATE: Providers sometimes change the bitrates they offer based on experience and feedback from thier users. For example, a couple of years after this article was written, Netflix split their 1080p 4800kbps offering into two normal/HQ variants, at 4300kbps and 5800kbps, and reduced their 720p HQ offering at the same time, down from 3600kbps to 3000kbps. Then a couple of years after that, Netflix started to do content-specific encoding for popular content, to save bandwidth in cases like 2D animation and simple "talking head" content. The bitrates recommended above, however, remain an excellent choice.
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).
The H.264 level is a compatibility issue related to speed and resolution. Whereas the H.264 profile (above) defines the video compression features the player must support, the H.264 level defines the peak bitrate the player can handle, along with the maximum resolution, and the maximum number of reference frames held in memory during playback (see later section). x264's default is to automatically set the output file's level based on the peak bitrate, resolution, number of reference frames, and other settings. There's no reason to change this setting, but it's a good idea to document the levels used.
x264's default is not to limit the peak bitrate at all, except for the x264Encoder QuickTime plug-in's iPod presets which limit it to 10 Mbps with a 256k buffer, which is the limit of the hardware decoder in the video iPods and iPhone 1/3G (ie: H.264 level 3.0, see H.264 level above). Most people and encoding tools recommend a peak bitrate of double the target average bitrate, a few only 1.5x, and some no limit at all.
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).
1080p Superbit: 25 Mbps to keep within H.264 level 4.0 (works out to 1.25x the already very high target bitrate), with a 30-Mbit buffer which is the minimum size allowed for Blu-ray players and therefore should be safe for most 1080p hardware decoders (works out to 1.2 seconds).
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.
Using a longer "lookahead" for this per-macroblock bitrate analysis increases quality by allowing more effective fine-grained, per-macroblock use of the available bitrate, but encoding will take longer and use significantly more memory, particularly at high resolutions (there are over 8000 16x16 macroblocks in a single 1920x1080 high-definition frame, after all). x264's default is 40 frames, with diminishing returns as the distance increases to about 60 frames, and no practical gain beyond that.
x264's default is 250 frames (8.3 seconds at 30fps), but for no good reason the x264Encoder QuickTime plug-in's default is only 60 frames (2 seconds). The x264 team have recently been using 500 frames (16.7 seconds) for their settings at the annual MPEG-4 AVC/H.264 Video Codecs Comparison competition, but that's definitely pushing things a bit too far. Digital TV normally uses 1 or 2 seconds, but that's deliberately quite short to make channel switching fast and to have quick error recovery in case of interference. DVD uses a very short 0.5 second keyframe interval, and Blu-ray 1 second, because they use very high bitrates (so quality isn't an issue) and they want to guarantee good fast-forwarding behavior despite being read from a relatively slow optical disc. The most common recommendation for Internet video is 10 seconds.
Ultimately, high-quality video encoding at lowish bitrates is all about finding similar image areas in previous frames, and reusing them. The search pattern is the pattern used during motion estimation to search for the most similar area to each macroblock in each possible reference frame, in order to select the best motion vector for each macroblock. This is where a great deal of encoding time is spent. More thorough search patterns 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. Of course, a more thorough search also takes a lot longer during encoding.
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.
The H.264 format allows the encoder to use predicted motion vectors instead of actually encoding each vector explicitly, which saves some bits and thus slightly improves quality. The prediction can be either spatial (predict from neighboring blocks) or temporal (predict from previous frames). x264's default is spatial, but it also offers an automatic mode which selects the best choice for each frame (requires 2-pass encoding).
x264's default is 3 reference frames, which is also what YouTube uses. iTunes uses 4 for 1080p, but only 2 for 720p, presumably for compatibility with older, slower computers (Apple also avoids CABAC at 720p, presumably for the same reason, and uses a high bitrate to compensate). Taking this to an extreme, iTunes uses just 1 reference frame for 480p, which is ridiculous since playing 480p H.264 baseline video should be relatively easy for any modern computer. Perhaps Apple are just being ultra-conservative in case something becomes a problem in the future, and they want their fallback SD videos to be as undemanding as possible in terms of required performance, but not using even 2 reference frames is taking things way too far! 2ff7e9595c
Comments