Google VP9 "Next Generation Open Video" information posted

[tuqueque]

All I see here are assumptions from x264 fanboys... I tend to be very patient and friendly, but this is ridiculous...

It might not be "fair" but is going from "good" to "best" going to make much of any noticeable difference? Probably not.

You won't KNOW it if you don't do the test!... And again, how convenient is to set --preset placebo instead of --preset veryslow (knowing that -- preset veryslow is the proposed setting in these comparison test!).

Is also ridiculous to compare speed at this point. VP9 is still under heavy sort-of-alpha/beta development and x264 is a quite mature project... Give VP9 a couple of years at least so you can speak properly about speeds.

[paradoxical]

All I see here are assumptions from x264 fanboys... I tend to be very patient and friendly, but this is ridiculous...

Assumptions? More like the words straight from the developers? And calling me a fanboy? That's classic.

You won't KNOW it if you don't do the test!... And again, how convenient is to set --preset placebo instead of --preset veryslow (knowing that -- preset veryslow is the proposed setting in these comparison test!).

I have done tests between the presets. In my tests, the compression difference is usually less than .5% and visually there is no difference. So there is no "convenience" to it, the fact that they used placebo did nothing more than make the encode take many times longer. Again, there's a reason it's called "placebo". You do know what a placebo is, right?

And again:

Setting --good quality and --cpu-used=0 will give quality that is usually very close to and even sometimes better than that obtained with --best


So by Google's own documentation this supposed unfairness is probably next to nothing for VP9. So unless you have any data showing that going from good to best has something more than 1% or less difference then your whining is really overblown.


Is also ridiculous to compare speed at this point. VP9 is still under heavy sort-of-alpha/beta development and x264 is a quite mature project... Give VP9 a couple of years at least so you can speak properly about speeds.

Why is it ridiculous? Speed for quality is a very important metric.

[vivan]

I've asked you: 3) Have you actually tested this?And you still haven't answered.
I did not want to spend 6 hours encoding and then hearing something like "--best is broken, you should have used --good".
And, for example, --tune=ssim is broken and leads to crash.
Optimisation is not just making everything faster. It's also about using faster algorithms that are less accurate. So, at best, making vp9 faster would be the same as going from placebo to veryslow.

Anyway, moving to http://downloads.webmproject.org/rbultje/io2013/gF58loLxjRk.vid.mp4
encoded with vpxenc using "--good --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --cq-level=20 --end-usage=0 --auto-alt-ref=1 --passes=2 --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 --target-bitrate=X --codec=vp9 -o out.webm in.y4m".@250, 500, 1000 and 2000 kbps.
x264 - preset veryslow and keyint infinity. And --tune psnr for psnr chart below:
http://4.firepic.org/4/images/2013-05/23/yar5wrd2m1us.png

source (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_source.png), x264_0750 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_x264_0750.png), x264_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_x264_1000.png), x264_2000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_x264_2000.png), vp9_0500 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_vp9_500.png), vp9_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_vp9_1000.png).
source (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_source.png), x264_0750 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_x264_0750.png), x264_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_x264_1000.png), x264_2000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_x264_2000.png), vp9_0500 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_vp9_500.png), vp9_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_vp9_1000.png).
source (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_source.png), x264_0750 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_x264_0750.png), x264_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_x264_1000.png), x264_2000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_x264_2000.png), vp9_0500 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_vp9_500.png), vp9_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_vp9_1000.png).
source (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_source.png), x264_0750 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_x264_0750.png), x264_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_x264_1000.png), x264_2000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_x264_2000.png), vp9_0500 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_vp9_500.png), vp9_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_vp9_1000.png).
encodes (https://www.dropbox.com/sh/xu7tkht1jpvu32h/NZvWOP1l03)

x264 fails completely at 500 kbps, vp9 at 250 kbps.
At 1000 kbps vp9 and x264 are on par with a different artifacts: vp9 filters out everything, source artifacts, noise, details... x264 tries to encode source artifacts.
At 500 kbps downscaled to 360p and then upscaled back x264 is on par with vp9: 1 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_x264_0500.png) 2 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_x264_0500.png) 3 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_x264_0500.png) 4 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_x264_0500.png).

