Google Gets Ready With VP9 Codec

[archibald]

There is no way in hell VP9 supplants H.265 in any market form, period. End of story.

I disagree: it may have no effect at the upper end, but I think it could really shine in the lower/middle sections. These are the sections where the costs of licensing h.265 could be a significant consideration, and the option of a free codec might start to look very friendly to a cash-strapped studio. I think the main thing blocking it at the moment is hardware support.

Whilst we can (and do) compare codecs side by side, given that we don't watch and compare videos most of the time (cinema, youtube, TV, Laserdisc...), I suspect the quality difference might not be as significant as it appears when comparing side-by-side.

[Prescience500]

1: There is nothing to beat to the market. HEVC is done and the Samsung Galaxy 4 already supports it.
2: VP8 was never even competitive to decent AVC encoders. Maybe VP9 will catch up with AVC but no way with HEVC.
3: On2, the company Google bought for VP8, has a long history of flat-out lying about their codecs? quality.


WebM is no container. It's just Matroska with another file extension.

Prehaps not, but it will weaken MPEG LA by significantly driving down the prices that they'll be able to charge people. That means it'll hurt their ability to develop new codecs in the future because they won't have as much money to spend on it because it won't be as profitable.

[Marc Driftmeyer]

Google is great for people deluded into thinking they give a rat's ass about you.

There is no way in hell VP9 supplants H.265 in any market form, period. End of story.

[Awesomeness]

Beat H.265 to market and force all Android phone makers to support it.

1: There is nothing to beat to the market. HEVC is done and the Samsung Galaxy 4 already supports it.
2: VP8 was never even competitive to decent AVC encoders. Maybe VP9 will catch up with AVC but no way with HEVC.
3: On2, the company Google bought for VP8, has a long history of flat-out lying about their codecs? quality.

WebM is a container flexible enough and was designed to support multiple codecs since Google has been planning to update VP8 all along. This will happen as VP9 gets finalized. No need for WebM2.

WebM is no container. It's just Matroska with another file extension.

[plonoma]

i have the suspicion that the main problem with the adoption of vp8 is HW acceleration. And this shouldn't be the case with vp9 if google wants it to succeed.

They could do OpenCL decoders that would work on a wide range of devices without rewriting.
Could do a lot for HW acceleration.

[XorEaxEax]

Please, please, tell me how - I would love to support libvpx in realtime on common (or at worst, high-end, modern) hardware.

You should direct these questions to the webm/vp8 discussion lists, like: https://groups.google.com/a/webmproj...um/codec-devel

Given that this is an area where vp8 (and I assume also vp9) is supposed to shine, I'm certain you can get information on how to best yield quality output in a real-time setting, I mean this is what the whole 'hello Chrome/Firefox' WebRTC announcement showed off:

https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-calling/

http://blog.chromium.org/2013/02/hello-firefox-this-is-chrome-calling.html

I am also assuming that we are talking about VP8 here, VP9 isn't yet finalized and serious optimization work on is unlikely to happen until it's features are finalized.

[pdffs]

MP4 container? WebM is based off Matroska.

Yes, my point was, out of the two serious contenders (that are actually both required for HTML5 video support across the gamut of browsers), one requires using H.264 (that libx264 does an amazing job of) in MP4, which simply can not be stream encoded (due to the way it stores it's metadata). And the other is a gimped version of matroska that (unless you use Chrome on Linux, which by accident supports H.264 in matroska with the video/webm MIME type and the right codecs installed) requires video encoded by the abysmally (IME) performing libvpx.

a. you are trolling

I wish I was.

b. you doing it wrong [TM]

Please, please, tell me how - I would love to support libvpx in realtime on common (or at worst, high-end, modern) hardware.

c. you are using really old software

I am using the latest available avcodec codebase. If there are better alternatives available, I would be very glad to hear of them (though, a common interface is rather useful, until it's not).

d. you hit some really nasty bug

I really hope so! I am dead serious - if anyone has methods of producing high quality realtime output from libvpx, I'm all ears. I'll gladly credit them in my application (it's GPL anyway, though not published yet, partly thanks to codec/container nonsense).

yes x264 is awesome too

It really is.

[GreatEmerald]

I can in a heartbeat on a PC, you just have to listen the whistling of the fan ramp up on VP8.

That has nothing to do with the codec itself, but rather with your hardware.

[deanjo]

it's not as if anyone I've shown Youtube vp8 and h264 videos have been able to tell the difference, and I haven't either.

I can in a heartbeat on a PC, you just have to listen the whistling of the fan ramp up on VP8.

[XorEaxEax]

If all the OEM's hear from everyone is that "VP9 is worse than h.265", that's enough to shut them off from even hearing more about it and considering it, and they'd rather pay that extra 50 cents.

The chipmakers will support it if they think it makes their chips more attractive, in webm's case (VP8/VP9) it's also free to implement. Google can mandate VP8/VP9 hardware support for chips used in Android devices, but I'm not sure they've gone that far, still there are already many chip makers who implement hardware webm support including AMD, ARM, Broadcom, Qualcomm, Texas Instruments etc

Actually, they'll probably have to pay anyway for the next 5-10 years, even if they do support VP9. Unless they are a camera maker, they will at least have to support both for a while.

Certainly, but they don't have to pay Google for implementing VP8/VP9 support in their hardware, it just adds to the capacity/attractiveness of their product.

So if VP9 is not even better than h.265, they'll just say "why bother implementing this, too?!". That's bad for VP9, and why it's to critical that VP9 wins in performance. I know VP9 has been in development only for 2 years, while h.265 for 5 years, but in the end no one cares about excuses.

The chipmakers don't care about the quality of said codecs, they implement these technologies in order to make their chips more attractive to buyers (ie those who make devices). Android devices (of which there are 'quite a few' last I checked) will support VP8/VP9 and will therefore want chips with hardware support for these codecs, Google's upcoming Glass will most likely use their own VP9 codec for recording video, etc.

Also from what I've read of VP8/VP9 it seems that they've also tailored the codec specifically for great real-time performance, which is what made it such a hot candidate as a WebRTC standard.

It just needs to beat it, if they want people to demand support for it in both software and hardware. So I sure hope this is not another one of Google's half-asseries again.

There is no 'half-assery' going on, there's this thing called 'software patents', these software patents are defined very broadly and in areas such as video compression there is a ton of them, so there is only so much room for VP9 or any other new competing codec to develop improvements in.

There's nothing 'technical' preventing Google or anyone else from creating a codec just as good or better than h.265, but there's a crap-load of patents preventing it. Get used to it, it's only going to get worse.

So no, given the vast amount of video patents in the MPEGLA patent pool I seriously doubt that VP9 can come out on top in a h.265 vs VP9 comparison, it would be something close to a miracle if it did, but it can certainly be good enough for web-video, it's not as if anyone I've shown Youtube vp8 and h264 videos have been able to tell the difference, and I haven't either. It's free to implement in hardware, it's free to implement in software, resulting video files are free to distribute, the quality is good enough by far for web video purposes.