VP9 vs. HEVC

According to the following papers – HEVC is better than VP9 in coding efficiency:

1. “Coding Efficiency Comparison of AV1/VP9, H.265/MPEG-HEVC,and H.264/MPEG-AVC Encoders“, by Detlev Marpe et al, HHI
2. “PERFORMANCE EVALUATION OF H.265/MPEG-HEVC, VP9 AND H.264/MPEGAVC VIDEO CODING“, by Ahmad A. Mazhar, 2016
3. “Contemporary Video Compression Standards H.265/HEVC, VP9, VP10, Daala“, by M.P. Sharabayko et al., 2016 . Tomsk University
4. “Comparison of compression efficiency between HEVC/H.265 and VP9 based on subjective assessments“, Martin Rerabek and Touradj Ebrahimi.
5. White paper Choosing the Right Codec: Comparing HEVC & VP9

 

It’s always unclear what the authors of the above papers actually compare – video compression standards or specific codecs on specific platforms (e.g. x265 vs. vpx).
In my opinion to compare video compression standards one need analyze features list and estimates how each feature would impact on bitrate/coding efficiency and encoding time.

Let’s take for example the following feature – the number of intra prediction modes. In HEVC there are 35 intra modes while in VP9 only 10 intra modes are available. Hence, HEVC tends to exploit better spatial redundancy and consequently bitrate/coding efficiency is improved. On the other hand, the encoding time of HEVC is reduced since the search of best mode among 35 intra modes would take more cycles than that among 10 intra modes of VP9.

In comparison of HEVC vs. VP9 we can assign a pair (impact on coding efficiency, impact on complexity) to each feature. For instance for intra modes feature the pair is ( + , – ) meaning coding efficiency of HEVC improved against VP9, but the complexity of VP9 is reduced against HEVC.

At the end we can sum up pluses and minuses and derive a conclusion, e.g.  HEVC is expected to provides better coding efficiency against VP9 while VP9 is expected to reduce encoding time against HEVC.

 

HEVC Error Resilience is better than that of VP9

i see three flaws in VP9 which deteriorate error resilience: lack of start-codes, lack of slices and non-adaptivity of probabilities within a frame.

When arithmetic coding is used the error-detection lag is expected to be long (the error detection lag is a distance in MBs/CTUs/Superblocks between a place where a bitstream error occurs and the place where it’s detected). For example, a bit-flip can occur at the start of a frame but detected at the end of this frame, as a result the error-detection lag is the whole frame. If the error is detected at the middle of the frame then the second half of the frame can be filled by co-located MBs/CUTs/Superblocks (error concealment).

In the figure below error-detection latency is 2 MBs (usually the latency is much higher):

In HEVC/AVC (as well as in H264/AVC)), a bitstream error is necessarily detected either at the end of a frame when the next start code is sensed but not all blocks have been decoded or when the number of CTUs/MBs exceeding the expected amount (according to resolution), i.e. there are non-decoded blocks but the start-code already have been sensed.

In VP9 (due to lack of start codes) a bitstream error can be detected at the middle of the next frame or at the middle of next-next-frame and in such case two or more frames are corrupted (it’s worth mentioning that in HEVC in worst case a single frame is corrupted).  It’s useful to provide a sort of CRC at the start of each frame to detect bit flips.

Division into slices is extremely useful to enhance the error resilience, since corruption area is limited to the corrupted slice area (notice that a bitstream error is inevitable detected prior to start-code of the next slice). Consequently in worst case a single slice is corrupted and not the whole frame.

VP9 has a special error-resilience mode, in this mode each frame is coded with a default set of fixed probabilities (or context models in HEVC/AVC’s jargon), VP9 encoder can’t utilize probabilities from the previous frame, otherwise if the previous frame gets corrupted then the current frame is also corrupted. Consequently all frames in error-resilience VP9 mode are coded with fixed probabilities.  There is a problem with fixed context models (or probabilities), if the actual context models are close to the fixed ones then arithmetic coding is effective. If no then tons of penalty bits are produced (the penalty can be assessed via Kullback–Leibler divergence). Consequently, VP9 entropy coding is non-effective due to lack of adaptivity.

