Google Gets Ready With VP9 Codec

[Kivada]

Now will they finally put their foot down and kill off Flash and their Pepper API? Beat H.265 to market and force all Android phone makers to support it.

IIRC any programmable DSP that can support H.264 can also accelerate WebM. And almost all Android devices have a DSP that can accelerate H.264.

[pdffs]

Let me know when libvpx encode performance isn't absolutely pathetic. I was hoping to use HTML5 video for a realtime streaming application, but the MP4 container is a piece of crap and can't be stream encoded, and libvpx performance is so bad that maxing an IVB i7 results in blocky unwatchable crap with a realtime deadline. Until they fix performance, flash is sadly still the only option for on-the-fly encodes, and libx264 is still absolutely light years ahead in terms of performance and output quality per CPU cycle.

[gigaplex]

Let me know when libvpx encode performance isn't absolutely pathetic. I was hoping to use HTML5 video for a realtime streaming application, but the MP4 container is a piece of crap and can't be stream encoded, and libvpx performance is so bad that maxing an IVB i7 results in blocky unwatchable crap with a realtime deadline. Until they fix performance, flash is sadly still the only option for on-the-fly encodes, and libx264 is still absolutely light years ahead in terms of performance and output quality per CPU cycle.

MP4 container? WebM is based off Matroska.

[jrch2k8]

Let me know when libvpx encode performance isn't absolutely pathetic. I was hoping to use HTML5 video for a realtime streaming application, but the MP4 container is a piece of crap and can't be stream encoded, and libvpx performance is so bad that maxing an IVB i7 results in blocky unwatchable crap with a realtime deadline. Until they fix performance, flash is sadly still the only option for on-the-fly encodes, and libx264 is still absolutely light years ahead in terms of performance and output quality per CPU cycle.

a. you are trolling
b. you doing it wrong [TM]
c. you are using really old software
d. you hit some really nasty bug

yes x264 is awesome too

[deanjo]

MP4 container? WebM is based off Matroska.

Which is another NIH issue. Why the hell Google could not simply use MKV is beyond my understanding.

[gigaplex]

Which is another NIH issue. Why the hell Google could not simply use MKV is beyond my understanding.

It's a subset of Matroska. Matroska splitters support WebM. WebM is pretty much just a spec that says to package VP8 video codec with Vorbis audio in Matroska container. If it was NIH they would have made something from scratch.

[przemoli]

1) Yes Google want to beat h265(6?). So that VP9 is nobrainer pick for performance. (It also include less bandwith for same results)
2) Yes Google want to beat h265(6?). So that VP9 is nobrainer pick for hw support. (It also include compatibility with WebP)
3) Yes Google want to beat h265(6?). Or at least match its standard status. (Hence MPEG is deciding if VP8/9 can be standarized).

[XorEaxEax]

It's too damn early to freeze it.
VP9 must be made better than H.265, otherwise the point of its existence is so moot Google had better not release it at all.

No it doesn't have to be better than h.265, and I doubt it ever will be due to the mess that is software patents, it needs to be good enough for it's intended purpose, which is video on the web, while being FREE.

The latter means that it can be picked up as a standard video component of HTML5, however I fear that will be difficult as the MPEGLA has much to lose on VP9 becoming a standard across the web and while Google and MPEGLA has a deal in place there can always be patent claims made from organisations/trolls outside of MPEGLA, like the recent Nokia trolling (Microsoft puppet company).

I'm certain we will see a continous stream of patent claims made against VP9 in order to prevent it from becoming an official HTML5/ WebRTC standard, simply because the MPEGLA members risk losing lots of revenue should this happen.

[Krysto]

I agree it needs to be better than h.265, even if by 1%, but it needs to beat it across all tests. Some say it doesn't really matter, as long as it's close in performance and open source. But I think it matters a lot - for its image. 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. 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.

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

I do want VP9+Opus to succeed (WebM supports Opus, too, now. Whatever container h.265 is in now, doesn't).

[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.