Re: WebRTC-SVC: "S" modes and simulcast using a single SSRC

El mar., 23 jul. 2019 18:25, Bernard Aboba <Bernard.Aboba@microsoft.com>
escribió:

> Sergio said:
>
>
> "So, obviously we can't switch from a single S3T1 encoding parameter
> (simulcast with 3 spatial layers single ssrc) to 3 encoding parameters with
> L1T1 (simulcast with 3 ssrcs/rids), but it is not because we can't change
> from S mode to non-S mode, but because we can't change the number of
> encoding parameters of an rtp sender. However it will be perfectly valid to
> go from S3T1 to L3T1 and vice versa within the same encoding parameter."
>
>
> [BA] Are you saying that going from S3T1 to L3T1 can occur without an
> Offer/Answer negotiation?  That would only make sense to me if the SDP
> remains unchanged (e.g. if there is no simulcast at all in Offer/Answer,
> because there is only one encoding in both cases).
>
AFAIK the SDP should remain unchanged when switching modes.

"The scalability structure present on vp9 svc or dependency info in av1
> will tell the SFU what to do. I don't expect this to be a problem, as
> client apps are tightly coupled to SFUs."
>
>
> [BA] The bitstream is self-describing, and if it is encrypted, the AV1
> Descriptor can provide the required information.  So from that perspective,
> the SFU will figure out what is being sent.  However, if the SFU wants to
> indicate to the browser what it wants (e.g. want to receive 3 simulcast
> streams), it doesn't seem like this is possible with "S" modes if the
> Offer/Answer doesn't include RIDs or an "a=simulcast" line.
>
It's not possible also to specify it for non S modes anyway.

If the sfu wants to indicate the desired mode it should do it in its own
signaling (not a problem imho)

>
> [BA] "S" modes are possible and valid within the AV1 bitstream
> specification, and there seems to be some desire to be able to use them with
> WebRTC.  If it can work as you describe (e.g. no simulcast SDP or RIDs) it
> might even be simpler.
>

Not sure about what is the benefit of S modes compared to their non S modes
counterparts, but it wouldn't have much impact to add them to the spec or
implement them on the browser side if encoders already supports them.



>
> [BA] OK.  Sounds like something we might want to reserve time to discuss
> further at TPAC.
>