7 ms·
VP8 and H.264 to both become mandatory for WebRTC
- yuhong 12y agoHopefully this means MS is finally willing to support VP8 and hopefully WebM too.
- cwyers 12y agoSeeing as Microsoft is still pushing an alternative to WebRTC, I somehow doubt it.
- rictic 12y agoI 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 https://status.modern.ie/webrtcobjectrtcapi
- cwyers 12y agoI think the plan is for Microsoft to ship Object RTC API in IE, and then to ship some sort of a polyfill on top of that that lets you talk to WebRTC over Object RTC.
- rurounijones 12y ago> “WebRTC-compatible” endpoints will be allowed to do either codec, both, or neither. Neither?! What? How will that work then?
- zenojevski 12y agoFor a proxy, I guess, or a load balancer, a mediator, a monitor, and so on.
- cjbprime 12y agoThese 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.
- rurounijones 12y agoSeems 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.
- derf_ 12y agoThis was already-existing terminology in the IETF working-group. A "WebRTC-compatible" device is one that does not conform to the standard, but which can talk to something that does conform to the standard )in whatever limited way it supports). By definition no codec requirements can be placed on it. This was spelled out clearly in the original proposal: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432... The IETF itself of course recognizes that the current taxonomy may not be ideal from a marketing standpoint: http://ietfmemes.tumblr.com/image/102328432749 http://ietfmemes.tumblr.com/image/102328432749
- qznc 12y agoCompare "HD Ready" TVs.
- Someone 12y agoA 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#section-2.2 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)
- Sanddancer 12y agoI'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-Linux 12y agoWebRTC-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 12y agoDoes this matter? Implementors can and will just do whatever they want for really critical things like this.
- TD-Linux 12y agoImplementers 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 12y agoIf implementors want to be able to interoperate with other implementations they will now know which codecs to target.
- asmicom 12y agoI 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!
- billconan 12y agoI thought this is vp9/h265 era already?
- TD-Linux 12y agoEncoders for vp9 and h265 have a long way to go before they can compete for real-time usage, such as WebRTC.
- billconan 12y agobecause they lack hardware implementation? I think vp8 doesn't have too many hardware implementation either. h264's situation is better though.
- ZeroGravitas 12y agoIt'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 12y agoOnly these two, or can others be used as well - such as Daala?
- TD-Linux 12y agoYes - both sides can offer any number of codecs, and will negotiate the best one. MTI is only for a baseline for universal compatibility.
- deleted 12y ago[deleted]
- brunorsini 12y agoI 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 12y agoMost 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.
- fithisux 12y agoI thought OpenCL is a standard interface to create decoders. Moreover a DSP could be exposed as an OpenCL machine.
- shmerl 12y agoI 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_ 12y agoCisco hired a law firm to write a summary, which they made public: http://www.duanemorris.com/memo/VP8Compilation.pdf 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.
- shmerl 12y agoThanks, that sounds pretty promising.
- ZeroGravitas 12y agoNokia 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?
- eridius 12y 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.
- l33tbro 12y agoI 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 12y agoThe 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 12y agoIt 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 12y agoWhy not VP9?
- gcp 12y agoWebRTC requires low-delay realtime encoding.
- markjonson 12y agoSeems like a marketing recipe for disaster. http://www.easycabs.com http://www.easycabs.com