Google VP9 "Next Generation Open Video" information posted

[Selur]

iirc they mainly determine how well threading is possible during decoding and row-mt was responsible for threading during encoding,..

[Mawazi]

Does -tile-columns and -tile-rows serve any purpose, when using -row-mt?
I don't see any difference in encoding speed and cpu utilization.

I experienced a decent boost in encoding speed with --row-mt=1, --tile-columns=6, and --threads=16. This is with a 4-core, 8-hyperthreads Intel. As far as I know, --tile-rows doesn't do much, as VP9's multithreaded encoding is column based.

[mzso]

I experienced a decent boost in encoding speed with --row-mt=1, --tile-columns=6, and --threads=16. This is with a 4-core, 8-hyperthreads Intel. As far as I know, --tile-rows doesn't do much, as VP9's multithreaded encoding is column based.

How about if you drop tile-columns? It made no difference to me. Row-mt gave the cpu utilization boost.

[mzso]

Is it normal for stuff that fades in to look this crappy, or is something going wrong on my end?
https://drive.google.com/open?id=1x3lReEfj12ifkIaeELgoGBj1CRbFJ_JH

(It sucks with AVC too BTW: https://drive.google.com/open?id=1n-rB7cgezgGQUuy3Kd_dj3P98PPCJ7R4)

[LigH]

New upload: VPx v1.7.0-120-g167594414

[Mawazi]

How about if you drop tile-columns? It made no difference to me. Row-mt gave the cpu utilization boost.

My initial testing with a number of permutations lead me to the numbers that I use, though I don't know (and can't find any documentation for) the default number for tile-columns once row-mt is activated. I assume it's at least two or you wouldn't see any difference at all.

[Mawazi]

Is there a way to add color-range (limited/tv vs full/pc) to vp9 encodes using vpxenc? I require pc range for an encode I'm doing. I know this is possible using ffmpeg, but I'm unsure if color-range is a part of the vp9 bitstream or just part of the container, or both I suppose, and without compiling my own ffmpeg there is no row-mt or tune film options in the binaries of ffmpeg I can track down, so I'd like to use vpxenc.

[mzso]

Is there a way to add color-range (limited/tv vs full/pc) to vp9 encodes using vpxenc? I require pc range for an encode I'm doing. I know this is possible using ffmpeg, but I'm unsure if color-range is a part of the vp9 bitstream or just part of the container, or both I suppose,

You mean color range metadata? You can't "add" color range itself.


and without compiling my own ffmpeg there is no row-mt or tune film options in the binaries of ffmpeg I can track down, so I'd like to use vpxenc.
This isn't true. Plain old zeronae builds have row-mt, just used it a few days ago.
Also there's a "-tune-content film" option.

[mzso]

By the way. I tested lossless encoding with vp9, but it had some 36% higher filesize (570MB vs 420MB) than a lossless encode with libx264.

Is VP9 this poorly suited to lossless encoding, or have something likely gone awry?

[LigH]

VPx v1.7.0-177-g2640f2507

[LigH]

VPx v1.7.0-217-g223f9e367

[LigH]

VPx v1.7.0-250-g933619766

[mandarinka]

Is it normal for stuff that fades in to look this crappy, or is something going wrong on my end?
https://drive.google.com/open?id=1x3lReEfj12ifkIaeELgoGBj1CRbFJ_JH

