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!
VP8 and H.264 to both become mandatory for WebRTC
11–20 of 78 posts
Re: VP8 and H.264 to both become mandatory for WebRTC
#12Earlier quoted context omitted.
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.
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.
This 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...
The IETF itself of course recognizes that the current taxonomy may not be ideal from a marketing standpoint: http://ietfmemes.tumblr.com/image/102328432749
Re: VP8 and H.264 to both become mandatory for WebRTC
#13I thought this is vp9/h265 era already?
Re: VP8 and H.264 to both become mandatory for WebRTC
#14Only these two, or can others be used as well - such as Daala?
Re: VP8 and H.264 to both become mandatory for WebRTC
#15I 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.
Re: VP8 and H.264 to both become mandatory for WebRTC
#16I 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.
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.
Re: VP8 and H.264 to both become mandatory for WebRTC
#17I thought this is vp9/h265 era already?
Encoders for vp9 and h265 have a long way to go before they can compete for real-time usage, such as WebRTC.
Re: VP8 and H.264 to both become mandatory for WebRTC
#18Does this matter? Implementors can and will just do whatever they want for really critical things like this.
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.
Re: VP8 and H.264 to both become mandatory for WebRTC
#19Only these two, or can others be used as well - such as Daala?
Yes - both sides can offer any number of codecs, and will negotiate the best one. MTI is only for a baseline for universal compatibility.
Re: VP8 and H.264 to both become mandatory for WebRTC
#20> “WebRTC-compatible” endpoints will be allowed to do either codec, both, or neither. Neither?! What? How will that work then?
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.