Google VP9 "Next Generation Open Video" information posted

[hajj_3]

Originally Posted by 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.

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 (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]

Originally Posted by jq963152

"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]

Originally Posted by hajj_3

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]

Originally Posted by Dark Eiri

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.

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]

Originally Posted by 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?

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.

Originally Posted by jq963152

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.

Originally Posted by jq963152

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

Because no one encodes SD footage anymore, right?

Originally Posted by jq963152

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 .

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.

Originally Posted by jq963152

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.

Originally Posted by jq963152

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]

Originally Posted by jq963152

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

Originally Posted by jq963152

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
And here encoded samples with cmd-files I used for encoding: VP9_vs_x264_samples.zip

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

[benwaggoner]

Originally Posted by MasterNobody

Here is archive xls-files with metrics and plots:VP9_vs_x264_metrics.zip
And here encoded samples with cmd-files I used for encoding: VP9_vs_x264_samples.zip

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

[phate89]

Originally Posted by benwaggoner

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]

Originally Posted by 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.

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.