VP8 & H.264 Become Mandatory For Browsers With WebRTC Support

[phoronix]

Phoronix: VP8 & H.264 Become Mandatory For Browsers With WebRTC Support

It looks like support for the VP8 and H.264 video codecs will soon effectively become mandatory for modern web browsers, due to the WebRTC standard enforcing support for both codecs...

http://www.phoronix.com/vr.php?view=MTg0MTg

[xeekei]

Why enforce both codecs? I'm usually against artificial barriers, but this was an opportunity to expand VP8's usage.

[Daktyl198]

Okay, this makes no sense to me...

The only two reasons they should have wanted to use h.264 over VP8 is that
1) it's a slightly better codec (c'mon guys, admit it. I don't like that fact either)
2) h.264 is already widely adopted by non-free browsers (i.e. IE lol), so it would make it easier on those browsers when implementing the standard (that is, they wouldn't have to write in support for an entirely new codec).

BUT IF YOU'RE GOING TO REQUIRE VP8 ANYWAY, why also require h.264 which can be a MAJOR pain in the ass for FOSS browsers??
*sniff sniff* I smell lobbyist pigs in here >_> Is no institution safe from money-grabbing bastards anymore??

[Marc Driftmeyer]

Okay, this makes no sense to me...

The only two reasons they should have wanted to use h.264 over VP8 is that
1) it's a slightly better codec (c'mon guys, admit it. I don't like that fact either)
2) h.264 is already widely adopted by non-free browsers (i.e. IE lol), so it would make it easier on those browsers when implementing the standard (that is, they wouldn't have to write in support for an entirely new codec).

BUT IF YOU'RE GOING TO REQUIRE VP8 ANYWAY, why also require h.264 which can be a MAJOR pain in the ass for FOSS browsers??
*sniff sniff* I smell lobbyist pigs in here >_> Is no institution safe from money-grabbing bastards anymore??

To cover both ends of the conversation. The browser view on one end chosen by the user configured for h.264 must be capable of being translated back into vp8 by the other browser which didn't configure for h.264.

[Daktyl198]

To cover both ends of the conversation. The browser view on one end chosen by the user configured for h.264 must be capable of being translated back into vp8 by the other browser which didn't configure for h.264.

Well, see, the way a specification works is that all projects (browsers, in this case) claiming to adhere to it must actually adhere to it. In this sense, if they had just said "WebRTC requires VP8" and ended it there, there wouldn't BE any browsers using h.264 to encode the video!! Because it wouldn't be allowed via the specification!

That brings up another good point though: this makes it twice as hard on the people having to actually program this. Instead of being able to just assume the incoming video stream is one codec or the other (as they would if they had simply chosen a single codec), they have to monitor to see which codec it is.

[jimbohale]

To cover both ends of the conversation. The browser view on one end chosen by the user configured for h.264 must be capable of being translated back into vp8 by the other browser which didn't configure for h.264.

Yup. I believe it is because we are in a transitionary period between h264/5 and VP8/9 if this works out how I think they are wanting it to. I think they are trying to get browsers to a state where they support both, and then slowly migrate to VP8/9 over time. Ultimately I'm a bit worried that scumbag companies like MPEG LA will have possession of a patent that covers a lot more than what it was intended and they will patent troll it somehow, but hopefully we have some sort of patent reform soon that will help deal with those fears.

Well, see, the way a specification works is that all projects (browsers, in this case) claiming to adhere to it must actually adhere to it. In this sense, if they had just said "WebRTC requires VP8" and ended it there, there wouldn't BE any browsers using h.264 to encode the video!! Because it wouldn't be allowed via the specification!

That brings up another good point though: this makes it twice as hard on the people having to actually program this. Instead of being able to just assume the incoming video stream is one codec or the other (as they would if they had simply chosen a single codec), they have to monitor to see which codec it is.

No, WebRTC is a very standard protocol and that's already in the protocol, so it doesn't make it any harder to find out the codec. Just blindly using one codec is dumb because it's likely that there will be more down the road. Common sense, please.

[kurros]

Without Apple and Microsoft on-board for WebRTC, having a "standard" is doomed anyway. Coincidentally they are the two that don't support VP8 right now.

In a hypothetical Utopian scenario where Apple and Microsoft finally got on-board with WebRTC and support VP8, requiring both codecs might reduce fragmentation for a short period. If it was agreed to use only use VP8, someone (read: Microsoft and Apple) would buck and offer H.264 as an option (or just ignore the VP8 mandate). And that is without considering VP9 or H.265, which are vastly superior to VP8/H.264 for video RTC.

It is confusing to me as all the players involved with WebRTC already support VP9. I can only assume that the compromise is for the sake of CPU/GPU requirements.

[mark45]

Didn't Google switch to VP9 from VP8 for youtube?

I mean, VP9 is clearly the present and the future, why hold onto the (much) more inferior VP8?

[xeekei]

Hopefully Xiph.org will release Daala soon, and that it will be accepted as an option.

[zxy_thf]

Didn't Google switch to VP9 from VP8 for youtube?

I mean, VP9 is clearly the present and the future, why hold onto the (much) more inferior VP8?

WebRTC isn't something for online videos like YouTube.
You can see Cisco only gets baseline profile implemented in its OpenH264.