Google VP9 "Next Generation Open Video" information posted

[CruNcher]

Nothing for the masses really in its overall price/performance balancing
Also well still need to understand how efficiently Ryzen will work together MultiGPU and how especially the ACE will interact between IGPU/CPU and Discrete sharing workloads and balancing them efficiently supporting each other, where Nvidia has 0 connection point with Intel and Nvidia mostly hacking up and workaround stuff :)

[NikosD]

Intel's HEDT processors, those ultra expensive 6, 8, 10 core processors, will be the first victims of RyZen beasts.

With Intel's prices ~1700 $ and very expensive motherboards, those processors are dead on arrival of RyZen.

Besides very specific AVX/AVX2 performance, those Intel's CPUs are a completely meaningless choice.

[nevcairiel]

will interact between IGPU/CPU and Discrete sharing workloads and balancing them efficiently supporting each other, where Nvidia has 0 connection point with Intel and Nvidia mostly hacking up and workaround stuff :)

Ryzen doesn't have a iGPU.

Ryzen is at a point between Intels consumer models and the HEDT platform. It offers 8 cores at a price somewhere in the HEDT range (ie. latest rumors put EU prices at ~600€ for the 1800X, which is slightly above a i7 6850k, or the 1700X for ~470€ which sits similar to a 6800k), but on the other hand it doesn't have some of the HEDT features like extra PCIe lanes for multi-GPU.

[CruNcher]

Raven Ridge (Ryzen APU) will have it based on most probably VEGA IP and run on every since then released AM4 Ryzen Mainboard
The basic Zen CPU is not that highlight but that combination combined with a Discrete HBM2 GPU and the workloads it allows Async efficiently powered by Vulkan ;)

[NikosD]

In order to not misinform anyone we must put the facts as they are.

The 8c/16t RyZen 1800X with 3.6GHz base clock and 4.0GHz turbo has a TDP of 95W and will cost ~600€

The 8c/16t Intel i7 6900K with 3.2GHz base clock and 3.7GHz turbo has a TDP of 140W and costs ~1200€

So, the Intel's equivalent for most workloads of RyZen 1800X has double price.

In other words, dead meat.

[leonccyiu]

Intel's HEDT processors, those ultra expensive 6, 8, 10 core processors, will be the first victims of RyZen beasts.

With Intel's prices ~1700 $ and very expensive motherboards, those processors are dead on arrival of RyZen.

Besides very specific AVX/AVX2 performance, those Intel's CPUs are a completely meaningless choice.

What about Ultra HD Blu-ray and Netflix in 4K? I read that they require Kaby Lake for copy protection, even Intel's HEDT platform doesn't work with either of those it's frustrating.

[nevcairiel]

What about Ultra HD Blu-ray and Netflix in 4K? I read that they require Kaby Lake for copy protection, even Intel's HEDT platform doesn't work with either of those it's frustrating.

It requires the Kaby Lake GPU, which the HEDT CPUs obviously don't have, since they don't have any iGPU.

With any hope dedicated GPUs from NVIDIA and AMD can also certify for that soon.

[hajj_3]

Netflix has given a talk about VP9 using low bitrates for static scenes: https://www.engadget.com/2017/03/01/netflix-mobile-good-video-bad-connection/

They haven't made a blog post about it, at least not yet.

[CruNcher]

Nothing new Really going 100 kbps on such a device when complexity is low the screen size allows it to hide most artifacts and if it's to blurry post sharpening will help it perceptually for the viewer but watching that 100 kbps stream then at 1080p or UHD and you will see all issues, HDMI out ;)

And if you show something like this to your normal press guy audience of course they'll be impressed.

Though absolutely nothing new Mobile Hype ;)

Per Pixel spatial temporal resolution overhead depending on the Viewing conditions see this for example the bigger the screen and resolution the more it will start to fall apart in motion

https://www.sendspace.com/file/050xe5

This is also why Metrics need to be taken into account with the actual Viewing condition and some already do that, especially for Mobile a low PSNR/SSIM can be sufficient enough your target surely doesn't need to be in the 50 or 0.99 range for that small display size of a Mobile device to be accepted as OK by the viewing audience if it's not showing significant prediction errors that distract ;)

As it turns out, Netflix seems to have cracked the code, and in a way that feels sort of obvious.

The thing to remember is that not all movies (or TV shows, for that matter) are created equal. Long, lingering static shots obviously aren't as complex as fight scenes, but to date, Netflix has been encoding those videos as though they were the same.

Geez no wonder trump want's to ban journalists, what for a snake oil seller capability that guy has explaining the difference between CBR and VBR + Psy optimization ;)

Especialy how he doesn't let Netflix look bad for what they did in the Past and Sold but glorifies them to the Olymp with the "they cracked the code" geez crazy ;)


But overall if you dig deeper you read out of what that show up actually was about ;)

It is about the Integration of VMAF results as Metric for at least the Complexity Masking inside of their VP9 Encoder for their further encodings so instead of PSNR and SSIM or (enter something else) they gonna use their VMAF based (Deep Learned) approach as Encoder Psy tuning internally which makes sense, for what would they have developed it else.

[LigH]

Don't miss the point that CBR (or "constricted VBR") is the rather obvious approach for delivering content over limited bandwidth. Less constricted VBR would only be applicable for rather huge buffers.

[Blue_MiSfit]

Yep, switching away from CBR / small buffer+maxrate VBR to true (almost) unrestricted 2 pass VBR is a big advantage in the download scenario. Long, fully adaptive GOPs also help.

ABR encoding is typically done with fixed GOP so the work can be parallelized across many servers (aka split and stitch) while still maintaining GOP alignment. In download we don't care about GOP alignment so we can let the encoder really stretch its legs :)

[CruNcher]

Yes but the core of this Presentation was their VMAF Research Investments

[dapperdan]

Some multithreaded encoding improvements for VP9 encoding:

https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/oiHjgEdii2U

[dapperdan]

Netflix (who also are namechecked in the above multi-threading email) talk a little about their use of VP9 for Android downloads here:

http://techblog.netflix.com/2017/03/downloads-on-android.html

Most of it is about Android development, but there's a few parpagraphs on VP9 under the heading "Improving Video Quality".

[mandarinka]

https://groups.google.com/a/webmproject.org/forum/#!topic/webm-discuss/G_fuix013KM

Seems libvpx is getting improved threading for VP9 encoding. No idea if it is something similar to slices or WPP, or to actual frame threads. Anybody knows what the details are?

[Mystery Keeper]

https://groups.google.com/a/webmproject.org/forum/#!topic/webm-discuss/G_fuix013KM

Seems libvpx is getting improved threading for VP9 encoding. No idea if it is something similar to slices or WPP, or to actual frame threads. Anybody knows what the details are?I don't. But I think their approach is dumb. What I want is this (https://bugs.chromium.org/p/webm/issues/detail?id=1393).

[mandarinka]

That method was actually provisionally used in x265, in 2013.
But I think it was only for purposes of early realtime encoding demos.

It was eventually removed, probably because of the huge downsides in memory consumption. And the fact that for offline encoding, it is more practical to just encode in parts?

[Mystery Keeper]

That method was actually provisionally used in x265, in 2013.
But I think it was only for purposes of early realtime encoding demos.

It was eventually removed, probably because of the huge downsides in memory consumption. And the fact that for offline encoding, it is more practical to just encode in parts?That's not trivial to automate. I don't even know how I could merge the encoded cuts.

[Clare]

I'm doing some tests over a selection of 30 clips encoded at different crf values in order to compare them.

On PSNR-HVS-M, x265 is slightly better than VP9:
https://i.imgpile.com/nw6d14.png

But if we look at the VMAF score, VP9 is squeezing more quality per bit:
https://i.imgpile.com/nw6hx2.png

I was surprised, I thought x265 would have beat VP9 by a margin on VMAF, especially considering its psychovisual optimizations.

[dapperdan]

Have VP9 (and AV1) been working on doing better on VMAF? With Netflix adopting them it wouldn't be that surprising if tweaks or bug-fixes that particularly affect VMAF got prioritized.

The question then is if it is "teaching to the test" and therefore not a valid quality increase, or if VMAF is good enough to direct them towards genuine improvements that agree with subjective viewers.

[Motenai Yoda]

on all samples in recent comparison of mine, 0.053bpp (rl) and 0.030bpp (anime), x265 10bit (no-sao) got the best in both, vp9 10bit is sometimes better than x265 10bit (no-sao) only on anime, but suffer for inconsistent (very low) quality, especially on high complexity + high correlation scenes, although shows very "high quality" on flashy/no-correlation ones and almost no banding at all (unlike x265), it still smooth a lot on movie sample.

