- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Mon, 22 Jul 2019 22:38:12 +0200
- To: public-webrtc@w3.org
- Message-ID: <f1b2be0d-4c1d-879f-a69d-7ad52e235333@gmail.com>
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
Received on Monday, 22 July 2019 20:38:33 UTC