So what do these results mean? Well, first of all, yeah, sure, x265/libvpx are ~50% better than x264, as claimed. Vertically, we see bitrate improvement, the metric we introduced previously, basically a combination of the quality (SSIM) and bitrate, compared to a reference point (x264 veryslow is the reference point here, which is why the bitrate improvement over itself is 0%). Horizontally, you see encoding time in seconds per frame. This is a graph people don’t talk about often, so let’s do exactly that. Let’s measure that! So, I picked a target bitrate of 4000kbps for each encoder, using otherwise the same settings as earlier, but instead of using the slow presets, I used variable-speed presets (x265/x264: –preset=placebo-ultrafast libvpx: –cpu-used=0-7). It’s not that they don’t want better bitrate/quality ratios, but rather, they complain that when they try to switch, it turns out these new codecs have much slower encoders, and when you increase their speed settings (which lowers their quality), the gains go away. Let’s be honest here: x264 is an incredibly well-optimized encoder, and many people still use it. Encoder devs don’t like to talk speed and quality at the same time, because they don’t go well together. These differences are small compared to the improvement of either encoder over x264, though. At high bitrates, libvpx outperforms x265. We can also see slight differences between x265/libvpx for this clip: at low bitrates, x265 slightly outperforms libvpx. As bitrates go up, the improvements go down. The distance between the red/green lines and blue line get larger as the bitrate goes down, so the codecs have a higher bitrate improvement at low bitrates. x265 gets approximately the same improvement over x264 as libvpx at this bitrate. Ergo, libvpx is 49% better than x264 at this bitrate, this is called the bitrate improvement (%). So, to accomplish the same SSIM score (quality), x264 needs 49% more bitrate than libvpx. Interpolation gives an estimated point for SSIM=18.16 around 2920kbps, which is 49% larger. For example, the red point at 1960kbps has an SSIM score of 18.16. By how much? So, we typically try to estimate how much more bits “blue” needs to accomplish the same quality as (e.g.) “red”, by comparing an actual point of red to an interpolated point (at the same SSIM score) of the blue line. Let’s first compare our two next-gen codecs (libvpx/x265 as encoders for VP9/HEVC) with x264/H.264: they’re way better (green/ref is left of blue, which means “smaller filesize for same quality”, or alternatively you could say they’re above, which means “better quality for same filesize”). As test clip, I used a 2-minute fragment of Tears of Steel (1920×800). highest-quality) setting (x264/5: –preset=veryslow libvpx: –cpu-used=0), all forms of threading/tiling/slicing/wpp disabled, and a 5-second keyframe interval. For the purposes of this comparison, I compared libvpx (VP9), x264 (H.264) and x265 (HEVC), each using 2-pass encodes to a set of target bitrates (x264/x265: –bitrate=250-16000 libvpx: –target-bitrate=250-16000) with SSIM tuning ( –tune=ssim) at the slowest (i.e. Now, when I say “codecs”, I really mean “encoders”. By drawing these bitrate/quality value pairs in a graph, we can compare video codecs. The recommended objective metric for video quality is SSIM. Scientifically, we typically encode one or more video clips using standard codec settings at various target bitrates, and then measure the objective quality of each output clip. The most important question for video codecs is quality. Fortunately, that concern has been addressed! So here, I will compare encoding (quality+speed) and decoding (speed) performance of VP9 vs. The elephant-in-the-room question since then has always been: what about HEVC? I couldn’t address this question back then, because the blog post was primarily about decoders, and FFmpeg’s decoder for HEVC was immature (from a performance perspective). We also talked about encoding performance (quality, mainly), and showed VP9 significantly outperformed H.264, although it was much slower. A while ago, I posted about ffvp9, FFmpeg‘s native decoder for the VP9 video codec, which significantly outperforms Google’s decoder (part of libvpx).
0 kommentar(er)
