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.