- From: Robin Raymond <robin@hookflash.com>
- Date: Sun, 11 May 2014 11:44:02 -0400
- To: "public-ortc@w3.org" <public-ortc@w3.org>
Scenario: 1) Alice (who supports "codec1", "codec2") wants to send video to Bob, Charles and Debbie (who all support "codec1" and "codec2") 2) Alice decides to SVC encode the information once using "codec1" and send that encoded stream to Bob, Charles and Debbie (but since each receiving party aren't all equal bandwidth some will receive more layers than others). 3) Edward wants to receive video from Alice but only supports "codec2" with SVC 4) Alice switches to "codec2" SVC and sends to Bob, Charles, Debbie and Edward Currently, it would have to be setup as follows: 1) Alice would need to create a "RtpSender" object for each party (which would have an "RtpReceiver" object) 2) Alice would have to configure each and every RtpSender's SVC identically 3) When switching codecs, Alice would need to set up a brand new RtpSender object per receiver and each receiver would need to create a brand new RtpReceiver object when the codec was switched Obviously, we can argue if that use case should be supported or not but this is a realistic use case I want/need ORTC be able to do. Plus, since ORTC is supposed to be able to support simulcast and SVC (and SVC is all about multi-party video) this doesn't seem like a far fetched scenario. So might I suggest a couple of things to make this a LOT easier: a) make the SVC layering information as part of the codec's usage definition on the receiver. This would allow switching between codecs with the same SSRC for the receiver without having to set up brand new receiver object every time a codec is changed (fyi - we already support being able to switch codecs on the receiver where no SVC codec is involved but it currently that doesn't appear possible when an SVC capable codecs is used). b) to avoid SVC re-encoding again and against per sender when the encoding mechanism is identical, we recommend media engines auto-detect the same encoding data will be output from multiple "RtpSender" objects; alternatively, we could avoid the auto-detection of identical encodings by way of allowing a "RtpSender" to send via more than one RtpIceTransport / RtpDtlsTransport if we want more of an explicit definition than an implicit one. -Robin
Received on Sunday, 11 May 2014 15:44:33 UTC