Google VP9 "Next Generation Open Video" information posted

[mzso]

Not following the 'open environment' argument, there's a HEVC specification and to implement the specification and sell the implementation you need to pay royalites to cover the patent licencing, VP9 afaik is entirely royalty free and also licenced permissively so in terms of 'open environment' it wins hands down there.

I still think you are right as far as the actual result though, given that Google gives away a free fully open source codec which is the 'standard', I think there's very little commercial opportunity to compete.

Compare that to HEVC where it's unlikely to be any quality open source and free offering until the x264 devs get a mature h265 encoder out (go guys go! :D), that situation leaves a lot of room for commercial closed source h265 encoders.

Since when does quality matter? You can see some ugly encodes on Blu-Rays...

[XaLBa]

I see, probably true.
But i find it weird, doesn´t a bitstream freeze mean that decoders will be compatible forever with the codec?

There was a bugfix (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=31a68bcdfffdefbfea28c3cf9678363d4fec4bc3) recently, which affected the bitstream.

Possibly this is the cause of the decoding problem.

[pieter3d]

That looks like it is part of comp (composite?) prediction, which I haven't been able to get the vp9 encoder to utilize. So, likely it isn't a factor.

[XaLBa]

Agree. But possibly I missed another fix changing bitstream.
Regarding compound prediction, developers restricted its usage not long before bitstream freeze: now it is available only in case when one reference frame is from the past and another is from the future. Not sure that encoder currently has such tools.

[dapperdan]

VP9 Status update from Google

https://groups.google.com/a/webmproject.org/forum/m/?fromgroups#!topic/webm-discuss/bbMo00Gvops


Progress so far is 7 times faster with no quality impact, 20x faster with 5% quality penalty and 50x faster with 12% quality drop.

[BadFrame]

Progress so far is 7 times faster with no quality impact, 20x faster with 5% quality penalty and 50x faster with 12% quality drop.
Looks very promising, have you seen anything regarding them enabling multithreaded encoding again?

I read somewhere that they disabled it to make development easier, now that the bitstream is finalized and optimizations are taking place it should be something of a priority methinks?

Being able to utilize more than one core for a single encode would make quite a difference.

[Kurtnoise]

Here are some recent (yesterday) windows builds for those are interested :

- x86 (http://tinyurl.com/lztn3ku)
- x64 (http://tinyurl.com/kbmexrz)

[Selur]

Thanks Kurtnoise for this new builds! :)

[XaLBa]

Looks very promising, have you seen anything regarding them enabling multithreaded encoding again?

I read somewhere that they disabled it to make development easier, now that the bitstream is finalized and optimizations are taking place it should be something of a priority methinks?

Being able to utilize more than one core for a single encode would make quite a difference.

As I can see, they didn't disable multithreading. They just haven't implemented it yet in VP9 encoder. VP9 format have tiles, which will allow easy threading implementation. But if VP9 is proposed as encoder for wide range of application (including video calls and screen capture), it should provide acceptable single-core performance.

Also what was confusing for me, they use “cpu-used” option, which implies multithreading, but actually it is something similar to “preset” option of x264.

[dapperdan]

Being able to utilize more than one core for a single encode would make quite a difference.

It'll happen eventually as part of the codec design was to plan for the multi-core future, this part of the preview spec (although headlined "Parallel Decodability") talks about tools for multi-threaded encoding:

http://tools.ietf.org/id/draft-grange-vp9-bitstream-00.html#rfc.section.3.2

On the other hand, they might want to wait until they start to hit diminishing returns on a single CPU, most heavy users can spin up mutiple encodes at the same time to use up idle CPUs and at the other end of the scale some people won't be able to spare more than one core so it may or may not be top of their agenda, it really depends on where they think the low hanging fruit are and what use-cases they are prioritising.

[mzso]

Aren't there any ffmpeg builds out there with vp9 support for windows?

It should be in ffmpeg (http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=libvpx) for a long while now, but the builds linked from the main site are stubbornly without vp9.

[mzso]

Well, I found this (http://oss.netfarm.it/mplayer-win32.php). but it fails every time I try to encode.
[libvpx-vp9 @ 04ec2ba0] Failed to set VP8E_SET_TOKEN_PARTITIONS codec control: Unspecified internal error

[Kurtnoise]

Why you need it ? Just use the pipe line...

[Selur]

@Kurtnoise: when trying to start the x86 build on Windows XP, I get: "vpxenc.exe is not a valid Win32 application" (works fine on Win7)
-> What compiler did you use?

[Kurtnoise]

Visual Studio 2012 - XP compatible (http://msdn.microsoft.com/en-us/library/vstudio/jj851139.aspx)...

I'll check it out when I'll get back to home.

[nevcairiel]

This XP compat is broken in Update 2 for VS2012, it only works with Update 1 or the new Update 3, which would result in exactly such a message.
An alternative could be SSE2 optimizations which are enabled in VS2012 by default, and Selur runs an ancient CPU. :)

[Rumbah]

Here are 32 and 64 bit MinGW compiles, perhaps they work with XP:

http://x264.janhum.alfahosting.org/vpx27072013.7z

[Selur]

@Rumbah: the MinGW compile works on XP :)
Would be nice if you could make a build which includes VP8 and VP9.
Thanks! :)