Increase qcomp (bias-pct) to 1.0 (100) help a bit, but I'd like some sort of psy/aq/deblock tuning. (aq1/aq2 looks a little worse)

ps I'm talking about 2pass+altref only as 1 pass crf quality is beaten by x264 too.

[benwaggoner]

Have VP9 (and AV1) been working on doing better on VMAF? With Netflix adopting them it wouldn't be that surprising if tweaks or bug-fixes that particularly affect VMAF got prioritized.

The question then is if it is "teaching to the test" and therefore not a valid quality increase, or if VMAF is good enough to direct them towards genuine improvements that agree with subjective viewers.
VMAF looks pretty promising. But it was trained just on Netflix's standard bitrates at 1080p SDR. So it's applicability to <300 Kbps, >8 Mbps, UHD, and HDR is undetermined. Also, it was only trained on (IIRC) a few dozen ~10 sec clips. Netflix has shared some of their test clips, but not all of them, so it's hard to know if some classes of content are under- or un-represented.

I also have some concern that the base metrics it uses are largely spatial only. While VMAF does include a temporal comparison of adjoining frames, it is pretty limited, and I worry there may be kinds of temporal distortions that it might not pick up on.

That said, these are relatively theoretic concerns, and VMAF certainly appears to outperform better than standbys like the mean SSIM, and way better than PSNR.

[mzso]

How do I get libvpx to utilize more of my cpu?
The CPU usage with my new 6 core CPU is pretty pathetic. <20% I increased the -threads -tile-columns options in ffmpeg, but it didn't do anything notable.

