We have a mandatory to implement codec in WebRTC! And it is… both.
The IETF got to an agreement on the MTI video codec for WebRTC. While I wouldn’t go to all the details and intricacies with the text suggested for the specification, suffice to say that for developers there is now choice between VP8 and H.264.
What interest me most is who wins and who loses in this long fight we had over the video codec in WebRTC. Here’s my list of winners and losers:
Microsoft
Microsoft got what it wanted. Time to prepare their Skype for the web. It also got H.264, which should make its life easier with the existing deployment it has out there for Lync and Skype devices that aren’t easily modifable or upgradable.
On the down side, it now needs to deal with VP8.
Google definitely won this round. Although it now has to concede to adding H.264 to Chrome, it got approval of VP8 into an important specification. It tried getting VP8 through WebM into video streaming and failed, opting for supporting it through YouTube and Chrome. But now it has it on paper that it is mandated for WebRTC.
This also means another reason to force chipset vendors to add VP8 hardware acceleration to their future chipsets.
As Google is already hard at work on VP9, it really has little interest to continue focusing on H.264/VP8 stuff and run as fast as possible to the next playing field of video codecs.
Mozilla
Mozilla is part of the reason this came to be. Its Firefox browser already has support for both VP8 and H.264, the latter through its partnership with Cisco.
Browser Vendors
Other, smaller, browser vendors are the losers here. Apple, Microsoft and Google have already paid the patents of H.264. For them, adding this codec to a browser is just a matter of coding.
Mozilla went through the motions (and pains) related to integrating Cisco’s OpenH264 project, needing to download the codec library dynamically to meet the needs of the royalty buyout license. Doing that yet again per browser is a bit more of a challenge. For those smaller browser players out there, this is going to be a real pain.
Opera, who runs on top of Google’s own Chromium project might find it hard to integrate with an H.264 codec in a way that won’t force them to pay royalties.
In a way, it sits nicely with the fact that browsers today are hard to implement and maintain, with some real barriers of entry:
As CEO Alok Bhardwaj told The Verge, “I think their hope is that us and any other browser disappears.” But without some sort of relationship with Mountain View, it’s not clear how Epic and other projects like it can survive.
Browsers are now a game for large players only. Even if the baseline is built out of WebKit, Blink or Chromium – there are large enough barriers to get it from there to the market.
Cisco (and Enterprise video conferencing vendors)
Cisco got what it wanted. It now has H.264 inside the browser, which means it won’t need to transcode to fit all of its enterprise related video conferencing products and services.
MPEG-LA
Definite losers here.
The fact that VP8 got accepted means VP9 is a reasonable choice for the future video codec, putting into question the whole H.265 royalties game that the MPEG-LA is trying to jump-start.
Application Developers
As long as what you are doing is point to point, you’re good. Just pick out whatever codec you feel more comfortable with and be done with it.
Multipoint is a nasty complexity in this case. For some scenarios, it will be close to impossible to force everyone to the same video codec.
Server Side Media Processing
This one is hard to evaluate. For some, having an extra codec means an unnecessary headache. For others, the fact that transcoding may now be required means more sales.
All in all, server side media processing is now a bit more complex to deal with as it needs to take into account more video codecs.
The Next Fight
That said, the next fight is right around the corner. Browsers will have VP8 and H.264, but the new technology in VP9 is already getting into Chrome and will be with us early next year.
The real winners here are the royalty free codecs movement:
- Images have been patent free for quite some time
- Decent voice codecs have been royalty free as well – SILK, Speex and now Opus
- VP8 just got “standardized” and “mandatorized” for use in an important specification, placing royalty free video codecs as a clear statement of our modern needs
I think you are taking too far the “mandatory to implement” mandate – in the large schema things, nothing changed. There are no real enforcement to get Microsoft to support VP8 or Google to support H.264. And the smoke cloud of Nokia VP8 patent issues didn’t go anywhere. Developers still have to prepare to deal with browser issues, and the only real winners ( or definitely not losers) are the companies which can support transcoding…
Anatoli,
While a specification doesn’t ensure compliance to it, it is better than the other option. This is the first specification that has a non-H.26x codec in it as mandatory to implement. As such, it is a big win for VP8 (and by extension VP9). Having H.264 in there means it wasn’t a knock out but rather winning by points – which is usually the most you can ask for in a standardization war anyway.
Well, I guess the time will tell…
Microsoft is not going to include VP8 just because the IETF writes down a MUST in some spec. Bernard Aboba is explaining why this is not a technical issue about 15 minutes into http://www.ietf.org/audio/ietf91/ietf91-coral3-20141113-1730-pm3.mp3 (in a way such that even I can understand it 🙂
So Opera does everything except H.264 to be compatible with WebRTC and forgo WebRTC label. They can interwork w all other browsers. So its user base has no impetus to change the browser on this count.
My suspicion is Mozilla went through the pain you identify for other reasons and other browsers do not have to follow their lead.
I don’t understand why you and Tsahi say Opera can’t support H.264.
Every device or browser or application can now use H.264.
Because can you just automatically download the Cisco binary from the OpenH264 site. You’ll need to include a URL and hash in your application so you can check what you downloaded was correct.
That is what Ericsson did with GStreamer:
http://www.openwebrtc.io/
Opera is based out of Chromium. They are effectively bound to Google’s decisions. Replacing the video codec that Google ends up using with the OpenH264 one is going to be complicated to implement and a lot more complicated to maintain in the longer term.
I doubt Chromium includes any H.264 support right now. My guess would be Chrome has it.
So if Opera adds OpenH264 to Chromium they won’t have to deal with the other H.264 implementation. It’s the Chrome team that has to deal with the merge. 😉
Also OpenH264 is an open source project. Opera can also add code to OpenH264 to make it easier to fit their needs.
Linux distributions, for decoding at least, already include gstreamer-ffmpeg decoder.
Google uses ffmpeg I believe.
Yes, Opera will have some work to do. Hopefully they are not the only ones that want this.
Lennie,
I think I didn’t make myself clear here. Opera using any H.264 implementation exposes them to royalty payments. Using OpenH264 requires them to dynamically download that library in runtime, which won’t be easy to maintain in a piece of source code maintained by another third party (Google).
I was also thinking: Opera already has a MPEG-LA deal for decoding:
http://en.wikipedia.org/wiki/HTML5_video#Browser_support
That is really good news, because that means we will have IE with more-less standard WebRTC in some time.
Stass,
That is correct. There are questions will Microsoft really adopt VP8, but I think this step is good enough for me now. We can all complain later if they decide not to deliver 🙂
it is a good news. there are lots of application using h264. so it is very neccessay to support it. if you don’t. lots of developers have to do it by themselves. besides . some of my client want to me do it.