(It sucks with AVC too BTW: https://drive.google.com/open?id=1n-rB7cgezgGQUuy3Kd_dj3P98PPCJ7R4)

VP9 (and I think AV1 is the same here, sadly) lacks weighted prediction, which is a special coding tool for fading. Without weighted prediction, the fade generates a lot of residual for every frame and the usual compression scheme fails to efficiently handle it, so the residual has to be quantized strongly, which means aggressive lossy compression and more artifacts.

If weighted prediction works right, the fade should look much better if the encoder tries to use it (weighted prediction is available in AVC and HEVC, but fast encoding profiles might not use it). Also if your source already has the fade ruined, you are out of luck.

[wiak]

For AOM, a range of 5..8 was recommended to me to speed up remarkably. But VPx may either not support such levels, or it may decrease the quality too much...
i just use 0 ;P

[mzso]

VP9 (and I think AV1 is the same here, sadly) lacks weighted prediction, which is a special coding tool for fading. Without weighted prediction, the fade generates a lot of residual for every frame and the usual compression scheme fails to efficiently handle it, so the residual has to be quantized strongly, which means aggressive lossy compression and more artifacts.

If weighted prediction works right, the fade should look much better if the encoder tries to use it (weighted prediction is available in AVC and HEVC, but fast encoding profiles might not use it). Also if your source already has the fade ruined, you are out of luck.

I used the preset slower as usual, which gave me this result. (which apparently resulted in this: weightb=1 / weightp=2 /)
Not sure what they mean, if anything since I never change anything other than quality and presets.

[LigH]

@wiak:

Too late to discuss that. Pages ago people mentioned this CLI option possibly being abandoned.

[cherishjoo]

How much is it than H.264 or H.265?

[LigH]

How much is it »better« than H.264 or H.265?

"I accidently ... is that dangerous?" :D

I don't have much own practical experience, but believe that VP9 can be (depending on parameters, and comparing vpxenc with other specific encoders) better than x264, yet slower than x265, and x265 can beat it for most kinds of material at similar bitrates, I read.

[LigH]

VPx 1.7.0-291-g3b460db21

[LigH]

VPx 1.7.0-309-ge4408a07b

[LigH]

Did you want to ask that in the AOM thread?

[mzso]

Did you want to ask that in the AOM thread?

Yeah...

[bstrobl]

Looks like VP9 has been smuggled into the iOS Youtube App, allowing HDR Videos on some devices.

[Blue_MiSfit]

How do you know it's VP9 and not HEVC? I'd be utterly shocked if apple allows you to do VP9 via DASH on iOS! They certainly don't have a hardware decoder.

[bstrobl]

How do you know it's VP9 and not HEVC? I'd be utterly shocked if apple allows you to do VP9 via DASH on iOS! They certainly don't have a hardware decoder.

The iOS app has a stats for nerds option. Video codec is declared as webm VP9.2 on HDR content with AAC audio.

Edit: Furthermore Apple is part of AOM, so they most likely softened up a bit. And it’s not like they don’t do HEVC with software on devices that are much slower.

[iwod]

https://www.reddit.com/r/apple/comments/8iclij/youtube_now_supports_hdr_on_iphone_x/dyrir7l/

[LigH]

VPx v1.7.0-387-ge27a33177

[benwaggoner]

The iOS app has a stats for nerds option. Video codec is declared as webm VP9.2 on HDR content with AAC audio.

Edit: Furthermore Apple is part of AOM, so they most likely softened up a bit. And it’s not like they don’t do HEVC with software on devices that are much slower.
Wow, I wonder what the battery hit is like. And VP9's lack of b-frames and weird vertical slices don't make for efficient parallelization in software decoders.


All HDR capable iOS devices have HEVC Main10 hardware decoders, so choosing a built-in software decoder would not be a technically-driven decision.

[iwod]

Wow, I wonder what the battery hit is like. And VP9's lack of b-frames and weird vertical slices don't make for efficient parallelization in software decoders.


All HDR capable iOS devices have HEVC Main10 hardware decoders, so choosing a built-in software decoder would not be a technically-driven decision.

Very very very bad. Basically kills the iPhone within 1 to 2 hours of Youtube and making it extremely hot. As mentioned in Reddit.

However it doesn't seems everyone is getting it. May be it is only on new iPhone models?

I guess Apple had to support it since Youtube is only providing with H.264 encodes for below 2K resolution and 2K+ with HDR with VP9.

[IgorC]

I was surprised (in a good way) after visiting Netflix tech blog.

They make strong accent on VP9 in pretty every article that includes video compression topics. Good news for VP9. :)
Like here https://medium.com/netflix-techblog/optimized-shot-based-encodes-now-streaming-4b9464204830
or https://medium.com/netflix-techblog/dynamic-optimizer-a-perceptual-video-encoding-optimization-framework-e19f1e3a277f

I can speak from my own experience about Netflix and VP9 on smartphone. Long battery life and very good quality. Thumb up.

[iwod]

I was surprised (in a good way) after visiting Netflix tech blog.

They make strong accent on VP9 in pretty every article that includes video compression topics. Good news for VP9. :)
Like here https://medium.com/netflix-techblog/optimized-shot-based-encodes-now-streaming-4b9464204830
or https://medium.com/netflix-techblog/dynamic-optimizer-a-perceptual-video-encoding-optimization-framework-e19f1e3a277f

I can speak from my own experience about Netflix and VP9 on smartphone. Long battery life and very good quality. Thumb up.

Which is basically All Smartphone apart from iPhone.

[IgorC]

Google is so sorry about Apple users that their own company doesn't care to support open formats. Netflix is next to be sorry about that and many others. What an unfair world for Apple company.

[iwod]

Google is so sorry about Apple users that their own company doesn't care to support open formats. Netflix is next to be sorry about that and many others. What an unfair world for Apple company.

I am pretty sure you are talking about VP9 here, and not the AV1 from Open Media Alliance.

And VP9 is less open then H.264. Free /= Open.

[LigH]

VPx v1.7.0-426-g19222548a

[Motenai Yoda]

They make strong accent on VP9 in pretty every article that includes video compression topics. Good news for VP9. :)
Yep but then you'll find this
Encoding parameters used in VP9-libvpx were taken from a previous study; its findings were presented at Netflix’s “Open house on royalty-free codecs” in Oct. 2016. Based on that study, which used the same set of 10 full-titles for testing as those chosen for the first experiment reported earlier, the best configuration to use is “fixed-QP, AQ-mode=0, CPU=0, best”, shown to produce highest quality both in terms of PSNR and VMAF quality metrics. The following figures show the effect in terms of average BD-rate loss when choosing different parameters in VP9-libvpx encoding.
as they don't even complaing enabling alt-ref frames for the 2 pass test which give a HUGE quality boost, not even playing with qcomp.
So what their comparisons mean?

