VP8 and H.264 to both become mandatory for WebRTC

[shmerl]

I hope Daala will put an end to this mess. But even though Opus is mandatory now, it didn't yet translate into support by Apple and MS for instance for regular music and Web audio. Their historic sickening opposition to open codecs is not easy to dismantle. Apple still doesn't even support FLAC, just because they like to make things messy for everyone.

By the way, what happened with Nokia's attacks on VP8? Were they refuted by Google or they were validated by some courts?

[derf_]

Cisco hired a law firm to write a summary, which they made public: http://www.duanemorris.com/memo/VP8Compilation.pdf

TL/DR: VP8 was found not to infringe one patent. The other proceeding in the German courts was stayed until it was determined if the patent was valid. Before that could happen, Nokia and HTC settled all of their outstanding suits for some undisclosed amount. All remaining actions between those two parties were dismissed without prejudice (including the VP8 lawsuits). Separately, Google is still proceeding with two lawsuits in Germany to get the Nokia patents declared invalid.

[bhaak]

Despite the gazillions of dollars they have earned, Apple is really constrained when it comes to software development.

They don't have the man power to stray far from their focused feature set. Just look at the mess that iOS 8.0 is. I don't know if they are not willing to hire more capable people or if they just don't care as long as the money pours in (that could bite them in the long term though).

FLAC is a niche feature and those features are usually only supported if someone at Apple has a personal interest in supporting it and if it doesn't get vetoed by the power that be.

In the case of FLAC it might even have been the latter as you could describe FLAC (not entirely correct) as the codec that let's you digitize your CDs losslessly. That view would put it in competition with iTunes (320kps AAC/MP3 ought to be enough for anybody?) and additionally, if you are a true Apple follower, you don't have a CD drive anymore anyway.

[yjm]

For the record VP8 sucks for anyone who needs to support it because it eats up to 7 times more resources than h264 does for transcoding.

[eridius]

> Their historic sickening opposition to open codecs

What are you talking about? I'm not aware of any historic opposition to open codecs at Apple. Hell, they're still big into AAC, which is an open codec. And even ALAC is now open source and royalty-free.

[rurounijones]

> “WebRTC-compatible” endpoints will be allowed to do either codec, both, or neither.

Neither?! What? How will that work then?

[Someone]

A WebRTC-compatible endpoint must be able to communicate with a WebRTC endpoint, but apparently need not understand it, at least that is what I make of it.

https://tools.ietf.org/html/draft-ietf-rtcweb-overview-12#se... mentions one concrete example of a WebRTC-compatible endpoint: a WebRTC Gateway that mediates between a WebRTC endpoint and a non-WebRTC endpoint.

Vague? Yes. Poor choice of words? Yes (both IMHO)

[TD-Linux]

WebRTC-compatible are things that do not implement the Javascript API. These include things like single-purpose smartphone apps. A "WebRTC doorbell" was an example given at the IETF.

With this proposal, any WebRTC-compatible device can communicate with any browser with video.

[cjbprime]

These are video codecs. Presumably an audio-only app (e.g. IP phone) would be compatible too, so that would explain using neither of the two video codecs. WebRTC also has datachannels that use neither audio nor video.

[zenojevski]

For a proxy, I guess, or a load balancer, a mediator, a monitor, and so on.

[Sanddancer]

I'm reading that as WebRTC endpoints have to implement those two, but there's nothing precluding them from negotiating to use H.265 or Sorenson or Mpeg-1.

[yuhong]

Hopefully this means MS is finally willing to support VP8 and hopefully WebM too.

[cwyers]

Seeing as Microsoft is still pushing an alternative to WebRTC, I somehow doubt it.

[asmicom]

I saw it long coming. We were butting head at the IETF 88 in Vancouver last year, and following the various correspondences on the mailing list, I knew we needed to make a compromise.

Good job!

[MichaelGG]

Does this matter? Implementors can and will just do whatever they want for really critical things like this.

[TD-Linux]

Implementers won't be able to call themselves WebRTC implementations. This specification is referenced by corresponding 3GPP specifications, so compliance there will be more strongly enforced.

[guelo]

If implementors want to be able to interoperate with other implementations they will now know which codecs to target.

[billconan]

I thought this is vp9/h265 era already?

[TD-Linux]

Encoders for vp9 and h265 have a long way to go before they can compete for real-time usage, such as WebRTC.

[ZeroGravitas]

It's only the fallback "mandatory-to-implement" codecs they're talking about. If two devices can speak vp9/h265 or others not yet invented, they can use those instead.

[brunorsini]

I don't really agree with the author's comment that this is "an unmitigated win for users": if nothing else, hardware products might become more expensive because they will need native encoding/decoding capability for each codec.

[TD-Linux]

Most hardware decoders are microcoded anyway, supporting H.264, ASP, and VC-1. Adding VP8 isn't that bad - Qualcomm, nVidia, and Mediatek already ship VP8 decoders.

The next generation codecs such as HEVC and VP9 are a lot more computationally expensive and do require a lot more die area.

[higherpurpose]

Only these two, or can others be used as well - such as Daala?

[TD-Linux]

Yes - both sides can offer any number of codecs, and will negotiate the best one. MTI is only for a baseline for universal compatibility.

[ck2]

The problem is the minimum level for WebRTC is so low, it makes H.264 useless for regular video decoding (like what you'd find on youtube).

So hopefully browsers implement more than the minimum.

[gcp]

It would be perfectly possible for a browser to support H264 high profile in WebRTC and refuse to decode it in a <video> tag, for example due to licensing restrictions, so what you're saying is irrelevant.

Remember WebRTC also covers encoders.

[fithisux]

Why not VP9?

[gcp]

WebRTC requires low-delay realtime encoding.

[l33tbro]

I thought the licensing thing is not an issue if you switch to x264 (open source)? Better video also - smaller file size, less artifacts, doesn't desaturate the image.

[markjonson]

Seems like a marketing recipe for disaster. http://www.easycabs.com