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…
Early in 2013, Robin and I were becoming growingly concerned about the direction the WebRTC WG in the W3C and the RTCWEB WG in the IETF were taking, specifically with respect to mandating SDP and not taking into consideration those who might want an Object interface versus a C++ / SDP O/A interface.
Do we need SDP ”blob” format in the exchange in the first place? All media
can be done without SDP given an intelligent stream API. An API already
exists to create these streams (albeit somewhat lacking if we remove the
SDP ’blob’). This API helps “simplify” creating this blob for later
exchange. But the blob is truly not needed. Each side could in fact create
the desired streams, pass in the appropriate media information such as
codecs and ICE candidates and chose the socket pair to multiplex upon.
Yes, it’s a bit more low level but it certainly can be done (and cleanly).
Read the rest here.. ORTC.org/History