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

Hi Bernard,

I guess that the answers are very codec specific, I will answer from VP9 
and AV1 point of view, but they may be different for other codecs  (h265?)

On 22/07/2019 19:15, Bernard Aboba wrote:
> In early drafts of the WebRTC-SVC Extension, "S" modes were included 
> in the mode table but those modes were subsequentliy removed, under 
> the assumption that each simulcast stream would be sent on a separate 
> SSRC.
>
> Recently the Issue has come up again, as part of the design of the AV1 
> RTP payload, since the AV1 bitstream specification supports simulcast:
> https://github.com/AOMediaCodec/av1-rtp-spec/issues/51
>
> Specifically, the following WebRTC-related questions have been asked:
>
>  1. What are the implications of enabling "S" modes for the WebRTC
>     API? For example, would adding "S" modes back violate the
>     requirement that setParameters() never set "negotiationneeded"?
>
VP9 send the scalability structure in rtp payload and AV1 rtp draft 
proposes to send the dependency descriptor as an rtp payload header. So 
in both cases it should be possible to change the SVC mode on the fly 
(even from no "S" mode to "S" modes and vice versa)


>  1. Would enabling "S" modes result in SDP changes?  For example,
>     would an Offer with "S" modes be different from one where
>     simulcast is sent on separate SSRCs, but the SSRCs are not
>     signaled in the SDP? If so, how?
>
A simulcast using different ssrcs would have one encoding parameter for 
each simulcast layer with a different rid each one, while the "S" modes 
will have a single encoding. So the differences in the SDP are not due 
to the "S" mode but due to the different number od encoding parameters.


Note that it would be possible to enable the crazy scenario of having 
multiple simulcast encodings each one using "S" mode, which will porduce 
multiple ssrcs/rids, and each one contain multiple independent spatial 
layers within.


>  1.  In an SDP Simulcast Offer where only RIDs are present and not
>     SSRCs, how does the Answerer know whether the intent is to send
>     simulcast on separate SSRCs or not?
>
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)


>  1. For a conference server that supports RIDs,  how much difference
>     does it make whether simulcast is sent on multiple SSRCs or a
>     single one?  For example, RIDs would be present in each packet,
>     but instead of RTCP messages for each SSRC, there would only be a
>     single SSRC.
>

For VP9 the change is quite substantial IMHO, with no "S" modes, the up 
switch/down switch can be done just by checking a couple of bits of the 
rtp payload descriptor headers, while in "S" mode that to do it properly 
an SFU will have to properly parse the scalability structure, determine 
the layer dependencies and do the switching based on the received frames 
and the frame dependency. Iñaki has implemented VP9 K-SVC support that 
was added in latest chrome versions (I am still using 73 for production) 
so he might be able able to provide more info regarding this (although 
not sure if he parses the SS or if he detects the K-SVC mode based 
screencast/camera flag).


In AV1, the dependency structure is provided in the rtp header 
extension, so will be much easier to implement. Anyway, as the SFU will 
be able to choose the SVC mode, each one of us will implement the one 
that fits bets for us.


Would be very interesting to understand the benefits found by google 
team that made them allow the K-SVC modes in some cases over non "S" 
modes in VP9.


Best regards

Sergio