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

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

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


"If the offered sends an offer with only rids, the answerer should create one encoding parameter per rid (I think that was the final proposal we choose for accepting simulcast offers). Then, in each encoding parameter the answerer will be able to choose the simulcast mode (even an "S" mode as shown before)"

[BA] If the intent of the Offerer is to use "S" mode, why would it need to send an offer with RIDs if there is only one encoding parameter? Since the bitstream and RTP header extensions should make it clear what is being sent the RID is unnecessary.

"Not saying that it would be useful for anyone, just that it will be a possible and valid configuration."


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


"Yes, just saying that for VP9, it was easier to just look at the up/down switch bits without having to deal with the scalability structure in deep. I have not thought in deep about the pros/cons of the S-modes vs rid for simulcast, I feel that they will solve some issues and make other harder, not sure what I would prefer to use yet."


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