Google VP9 "Next Generation Open Video" information posted

[benwaggoner]

Originally Posted by Tommy Carrot

I don't know what exactly --auto-alt-ref does, but setting it to 6 makes the popping or frame strobing effect, which is probably the biggest problem of VP9, significantly less noticeable.

I believe it dynamically determines the optimal alt-ref ("golden") frame. Which should exactly reduce strobing artifacts, by providing a superior frame for other frames to be predicted from.

Over-tuning for mean per-frame PSNR tends to result in some strobing, because improving quality of reference frames pays off more than non-reference frames.

Dark Shikari had a great blog post about that way back when.

[Beelzebubu]

Originally Posted by benwaggoner

I believe it dynamically determines the optimal alt-ref ("golden") frame. Which should exactly reduce strobing artifacts, by providing a superior frame for other frames to be predicted from.

This is what --auto-alt-ref=1 does; --auto-alt-ref=N for N>1 enables multi-level hierarchical frame ordering, with the number of layers being equal to N. This is known to improve coding efficiency, HEVC/H264 use it also (pyramid frame ordering).

[Selur]

Thanks for that info!

[Blue_MiSfit]

Typical Google - I really wish they would have usable documentation for all of this stuff! Who wants to dig through mailing lists and forum posts to have any idea how to properly do VP9 encoding??

Glad to see libvpx continuing to improve in any case, particularly when it comes to rate control.

[benwaggoner]

Originally Posted by Beelzebubu

This is what --auto-alt-ref=1 does; --auto-alt-ref=N for N>1 enables multi-level hierarchical frame ordering, with the number of layers being equal to N. This is known to improve coding efficiency, HEVC/H264 use it also (pyramid frame ordering).

So, N=maximum number of alt-ref frames that can be currently used, ala the --ref parameter in x264?

I wish VP9 had a x265.readthedocs.io equivalent .

And a translation guide would be helpful as well. The VPx codecs wind up trying to do the same essential thing as MPEG codecs, but structured differently to get around patents.

[Mr_Khyron]

https://github.com/OpenVisualCloud/SVT-VP9

The Scalable Video Technology for VP9 Encoder (SVT-VP9 Encoder) is a VP9-compliant encoder library core. The SVT-VP9 Encoder development is a work-in-progress targeting performance levels applicable to both VOD and Live encoding/transcoding video applications.

The SVT-VP9 Encoder is being optimized to achieve excellent performance levels currently supporting 10 density-quality presets (please refer to the user guide for more details) on a system with a dual Intel® Xeon® Scalable processor targeting:

• Real-time encoding of up to two 4Kp60 streams on the Gold 6140 with M8.

SVT-VP9 Encoder also supports 3 modes:

• A visually optimized mode for visual quality (-tune 0)

• An PSNR/SSIM optimized mode for PSNR / SSIM benchmarking (-tune 1 (Default setting))

• An VMAF optimized mode for VMAF benchmarking (-tune 2)

[Mr_Khyron]

https://phoronix.com/scan.php?page=n...P9-Open-Source

At the start of the month Intel open-sourced SVT-AV1 aiming for high-performance AV1 video encoding on CPUs. That complemented their existing SVT-HEVC encoder for H.265 content and already SVT-AV1 has been seeing nice performance improvements. Intel now has released SVT-VP9 as a speedy open-source VP9 video encoder.

Uploaded on Friday was the initial public open-source commit of SVT-VP9, the Intel Scalable Video Technology VP9 encoder. With this encoder they are focusing on being able to provide real-time encoding of up to two 4Kp60 streams on an Intel Xeon Gold 6140 processor. SVT-VP9 is under a BSD-style license and currently runs on Windows and Linux.

Earlier today I added now the SVT-VP9 test profile for benchmarking this new VP9 encoder via the Phoronix Test Suite. I've been testing SVT-VP9 on a few Intel/AMD Linux systems so far today and the early results are extremely promising.

[Beelzebubu]

Originally Posted by benwaggoner

So, N=maximum number of alt-ref frames that can be currently used, ala the --ref parameter in x264?

Yes, it's somewhat similar to that. Note that the distance between equi-level ref-frames isn't necessarily the same, so it's not exactly the same. (I can explain this a bit further if I'm not making sense here.)

I wish VP9 had a x265.readthedocs.io equivalent .

Good luck getting Google to spend effort on that .

[edit]

Maybe I'm being unfair in that last comment, bit snarky also, so allow me to re-phrase that. I guess Google would have hoped that if they provide engineering talent, that other community contributors would have done these things that make it more widely useful but aren't necessary for Google internally. Obviously this never happened, but it would make sense from Google's perspective to hope for some more community participation than they've seen.

[benwaggoner]

Originally Posted by Beelzebubu

Good luck getting Google to spend effort on that .

[edit]

Maybe I'm being unfair in that last comment, bit snarky also, so allow me to re-phrase that. I guess Google would have hoped that if they provide engineering talent, that other community contributors would have done these things that make it more widely useful but aren't necessary for Google internally. Obviously this never happened, but it would make sense from Google's perspective to hope for some more community participation than they've seen.