So, well, vp9 is less bad for low quality sources at really low bitrates. Probably proper filtering before encoding using x264 will change things.
If you never seen source vp9 could look a bit better... But for video creators it coud be pain. Nobody cares about quality on youtube, but, vimeo, please no :D

Oh, btw, source is BT.601, so all other files too.

[Beelzebubu]

This one -
http://forum.doom9.org/showthread.php?p=1628695#post1628695.
v1.2.0-2727-g18e0742

First, a general comment: I'm a little suspicious of the fact that your highest PSNR point is 30, that's still unwatchable. We do indeed lose around the 30dB mark, but we consistently beat x264 again from 35dB and up (same settings).

Now, more to the point, we've definitely seen parkjoy being one of the clips that we do poorly on. Other clips in this same bucket are crowdrun and parkrun, they're all basically very similar clips, and we tend to be worse than x264 on some datapoints for these clips, similar to your graph (all around the 30dB point). This is probably due to a mix of AQ, mbtree and possibly other things.

VP9 is currently not optimized for extreme test footage like parkrun, parkjoy, etc. - those edge cases will be covered later this year. Right now, we are focused on real-world videos that people watch every day and represent the vast majority of real-world content. Note also that if you disable aq and mbtree (--aq-mode=0 --no-mtree), you'll see we consistently beat x264 at all datapoints for these clips.

[benwaggoner]

First, a general comment: I'm a little suspicious of the fact that your highest PSNR point is 30, that's still unwatchable. We do indeed lose around the 30dB mark, but we consistently beat x264 again from 35dB and up (same settings).
Are you using PNSR as your primary measure for quality at this point? Have you done any double-blind subjective testing yet?

Note also that if you disable aq and mbtree (--aq-mode=0 --no-mtree), you'll see we consistently beat x264 at all datapoints for these clips.
By that, are you indicating you plan to implement similar features in the reference VP9 encoder? Those features are huge for improving perceptual quality, and I imagine would help VP9 as much as H.264.

To some degree this thread is conflating two related but distinct questions:

What is the potential compression efficiency of VP9 compared to H.264 and HEVC?
How does the current VP9 encoder compare to the best encoders for H.264 and HEVC?


It would be unreasonable to extrapolate VP9's relative potential based on the current encoder, as it clearly is not nearly as refined as available H.264 encoders.

It would be reasonable to extrapolate how useful VP9 is at this moment in time based on the current encoder, since that's all there is.

HEVC and VP9 are a lot easier to compare at this point since they both have encoders at early stages of refinement.

There's also a lack of clarity about what we mean by "quality." I only talk about quality in terms of subjective quality myself. When I'm talking about PSNR I call it "PSNR" - my customers never watch rate-distortion curves :). But codec developers tend to talk about PSNR a lot more than codec operators; it's a time-honored and easy to measure objective value.

[paradoxical]

First, a general comment: I'm a little suspicious of the fact that your highest PSNR point is 30, that's still unwatchable. We do indeed lose around the 30dB mark, but we consistently beat x264 again from 35dB and up (same settings).

