Living with VP9

[Blue_MiSfit]

Hey folks,

I'm looking to learn more about using VP9 for general purpose encoding. To that end I'm going to share what I've learned so far, and hope that others will share their experiences!

I've been working on using VP9 as an alternative to HEVC due to licensing issues and have been mostly impressed.

I'm doing 360 video encoding, which has very large frame sizes (2880x2880 to 4096x4096). At the data rates that we're targeting, AVC totally falls apart. HEVC is quite good, and VP9 is somewhere in the middle, but definitely closer to HEVC.

I've had a few issues with VP9 - namely rate control. Even with 2 pass, some clips undershoot by more than 50%. Sometimes they're transparent, and sometimes they're not. Does anyone have words of wisdom on how to improve this? Or is it just "how it is"?

Also, I've learned that by default in ffmpeg libvpx-vp9 defaults to a max keyframe interval of 9999 frames, which is ideal for compressibility but awful for usability I'm setting -g 250 to make it match x264 and x265.

I've also noticed that the first pass in VP9 encoding seems to be single threaded, making it very slow. The second pass, however, does thread relatively well - at least on my quad core Skylake dev box.

I'm using an x64 Zeranoe ffmpeg build on Windows, and this seems to work well, but I've noticed it includes libvpx version 1.5.0 which was released last November. There seems to be active development. Should I look into building my own libvpx?

I've found decoding performance to be excellent. At similar resolutions and frame size I've found that VP9 requires less CPU power than HEVC. This is all using LAV Filters + MadVR in MPC-HC x64 on Windows 10. For example:

*2880x2880p30 at 15 Mbps takes 10-12% CPU for me using VP9, and HEVC takes 14-15%.
*4096x4096p60 at 15 Mbps takes 50-52% CPU using VP9, and HEVC maxes out the CPU and drops frames everywhere.

Any words of wisdom?

[mandarinka]

The terrible rate control is a known thing. AFAIK there is no solution.

Supposedly the main user of libvpx VP9 encoding is youtube and I heard that they rolled some custom override hack that completely bypasses the upstream rate control. So that probably contributes to this defect not being addressed.

[Motenai Yoda]

ffmpeg should permitt to override the rc too with
-rc_override and -rc_eq

-rc_override[:stream_specifier] override (output,per-stream)

    Rate control override for specific intervals, formatted as "int,int,int" list separated with slashes.
Two first values are the beginning and end frame numbers, last one is quantizer to use if positive,
or quality factor if negative.

rc_eq string (encoding,video)

    Set rate control equation. When computing the expression, besides the standard functions defined in the
section ’Expression Evaluation’, the following functions are available: bits2qp(bits), qp2bits(qp).
Also the following constants are available: iTex pTex tex mv fCode iCount mcVar var isI isP isB avgQP qComp
avgIITex avgPITex avgPPTex avgBPTex avgTex.

also you can try to use the constrained fixed quality/quantizer mode and set your crf and bitrate cap

ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 10 -b:v 1000k -c:a libvorbis output.webm

from webmproject.org

CQ mode is a special variant of VBR. It is designed as a fire-and-forget mechanism for encoding a
large set of clips such that, as much as possible, the output stays within given quality and size constraints
across the set. CQ mode exposes an additional parameter (--cq-level), and the meaning of the --target-bitrate
parameter changes to be the “target maximum rate”.

In CQ mode the encoder will try to encode normal frames (all frames apart from key frames, golden frames
and alternative reference frames) at a quantizer / quality level of --cq-level, provided that this does not cause
the bitrate to rise above the target maximum value. Key frames, golden frames and alt ref frames may be coded
at a lower “q” value, but the minimum is still linked to the user-selected value, and in all cases --min-q
and --max-q are treated as hard limits. In practice this means that easy clips may undershoot the target
maximum bitrate, because they are constrained by the CQ level, but harder clips will be bounded by the target
maximum data rate and will increasingly revert to standard VBR behavior.

CQ mode is available for one-pass encodes, but is generally intended for two-pass. For one-pass, CQ applies
the user cq-value, but can’t adapt to a higher value if the clip is difficult.

In the two-pass variant of CQ mode there is a further refinement. If the first pass analysis suggests that a clip is
too difficult to be encoded at the user-selected --cq-level, then rather than code part of the clip at this level
and the rest at a much lower quality, it tries to pick a sustainable “auto-cq” level. Under no circumstances will
this “auto-cq” value drop below the user-selected value.

anyway try with -qmin 0 and -undershoot-pct 95

edit: seems not -rc_override nor -rc_eq works with libvpx