Doing it with community support would make plenty of sense. It seems more likely for AV1, which has a much broader set of stakeholders and a lot more options to choose between.

[dipje]

With vpxenc (tried with 1.7.0 and 1.8.0) I get weird rate-control.. 1.7.0 was undershooting quite a bit, 1.8.0 seemed to do better but with the same source and less bitrate it starts to overshoot out of nowhere (by quite a lot).

vpxenc --cpu-used=9 --good --end-usage=vbr --auto-alt-ref=6 --target-bitrate=6000 --passes=2 --pass=1 (and 2) --aq-mode=1 --row-mt=1

I also tried adding '--cq-level=0' in there when which I've read in this thread somewhere. Am I doing something wrong (I get a videostream of 6856 kbit/sec, while x264 hits 5847 and x265 hits 5888) or is this just a VP9 thing that the rate-control might be a bit all over the place?

[Asilurr]

Originally Posted by dipje

vpxenc --cpu-used=9 --good --end-usage=vbr --auto-alt-ref=6 --target-bitrate=6000 --passes=2 --pass=1 (and 2) --aq-mode=1 --row-mt=1

1. For general-purpose encoding is recommended to set --cpu-used to [0 .. 3]. The latter, namely 3, is already reasonably fast (when properly supported by multithreading, more on this later on) while still maintaining decent quality.
2. Do keep in mind that --auto-alt-ref accepts the full range of integers in [0 .. 6], not only 0/1/6. The benefits of switching from 0 to 1 are usually (most sources, at most resolutions) significantly greater than switching from 1 to any >1 value; higher values such as 6 may provide negligible gains over lower values such 2/3, in which case the speed penalty may become undesirable. As you are already instructing the encoder to be fast with --cpu-used, it's probably a saner option to set --auto-alt-ref to 1. For general-purpose encoding, I'd look at auto-alt-ref 2/3 for cpu-used 1/2 thus reserving the highest possible value of 6 to cpu-used 0.
3. It's redundant to manually specify a --pass, by setting up --passes the encoder can automatically run multi-pass encodings.
4. While --aq-mode 1/2 will occasionally (some sources, at some resolutions) provide better results, accompanied or not by --alt-ref-aq >0, for general-purpose encoding is strongly recommended to disable AQ by setting aq-mode to 0.
5. For general-purpose encoding is recommended to use explicitly --lag-in-frames 25, and also --enable-tpl 1.

Properly enabling multithreading in vpxenc/libvpx requires several parameters, not just --row-mt on its own. In addition to setting row-mt to 1, it's needed to set up the tiles too and that can be achieved as it follows: explicitly disable tile rows (--tile-rows 0), and explicitly enable tile columns instead (set --tile-columns to 5/6, 5 is already enough for 99.9999% of encodings; do note that the encoder will automatically use as many horizontal tiles as permitted by the horizontal resolution, i.e. width, of the source. In practical scenarios, the encoder will restrict tile-columns to [0 .. 3] much more often than not because that corresponds to sources up to 16:9 2160p). Lastly, enable explicitly --threads by setting up a high value, for instance 64 (do NOT change --threads according to the number of actual logical cores of the machine used for encoding, set up a high value and the encoder will spawn automatically as many threads as it needs). Wrapping it up, this is how multithreading should be set up for file-based encoding (nota bene, chunk-based encoding is addressed differently): --tile-rows=0 --tile-columns=5 --row-mt=1 --threads=64.

The rate control of vpxenc/libvpx is peculiar, to say the least. It works better with quantizers (--end-usage cq/q, plus --cq-level [desired CRF], plus --min-q and/or --max-q [desired QP]) than with bitrates (--end-usage vbr/cbr, plus --target-bitrate, plus --undershoot-pct and/or --overshot-pct, plus --bias-pct). The absolute best results are achieved through chunk-based encoding (i.e. the very way vpxenc was designed to be used), rather than the file-based encoding that would be expected by normal people (a very non-specific alias for consumers). Yes, it's probably fair to state that "rate control in libvpx sucks", as long as it's understood that attempting to achieve strict rate control in file-based encoding will undershoot/overshoot much more often than not especially when using lax parameters (for instance only --target-bitrate on its own, without the other RC tools).

Belated disclaimer: my insight of vpxenc/libvpx is purely empirical, gained from using them extensively myself on various sources, at various resolutions, with various parameter sets. Professionals such as Ronald can provide technical insight, if you can actually persuade them to do so.

[LigH]

New upload (MSYS2; MinGW32: GCC 7.4.0 / MinGW64: GCC 8.3.0):

VPx v1.8.0-226-g7969c6e0b

[Leeloo Minaï]

Originally Posted by LigH

New upload (MSYS2; MinGW32: GCC 7.4.0 / MinGW64: GCC 8.3.0):