[Rumbah]

sure, here you go:

http://x264.janhum.alfahosting.org/vp8vp927072013.7z

[Selur]

Nice! Thanks a lot!

[mindwin]

I am trying to encode(VP9 vpxenc) foreman.y4m, first pass works fine, but the second pass encoder all the time crashes.
What problem could be?
(AMD Phenom II X3, Windows 7 x64

The problem was in options.
Works well with
-p 2 --min-q=0 --drop-frame=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --end-usage=vbr --target-bitrate=100 --codec=vp9 --good --profile=0 --auto-alt-ref=1 --lag-in-frames=25 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --kf-min-dist=0 --kf-max-dist=9999 -v --psnr --tune=psnr --test-decode=warn

[Selur]

vp9: tile limits were off source: http://forum.selur.de/topic22-infos-about-fixed-bugs-etc-in-the-next-release.html

Will be fixed in the release I plan to make this evening,..

[easyfab]

I try to compile ffplay with libvp9 and it seems to work for me, if someone want to play with this ffplay vp9 version : https://mega.co.nz/#!1VE3XBJS!PeLmHlEMp_anouHgdhwuiWBramsYPL0I6aAqYwQ7cG4
As libvp9 support is experimental in ffmpeg please add -strict -2
command line example : ffplay.exe video.webm -strict -2

[xooyoozoo]

VP9 development seems to have stabilized, as there's been few speed/quality commits in the past several weeks. This is then likely a good time to finally assess fps-size tradeoffs as well as compare VP9 to both VP8 and x264.

Using four 300 frames 704x576 test sequences (ftp://ftp.tnt.uni-hannover.de/pub/svc/testsequences/), I measured normalized size for the same quality (via ratios of logMSSSIM (http://mmspg.epfl.ch/vqmt)-based bdrate (http://webcache.googleusercontent.com/search?q=cache:okESKHI6xzQJ:www-ee.uta.edu/dip/courses/ee5356/BDPSNR.doc+&cd=1&hl=en&ct=clnk&gl=us)) and normalized encoding speed (via ratios of geometric means) and took the mean of all clips. The 2pass encoders had bitrate scaling (based on previous tests) to prevent bdrate calculations from chopping off large regions of extremities. The versions and settings tested are shown here (http://pastebin.com/QnhBhhH4).

Everything was normalized to be a ratio of x264-veryslow's results:

http://i.imgur.com/Ng7MY3s.png

The three dashed lines are power law trend lines respectively based on speed-size scalings between x264's superfast-faster, faster-slower, and slower-veryslow. The logic here is that some compromises are reasonable, and the trends demonstrate the tradeoffs x264 makes and thus the regions where next-gen encoders must be in order to be "acceptable" for current x264 users.

I included VP8's best mode, but it's obvious the mode is VP8's equivalent of a placebo preset. The same is even more true (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=0d8723f8d5372eaaadfb5373a3b9d35e2c78c42d) for VP9, though I didn't bother with actually testing that.

The lone cross in the graph's bottom left corner is a result for a week old x265 build. x265's development is currently too rapid for reliable testing, so I didn't want to focus on it but still wanted to include a single (admittedly non-useful) data point.

Lastly, I included x264-veryslow with --aq-mode 0 (effectively --tune psnr) to demonstrate how well psychovisually-revelant metrics favor adaptive quantization. Both x265 and VP9 currently have no AQ. Commits in x265 indicate that AQ's on-track/definite, and VP9/WebM's mailing lists indicate that the developers will look into it.

Note that everything was tested on a dualcore Penryn left untouched during runs for accurate speed results. Having (only) 2 cores means that on other machines, single-threaded VP9 may have much lower normalized speeds. Also, I believe x264 is well optimized for newer instruction sets and should be relatively faster on AVX2/FMA/etc chips.

Edit:

If we play around with the numbers established in the graph above, an idealized next-gen "equivalent" (i.e. half the size at similar speed scaling) for x264-medium would have a point at [0.5914, 0.0204] on the graph. The same for x264-veryslow would be at [0.5, 1.375E-6], so someone who chooses 'veryslow' over 'slower' may find it reasonable to halve the filesize even if a 1hr encode now takes 83 years. ;)

[mandarinka]

An interesting development: https://gerrit.chromium.org/gerrit/#/c/65426/

A variance-based adaptive quantization patch for VP9 - it is based on x264's approach AFAIK, although according to the developer, it turned out to be less effective in VP9 (so far).

[Nintendo Maniac 64]

GStreamer 1.2 supposedly includes experimental VP9 encode & decode via the vpx plugin:
Major changes:
　• New plugins:
　 　∘ vpx plugin has experimental VP9 decoding and encoding support

Source: http://gstreamer.freedesktop.org/

Direct link to release notes: http://lists.freedesktop.org/archives/gstreamer-devel/2013-September/043124.html

[zerowalker]

Is there still no Decoder for Media Players for VP9?
It´s been around for half a year now, and while it has improved in terms of speed from my tests, it isn´t exactly adopting to well, though then again VP8 never did either.

EDIT:

How do you make 64 bit builds?

[Nintendo Maniac 64]

According to this article:
http://www.myce.com/news/vlc-2-1-released-new-audio-core-4k-ready-new-mobile-ports-68904/

The VideoLAN guys supposedly said that VLC would get VP9 support in about two weeks. However, I cannot find any source on where they got the "two weeks" thing from, so who knows?

On the other hand, the following forum thread is very relevant and contains a direct comment from one of the VideoLAN forum admins regarding VP9 not actually having a proper release yet:
https://forum.videolan.org/viewtopic.php?f=7&t=111668

[zerowalker]

Oh, thought everything was public and ready, except that it´s not 100% completed.
By that explains the standstill.

Hope things starts moving when it´s released, cause VP9 is pretty worthless now for use as you can´t even play it,
small steps like usability is a good thing that hopefully will bring more eyes to it.

[BadFrame]

Oh, thought everything was public and ready, except that it´s not 100% completed.

According to the webm git history the developers tagged a 'stable vp9 decoder' branch 36 hours ago, so I guess from here on the decoder is ready to go and we'll likely see quick uptake in atleast the open source ecosystem.

http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=tags

[zerowalker]

Ah great, will be holding hopes on this, Open Source Codecs like this are really interesting.

[Kurtnoise]

There is also a patch review for a native vp9 decoder (http://ffmpeg.org/pipermail/ffmpeg-devel/2013-September/148634.html) from the FFmpeg crew...

[Nintendo Maniac 64]

Once we have actual VP9 encoders and decoders, shouldn't we make separate threads instead of bunching up in this topic that doesn't even mention VP9 in the title? I mean, by then VP9 will be current-gen, not next-gen. :P

EDIT: For reference I just counted 9 separate h.265-related threads on the first page of the "New and alternative video codecs" forum.

[dapperdan]

Another VP9 status update from Google:

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

Some highlights:

[encode] x7.5 speedup for --cpu-used=0 up to approximately a x80 speed up for --cpu-used=2.

[decode] Arm / Neon ~ x4 speedup (We can now decode 720p a Nexus 10). Intel ~ x1.5 speedup.

have added a command line constant quality option (--end-usage=3, --cq-level=<value>, where value is the Qp level).

[zerowalker]

So multi core works now?
Or am i misreading it?

Nintendo: I agree, this thread is more suited for (What news does this unknown new Google codec bring?).

[mzso]

Once we have actual VP9 encoders and decoders, shouldn't we make separate threads instead of bunching up in this topic that doesn't even mention VP9 in the title? I mean, by then VP9 will be current-gen, not next-gen. :P

EDIT: For reference I just counted 9 separate h.265-related threads on the first page of the "New and alternative video codecs" forum.

When will that be... Last time I checked the builds on the webmproject site didn't include VP9.

[Nintendo Maniac 64]

When they say "Intel", I wonder if they mean x86 or if they actually mean 'Intel'. Previously when I tried to play a VP9 video in Chrome it fully pegged a core on a 2.8GHz Phenom II 920. For reference I can do 720p VP8 in VLC on a 1.6GHz Intel Atom N270 (1 core, 2 threads), on a 2GHz Pentium 4 (Northwood), and on an underclocked-to-1GHz Athlon 64 x2 (Brisbane with 2x512KB L2).

[Rumbah]

The last time I checked the decoder and encoder were not multithreaded.

And VP9 is more complex than VP8 so it's more ressource hungry when decoding.

[BadFrame]

So multi core works now?
Or am i misreading it?

You are misreading it, the '--cpu-used' parameter (atleast as I understand it) is there to offer more fine-grained quality/resource demand settings beyond that of --good and --rt .

For example, '--good' used with '--cpu=0' should be very close to the quality of '--best', and then as you increase '--cpu=n' the quality will drop as certain performance demanding features are disabled, leading to increased encoding/decoding speed (again at the cost of quality).

It certainly has nothing to do with multithreading the encoder, which is not yet implemented although I'm certain it's currently being worked on in a non-public branch as it's kind of disruptive.

I'd also guess that it is being primarily done by Ronald Bultje as I haven't seen any public commits from him in a long time and as far as I know he is one of the current lead developers of VP9.

[BadFrame]

When will that be... Last time I checked the builds on the webmproject site didn't include VP9.
The builds there are based upon official releases, the last one was 1.1 (eider), the next one is 1.2 (yet unnamed) which supports VP9. I guess it will be out once multi-threading is in place (together with yet more fine-tuning).

Meanwhile if you go to 'downloads' they do offer snapshots of the current branch for you to build, or you can of course just build directly against the git master branch (that's what I do).

[easyfab]

I'd also guess that it is being primarily done by Ronald Bultje as I haven't seen any public commits from him in a long time and as far as I know he is one of the current lead developers of VP9.

I think he did the native VP9 decoder in ffmpeg recently but I hope mutithreading in under way.

[mandarinka]

I don't recall the source (must have been somebody from libav), but IIRC he left or is going to leave Google.

[Kurtnoise]

Only the loop filter is multithreaded in the vp9 library for the moment...

[Nintendo Maniac 64]

And VP9 is more complex than VP8 so it's more ressource hungry when decoding.

The 2GHz Northwood Pentium 4 is a single core and single thread processor, and a Phenom II is nearly twice as fast per-GHz (SOURCE (http://www.tomshardware.com/reviews/processor-architecture-benchmark,2974-15.html)). Doing some math*, that would make a 2.8GHz Phenom II be about 2.7x faster in single-threaded operations than a 2GHz Northwood.

So you're telling me that VP9 is almost 2.7 times slower to decode than VP8? Doesn't that seem a bit...much? Even h.264 high profile isn't that much more CPU demanding than VP8 is; I can decode either 1280x720 30fps VP8 or high-profile 1280x720 30fps h.264 on a mere underclocked-to-1GHz Athlon 64 x2 (Brisbane with 2x 512KB L2) - and yes that's without h.264 GPU acceleration.


* Here's the math I did.
3 (Reference Pentium 4 clockrate) / 2 (My Pentium 4 clockrate) = 1.5
240 (Reference Pentium 4 score) x 1.5 = 360 (estimated 2GHz Pentium 4 score)
3 (Reference Phenom II clockrate) / 2.8 (My Phenom II clockrate) = 1.07
124 (Refrence Phenom II score) x 1.07 = 133 (estimated 2.8GHz Phenom II score)
360 / 133 = 2.7

[fumoffu]

I would say this sounds about right - yes it's that much slower. VP8 has similar complexity to h264 so there isn't much difference. But VP9 and HEVC are 2-3 times more hardware demanding than previous generation. (and yes I'm talking about decoding, because encoding speeds are 5-10times slower...)

[phate89]

The 2GHz Northwood Pentium 4 is a single core and single thread processor, and a Phenom II is nearly twice as fast per-GHz (SOURCE (http://www.tomshardware.com/reviews/processor-architecture-benchmark,2974-15.html)). Doing some math*, that would make a 2.8GHz Phenom II be about 2.7x faster in single-threaded operations than a 2GHz Northwood.

So you're telling me that VP9 is almost 2.7 times slower to decode than VP8? Doesn't that seem a bit...much? Even h.264 high profile isn't that much more CPU demanding than VP8 is; I can decode either 1280x720 30fps VP8 or high-profile 1280x720 30fps h.264 on a mere underclocked-to-1GHz Athlon 64 x2 (Brisbane with 2x 512KB L2) - and yes that's without h.264 GPU acceleration.


* Here's the math I did.
3 (Reference Pentium 4 clockrate) / 2 (My Pentium 4 clockrate) = 1.5
240 (Reference Pentium 4 score) x 1.5 = 360 (estimated 2GHz Pentium 4 score)
3 (Reference Phenom II clockrate) / 2.8 (My Phenom II clockrate) = 1.07
124 (Refrence Phenom II score) x 1.07 = 133 (estimated 2.8GHz Phenom II score)
360 / 133 = 2.7

I think that twice the decoding complexity was planned for both h265 and vp9, the missing 0.7 is all better optimization

[Nintendo Maniac 64]

I think that twice the decoding complexity was planned for both h265 and vp9, the missing 0.7 is all better optimization

I heard/read that decoding performance for VP9 was to be similar to h.264...

Nevertheless, I just hope that a 2.5GHz Brisbane and/or a 2GHz Conroe will be able decode 720p VP9! Otherwise I'm SOL, especially since I was hoping for VP9 in order to actually stream YouTube 720p. (My connection is just a bit too slow for it, unless the video has very minimal movement)

[phate89]

I heard/read that decoding performance for VP9 was to be similar to h.264...

Nevertheless, I just hope that a 2.5GHz Brisbane and/or a 2GHz Conroe will be able decode 720p VP9! Otherwise I'm SOL, especially since I was hoping for VP9 in order to actually stream YouTube 720p. (My connection is just a bit too slow for it, unless the video has very minimal movement)

vp8 is similar to h264...

[benwaggoner]

Nevertheless, I just hope that a 2.5GHz Brisbane and/or a 2GHz Conroe will be able decode 720p VP9! Otherwise I'm SOL, especially since I was hoping for VP9 in order to actually stream YouTube 720p. (My connection is just a bit too slow for it, unless the video has very minimal movement)
If you are CPU-bound than H.264 is definitely your friend on older hardware, as long as you have a GPU good enough to enable hardware decode in Flash or HTML5. VP9 and HEVC are going to be software (or software + GPU) on existing and near-future PC platforms.

It is an interesting and evolving question for when using >H.264 codecs delivers more benefit from better compression than the downside from increase decoder requirements. Particularly for battery-powered devices.

HEVC is promising for multi-core machines as it is highly parallelizable with Wavefront Parallel Processing; you can easily get a parallel decoder thread per 64 pixels of frame height. Finally something to do on those quad-core ARM phones :).

Also, there really aren't any practical VP9 or HEVC encoders available today. We can do apples-to-apples comparisons to some degree, but x264 generally gets used to make oranges. Common scenarios like capped VBR with adaptive GOP length and B-frame patterns with reasonable encode times are months away for the next gen codecs.

[Nintendo Maniac 64]

If you are CPU-bound
I'm largely bandwidth-bound. 720p YouTube requires about 330KB/s and I can only achieve that with multi-chunk downloads (~360KB/s). With video streaming and/or single-chunk downloads, I can only achieve around 310 KB/s.

than H.264 is definitely your friend on older hardware, as long as you have a GPU good enough to enable hardware decode in Flash or HTML5.
I'm talking about purely software decoding. You definition of "older hardware" is newer than the 'older hardware' that I'm currently using. :p

Integrated GPU hardware that was compatible with the Athlon 64 x2 or the Core 2 Duo largely predates the concept of h.264 decoding on the GPU. Only the Radeon HD 3200 and 4200 series of iGPs were new enough to have h.264 decoding and yet were still compatible with the both older (AM2) Athlon 64 x2 and the newer Phenom II x6.

For reference, my desktop is the Athlon 64 x2 Brisbane previously mentioned, and luckily for me I happen to have a Radeon HD 4200 iGP. My Core 2 Duo laptop is not so lucky however...