Re: Use case - alice multiway video sending using SVC and changing codecs

On Sun, May 11, 2014 at 8:44 AM, Robin Raymond <robin@hookflash.com> wrote:

>
> 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
>

​Why is Alice using SVC if she is sending to each receiver directly and not
sending through an SFU?​  If she's sending SVC to an SFU, why is she
creating separate RtpSenders?  You would do SVC with an SFU or no-SVC with
no-SFU.  Why would you do SVC without an SFU?



> 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
>

​Why?  The RtpReceiver objects could all have both codecs, and the
RtpSender could simply change the order of the codecs so a different one is
sent.  Why re-create objects?​

Do you mean switching between layering and simulcast?  If you want to
change those setting, change those settings.  You don't need a new
RtpSender, I don't think.



>
>
> 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).
>
>
​We already have the layerings/simulcast information in the RtpReceiver,
but that's orthogonal to the codec (modulo not all codecs support dependent
layering).




> 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.
>
>
​If the implementation could avoid re-encoding, that would be a nice
performance optimization.  ​ But having multiple IceTransports and
DtlsTransport hooked up to the same RtpSender can't possibly work.



>
> -Robin
>
>
>