VPx v1.8.0-226-g7969c6e0b

Thanks for your work !

Is there any changelog about VP9 evolution ?
Each new build is slower than its predecessor... I expected that there could be some speed optimization all over the time and not the contrary

[LigH]

The commit log is at https://chromium.googlesource.com/webm/libvpx

[singhkays]

I'm getting VMAF score of VP9 video which is less than H.264 at 500Kbps using highest quality settings on each. Anyone encounter this before?

the ffmpeg 2-pass settings for

x264 - VMAF score 72.8

./ffmpeg -i scene1.mp4 -c:v libx264 -an -b:v 500k -filter:v scale=720:-1 -preset placebo -pass 1 -f mp4 -y /dev/null /
&& ./ffmpeg -i scene1.mp4 -movflags +faststart -pix_fmt yuv420p -c:v libx264 -an -b:v 500k -filter:v scale=720:-1 -pass 2 -preset placebo ./x264/scene1/x264_500k.mp4

vp9 - VMAF score 67.1

./ffmpeg -i scene1.mp4 -c:v libvpx-vp9 -an -b:v 500k -filter:v scale=720:-1 -row-mt 1 -quality best -cpu-used 0 -tile-columns 2 -threads 8 -pass 1 -f webm -y /dev/null && /
./ffmpeg -i scene1.mp4 -pix_fmt yuv420p -c:v libvpx-vp9 -an -b:v 500k -filter:v scale=720:-1 -row-mt 1 -quality best -cpu-used 0 -tile-columns 2 -threads 8 -pass 2 ./vp9/scene1/vp9_500k.webm

This seems completely unexpected! I've attached both encoded files below




VMAF was then measure with the following command

../../ffmpeg -i vp9_500k.webm -i ../../scene1.mp4 -filter_complex "[0:v]scale=1920x800:flags=bicubic[main];[main][1:v]libvmaf=model_path=/home/kay/vmaf/model/vmaf_v0.6.1.pkl" -f null - >>vmaf-scene1.txt -hide_banner

The encoded files can be downloaded from here https://github.com/Netflix/vmaf/file...oded-files.zip

[poisondeathray]

Originally Posted by singhkays

I'm getting VMAF score of VP9 video which is less than H.264 at 500Kbps using highest quality settings on each. Anyone encounter this before?

the ffmpeg 2-pass settings for

x264 - VMAF score 72.8

./ffmpeg -i scene1.mp4 -c:v libx264 -an -b:v 500k -filter:v scale=720:-1 -preset placebo -pass 1 -f mp4 -y /dev/null /
&& ./ffmpeg -i scene1.mp4 -movflags +faststart -pix_fmt yuv420p -c:v libx264 -an -b:v 500k -filter:v scale=720:-1 -pass 2 -preset placebo ./x264/scene1/x264_500k.mp4

vp9 - VMAF score 67.1





This seems completely unexpected! I've attached both encoded files below




VMAF was then measure with the following command

../../ffmpeg -i vp9_500k.webm -i ../../scene1.mp4 -filter_complex "[0:v]scale=1920x800:flags=bicubic[main];[main][1:v]libvmaf=model_path=/home/kay/vmaf/model/vmaf_v0.6.1.pkl" -f null - >>vmaf-scene1.txt -hide_banner

The encoded files can be downloaded from here https://github.com/Netflix/vmaf/file...oded-files.zip

something buggy about your vp9 encode , and the frames are not aligned at the end between x264 and vp9 . You didn't upload the immediate source, but both encodes have duplicate frames that aren't in the movie

You can decode to uncompressed or lossless I-frame like utvideo and compare them

ffmpeg gives warning when encoding the vp9 version too

#invalid length 0x11 > 0x3dfb4 in parent

[Beelzebubu]

Originally Posted by poisondeathray

something buggy about your vp9 encode

Sometimes the timebase is different. You can ignore timestamps by using "settb=1/30,setpts=N" as extra lavfilters in your commandline for each of the two video streams.

[poisondeathray]

Originally Posted by Beelzebubu

Sometimes the timebase is different. You can ignore timestamps by using "settb=1/30,setpts=N" as extra lavfilters in your commandline for each of the two video streams.

Still buggy . More frame drops now, gaps in motion, and the framecount does not match when setting timebase and pts

You can index it with avisynth/vapoursynth, but frames still don't match

I suspect he had issues with the immediate source

[user1085]

What is the proper way to multithread in 2019? Is it possible to achieve 100% cpu usage on 8 cores? Also, I read somewhere that frame parallel is not needed anymore. Is that correct?

[singhkays]

Originally Posted by poisondeathray

Still buggy . More frame drops now, gaps in motion, and the framecount does not match when setting timebase and pts

You can index it with avisynth/vapoursynth, but frames still don't match

I suspect he had issues with the immediate source

I think I fixed it. I changed the VP9 in WebM container to VP9 in MP4 container and getting expected VMAF scores now

72.8 for x264 vs 74.7 for VP9