Update: There is now some healthy conversation in the IETF WG around what “compliant” and “compatible” actually mean. More on this as it unfolds.
We are now in the final throes of a consensus call in the IETF around which video codec should be made mandatory for those building WebRTC apps, services et al, who wish to be considered “WebRTC Compliant”. The codec contenders are VP8 and H.264, in many forms and combinations.
This latest consensus call is for both codecs to be mandated for all WebRTC endpoints, or “dual MTI codec”. I am sure I will catch hell from someone on language but that is the essence of it. As one might expect, there are some that are in favor and some that are against a dual MTI video codec. Those in favor seem motivated to accept this based on the promise of interoperability that might follow and other reasons. As one might expect, we are all quite eager to put this debate to bed so we could get on with other work.
This is not a decision that should be made lightly. Let’s consider the implications. Imposing a dual MTI suggests that every developer that wishes to produce a WebRTC compliant app must implement both codecs.
I find it difficult to agree to mandate a dual MTI codec knowing that there are a great many developers who will not want or will be in a position to implement both codecs. Yes, many WebRTC SDK vendors will support both. Even if both codecs and their transports are provided as part or could be easily added to the application at compile time it doesn’t mean that every developer will want to implement or ship both codecs.
Bottom line is, according this consensus, if developers do not implement/ship both codecs they are not considered WebRTC compliant. To me, this seems like a rather unreasonable expectation. Developers should be able to choose which codec they ship, and not be forced to do 2x the work to become compliant.
I would love to hear from other developers on this. Do you plan on implementing both VP8 and H.264 in your apps?
It touches on some interesting points, namely “a WebRTC app is not defined by its wrapper.” Here is an excerpt from the post..
Google Chrome was the first browser to support WebRTC, and most of the new applications rely on Chrome in order to be plugin-free. Other browsers that support WebRTC include Mozilla Firefox and Opera. These browsers use much of the same code, yet compatibility issues exist because Chrome has considerably more capability than what’s specified in the WebRTC specification….
There is a some interesting activity regarding Sender / Receivers on both the WebRTC WG and the ORTC CG. Robin Raymond of Hookflash (ORTC CG Editor and Chair), submitted this beauty over an hour ago. To me, this is where we begin to see some real benefits offered by an Object model that is not encumbered by SDP O/A.
Hint: SVC (Scalable Video Coding or Scalable Video Codec) becomes the norm, not the exception.
From Robin’s proposal…
Introduction After attempting to write out some use cases using the existing RTCRtpSender and RTCRtpReceiver objects and parameters for ORTC, some issues were discovered. Specifically, the application developer would need to have a fair amount of knowledge on exactly how to tweak low level parameters for anything beyond very simple use cases. For example, setting up an SVC (Scalable Video Codec) would have required knowing about what codecs support SVC, how the layering is setup for particular codecs, and finally setting up specific geometric (or temporal) attributes and layering relationship details by an application developer.
Robin also includes some great SVC use cases..
Alice wants to use a SVC (Scalable Video Codec) to send to Bob
This is for illustration purposes only. Typical benefits of SVC are
greater in conference scenarios rather than traditional point to point
scenarios. However, this scenario can presume that an intermedia
conferencing bridge would be between Alice and Bob.
Current Parameter Based API
Step 1: (Alice)
var senderCaps = RTCRtpSender.getCapabilities();
Step 2: (Bob)
var senderCaps = mysignal();
var receiverCaps = RTPRtcReceiver.getCapabilities();
Read the rest here…