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)
