VP8 and H.264 to both become mandatory for WebRTC

http://andreasgal.com/2014/11/16/vp8-and-h-264-to-both-become-mandatory-for-webrtc/

by kinetik • 12 years ago

147 74 12 years ago

andreasgal.com

yuhong• 12 years ago

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

cwyers2• 12 years ago

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

rictic• 12 years ago

I came in this thread to say that Microsoft are implementing WebRTC, but when I double checked it looks like it's more complicated than that. There's an API that they want, and may have gotten into the spec called the Object RTC API, but they aren't currently planning on implementing WebRTC as existing browsers speak it: https://status.modern.ie/webrtcobjectrtcapi

rurounijones2• 12 years ago

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

Neither?! What? How will that work then?

cjbprime• 12 years ago

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.

rurounijones2• 12 years ago

Seems like a marketing recipe for disaster.

"Why can't I see you on you on my webrtc compatible desktop app?!"

Like an end-user is going to recognize the difference in terminology.

Someone• 12 years ago

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)

zenojevski• 12 years ago

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

Sanddancer• 12 years ago

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.

TD-Linux5• 12 years ago

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.

MichaelGG• 12 years ago

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

guelo• 12 years ago

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

TD-Linux5• 12 years ago

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.

asmicom• 12 years ago

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!

billconan2• 12 years ago

I thought this is vp9/h265 era already?

TD-Linux5• 12 years ago

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

billconan2• 12 years ago

because they lack hardware implementation?

I think vp8 doesn't have too many hardware implementation either. h264's situation is better though.

ZeroGravitas2• 12 years ago

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.

higherpurpose• 12 years ago

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

TD-Linux5• 12 years ago

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

brunorsini• 12 years ago

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-Linux5• 12 years ago

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.

fithisux2• 12 years ago

I thought OpenCL is a standard interface to create decoders. Moreover a DSP could be exposed as an OpenCL machine.

shmerl16• 12 years ago

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_2• 12 years ago

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.

shmerl16• 12 years ago

Thanks, that sounds pretty promising.

ZeroGravitas2• 12 years ago

Nokia just announced an Android tablet, running Lollipop 5.0 (which requires VP8 and VP9), it also uses an intel chipset with VP8 encode and decode.

Does that trigger any of the reciprocal patent grant thingies that VP8 (and 9?) have and remove Nokia's patents from the picture?

eridius9• 12 years ago

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.

gcp5• 12 years ago

He meant patent-free codecs, not open codecs. i.e. Vorbis, FLAC, Opus, Theora, VP8.

shmerl16• 12 years ago

And even ALAC is now open source and royalty-free.

Nothing stops them from supporting FLAC as well except their nasty attitude in general. FLAC is actually used by many services which sell music, unlike ALAC.

AAC is nowhere patent free.

vetinari2• 12 years ago

What are you talking about?

AAC is pay for use codec and Apple receives royalties for its use through MPEG-LA. ALAC was historically proprietary, it was opened only after it lost to FLAC. Apple never supported any codec, that was really free, like Vorbis or FLAC.

bhaak• 12 years ago

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.

Osmium• 12 years ago

That view would put it in competition with iTunes (320kps AAC/MP3 ought to be enough for anybody?)

Apple has its own lossless audio codec that's supported by iTunes called ALAC. Created in 2004, it was initially propriety but as of 2011 it is now open source and royalty free under the Apache License.

http://en.wikipedia.org/wiki/Apple_Lossless

yjm• 12 years ago

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.

gcp5• 12 years ago

Someone is confusing (crappy) implementations with standards.

l33tbro• 12 years ago

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.

ck2• 12 years ago

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.

gcp5• 12 years ago

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.

fithisux2• 12 years ago

Why not VP9?

gcp5• 12 years ago

WebRTC requires low-delay realtime encoding.

markjonson• 12 years ago

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

VP8 and H.264 to both become mandatory for WebRTC

Related Stories