In HEVC/AVC, even if start probabilities strongly differ from the actual ones, CABAC quickly adapt itself to the actual and coding gets optimal.

Feature Analysis/Comparison – Advantages of HEVC against VP9:

1) VP9 does not support slices while HEVC (and other standards like AVC/H.264) does support. Therefore MTU-matching, ultra low-delay modes, parallelization and error resilience in VP9 is challenging.

2) Tiles in VP9 are not self-contained since prediction is not broken across vertical boundaries while it’s broken across horizontal boundaries (actually a rows of tiles is self-contained but tiles in the row are not independent). In HEVC each tile is self-contained since the prediction is completely broken across all tile boundaries (excepting deblocking but the deblocking filter can be optionally switched off across tile boundaries). Consequently the parallization in HEVC can be exploited better than in VP9.

3) In VP9 tiles are uniformly divided (tiling grid is uniform) while in HEVC the tile grid can be divided in a custom manner. Hence HEVC encoder can adapt the tiling grid such that workload balancing is exploited better (most of scenes consist of complex and easy areas)

4) Number of intra prediction modes is 10 while in HEVC the amount of intra prediction is 35.

5) In HEVC an adaptive smoothing filter is applied on neighboring samples of an intra-prediction block (excepting 4×4 blocks).  The intention of this filtering is to avoid steps in the values of reference samples that could potentially generate unwanted directional edges in the prediction block and consequently deteriorate coding efficiency and visual perception. In VP9 no filtering on neighboring samples exist.

6)  In HEVC a custom quantization matrix can be applied in quantization process, where each DCT coefficient is quantized with its own step. However, in VP9, the custom quantization is almost absent (you can specify different quantization steps for DC and AC). It is well known that the human visual system is less sensitive to distortion of high-frequency components than that of low-frequency components. This property has been utilized in almost all standards (e.g. in HEVC and in AVC) by means of the custom quantization matrix.

7)  Assymetric Inter Prediction is absent in VP9

8) Weighted Prediction is absent in VP9

9) SAO is absent in VP9

10)  In HEVC probabilities are updated within frame to approach to optimal probabilities. However, in VP9 the probabilities are fixed within a frame and can be changed only at frame level.This is a real flaw of VP9. Indeed, in VP9 at random access frame (key frame) a default context is chosen (otherwise this frame can’t be the random access point since its probabilities are dependent on previous frames) if the context (the probabilities) is close to the actual probabilities then the entropy coder is near-optimal. However, in most cases the default context is pretty far to the actual probabilities. In such case VP9 entropy coder is sub-optimal within the whole frame and would produce tons of penalty bits.

Feature Analysis/Comparision – Advantages of VP9 against HEVC:

Segmentation – this is a strong tool to exploit super-block header redundancy especially on scenes with still background.

 

Appendix:  Running VP9 with ffmpeg

vp9 encoder is activated via ‘-c:v libvpx-vp9’

Running with constant-quality mode (CRF), frame rate 50, (CRF is activated with ‘-b:v 0’ and ‘-crf x’), in CRF mode instant video bitrate is unlimited and depends on complexity of the scene:

ffmpeg -r 50 -s 1920×1080 -i  crowdrun1080p50fps.yuv -c:v libvpx-vp9  -b:v 0 -crf 15 -y crowd.webm

 

Running with constrained constant-quality mode, say you wish to deliver video with near constant quality -crf 15 but not crossing 10Mbps (-b:v 10M), quality can be worse than crf=15:

ffmpeg  -r 50 -s 1920×1080 -i  crowdrun1080p50fps.yuv -c:v libvpx-vp9  -b:v 10M -crf 15 -y crowd.webm