Beat in what manner? Subjective quality or just PSNR? Because purely on PSNR is meaningless. Most of us here are not impressed by a codec that can win in PSNR by blurring details out. Which is why the original VP8 vs x264 comparison that On2 did (http://web.archive.org/web/20100208115706/http://www.on2.com/index.php?599) was a complete joke. It's because of comparisons like that that you will see many people here very skeptical of claims when it comes to new codecs (and, no, it's not because we are fanboys).

Note also that if you disable aq and mbtree (--aq-mode=0 --no-mtree), you'll see we consistently beat x264 at all datapoints for these clips.

Isn't that sort of a tautological statement? Yes, if you purposefully disable optimizations that are there specifically to increase subjective quality you can make x264 look worse. Alert the press!

[mandarinka]

VP9 indeed smooths everything heavily. Not just temporally, it will wipe grain-like texture that is static, too. The lack of psy makes it very hard to establish that it is really better than x264 in compression... because all that removed detail and noise must save tons of bits, yet the results of VP9 aren't so great. I suspect its rate-control is still very poor which together with lack of AQ and psychovisually tuned RDO means the visual quality is way behind x264.

However, VP8 (last release from year ago, dunno if there are newer betas) is also quite bad - compared to VP9, much worse - as far as I can tell, after 2 years of being in the market. So there aren't any guarantees that Google will improve their encoder quickly/substantially. I may be wrong of course.

----------------------------------------
Here are randomly picked frames (http://check2pic.ru/compare/29294/10/) from a test I made at 1350kbps, the source is ~2200 frames of scenes taken from a DVD - I would upload the streams, but since the footage isn't permissively licensed, i don't know if I can do it here.

x264 (2216, 32bit, 8bit depth from x264.nl - these are IMHO suboptimal settings, but I picked them for simplicity - lower aq would probably help this source for example):
x264-2216-32-8.exe --fps 24000/1001 --preset veryslow --pass 1 --bitrate 1350 --threads 1
x264-2216-32-8.exe --fps 24000/1001 --preset veryslow --pass 2 --bitrate 1350 --threads 1

vp9 (vp9 - WebM Project VP9 Encoder v1.2.0-2727-g18e0742, build by jeeb):
vpxenc.exe --codec=vp9 --good --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63
--cq-level=20 --end-usage=0 --auto-alt-ref=1 --passes=2 --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0
--static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5
--arnr-type=3 --sharpness=0 --undershoot-pct=100 --target-bitrate=1350 --fps=24000/1001 --width=720 --height=478

Edit: Although I think it is sort of obvious - VP9 is encode b. Encode a is a reference encode with x264, with options above. BTW, the small sizes of the png images aren't accidental. If you encode teh VP9 stream into lossless h.264, the size of the file is half the size of lossless encode of the source.

[Leeloo Minaï]

[post removed]

[vivan]

First, a general comment: I'm a little suspicious of the fact that your highest PSNR point is 30, that's still unwatchable.Have you actually seen pj encoded at 8 mbps? In case not, here you are (https://dl.dropboxusercontent.com/u/16254258/test/vp9/x264_8000.mp4) (psnr is 29.8039).
It looks far better than any youtube video, making all youtube videos "unwatchable" by your definition of quality :D

[Dark Eiri]

Hmm... at least on youtube videos, I think WebM VP8 1080p videos are much higher quality than the H264 counterparts - and I compared a lot of them, the WebM versions seem a lot sharper. I don't know exactly which settings Google is using for x264, but I believe if they say VP9 is a lot better comparing with their own VP8 encodes, I'll be quite happy with it.

[hajj_3]

Hmm... at least on youtube videos, I think WebM VP8 1080p videos are much higher quality than the H264 counterparts - and I compared a lot of them, the WebM versions seem a lot sharper. I don't know exactly which settings Google is using for x264, but I believe if they say VP9 is a lot better comparing with their own VP8 encodes, I'll be quite happy with it.

The filesize is much higher for their vp8 encodes.

[mandarinka]

VP8 also smooths a lot, but it also blocks and bands a lot (way more than VP9).
Same test conditions as above, but x264 against VP8 1350 kbps (http://www.check2pic.ru/compare/29376/) (The binary used was 1.1.0 Eider, last encoder they released, a year ago; the VP8 commandline is the same as with VP9, x264 encode is the same) - some frames are the same, some which were too troublesome to find I replaced with different ones.
encode a = x264, encode b = vp8

[the_weirdo]

"encode a" = x264 or VP9?

"encode b" = x264 or VP9?

From what he describes, I can assume that "encode a" was encoded by x264, and "encode b" was encoded by VP9 (or VP8 in x264 against VP8 test).

[mandarinka]

Yeah, in both cases, A = x264. I added the explanation as an edit to the original post (I didn't want to clog the thread too much), sorry for not being clear. The VP codecs with their PSNR tuning (or you could call it utter lack of psychovisual model) result in very smoothed video with blur and possibly blocks/banding, so anybody aware of that will probably know which one is x264 right away.

[Dark Eiri]

The filesize is much higher for their vp8 encodes.

I've seen some that are quite similar and still, VP8 yeld a much sharper video. The video for Calvin Harris' I Need Your Love is practically the same filesize for both H264 and VP8 and yet, the x264 version is a little blurry.

[the_weirdo]

I've seen some that are quite similar and still, VP8 yeld a much sharper video. The video for Calvin Harris' I Need Your Love is practically the same filesize for both H264 and VP8 and yet, the x264 version is a little blurry.

Of course, this is true when applying to YouTube. Because, ahem, it is from Google.

[paradoxical]

One shouldn't use anime to compare encoders but should use artificial CGI or videogame footage? How does that make any sense? Why should anime be disqualified?

[benwaggoner]

One shouldn't use anime to compare encoders but should use artificial CGI or videogame footage? How does that make any sense? Why should anime be disqualified?
Yeah, testing anime content is really useful when evaluating an encoder's ability to encode anime :)! I've seen psychovisual optimizations that fail badly with cel animation content because of its very different properties.

Quality==Fitness for use, so judging the quality of any given encoder is only possible in the context of particular use.

[paradoxical]

IMHO, the Anime used by mandarinka doesn't seem to have much detail/texture...

That's why.

Seems completely arbitrary. Anime is a great test of preserving gradients and preventing banding.

Apart from that, it has only low resolution (i.e. not high definition).

Because no one encodes SD footage anymore, right? :rolleyes:

[paradoxical]

See above. I simply don't care about Anime. And they could implement something like --tune animation.

I would rather like to see comparisons using very detailed high definition sources showing real-life footage from digital or film camera, high quality CGI footage and modern 3D videogame footage.

Period :p.

Good for you? Then make your own tests testing the footage you care about. You seem to think that what you care or don't care about is supposed to matter to anyone else.

Unfortunately, even though we live in the year 2013, yes, we still have to deal with things like standard definition, chroma subsampling and interlacing...

Yes, which is my entire point. Saying "no SD content" is ridiculous since there is overwhelmingly plenty of content that will never be available at anything but SD resolutions.

[paradoxical]

Why should i ask for something i don't care about?

I did not say "no SD content". I simply didn't ask for it.

Then make your own comparisons rather than simply whining that you didn't like the content someone else chose to use. Nowhere in mandarinka's post did I see him asking your opinion on anything.

[benwaggoner]

--tune animation
...
And they could implement something like --tune animation.
Actually x264 does fine encoding cel animation using --tune film or no --tune at all. It can do a better job with the correct tuning, but it is not one of the pathological encoders I was referring to.

As yes, VP9 certainly can and probably should introduce an animation tuning mode. Good psychovisual tuning requires tuning for animation, even if it is an internal mode switch or a sufficiently advanced psychovisual model that has been extensively tested against cel animation.

The encoders that do badly with it are generally ones that didn't get good subjective visually tuning against animation sources. One of the big risks for codec developers is an insufficiently diverse library of sources.

[mandarinka]

I have chosen my sample for a single reason - nobody tests any clips like this. Note that this isn't particularly "anime" sample - it shakes, has noise, is cel (not used anymore today), is not digital, has grain. It might be closer to film sources (16mm in this case, I think?).

And it perfectly shows how much VP encoders suck when you are targeting transparent quality. Of course, I didn't use transparent bitrates (although a few months back I tried 2 megabits) but you can clearly see where VP9 aims to be - it is effectively tuning for PSNR and nothing else. This is no news though. I just hope the format itself isn't compromised in visual quality by development with an encoder that sorta ignores it.
IMHO this is an interesting type of footage to try (definitely more fun that Foreman and I would say less crazy than Parkrun/Parkjoy) and as benwaggoner says, it is better suited to no tuning or tune film in x264.
(And when I say interesting, I don't mean just the battle bikini...)

Here is a link with an archive (http://ulozto.net/xJcLBB6z/vp9-x264-test-dvd-sample-zip) that contains 1) vp9, vp8 and x264 encodes I posted screens from. 2) lossless reencode of the source footage 3) lossless reencode of teh VP9 encode, so that you can actually watch it (in motion, it looks worse than on stills, because there is a weird flickering of brightness in many scenes, I think it is a nasty side-effect of the altref smoothing or something?).

Unfortunately it's only a comparison of x264 vs. VP9, without showing the original source, but IMHO "encode b" (VP9) looks better than "encode a" (x264) because VP9 has noticeably less artifacts.
Now this is IMHO a fallacy. Note how VP9 used little to no bits to preserve the dirty/grainy backgrounds (or flat areas - you can see blocking on the girl's hair for example, because VP9 didn't code any residual at all there, I think). So naturally it has much more bits to throw at the outlines, but that hardly means it is more efficient at compression. Given the amount of smoothing it does, its improvements on the outlines are very meager IMHO (the cause could be primarily in sucky ratecontrol though).

You can watch the actual encodes if you download the zip. I think you would agree that x264 is more watchable.

[MasterNobody]

Here is my little (3 samples) VP9 vs x264 test. Not very representative (need more samples) but at least I didn't used parkrun / park_joy for test which were criticized as insane.
Here is archive xls-files with metrics and plots:VP9_vs_x264_metrics.zip (http://www.sendspace.com/file/7td7cs)
And here encoded samples with cmd-files I used for encoding: VP9_vs_x264_samples.zip (http://www.sendspace.com/file/pznpca)

P.S. Sorry, no time to make screenshots or to make formatted post with tables so download archives.

[benwaggoner]

Here is archive xls-files with metrics and plots:VP9_vs_x264_metrics.zip (http://www.sendspace.com/file/7td7cs)
And here encoded samples with cmd-files I used for encoding: VP9_vs_x264_samples.zip (http://www.sendspace.com/file/pznpca)
I don't see any way to download anything other than an .exe from that hosting provider.

[phate89]

I don't see any way to download anything other than an .exe from that hosting provider.

Uncheck the checkbox that tells you accept to download with their download tool, click on the button download now (or something like that, i don't remember exactly) , the page reloads, click on "Click here to start download from sendspace"

[dapperdan]

I have chosen my sample for a single reason - nobody tests any clips like this. Note that this isn't particularly "anime" sample - it shakes, has noise, is cel (not used anymore today), is not digital, has grain. It might be closer to film sources (16mm in this case, I think?).

And it perfectly shows how much VP encoders suck when you are targeting transparent quality. Of course, I didn't use transparent bitrates (although a few months back I tried 2 megabits) but you can clearly see where VP9 aims to be - it is effectively tuning for PSNR and nothing else.

I understand (I think) why grain is an issue for PSNR (in short because the best way to "preserve" it is basically to fake it) but why would preserving the detail on a static painted background not give you a higher PSNR score?

[dapperdan]

The VP9 Bitstream (at least for "profile 0") is now frozen, according to the latest info posted to this thread:

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

[mandarinka]

Am I the only person that finds it very weird that changes to the format are pursued and hectically made in the last few days and even hours prior to the bitstream finalization?
IMHO there is no way there could have been enough review to really do this all properly and search for possible problems.

Compare that to the lengthy and careful process HEVC has been through... true, maybe it was too lengthy and too slow, but surely that can't hurt as much as this hurry.

[hajj_3]

interesting, their website said the bitstream would be finalised on 17th, maybe they are testing until 17th then going public saying it is finalised assuming they don't find mistakes.

[Bathrone]

Has anyone got any links to windows builds please in preferably 64 bit or 32 bit if I have too? Im having troubles with cygwin and am after the latest compile from the git experimental tree from webm

[hajj_3]

Has anyone got any links to windows builds please in preferably 64 bit or 32 bit if I have too? Im having troubles with cygwin and am after the latest compile from the git experimental tree from webm

This might be of use: http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=summary

[Kurtnoise]

Has anyone got any links to windows builds please in preferably 64 bit or 32 bit if I have too? Im having troubles with cygwin and am after the latest compile from the git experimental tree from webm
x86 (http://tinyurl.com/mlmzm2l) / x64 (http://tinyurl.com/m93ehyu) builds from today.

[mzso]

Anyone have any ffmpeg vp9 enabled builds for windows?

[Selur]

a. I hope the official release will be multithreaded, since single threading vp9 encoding is just too slow to be really useful.
b. does someone know what are valid arguments for, the new parameters ?
--lossless=<arg> Lossless mode
--frame-parallel=<arg> Enable frame parallel decodability features
--tile-columns=<arg> Number of tile columns to use, log2
--tile-rows=<arg> Number of tile rows to use, log2
c. hope will be faster with providing a usable documentation than the last time (when vp8 was released)

[Kurtnoise]

a. I hope the official release will be multithreaded, since single threading vp9 encoding is just too slow to be really useful.
Known issue (https://code.google.com/p/webm/issues/detail?id=527)...

b. does someone know what are valid arguments for, the new parameters ?
--lossless=<arg> Lossless mode

--lossless=1, dunno about the rest.

[Bathrone]

x86 (http://tinyurl.com/mlmzm2l) / x64 (http://tinyurl.com/m93ehyu) builds from today.

Legend thankyou Merci

[Selur]

Known issue...
LOL and then you read that 'Google urges (for) fast adoption of VP9',... (+ but good that they have '-t <arg>, --threads=<arg> Max number of threads to use' as an option :D *gig*)

--lossless=1, dunno about the rest.
Thanks, didn't work for my before, since I didn't set '--min-q=0 --max-q=0' since I assumed that '--lossless=1' would automatically do this.

Cu Selur

[Leeloo Minaï]

--lossless=1, dunno about the rest.

Thanks, didn't work for my before, since I didn't set '--min-q=0 --max-q=0' since I assumed that '--lossless=1' would automatically do this.

Cu Selur

vpxenc definitively needs presets like x264.

[Selur]

I think first we need to a usable way to playback it. ;)

[Bloax]

Well as of the current, my experience with VP9 is that encoding is glacial - and decoding either whines about lacking FPS settings (despite vpxenc.exe outright refusing to work if you use the --fps xx/--fps=xx switch) or just outright refuses to be output.

i must be doing something horribly wrong
except it's not told anywhere so joke's on them

[benwaggoner]

Well as of the current, my experience with VP9 is that encoding is glacial - and decoding either whines about lacking FPS settings (despite vpxenc.exe outright refusing to work if you use the --fps xx/--fps=xx switch) or just outright refuses to be output.

i must be doing something horribly wrong
except it's not told anywhere so joke's on them
I think it's just that VP9 and HEVC are really at similar development stages right now. If Google puts the productization resources into VP9 that HEVC is getting, the bitstream will get a good shake.

The risk is that, like with VP3-9, we'll see a potentially promising bitstream get hobbled by having on a single vendor focused on it with an unhealthy PSNR bias, competing with a whole lot of other companies making big bets on making the best implementation for particular scenarios of the mainstream MPEG/ITU codec.

Single-developer codecs have been successful in the past; RealVideo and Windows Media did quite well in their eras, and certainly help their own and more versus MPEG-4 Part 2. But things were different with H.264. Momentum begats momentum, and when you have 90% of the world's best encoder developers focused on a particular bitstream, implementations get better fast.

I believe that if Microsoft had a sustained, coordinated effort around improving VC-1 after 2007 it would have remained quite competitive for some time (dynamic frame resizing was a hugely effective feature and much more friendly for software decoders than H.264's expensive in-loop deblocking). But there weren't any other companies in the wings to take lead in implementation when Microsoft progressively disbanded the Digitial Media Division and its component parts until there was simply no center of excellence for digital media instead Microsoft; just a lot of little teams solving their own local problems with the staff at hand and with very little coordination.

A successful VP9 will see multiple third parties competing hard to make the best implementation for particular scenarios of note. Even if it had a bitstream with 10% more raw potential, real-world results from having 10 focused encoding companies trying to make HEVC better would easily swamp that 10%. Psychovisual and scenario-specific tuning can drive 50% efficiency improvements in a couple of years.

[mandarinka]

I'd say it isn't completely the same. They were frantically working on the bitstream itself for this whole first half of this year, whereas HEVC was virtually done since january... which means codec developers have had a head start. Ateme, MainConcept, Vanguard, Cyberlink, Elemental and some other broadcast guys already announced their stuff, and that is just software. There are probably more players preparing to announce their encoders (and working on the code)...

What I wholeheartedly agree with is that as long as the only VP9 vendor is Google, the real produced encodes won't be anything spectacular, for the reason you described. I admit that I haven't been following how much VP8 changed over the three years that it was supposed to be on market (but was it? Google pushed it for yt, but that is opt-in for users, and of course it is natural for Google to deploy it, even if it sucked completely). But what I see now is still a codec with no psychovisual tuning - how much progress has there really been on the video quality? So if I had to judge based on VP8, then no, VP9's quality isn't really going to see much progress :D

[Bathrone]

Well as of the current, my experience with VP9 is that encoding is glacial

The discussion list for the project clearly says that they are not optimizing the code right now. Up till recently the focus of the project has been the bit stream. Optimization is the next phase.

Gee you critics are needlessly harsh. No one seems to recognise that here we have a competitor to HEVC, but we can legally use it without patent claims. x264 was always legally unclear in many countries because H.264/AVC is covered by lots of patents which some countries would enforce. Now we have a next gen codec that is totally free of patent encumberment. That alone makes it worth more interest than HEVC so we arent writing cheques out to media cartels

[dapperdan]

Google have committed to using it on Youtube and that internal usage alone should be enough to drive performance increases since they're accepting 100 hours of new video every minute (and encoding it in multiple resolutions). That's possibly enough money coming out of some department's budget to pay for the engineering time by itself. Though, having said that, I'm guessing they're relatively happy with single-threaded code, since they've got plenty of other videos they can use the spare cores for.

They've also announced their intention to push it for video chat in Chrome via WebRTC project. This also gives them motivation (from within yet another separate team within Google with it's own objectives to meet) to optimise for realtime and multithreaded encoding on various chipsets.

Same applies for decode in Chrome, (primarily at first with content from Youtube) but I don't know if anyone's complained about that being slow yet, or if it actually is or not (I seem to recall this being a relative strong point of VP8). If anyone is going to feel that pressure though it's the Chrome team, particularly on netbooks and mobile.

So I wouldn't worry about it too much, particularly based on a bitstream that's just been frozen.

[benwaggoner]

The discussion list for the project clearly says that they are not optimizing the code right now. Up till recently the focus of the project has been the bit stream. Optimization is the next phase.
Correct. The slow speed of the current encoder shouldn't be considered intrinsic to the technology itself. That said, the VPx series has typically lagged in speed @ quality performance.

Gee you critics are needlessly harsh. No one seems to recognise that here we have a competitor to HEVC, but we can legally use it without patent claims.
It may be found to be true that VP9 doesn't infringe on any patents, but experience suggests it'll be some years and lots of patent attorney billable hours before there's a clear answer to that.

Both VP8 and VC-1 wound up with lots of patent claims being asserted that weren't anticipated during standardization.

x264 was always legally unclear in many countries because H.264/AVC is covered by lots of patents which some countries would enforce. Now we have a next gen codec that is totally free of patent encumberment. That alone makes it worth more interest than HEVC so we arent writing cheques out to media cartels
One upside to MPEG-LA licensed technologies is that all the major patent owners in the video space agree to not assert any patent claims against anyone who has licensed the technology. So while there is the cost of licensing, the potential attack surface of patent claims is much, much smaller.

Sometimes it's cheaper to pay a known amount with relative security than it is to pay nothing but have to account for a higher risk of patent claims. Even if a patent is invalidated, defending against them is expensive, time consuming, and adds business risk.

The last popular "patent free" codec was MPEG-1. Since then, the industry has repeatedly voted that "free" has the potential of being way too expensive to be worth it.

Companies hate unbound risk. And AFAIK, no company that has a MPEG-LA license for H.264 has ever had a meaningful economic hit from losing a patent suit.

That said, there's lots of stuff that Google could do to mitigate those risks, like indemnifying all VP9 licensees. Thus they'd defend all VP9 patent claims and reimburse companies for any actual damages they were required to pay. Or a patent pool could be formed. It wouldn't have to be the MPEG-LA model; Google could potentially just pay a one-time fee for indemnification from the major patent-holding companies.

The licensing side of things strikes me as too ambiguous to worry about too much right now. The real question is whether VP9 will be a competitive bitstream, and for which scenarios.

If there's important stuff that VP9 can do substantially better than HEVC, there will be a lot of momentum to take care of licensing issues one way or another.

[paradoxical]

No one seems to recognise that here we have a competitor to HEVC, but we can legally use it without patent claims.

I can legally use an HEVC, H.264, etc. codec without worrying about patent claims. So VP9 gains me nothing in that area.

x264 was always legally unclear in many countries because H.264/AVC is covered by lots of patents which some countries would enforce.

It was pretty much known from the beginning that you had to license MPEG-LA patents in order to distribute x264 binaries or that using x264 to do commercial distribution of video (such as VOD, commercial Blurays, etc.) would require royalty payments in the United States. The MPEG-LA was quite upfront about the terms with regards to H.264. There was never anything "legally unclear" unless you were willfully ignorant.

Now we have a next gen codec that is totally free of patent encumberment.

Again, irrelevant for most people here.

That alone makes it worth more interest than HEVC so we arent writing cheques out to media cartels

I've yet to write a single check to a "media cartel" to use H.264 or for the HEVC test encodes I've done. So apparently this "interest" is lost on me.

[dapperdan]

Or a patent pool could be formed. It wouldn't have to be the MPEG-LA model; Google could potentially just pay a one-time fee for indemnification from the major patent-holding companies.

This (may have) already happened. There's some vagueness about the strength, number, essential-ness and validity of the patents and that impacts on how much Google paid them but the companies that came forward for MPEG-LA's patent pool seem to have opted for the latter approach rather than the standard usage fee based pool which points to either weak patents or a big bag of cash from Google (or some combination thereof).

http://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html

List of the companies involved (which wasn't made available at the time the story initially broke):
http://www.webmproject.org/cross-license/primary-licensors/

Google seems to have demonstrated it's commitment to fighting/paying off anyone it needs to so I'm not sure the remaining suits from Nokia make VP8 any worse in this regard than H.264 given the Motorola suits.

(Note the pool was formed around VP8, but the agreement covered VP9. Maybe other companies outside that group will claim patents on VP9 incremental improvements over VP8, but that seems much less serious than hassle from the big players)

[nevcairiel]

Wasn't there something about Nokia refusing to join the VP8/9 patent pool, leaving Google a bit in an awkward position?

[dapperdan]

Wasn't there something about Nokia refusing to join the VP8/9 patent pool, leaving Google a bit in an awkward position?

Yeah, they're currently suing HTC over Android using a bunch of patents, some of which is VP8 related.

They also listed 12 or so patents at the IETF that they claim VP8 infringes (though there's no business reason for them to be truthful here and some other highly respected names in IP spam pretty much any related IETF disclosure since there's no downside to claiming too much)

https://datatracker.ietf.org/ipr/2035/

list with clickable links to actual patent filings:

http://mdpaste.appspot.com/p/agdtZHBhc3Rlcg0LEgVQYXN0ZRjJoxYM

And some more background info:

http://www.groklaw.net/articlebasic.php?story=20130324162902177

So Google has to work around, pay for, invalidate or win in court (and/or the court of popular opinion), or call Nokia's bluff on those patents for VP8 (and I'm assuming they apply, or not, roughly equally to VP9) and it's very possible Nokia have more "encoding video *on a phone*" type patents they could dig up if they really wanted to.