Google Gets Ready With VP9 Codec

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

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.

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

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

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

[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

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

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

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

[uid313]

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.

Doesn't matter if its 1-2% better compression, 1-2% better quality, or 1-2% faster compression or decompression.

It doesn't have to be technically superior. Both VP9 and H.265 are likely so good that the difference will be marginal.

What is important is that it is freely available and open and royalty-free and standardized.