(lib264 gets to about 50% CPU usage. Even though apparently it doesn't have any multi-threaded encoding settings.)

[wiak]

How do I get libvpx to utilize more of my cpu?
The CPU usage with my new 6 core CPU is pretty pathetic. <20% I increased the -threads -tile-columns options in ffmpeg, but it didn't do anything notable.

(lib264 gets to about 50% CPU usage. Even though apparently it doesn't have any multi-threaded encoding settings.)

you need libvpx git with row-mt
https://nwgat.ninja/compiling-libvpx-with-row-mt-multi-threading-on-windows/

[mzso]

you need libvpx git with row-mt
https://nwgat.ninja/compiling-libvpx-with-row-mt-multi-threading-on-windows/

Is there an ffmpeg build with that? (I'm familiar with ffmpeg.)

[LigH]

You could try running jb-alvarado's media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite) for yourself and check if the result contains all you need. If not, suggest it in its issue tracker.

Remember, if you build a "non-free" ffmpeg regardless of all licenses, keep it for yourself, don't distribute it. The "zeranoe compatible" option already contains more libraries than most people need ...

P.S.: Just checked one I built on August 23, it reports:

libvpx-vp9 encoder AVOptions:
...
-row-mt <boolean> E..V.... Row based multi-threading (default auto)

So I assume a current MABS build and current Zeranoe builds should contain current VPX libs which support it.

[mzso]

@LigH

Thanks. I'll check it out.

[LigH]

New file in my VPx builds archive (https://www.mediafire.com/folder/n2k6a44pxns40/VPX): v1.6.1-1258-gc8f6e7b99 (MABS: MSYS2/MinGW, GCC 7.2.0)

VP10 as separate encoder branch seems to be abandoned.

[LigH]

New build: v1.6.1-1451-gc58f01724

[hajj_3]

new Libvpx 1.7.0 released: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1003857-libvpx-1-7-0-released-with-avx-optimizations-more

[LigH]

It may have been "released"; unfortunately, branch "mandarinduck" was not yet merged with branch "master", thus tag "v1.7.0" does not yet apply to the master branch. So it's not yet available without manually switching a branch.

[mzso]

Does anyone know typically how long it takes to get into ffmpeg? By the way does ffmpeg add the libvpx library centrally or is it usually decided by whoever makes the build? (eg: zeranoe builds)

[JEEB]

Does anyone know typically how long it takes to get into ffmpeg? By the way does ffmpeg add the libvpx library centrally or is it usually decided by whoever makes the build? (eg: zeranoe builds)

There are no official binaries so whomever is building picks whatever version that gets used in a binary. The only case where some work is required from FFmpeg's side is when the API is changed enough to break build, and thus API usage changes are required.

[LigH]

When it gets available in the master branch, I will try to build ffmpeg as well as vpxenc using the media-autobuild_suite. I will report if it worked for me. If successful, the vpx binaries will be published on MediaFire; but my ffmpeg build is "non-free", I have to keep it for myself.

[mzso]

but my ffmpeg build is "non-free", I have to keep it for myself.
Only zealots care.

[LigH]

vpx v1.7.0-69-g77108f500 (https://www.mediafire.com/file/m5ux8rktjq883rb/vpx_v1.7.0-69-g77108f500.7z) is available.

[Selur]

it even adds two new options,..
--corpus-complexity=<arg> corpus vbr complexity midpoint
and
--tune-content=<arg> Tune content type
default, screen, film
sadly that is all the information about those options. :(
Does anyone know:
a. what 'corpus-complexity' is for and what are valid values for it? seems to be a boolean, so 1&0 should be the valid values
b. what content did they have in mind for the types 'default, screen, film'? (wild guessing: screen = screen captures of simple windows; film = movies; default = anything else)

Cu Selur

[LigH]

VPx v1.7.0-110-gedc9a4687

[mzso]

I just checked that the zeranoe ffmpeg builds now have 1.7.0. CPU utilization is still crap. 30% or less in total with my R5 1600.

[Selur]

@mzso: have you tried a higher '--cpu-used' value? (using higher values fives me more cpu usage, ~70%+ on R7 1800X with 1080p content, but still freaking slow encoding speeds)

[mzso]

@mzso: have you tried a higher '--cpu-used' value? (using higher values fives me more cpu usage, ~70%+ on R7 1800X with 1080p content, but still freaking slow encoding speeds)
Doesn't help. Though all cores are utulised. Per core utilization is very poor. Some cores go up to 30+% average. Some are around 15%

[Selur]

Here's the command line I used:
ffmpeg -y -loglevel fatal -threads 8 -r 24000/1001 -analyzeduration 200M -probesize 200M -i "H:\00005.m2ts" -map 0:0 -an -sn -vsync 0 -strict -1 -pix_fmt yuv422p10le -f yuv4mpegpipe - | vpxenc --codec=vp9 --row-mt=1 --passes=1 --pass=1 --end-usage=cq --cq-level=18 --target-bitrate=15000 --profile=3 --good --cpu-used=2 --min-q=0 --max-q=63 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=1 --min-gf-interval=0 --max-gf-interval=0 --threads=32 --width=1920 --height=1080 --i422 --color-space=unknown --input-bit-depth=10 --bit-depth=10 -o "H:\Temp\15_10_58_7610_01.vp9" -
Cu Selur

[mzso]

Here's the command line I used:
Cu Selur

Unless you point out something relevant this is just a lot of noise to me.

I use something like this.
ffmpeg -i <input> -acodec libopus -b:a 260k -g 30 -vcodec libvpx-vp9 -b:v 0 -threads 12 -tile-columns 4 -cpu-used 1 -crf 30 out.webm

Increasing cpu-used did nothing.

[Selur]

Seeing the settings you use, enabling row-mt might help.

[Jamaika]

I see the wrong approach. The test should be performed on the itself VPX to eliminate accidental ffmpeg errors. Input y4m.
Support speedup in sse4 has been added for the VP8 codec.

[mzso]

Seeing the settings you use, enabling row-mt might help.

It helps a bit when cpu-used is 1 (not when it's 8). So I guess it makes higher quality encodings a little faster.

Let's hope that AOM will be more readily multi-processing optimized.

[Selur]

I would go for 1 or 2 (https://www.webmproject.org/docs/encoder-parameters/) not more,..

[LigH]

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...

[Selur]

vpxenc nowadays supports:
--cpu-used=<arg> CPU Used (-16..16)
but from my experience with older vpxenc versions I would normally stick to 1-3 not more. :)

[mzso]

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.

[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.

[utack]

Now VMAF gives different scores for mobile, 1080p, and UHD screen sizes. They don’t seem to specify which they used here.

>HVMAF is computed after scaling the encodes to the display resolution (assumed to be 1080p)


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?
They are using the approach described here.
https://medium.com/netflix-techblog/dynamic-optimizer-a-perceptual-video-encoding-optimization-framework-e19f1e3a277f
As far as I understood it encodes it "shot" multiple times, adjusting target bitrate until it hits a desired VMAF

And odd libvpx gets to use 2 passes while everything else is 1
It is, probably because everything else has lookahead?



And when aiming for PSNR, why not --tune psnr which is EXACTLY for that scenario! Psy-rd=0 is NOT tuning for PNSR!
They did tune for PSNR, in part1 "Results with the traditional approach"




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 don't think you can get any of the encoders to do much better, the article from above also goes into detail about how much the internal ratecontrol/quantization choice of all encoders could be improved with their "VMAF feedback loop".

[benwaggoner]

>HVMAF is computed after scaling the encodes to the display resolution (assumed to be 1080p)
That was the prior VMAF model. The new one also has a mobile and a UHD scale and comparison.

They are using the approach described here.
https://medium.com/netflix-techblog/dynamic-optimizer-a-perceptual-video-encoding-optimization-framework-e19f1e3a277f
As far as I understood it encodes it "shot" multiple times, adjusting target bitrate until it hits a desired VMAF
But that’s just tuning in BD rate. It isn’t actually tuning any of the other parameters.

Also, VMAF itself has plenty of flaws as a metric. It doesn’t do a good job differentiating between high quality encodes, doesn’t pick up on issues with gradients well, and has other flaws. It is the best objective metric we have, absolutely. But real MOS subjective testing is required to be talking about percentage differences in BD-rate.

It is, probably because everything else has lookahead?
Unless they are using a lookahead equal to clip duration, it wouldn’t be apples to apples.

They did tune for PSNR, in part1 "Results with the traditional approach"
No. If they were actually tuning for PSNR, they would have used --tune PSNR!

I don't think you can get any of the encoders to do much better, the article from above also goes into detail about how much the internal ratecontrol/quantization choice of all encoders could be improved with their "VMAF feedback loop".
With fixed QP and no adaptive quant? I can do a LOT better than that with some tuning, and enocode a lot faster at the same time. A reasonably tuned - -preset slower would look better and be a lot faster than the --preset placebo without real psychovisual tuning they did here. By the description, I guess they turned off psychovisual features that are on by default, like aq-mode > 0. And fixed QP is a silly rate control mechanism, since the optimal average QP per frame varies a fair amount by the content in the frame. Anime needs lower QP than a jungle scene, for example (even though it can deliver lower QP at a lot lower bitrate than the higher QP of the jungle scene takes).

[Beelzebubu]

I’m having a hard time figuring out what settings they are actually using. It sounds like it’s fixed QP [..] And really QP instead of CRF?

The paper says they use CRF for x264/5. I would recommend reading the paper if you want to know all the details, it's pretty detailed.

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.

The reason people don't use 1-pass CRF in libvpx is because it's pretty broken. Try it. Several bitstream (!!) features get *completely disabled* (!!) when using 1-pass encoding using libvpx. So you get several % BDRATE quality improvements when switching from 1-pass to 2-pass CRF.

[mandarinka]

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.

If this QP + arbitrary options toggling is true, then WTF I don't even. After all these years of proper methods being discussed and after their inclusion in AOM which should give them more expertise in this, they should know better.

I would start to suspect actual malice here (marketing/PR deciding the results here?). Because they are really jumping through hoops here to not use the encoders in a way they are supposed with that QP bullshit.

[mandarinka]

With fixed QP and no adaptive quant? I can do a LOT better than that with some tuning

I think the main point is that the default settings which they made effort to override could do much better. CQP is inferior to CRF mode, that is common knowledge, one of the first things that a non-100%clueless x264/x265 user picks up. It has been established 10 years ago.

[Beelzebubu]

Is aq-mode=0?

I missed this one. According to the figure in the blog post, as well as the paper, the default encoder setting for aq-mode was used for x264/5. The only encoder where aq-mode was specifically disabled is vpxenc, probably because enabling AQ in libvpx causes BDRATE losses in both PSNR as well as VMAF.

[mzso]

Hi!

Is libvpx really poor at encoding grainy video, or is something wrong on my end? I sporadically encoded some videogame footage, or desktop screencasts, and it looked perfect to me with CRF 30.

But recently I tested with footage from a grainy film and it still looked horrible at CRF 20, and at only CRF 15 it started to look good, which is 5 times the bitrate...

The CLI is like this:
ffmpeg -i infile -g 30 -vcodec libvpx-vp9 -b:v 0 -threads 12 -row-mt 1 -cpu-used 1 -crf 30 out.webm

[benwaggoner]

If this QP + arbitrary options toggling is true, then WTF I don't even. After all these years of proper methods being discussed and after their inclusion in AOM which should give them more expertise in this, they should know better.

I would start to suspect actual malice here (marketing/PR deciding the results here?). Because they are really jumping through hoops here to not use the encoders in a way they are supposed with that QP bullshit.
It's not malice. Fixed QP without rate control has been a standard codec comparison method for ages. What I do get nervous about is results comparing encoders where one has a bunch of its features turned off to match the limitations of another, and then the results treated as meaningful.

One of the interesting artifacts of this kind of testing is we tend to build codecs where fixed QP optimizes for high mean PSNR and, to a lesser degree, high psychovisual quality. Which is a silly design goal in my opinion, because real-world encoders don't ever do that. Adaptive inter-frame and intra-frame quantization has been standard for professionally-created content for 10+ years.

So why compare codecs in a mode where EVERY block, be it in an I or non-ref B frame, has the exact same QP?

This will also overemphasize adaptive deadzone techniques, which don't show up in the bitstream. So it's not like there aren't ways to sneak in psychovisual or other optimizations; it's just that adaptive quant is disallowed.

[benwaggoner]

Is libvpx really poor at encoding grainy video, or is something wrong on my end? I sporadically encoded some videogame footage, or desktop screencasts, and it looked perfect to me with CRF 30.

But recently I tested with footage from a grainy film and it still looked horrible at CRF 20, and at only CRF 15 it started to look good, which is 5 times the bitrate...[/CODE]
Grainy video is quite hard to encode, and requires a lot of psychovisual tuning for it to look good at reasonable bitrates. It's a HUGE difference between grain/noise free screen captures. You'll always have to use some more bits for grain to look good versus a very clean source.

Since YouTube is getting UGC and thus not a lot of grainy video, I wouldn't be surprised if libpvx hasn't gotten a lot of tuning around grain. And what grain they do get is going to almost always be synthesized as a video effect, not true grain like something shot on film would have.

AV1 has some grain synthesis features that would help a lot, but IIRC they weren't in VP9.

[mzso]

Since YouTube is getting UGC and thus not a lot of grainy video, I wouldn't be surprised if libpvx hasn't gotten a lot of tuning around grain. And what grain they do get is going to almost always be synthesized as a video effect, not true grain like something shot on film would have.

AV1 has some grain synthesis features that would help a lot, but IIRC they weren't in VP9.

Too bad. It fails hard. It's essentially useless for grainy video. (And I guess we will never see whether Eve does any better)

[mandarinka]

I always wondered if Two Orioles could release a public demo build of encoder so that people could validate their quality claims for themselves. Assuming they even want that of course.

My idea was that if they made a binary that lacked SIMD assembly, it would be slow enough to be unusable for production and also not be at risk of software piracy, but it could still be used to check and compare the quality.

[utack]

I always wondered if Two Orioles could release a public demo build of encoder so that people could validate their quality claims for themselves. Assuming they even want that of course.

My idea was that if they made a binary that lacked SIMD assembly, it would be slow enough to be unusable for production and also not be at risk of software piracy, but it could still be used to check and compare the quality.

Some of the classic xiph samples encoded with EVE would also help
One screenshot on their website saying "hey this is better" does not really help

[benwaggoner]

Some of the classic xiph samples encoded with EVE would also help
One screenshot on their website saying "hey this is better" does not really help
Yeah, EVE gets talked about a lot for something for which there isn't any apparent way to actually test.

[utack]

Libvpx 1.8
https://www.phoronix.com/scan.php?page=news_item&px=Libvpx-1.8-Released

[Phanton_13]

from: https://chromium.googlesource.com/webm/libvpx/+/refs/tags/v1.8.0
- Enhancements:
2 pass vp9 encoding has improved substantially. When using --auto-alt-ref=6,
we see approximately 8% for VBR and 10% for CQ. When using --auto-alt-ref=1,
the gains are approximately 4% for VBR and 5% for CQ.

For real-time encoding, speed 7 has improved by ~5-10%. Encodes targeted at
screen sharing have improved when the content changes significantly (slide
sharing) or scrolls. There is a new speed 9 setting for mobile devices which
is about 10-20% faster than speed 8.
what? "--auto-alt-ref=6" it isn't supposed "--auto-alt-ref" to have as only valid values 1 or 0? plus the documentation don't reference to values other than 1 or 0. someone have an explanation?

[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.

[Selur]

some updated documentation really would help,... :/

[hajj_3]

2 pass vp9 encoding has improved substantially. When using --auto-alt-ref=6,
we see approximately 8% for VBR and 10% for CQ. When using --auto-alt-ref=1,
the gains are approximately 4% for VBR and 5% for CQ.

Are these percentages compression improvements or speed improvements. If compression improvements then that would be very nice indeed. Are these benchmarks for live encoding or non-live encoding?

[Selur]

May be if some more folks vote https://bugs.chromium.org/p/webm/issues/detail?id=1597 up the will update the documentation,...

[LigH]

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

VPx v1.8.0-142-gce4336c2a (https://www.mediafire.com/file/cpjkqwyxpppghwy/vpx_v1.8.0-142-gce4336c2a.7z)

[benwaggoner]

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]

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]

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=news_item&px=SVT-VP9-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]

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]

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]

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 (http://forum.doom9.org/member.php?u=27401) can provide technical insight, if you can actually persuade them to do so. :p

[LigH]

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

VPx v1.8.0-226-g7969c6e0b (https://www.mediafire.com/file/8t8kgvyttphg7qg/vpx_v1.8.0-226-g7969c6e0b.7z/file)

[Leeloo Minaï]

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

VPx v1.8.0-226-g7969c6e0b (https://www.mediafire.com/file/8t8kgvyttphg7qg/vpx_v1.8.0-226-g7969c6e0b.7z/file)

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 :scared:

[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/files/3075485/encoded-files.zip

[poisondeathray]

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/files/3075485/encoded-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]

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]

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]

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

[Beelzebubu]

What is the proper way to multithread in 2019? Is it possible to achieve 100% cpu usage on 8 cores?

Using aomenc, --tile-columns=3 --threads=8 should give you 8 tile col threads. Also try --row-mt and non-zero values for --tile-rows.

Also, I read somewhere that frame parallel is not needed anymore. Is that correct?

See last paragraph in https://forum.doom9.org/showthread.php?p=1859991#post1859991

[singhkays]

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

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.

I'm seeing another issue with my VP9 encode. I'm getting the following message after 1st pass -"output file is empty". Is this expected for first pass?

[libvpx-vp9 @ 0x5f5d480] v1.8.0-366-gc46694c1d
Output #0, mp4, to '/dev/null':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.27.101
Stream #0:0(eng): Video: vp9 (libvpx-vp9) (vp09 / 0x39307076), yuv420p, 720x300 [SAR 1:1 DAR 12:5], q=-1--1, 500 kb/s, 24 fps, 12288 tbn, 24 tbc (default)
Metadata:
handler_name : VideoHandler
encoder : Lavc58.49.100 libvpx-vp9
Side data:
cpb: bitrate max/min/avg: 500000/500000/500000 buffer size: 1000000 vbv_delay: -1
frame= 158 fps=0.0 q=0.0 Lsize= 0kB time=00:00:00.00 bitrate=N/A speed= 0x
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Output file is empty, nothing was encoded

Here's the CLI for trying to get a 500K file
./ffmpeg -i scene6.mp4 -c:v libvpx-vp9 -pix_fmt yuv420p -auto-alt-ref 1 -lag-in-frames 25 -b:v 500k -filter:v scale=720:-1 -row-mt 1 -quality best -cpu-used 1 -tile-rows 2 -tile-columns 2 -threads 16 -enable-tpl 1 -pass 1 -minrate 500k -maxrate 500k -bufsize 1000k -g 240 -f mp4 -hide_banner -y /dev/null && \
./ffmpeg -i scene6.mp4 -c:v libvpx-vp9 -pix_fmt yuv420p -auto-alt-ref 1 -lag-in-frames 25 -b:v 500k -filter:v scale=720:-1 -row-mt 1 -quality best -cpu-used 1 -tile-rows 2 -tile-columns 2 -threads 16 -enable-tpl 1 -pass 2 -minrate 500k -maxrate 500k -bufsize 1000k -g 240 -hide_banner -movflags faststart ./vp9/scene6/vp9_500k.mp4

[Asilurr]

These suggestions will probably help you:
1. With contemporary versions of libvpx there's no real benefit to using tile-rows>0. The combination of tile-rows=0/tile-columns>0/row-mt>0 is advisable.
2. Do not expect multithreading miracles when working with sources which have a paltry 720 pixels horizontal resolution. There are "thresholds" which allow specific values of tile-columns (the primary MT mechanism of libvpx), and then there's row-mt which basically "doubles" the thread count (it's not exactly a 2x count, it depends on the source). Practical example: with your 720 pixels horizontal resolution source, you input tile-columns=2 and threads=16 to the encoder. It accepts them without throwing errors back at you, but it will default to what it can actually use on your source: tile-columns=1 and threads~4 (assuming row-mt=1); the encoder simply can't "fit in" 16 threads working with a 720 width source.
horizontal resolution | superblock columns | horizontal tiles | tile-columns | rough thread count with row-mt=1
0001-0448 | 001-007 | 01 | 0 | ~02
0449-0960 | 008-015 | 02 | 1 | ~04
0961-1984 | 016-031 | 04 | 2 | ~08
1985-4032 | 032-063 | 08 | 3 | ~16
4033-8128 | 064-127 | 16 | 4 | ~32
3. Considering your current quality best, you don't really care about the encoding speed; however do keep in mind that quality good usually provides superior results (yes, really). As such, switching to quality good/cpu-used=0/auto-alt-ref=6 is advisable.
4. FFmpeg's "output file is empty" notification is entirely expected, you are outputting the first pass to /dev/null (https://en.wikipedia.org/wiki/Null_device).

[singhkays]

These suggestions will probably help you:
1. With contemporary versions of libvpx there's no real benefit to using tile-rows>0. The combination of tile-rows=0/tile-columns>0/row-mt>0 is advisable.
2. Do not expect multithreading miracles when working with sources which have a paltry 720 pixels horizontal resolution. There are "thresholds" which allow specific values of tile-columns (the primary MT mechanism of libvpx), and then there's row-mt which basically "doubles" the thread count (it's not exactly a 2x count, it depends on the source). Practical example: with your 720 pixels horizontal resolution source, you input tile-columns=2 and threads=16 to the encoder. It accepts them without throwing errors back at you, but it will default to what it can actually use on your source: tile-columns=1 and threads~4 (assuming row-mt=1); the encoder simply can't "fit in" 16 threads working with a 720 width source.
horizontal resolution | superblock columns | horizontal tiles | tile-columns | rough thread count with row-mt=1
0001-0448 | 001-007 | 01 | 0 | ~02
0449-0960 | 008-015 | 02 | 1 | ~04
0961-1984 | 016-031 | 04 | 2 | ~08
1985-4032 | 032-063 | 08 | 3 | ~16
4033-8128 | 064-127 | 16 | 4 | ~32
3. Considering your current quality best, you don't really care about the encoding speed; however do keep in mind that quality good usually provides superior results (yes, really). As such, switching to quality good/cpu-used=0/auto-alt-ref=6 is advisable.
4. FFmpeg's "output file is empty" notification is entirely expected, you are outputting the first pass to /dev/null (https://en.wikipedia.org/wiki/Null_device).

Thank you for the recommendations, will update my scripts! :thanks:

Re: quality = good - wow! the more I delve into VP9, the more I'm surprised who came up with all these quirks! Is there more info on why quality = good is better?

Re: auto-alt-ref - Is there more info on what values 1 to 6 mean?

Re: output file - The reason I ask is that ffmpeg VP9 wiki states - "In pass 1, output to a null file descriptor, not an actual file. (This will generate a logfile that ffmpeg needs for the second pass.)" https://trac.ffmpeg.org/wiki/Encode/VP9

Few other questions

Do you have recommendations for aq-mode?
Any other recommendations on preventing the VP9 encoder from undershooting the target bitrate?

[Leeloo Minaï]

Re: output file - The reason I ask is that ffmpeg VP9 wiki states - "In pass 1, output to a null file descriptor, not an actual file. (This will generate a logfile that ffmpeg needs for the second pass.)" https://trac.ffmpeg.org/wiki/Encode/VP9

If you are under Windows, you may have not noticed the following note on https://trac.ffmpeg.org/wiki/Encode/VP9 :
Note: Windows users should use NUL instead of /dev/null

[singhkays]

If you are under Windows, you may have not noticed the following note on https://trac.ffmpeg.org/wiki/Encode/VP9 :

I did but I'm on Linux

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 9.1.0):

VPx v1.8.1-34-g53dc2d9d9 (https://www.mediafire.com/file/g2ggjb01egj40yq/vpx_v1.8.1-34-g53dc2d9d9.7z/file)

[utack]

Is there a way to get libvpx not to "crush" flat or dark parts of the image so much? It is one of the major weak points it still has that can ruin certain parts of a stream and that x264 solved ages ago.
Both tune-content=film and aq-mode=1/2 do not seem to suffice to control this behaviour.
Is there another method like limited the quantizer range or such?
Thank you

[LigH]

Apart from raising the bitrate? ... Reducing "noise" is one of the most important ways to encode efficiently; maybe you can change the amount with the VP9 specific parameter
--noise-sensitivity=<arg> Noise sensitivity (frames to blur)
but its default is already 0, so this may make it only worse...

Or it might be possible to move bitrate distribution away from usually preferred frames (keyframes, "golden frames"), which may hurt the quality in other scenes.

Unfortunately, not all encoders offer control over the same kind of algorithms. They may not even contain the same set of algorithms. If VPx has no exposed parameters to control rate distribution in relation to specific content dynamics, "enough bitrate" (or a forced limit for the maximum quantization) may be your only hope.

[benwaggoner]

Is there a way to get libvpx not to "crush" flat or dark parts of the image so much? It is one of the major weak points it still has that can ruin certain parts of a stream and that x264 solved ages ago.
Both tune-content=film and aq-mode=1/2 do not seem to suffice to control this behaviour.
Is there another method like limited the quantizer range or such?
Thank you
This is where adaptive quantization algorithms shine, and where PNSR-tuned encoders can fall flat.

I've yet to see a VPx series encoder that had a good adaptive quant algorithm. I don't know that this is a limitation of the bitstream itself; it's more likely just a reflection of the psychovisual maturity of the encoders.

[mandarinka]

I recall there being an actual limitation in the bitstream. The AQ has to be done via segmentation maps where you pick quants you can use and then you can assign one of those to blocks through assigning them to one or another segment. Roughly speaking. I recall that it was believed to be a hinder to AQ being useful.

[benwaggoner]

I recall there being an actual limitation in the bitstream. The AQ has to be done via segmentation maps where you pick quants you can use and then you can assign one of those to blocks through assigning them to one or another segment. Roughly speaking. I recall that it was believed to be a hinder to AQ being useful.
Oh, yeah. That would require weird loops where you'd encode the frame once, figure out the segments, and then reencode again. MPEG-4 part 2 had a similar issue in its adaptive quant which also was a huge hassle to tune.

[IgorC]

Is there a way to get libvpx not to "crush" flat or dark parts of the image so much? It is one of the major weak points it still has that can ruin certain parts of a stream and that x264 solved ages ago.
Both tune-content=film and aq-mode=1/2 do not seem to suffice to control this behaviour.
Is there another method like limited the quantizer range or such?
Thank you
If 10 bits is an option that would fix a major part of described issue.

[Beelzebubu]

Oh, yeah. That would require weird loops where you'd encode the frame once, figure out the segments, and then reencode again.

Why? For example, x264 heuristically assigns quant deltas before the frame encode. To fit this in a segment-ID design, all you need is a clustering algorithm (see e.g. webp).

[Blue_MiSfit]

Super interesting stuff. I totally agree that these types of issues are what disqualify VP9 for my use cases. It's better than AVC at low bitrates for sure, but when we go for high quality / transparency as required for premium OTT delivery of Hollywood content it's a bit lacking in exactly this way.

It's useful for UHD, but there we usually can use HEVC which just ends up looking better.

If we had good AQ I could totally see VP9 being incredibly useful, especially in cases where HEVC is off the table!

[benwaggoner]

Why? For example, x264 heuristically assigns quant deltas before the frame encode. To fit this in a segment-ID design, all you need is a clustering algorithm (see e.g. webp).
Oh, it would be possible, just a lot more finicky to do so optimally. x264 devs figured out how to do adaptive quant in xvid eventually, although it was slower and less optimal than in x264.

[Spyros]

Phoronix - Intel's Open-Source VP9 Video Encoder Just Scored A Massive ~3x Performance Boost (https://www.phoronix.com/scan.php?page=news_item&px=Intel-SVT-VP9-3x-AVX2-Boost)

SVT-VP9 is now a lot faster on AVX2 CPUs from both Intel and AMD.

[...]

The i7-7740X went from 30 FPS to 120 FPS, the E5-1680 v3 from 38 to 113 FPS, and the E5-2687W v3 from 46 to 150 FPS. Damn!

[benwaggoner]

Phoronix - Intel's Open-Source VP9 Video Encoder Just Scored A Massive ~3x Performance Boost (https://www.phoronix.com/scan.php?page=news_item&px=Intel-SVT-VP9-3x-AVX2-Boost)
Impressive, but not fundamentally surprising. Libvpx never received the sort of sustained high-touch optimization or tuning that the x24? series of encoders got. A really good encoder matters more than a bitstream with really good potential without encoders well tuned to use that potential.

[dapperdan]

That particular speed up isn't impressive, nor does it say much about libvpx.

Effectively they forgot to flick a switch to send the fast code to all platforms that could use it. Then they noticed and fixed it. The headline could just as easily been "vp9-svt pointlessly 3x slower on some platforms until now".

That all said, I'm intrigued to see how the SVT family of encoders turns out. They seem to be throwing a fair bit of engineering at it, though initially it seemed the VP9 team were redirected to work on the AV1 encoder, so good to see some work on it again, even if it's just basic stuff like that. Part of the SVT idea is that optimisations can be shared between codec families I believe, so VP9 should be benefitting even when not the focus.

Their effective use of all a available cores seems like their secret weapon. In many real world situations that might give them an edge that other encoders would have to work hard to match if coming from the libvpx codebase.

[Adonisds]

Has anyone done a comparison of the quality of youtube VP9 vs Stadia VP9?

[LigH]

YouTube will use ffmpeg with a streaming focused bitrate control. Easy to beat with constant quality focus. What is the main target of Stadia?

[soresu]

YouTube will use ffmpeg with a streaming focused bitrate control. Easy to beat with constant quality focus. What is the main target of Stadia?

FFMPEG is still using libvpx though isn't it?

It's a good sign that we are seeing so much competition so soon with AV1 encoders - the dearth of VP9 encoder competition until very recently stifled its chances of market penetration somewhat.

[osgZach]

FFMPEG is still using libvpx though isn't it?

It's a good sign that we are seeing so much competition so soon with AV1 encoders - the dearth of VP9 encoder competition until very recently stifled its chances of market penetration somewhat.

Just sucks because we're always playing leapfrog with CPU power. I got a ryzen 7 3800x with a nice upgrade path to a Ryzen 9 3950X in the future, but how fast is AV1 going to realistically get within that time before something -else- comes along, etc.

H.264 had a great run for sure, HEVC was hampered with all the political/patent BS and we've been stuck with marginally slow encoding VP9. H.265 browser support would have been nice.


it all gets so tiring :cool: I actually wish consumers had affordable FPGA options for encoders. There has to be a market somewhere out there worth tapping.

[Blue_MiSfit]

HEVC works perfectly in the primary browsers of macOS (Safari) and Windows (Edge).

Google chose not to implement HEVC decoding in Chrome, unfortunately. I'm not aware of exactly why (since hardware decoders exist for all modern systems that they could just hook into), but it may be theological reasons. Maybe it was the unknown liability for licensing a software fallback decoder.

They DID do this in Android.

[benwaggoner]

HEVC works perfectly in the primary browsers of macOS (Safari) and Windows (Edge).

Google chose not to implement HEVC decoding in Chrome, unfortunately. I'm not aware of exactly why (since hardware decoders exist for all modern systems that they could just hook into), but it may be theological reasons. Maybe it was the unknown liability for licensing a software fallback decoder.

They DID do this in Android.Actually HEVC did work in Firefox and Chrome initially, using the same passthrough-to-OS logic that enabled H.264. They later specifically blocked HEVC playback, even if an OS decoder was available.

It'd be a trival patch to remove the block. The net effect of the block is that there isn't any premium content HDR in browsers, since there is no broadly available HW with DRM 10-bit decoder in modern browsers.

Sent from my SM-T837V using Tapatalk

[benwaggoner]

Just sucks because we're always playing leapfrog with CPU power. I got a ryzen 7 3800x with a nice upgrade path to a Ryzen 9 3950X in the future, but how fast is AV1 going to realistically get within that time before something -else- comes along, etc.



H.264 had a great run for sure, HEVC was hampered with all the political/patent BS and we've been stuck with marginally slow encoding VP9. H.265 browser support would have been nice.





it all gets so tiring :cool: I actually wish consumers had affordable FPGA options for encoders. There has to be a market somewhere out there worth tapping.Using F1 instances is a lot cheaper than buying a FPGA for experimentation.

https://aws.amazon.com/ec2/instance-types/f1/

Sent from my SM-T837V using Tapatalk

[Blue_MiSfit]

Indeed ^^

I've been looking forward to trying out Socionext's FPGA AV1 encoder :)

[osgZach]

Using F1 instances is a lot cheaper than buying a FPGA for experimentation.

https://aws.amazon.com/ec2/instance-types/f1/

Sent from my SM-T837V using Tapatalk

It's neat to know something like this exist, however it's not really feasible for my usage case due to a processing time / bandwidth required point of view. I need local hardware, ahh... beggars can't be choosers and all that :cool:

[osgZach]

And a bit of a rando question, not sure whether this is ffmpeg specific or VPX/VP9 specific.

2-pass CRF is nice, I like it, and it actually seems to run a tad bit faster than a traditional 2pass, which bringing potentially better compression. However I'm also interesting in vbv/constained buffer values. I have found examples of how to do such in a regular 2-pass encode, but I cannot find anything that says whether it will/won't work if you try it with a 2pass CRF encode.

Can anyone elaborate on whether this would work, or how I could at least verify it with some test cases ? I'm worried if I specify anything other than b:v 0 it will fall back to some other mode, or not generally drop the bitrate below b:v X even if it can go lower than X

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.1.0):

VPx v1.8.2-184-gf80e88872 (https://www.mediafire.com/file/hqrzja1kltm2yjs/vpx_v1.8.2-184-gf80e88872.7z/file)

[Sagittaire]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.1.0):

VPx v1.8.2-184-gf80e88872 (https://www.mediafire.com/file/hqrzja1kltm2yjs/vpx_v1.8.2-184-gf80e88872.7z/file)

thx ... ;-)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.1.0):

VPx v1.8.2-219-g8c7142d77 (https://www.mediafire.com/file/ze44955w1p2l6i9/vpx_v1.8.2-219-g8c7142d77.7z/file)

[kerry7]

It's neat to know something like this exist, however it's not really feasible for my usage case due to a processing time / bandwidth required point of view. I need local hardware, ahh... beggars can't be choosers and all that :cool:

Also you can considere to use GCP Cloud computing. It is an alternative to EC2, but with the huge advantage that most likely google offers a better integration with VP9

[Blue_MiSfit]

Also you can considere to use GCP Cloud computing. It is an alternative to EC2, but with the huge advantage that most likely google offers a better integration with VP9


Nope. EC2 is just renting VM time. Google Cloud's Compute Engine is the same thing. You get an instance, typically with some Linux distro on it. The rest is up to you.

If you want video transcoding as a service you have a lot of options, but that's separate from any conversation about EC2 vs the equivalent on GCP.

[dapperdan]

Apple appear to be rolling out VP9 suppprt across iOS, tvOS and MacOS/Safari.

Most of the news stories just say "4K Youtube support" but it appears to be via VP9.2 and hardware accelerated where the hardware supports it.

https://webkit.org/blog/11183/release-notes-for-safari-technology-preview-112/

[Blue_MiSfit]

Very exciting. I've had my Apple TV on the beta for awhile, but YouTube is still HD-only there. I wonder what Apple devices actually offer hardware VP9 decoding under the hood that's just been disabled all this time?

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.2.0):

VPx v1.9.0-61-gc413c8f18 (http://www.mediafire.com/file/65po2ws983ucna9/vpx_v1.9.0-61-gc413c8f18.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.2.0):

VPx v1.9.0-103-g3f7fee29e (https://www.mediafire.com/file/u4xi09wcxbtz17h/vpx_v1.9.0-103-g3f7fee29e.7z/file)

[utack]

Is Google now actively killing 8k VP9?
A lot of videos only have AV1 as 8k option available, and I found reference to one a year back in a forum that clearly showed VP9 was still available at the time.

[Blue_MiSfit]

Good luck "forcing" Apple to do anything :D

[benwaggoner]

Is Google now actively killing 8k VP9?
A lot of videos only have AV1 as 8k option available, and I found reference to one a year back in a forum that clearly showed VP9 was still available at the time.
The bigger challenge is that reality is killing 8K video because of the limits of human perception. I challenge you to find video content that looks better encoded at native 8K than downscaled to 4K at the same bitrate when viewed at enough distances that the edges of the screen are at a minimally acceptable viewing angle. No one in Hollywood is doing any post production in 8K. Heck, most visual effects are still being done in 2K for cost/speed reasons, and because 2K looks just fine if there's some motion blur and/or grain.

And with everyone working from home, even experimenting in 8K is nigh impossible. There literally aren't any monitors that are 8K, HDR, and have DisplayPort. Monitoring 8K HDR means using a (WAY too big for a desk) TV and a $3K AJA Kona 5 with experimental and finicky HDMI 2.1 firmware.

[takla]

With libvpx-vp9 v1.9.0 auto-alt-ref only works in 2pass. was this changed or was this always the case?

[Beelzebubu]

With libvpx-vp9 v1.9.0 auto-alt-ref only works in 2pass. was this changed or was this always the case?

Yes (sadly).

[edit]
At --cpu-used=4 using VBR, it works also in one-pass mode in some cases. But at other speeds or in CRF, it works in 2-pass only.

See this (https://chromium.googlesource.com/webm/libvpx/+/refs/heads/master/vp9/encoder/vp9_encoder.c#7707) code.

[takla]

Yes (sadly).

[edit]
At --cpu-used=4 using VBR, it works also in one-pass mode in some cases. But at other speeds or in CRF, it works in 2-pass only.

See this (https://chromium.googlesource.com/webm/libvpx/+/refs/heads/master/vp9/encoder/vp9_encoder.c#7707) code.

Thanks for clarifying. But I'm confused. Why was it changed? Was it not working correctly before?

[Beelzebubu]

Thanks for clarifying. But I'm confused. Why was it changed? Was it not working correctly before?

I meant: yes, it was always the case. Sorry for the confusing answer.

[takla]

I meant: yes, it was always the case. Sorry for the confusing answer.

Ah alright then. Thanks.

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.2.0):

VPx v1.9.0-156-g24bd0733e (http://www.mediafire.com/file/3gkr2zeiyqgub7g/vpx_v1.9.0-156-g24bd0733e.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 10.3.0):

VPx v1.10.0-61-g4808d831d (https://www.mediafire.com/file/jab9n85wxbkoljl/vpx_v1.10.0-61-g4808d831d.7z/file)

[takla]

2021-09-27
v1.11.0 "Smew Duck"

This maintenance release adds support for VBR mode in VP9 rate control
interface, new codec controls to get quantization parameters and loop filter
levels, and includes several improvements to NEON and numerous bug fixes.

- Upgrading:
New codec control is added to get quantization parameters and loop filter
levels.

VBR mode is supported in VP9 rate control library.

- Enhancement:
Numerous improvements for Neon optimizations.
Code clean-up and refactoring.
Calculation of rd multiplier is changed with BDRATE gains.

- Bug fixes:
Fix to overflow on duration.
Fix to several instances of -Wunused-but-set-variable.
Fix to avoid chroma resampling for 420mpeg2 input.
Fix to overflow in calc_iframe_target_size.
Fix to disallow skipping transform and quantization.
Fix some -Wsign-compare warnings in simple_encode.
Fix input file path in simple_encode_test.
Fix valid range for under/over_shoot pct.


Source (https://github.com/webmproject/libvpx/blob/16837ae1680bbc73381570cc783439b0ea121ba6/CHANGELOG)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 12.1.0):

VPx v1.11.0-218-g9f1329f8a (https://www.mediafire.com/file/o441fgsk2acws5e/vpx_v1.11.0-218-g9f1329f8a.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 12.1.0):

VPx v1.12.0-72-g59acf6739 (https://www.mediafire.com/file/o52kl32cr9xm1k6/vpx_v1.12.0-72-g59acf6739.7z/file)

SVT-VP9 0.3.0-d9ef3cc (https://www.mediafire.com/file/mkpxvw2qzkd7g0w/SVT-VP9_0.3.0-d9ef3cc.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 12.2.0):

VPx v1.12.0-153-ga46ca4b6b (https://www.mediafire.com/file/rc9hzzp8kbmvjmf/vpx_v1.12.0-153-ga46ca4b6b.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 12.2.0):

VPx v1.12.0-214-gddca3dec3 (https://www.mediafire.com/file/idslbndhyldqyt5/vpx_v1.12.0-214-gddca3dec3.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 12.2.0):

VPx v1.12.0-228-gd998bd823 (https://www.mediafire.com/file/ph7xc2hmzku0vip/vpx_v1.12.0-228-gd998bd823.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 13.1.0):

VPx v1.13.0-398-g9ad950a9c (https://www.mediafire.com/file/vdyafg7ftotfir1/vpx_v1.13.0-398-g9ad950a9c.7z/file)

[oibaf]

Some (not so) recent news:


2023-09-29 v1.13.1 "Ugly Duckling"
This release contains two security related fixes. One each for VP8 and VP9.
- Upgrading:
This release is ABI compatible with the previous release.
- Bug fixes:
https://crbug.com/1486441 (CVE-2023-5217)
Fix to a crash related to VP9 encoding (#1642)

2023-01-31 v1.13.0 "Ugly Duckling"
This release includes more Neon and AVX2 optimizations, adds a new codec
control to set per frame QP, upgrades GoogleTest to v1.12.1, and includes
numerous bug fixes.
- Upgrading:
This release is ABI incompatible with the previous release.
New codec control VP9E_SET_QUANTIZER_ONE_PASS to set per frame QP.
GoogleTest is upgraded to v1.12.1.
.clang-format is upgraded to clang-format-11.
VPX_EXT_RATECTRL_ABI_VERSION was bumped due to incompatible changes to the
feature of using external rate control models for vp9.
- Enhancement:
Numerous improvements on Neon optimizations.
Numerous improvements on AVX2 optimizations.
Additional ARM targets added for Visual Studio.
- Bug fixes:
Fix to calculating internal stats when frame dropped.
Fix to segfault for external resize test in vp9.
Fix to build system with replacing egrep with grep -E.
Fix to a few bugs with external RTC rate control library.
Fix to make SVC work with VBR.
Fix to key frame setting in VP9 external RC.
Fix to -Wimplicit-int (Clang 16).
Fix to VP8 external RC for buffer levels.
Fix to VP8 external RC for dynamic update of layers.
Fix to VP9 auto level.
Fix to off-by-one error of max w/h in validate_config.
Fix to make SVC work for Profile 1.

2022-06-17 v1.12.0 "Torrent Duck"
This release adds optimizations for Loongarch, adds support for vp8 in the
real-time rate control library, upgrades GoogleTest to v1.11.0, updates
libwebm to libwebm-1.0.0.28-20-g206d268, and includes numerous bug fixes.
- Upgrading:
This release is ABI compatible with the previous release.
vp8 support in the real-time rate control library.
New codec control VP8E_SET_RTC_EXTERNAL_RATECTRL is added.
Configure support for darwin21 is added.
GoogleTest is upgraded to v1.11.0.
libwebm is updated to libwebm-1.0.0.28-20-g206d268.
Allow SimpleEncode environment to take target level as input to match
the level conformance in vp9.
- Enhancement:
Numerous improvements on checking memory allocations.
Optimizations for Loongarch.
Code clean-up.
- Bug fixes:
Fix to a crash related to {vp8/vp9}_set_roi_map.
Fix to compiling failure with -Wformat-nonliteral.
Fix to integer overflow with vp9 with high resolution content.
Fix to AddNoiseTest failure with ARMv7.
Fix to libvpx Null-dereference READ in vp8.

[benwaggoner]

Sounds like meaningful development wrapped up around January? I wonder if many of the contributors moved on to SVT-AV1.

Kind of funny that per-frame QP control took that long to implement.

[oibaf]

Sounds like meaningful development wrapped up around January? I wonder if many of the contributors moved on to SVT-AV1.

Kind of funny that per-frame QP control took that long to implement.

There are still lot of commits in libvpx after 1.13: https://chromium.googlesource.com/webm/libvpx/+log

Also for classic AV1 libaom: https://aomedia.googlesource.com/aom/+log

Much more than on SVT-AV1 https://gitlab.com/AOMediaCodec/SVT-AV1/-/commits/master/?ref_type=HEADS

[benwaggoner]

There are still lot of commits in libvpx after 1.13: https://chromium.googlesource.com/webm/libvpx/+log

Also for classic AV1 libaom: https://aomedia.googlesource.com/aom/+log

Much more than on SVT-AV1 https://gitlab.com/AOMediaCodec/SVT-AV1/-/commits/master/?ref_type=HEADS
Yeah, no doubt that work continues apace on AV1 encoders, open source and proprietary.

[takla]

https://chromium.googlesource.com/webm/libvpx/+/refs/tags/v1.14.0

Release v1.14.0 Venetian Duck

2024-01-18 v1.14.0 "Venetian Duck"

This release drops support for old C compilers, such as Visual Studio 2012
and older, that disallow mixing variable declarations and statements (a C99
feature). It adds support for run-time CPU feature detection for Arm
platforms, as well as support for darwin23 (macOS 14).

- Upgrading:
This release is ABI incompatible with the previous release.

Various new features for rate control library for real-time: SVC parallel
encoding, loopfilter level, support for frame dropping, and screen content.

New callback function send_tpl_gop_stats for vp9 external rate control
library, which can be used to transmit TPL stats for a group of pictures. A
public header vpx_tpl.h is added for the definition of TPL stats used in
this callback.

libwebm is upgraded to libwebm-1.0.0.29-9-g1930e3c.

- Enhancement:
Improvements on Neon optimizations: VoD: 12-35% speed up for bitdepth 8,
68%-151% speed up for high bitdepth.
Improvements on AVX2 and SSE optimizations.
Improvements on LSX optimizations for LoongArch.
42-49% speedup on speed 0 VoD encoding.
Android API level predicates.

- Bug fixes:
Fix to missing prototypes from the rtcd header.
Fix to segfault when total size is enlarged but width is smaller.
Fix to the build for arm64ec using MSVC.
Fix to copy BLOCK_8X8's mi to PICK_MODE_CONTEXT::mic.
Fix to -Wshadow warnings.
Fix to heap overflow in vpx_get4x4sse_cs_neon.
Fix to buffer overrun in highbd Neon subpel variance filters.
Added bitexact encode test script.
Fix to -Wl,-z,defs with Clang's sanitizers.
Fix to decoder stability after error & continued decoding.
Fix to mismatch of VP9 encode with NEON intrinsics with C only version.
Fix to Arm64 MSVC compile vpx_highbd_fdct4x4_neon.
Fix to fragments count before use.
Fix to a case where target bandwidth is 0 for SVC.
Fix mask in vp9_quantize_avx2,highbd_get_max_lane_eob.
Fix to int overflow in vp9_calc_pframe_target_size_one_pass_cbr.
Fix to integer overflow in vp8,ratectrl.c.
Fix to interger overflow in vp9 svc.
Fix to avg_frame_bandwidth overflow.
Fix to per frame qp for temporal layers.
Fix to unsigned integer overflow in sse computation.
Fix to uninitialized mesh feature for BEST mode.
Fix to overflow in highbd temporal_filter.
Fix to unaligned loads w/w==4 in vpx_convolve_copy_neon.
Skip arm64_neon.h workaround w/VS >= 2019.
Fix to c vs avx mismatch of diamond_search_sad().
Fix to c vs intrinsic mismatch of vpx_hadamard_32x32() function.
Fix to a bug in vpx_hadamard_32x32_neon().
Fix to Clang -Wunreachable-code-aggressive warnings.
Fix to a bug in vpx_highbd_hadamard_32x32_neon().
Fix to -Wunreachable-code in mfqe_partition.
Force mode search on 64x64 if no mode is selected.
Fix to ubsan failure caused by left shift of negative.
Fix to integer overflow in calc_pframe_target_size.
Fix to float-cast-overflow in vp8_change_config().
Fix to a null ptr before use.
Conditionally skip using inter frames in speed features.
Remove invalid reference frames.
Disable intra mode search speed features conditionally.
Set nonrd keyframe under dynamic change of deadline for rtc.
Fix to scaled reference offsets.
Set skip_recode=0 in nonrd_pick_sb_modes.
Fix to an edge case when downsizing to one.
Fix to a bug in frame scaling.
Fix to pred buffer stride.
Fix to a bug in simple motion search.
Update frame size in actual encoding.

[LigH]

New uploads (MSYS2; MinGW32 / MinGW64: GCC 13.2.0):

VPx v1.14.0-162-gd4959f982 (https://www.mediafire.com/file/pmnjwnofr6l21jw/vpx_v1.14.0-162-gd4959f982.7z/file)

SVT-VP9 0.3.0-3ecdf8f (https://www.mediafire.com/file/gxnqotrppg6tnyd/SVT-VP9_0.3.0-3ecdf8f.7z/file)

[LigH]

New uploads (MSYS2; MinGW32 / MinGW64: GCC 14.1.0):

VPx v1.14.1-318-g3219f76c (https://www.mediafire.com/file/9ft9i9ic85ja2rv/vpx_v1.14.1-318-g3219f76c.7z/file)

[LigH]

New uploads (MSYS2; MinGW32 / MinGW64: GCC 14.2.0):

VPx v1.14.1-359-gc6de95ce (https://www.mediafire.com/file/lrjende6rrkvbn9/vpx_v1.14.1-359-gc6de95ce.7z/file)

[takla]

For anyone still interested in VP9:
I wanted to point out, that it has, in recent times, recieved multiple new AQ-Modes, which were not mentioned in any patchnotes, iirc.

-aq-mode X

1 = VARIANCE_AQ
2 = COMPLEXITY_AQ
5 = PERCEPTUAL_AQ
6 = PSNR_AQ
7 = LOOKAHEAD_AQ <-- requires -auto-alt-ref 1 (or greater) which itself requires 2-pass

Source (https://github.com/webmproject/libvpx/blob/a5ea71f0919cf0670c832ddc36fec4c7d9b8ed84/vp9/encoder/vp9_encoder.h#L118)

[LigH]

New uploads (MSYS2; MinGW32 / MinGW64: GCC 14.2.0):

VPx v1.15.0-22-g66d339b3 (https://www.mediafire.com/file/a2n959vk9fnkxy8/vpx_v1.15.0-22-g66d339b3.7z/file)

SVT-VP9 0.3.0-1feb760 (https://www.mediafire.com/file/3hi42orkiw5tdir/SVT-VP9_0.3.0-1feb760.7z/file)

[Blue_MiSfit]

Does anyone have recommendations for quick and dirty libvpx-vp9 encoding parameter settings for relatively fast file based encoding for a ~4 Mbps capped CRF 1080p SDR editorial proxy use case?

A certain popular NLE doesn't support HEVC or AV1 for proxies, but does support AVC and VP9, so I've been asked to look into how libvpx-vp9 compares with x264 for this use case.

Are there any settings that aren't defaults but probably should be? Is there current guidance on lag-in-frames, auto-alt-ref, and row-mt? I'm paraphrasing as I forget the actual parameter names :)

[GeoffreyA]

ffmpeg -i INPUT -c:v libvpx-vp9 -quality good -cpu-used 3 -crf 18 -b:v 4000k OUTPUT

[takla]

Release v1.15.0 Wigeon Duck

2024-10-31 v1.15.0 "Wigeon Duck"
This release includes new codec control for key frame filtering, more Neon
optimizations, improvements to RTC encoding and bug fixes.

- Upgrading:
This release is ABI compatible with the previous release.

Temporal filtering improvement that can be turned on with the new codec
control VP9E_SET_KEY_FRAME_FILTERING, which gives 1+% BD-rate saving with
minimal encoder time increase.

libwebm is upgraded to libwebm-1.0.0.31-10-g3b63004

- Enhancement:
Neon optimization speed up
1-3% speed up across speed 5 to 10 for RTC
3% speed up for speed 0 and 1 for VoD in standard bitdepth
3% and 7% speed up for speed 0 and 1 respectively for VoD in high bitdepth
Scene detection is allowed for all RTC speeds (>=5)
Support profile guided optimizations

Delta quantization parameters for UV channels for vp8 is supported in RTC
rate control library

Rate control parameters are reset and maximum QP is enforced on scene
changes in SVC when there is no inter-layer prediction

- Bug fixes:
Fix to Uninitialized scalar variable in `vp9_rd_pick_inter_mode_sb()`
Fix to Integer-overflow in `resize_multistep`
Fix to Heap-buffer-overflow in `vpx_sad64x64_avx2`
Fix to Crash in `vpx_sad8x8_sse2`
Fix to Assertion in `write_modes`
Support profile guided optimizations
Fix to Integer-overflow in `encode_frame_to_data_rate`
Fix to Integer-overflow in `vp9_svc_check_reset_layer_rc_flag`
Fix to core dump error from /usr/bin/tools/tiny_ssim --help
Fix to use-of-uninitialized-value in `vp9_setup_tpl_stats`
Fix to Undefined-shift in `vp9_cyclic_refresh_setup`
Fix to redundant `&& __GNUC__` preproc check
Fix to valgrind warning in EncodeAPI.OssFuzz69906
Fix to Index-out-of-bounds in `vp8_rd_pick_inter_mode`
Fix to Integer-overflow in `vp8_pick_frame_size`
Fix to Use-of-uninitialized-value in `vpx_codec_peek_stream_info`
Fix to log clutters with the message "Warning: Desired height too large"
Fix to Integer-overflow in `vp9_svc_adjust_avg_frame_qindex`

Fix to integer overflows caused by huge target bitrate, frame rate, or
g_timebase numerator or denominator

Fix to missing license headers
Fix to build failure for Android Armv7
Fix to integer overflows in image helpers
Fix to Integer-overflow in `vp9_calc_iframe_target_size_one_pass_cbr`
Fix to Heap-buffer-overflow in `vp9_pick_inter_mode`
Fix to Segv in `vp9_multi_thread_tile_init`
Fix to Use-of-uninitialized-value in `vp9_row_mt_sync_mem_dealloc`
Fix to Crash in `mbloop_filter_vertical_edge_c`
Fix to Check failed in CheckUnwind
Fix to Heap-buffer-overflow in `write_modes_b` and `vpx_write`
Fix to Possible signed integer overflow found in `vpx_codec_encode`
Fix to build conflicts between Abseil and libaom/libvpx in Win ARM64 builds
Fix to build failures on aarch64
Fix to Data race in libvpx ARM NEON
Fix to Heap-buffer-overflow in `scale_plane_1_to_2_phase_0`
Fix to integer overflow in `encode_mb_row`
Fix to Floating-point-exception in `vp8_pick_frame_size`
Fix to Heap-buffer-overflow in `vp9_enc_setup_mi`
Fix to build failure with --target=arm64-win64-vs17
Fix to heap-buffer-overflow write in `vpx_img_read()`
Fix to C vs armv8-linux-gcc encode mismatches for `y4m_360p_10bit_input`
Fix to Null-dereference READ in `ml_predict_var_rd_partitioning`
Fix to Heap-buffer-overflow in `vpx_scaled_2d_ssse3`
Fix to Crash in `convolve_horiz`
Fix to Ill in `vpx_scaled_2d_ssse3`
Fix to Global-buffer-overflow in `cost_coeffs`


Source (https://chromium.googlesource.com/webm/libvpx/+/refs/tags/v1.15.0)

[takla]

Are there any settings that aren't defaults but probably should be? Is there current guidance on lag-in-frames, auto-alt-ref, and row-mt? I'm paraphrasing as I forget the actual parameter names :)

-lag-in-frame is only used in 2pass, and defaults to the maximum of 25, so no reason the specify it

-auto-alt-ref also only works in 2pass. Personally, I'd never use it. It blurs frames too much.

-row-mt 1 can speed things up

And don't forget to set a keyint value. -g 240 for example.

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 14.2.0):

VPx v1.15.0-28-g6f0c446c (https://www.mediafire.com/file/jk4r6b66ljlz75x/vpx_v1.15.0-28-g6f0c446c.7z/file)

[takla]

2025-02-10 v3.12.0

Thats for libaom-av1 (https://aomedia.googlesource.com/aom/+/refs/tags/v3.12.0)

So, wrong thread.
Should have posted it here (https://forum.doom9.org/showthread.php?t=172550).

[LigH]

New upload (MSYS2; MinGW32 / MinGW64: GCC 14.2.0):

VPx v1.15.0-69-g027bbee3 (https://www.mediafire.com/file/wf46wa8ydpjcj72/vpx_v1.15.0-69-g027bbee3.7z/file)

[LigH]

New upload (MSYS2; MinGW32 / MinGW64; GCC 15.1.0):

VPx v1.15.1-85-g37c2802f (https://www.mediafire.com/file/c2poa80zh53wn2r/vpx_v1.15.1-85-g37c2802f.7z/file)

SVT-VP9 0.3.0-c4a41ee (https://www.mediafire.com/file/nox7iinxjf309yo/SVT-VP9_0.3.0-c4a41ee.7z/file)