[LigH]

VPx v1.7.0-455-g3ac2b5701

[IgorC]

Yep but then you'll find this

as they don't even complaing enabling alt-ref frames for the 2 pass test which give a HUGE quality boost, not even playing with qcomp.
So what their comparisons mean?
Maybe. I didn't know about that.

[LigH]

New upload:

VPx v1.7.0-541-gdd3d08f0c (https://www.mediafire.com/file/954xksf29sycch6/vpx_v1.7.0-541-gdd3d08f0c.7z)

[LigH]

New upload:

VPx v1.7.0-653-g03e1bd397 (https://www.mediafire.com/file/aah5mhq7966mvbn/vpx_v1.7.0-653-g03e1bd397.7z)

[LigH]

New upload:

VPx v1.7.0-747-g3ff77503c (https://www.mediafire.com/file/6qawi539y3c1lid/vpx_v1.7.0-747-g3ff77503c.7z)

[LigH]

New upload:

VPx v1.7.0-798-gaab2aff9a (https://www.mediafire.com/file/aad9r0rd0380wc0/vpx_v1.7.0-798-gaab2aff9a.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)

[LigH]

New upload:

VPx v1.7.0-1002-gb3a837cbf (https://www.mediafire.com/file/m4yuadzqm3xijj2/vpx_v1.7.0-1002-gb3a837cbf.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)

[mzso]

New upload:

VPx v1.7.0-1002-gb3a837cbf (https://www.mediafire.com/file/m4yuadzqm3xijj2/vpx_v1.7.0-1002-gb3a837cbf.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)

Any meaningful improvements these days?

[LigH]

A lot (https://chromium.googlesource.com/webm/libvpx/+log) cleanups, fixes, improvements ... but I don't know any especially "meaningful" changes in detail, did not study this list.

[LigH]

New upload:

VPx v1.7.0-1064-g3448987ab (https://www.mediafire.com/file/78tm3motdli975m/vpx_v1.7.0-1064-g3448987ab.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)

[LigH]

New upload (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0):

VPx v1.7.0-1137-g4a47ef814 (https://www.mediafire.com/file/w8hcpwvh8an1yj6/vpx_v1.7.0-1137-g4a47ef814.7z)

[LigH]

New upload (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0):

VPx v1.7.0-1288-g811759d86 (https://www.mediafire.com/file/kd7xa41jm2sbxdj/vpx_v1.7.0-1288-g811759d86.7z)

[LigH]

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

VPx v1.7.0-1507-gc62d9d568 (https://www.mediafire.com/file/jtm7p8b5qlc74ap/vpx_v1.7.0-1507-gc62d9d568.7z)

[utack]

Netflix dropped a new article.
H264/H265/VP9 comparison using HVMAF with reference encoders and production encoders.
libvpx is doing mediocre'ish, EVE does well
Relative Bitrate savings for low and high quality using three test sets:
https://i.imgur.com/Cf7fQ9V.png


https://medium.com/netflix-techblog/performance-comparison-of-video-coding-standards-an-adaptive-streaming-perspective-d45d0183ca95

[benwaggoner]

Netflix dropped a new article.
H264/H265/VP9 comparison using HVMAF with reference encoders and production encoders.
libvpx is doing mediocre'ish, EVE does well
Relative Bitrate savings for low and high quality using three test sets:
https://i.imgur.com/Cf7fQ9V.png


https://medium.com/netflix-techblog/performance-comparison-of-video-coding-standards-an-adaptive-streaming-perspective-d45d0183ca95
Now VMAF gives different scores for mobile, 1080p, and UHD screen sizes. They don’t seem to specify which they used here.
Or perhaps this was done with an older VMAF implementation?

I’m having a hard time figuring out what settings they are actually using. It sounds like it’s fixed QP, with one psychovisual parameter added for each “perceptual” tuned mode. So are x264 and x265 fixed QP encodes with psy-rd=1? Is aq-mode=0? And really QP instead of CRF? And when aiming for PSNR, why not --tune psnr which is EXACTLY for that scenario! Psy-rd=0 is NOT tuning for PNSR!

And odd libvpx gets to use 2 passes while everything else is 1. Although that wouldn’t really matter that much if it’s truly a fixed QP encode with no rate control. But if using --tune psnr for x26? multipass encoding should help mean and harmonic mean PSNR.

This seems a quite poor study for predicting the real-world subjective quality different encoders can produce, as it will substantially underestimate the achievable perceptual quality the x26x codecs can deliver in the real world. I’d expect just adding --tune film to x264 would improve VMAF a bunch in the perceptual case.

It sort of conflates encoder psychovisual tuning and bitstream capabilities. I imagine a port of x264’s psyovisual stuff to a vp9 encoder would offer big improvements, like was seen when x264 algorithms got ported into x265.