search

w3c / ortc

ORTC Community Group specification repository (see W3C WebRTC for official standards track)
http://www.w3.org/community/ortc/
122 stars 42 forks source link

SVC: encodingId attribute overloaded #860

Closed aboba closed 6 years ago

aboba commented 6 years ago

In the definition of encodingId, it is implied that a single attribute is used to denote SVC and simulcast layering:

"encodingId of type DOMString An identifier for the encoding object. This identifier should be unique within the scope of the localized sequence of RTCRtpCodingParameters for any given RTCRtpParameters object. Values MUST be composed only of alphanumeric characters (a-z, A-Z, 0-9) up to a maximum of 16 characters. An RTCRtpSender places the value of encodingId into the RID header extension [RID], and an RTCRtpReceiver determines the encodingId that an RTP packet belongs to based on the value of the RID header extension. For a codec (such as VP8) using SRST transport which requires a compliant decoder to be able to decode anything that an encoder can send, it is not required that the encodingId and dependencyEncodingIds be set in order to enable a receiver to decode scalable video coding, and if set, they are ignored by the receiver."

However, this does not appear to be correct, because it would imply that SVC layers utilizing the same SSRC would contain different rid header extensions, and that rid header extensions would be included in the RTP packets of SVC streams even when simulcast is not used (e.g. temporal and spatial scalability only). This does not make sense.

Proposed fix is to add a "rid" attribute to RTCRtpEncodingParameters with the same meaning as the "rid" attribute in WebRTC 1.0. This attribute would only be set when simulcast encoding is desired, and when SRST SVC encoding is used, all SVC layers of the same simulcast stream MUST contain the same "rid" attribute value.

If simulcast encoding is not needed, then the "rid" attribute would be unset.

ibc commented 6 years ago

Can different temporal or spatial layers of a SVC stream be carried over different SSRCs?

aboba commented 6 years ago

@ibc Yes, but only in an RTP encapsulation that supports MRST. So far, this has only been implemented with H.264/SVC by Skype/Teams/Edge (which support temporal scalability only). VP8, VP9, AV1 and most other implementations of H.264/SVC always use the same SSRC for all SVC layers. So probably best to assume that we can avoid the MRST case in WebRTC/ORTC.

ibc commented 6 years ago

Yes, please, let's assume SRST :)

aboba commented 6 years ago

@robin-raymond Another reason to avoid overloading encodingId and rid is so that the application can avoid sending a RID header extension if the SFU doesn't support it (which most SFUs do not, today). For example, if a sender is sending temporal/spatial SVC without simulcast, there is no reason to include a RID header extension. If encodingId were not overloaded, then a rid attribute could be omitted and the RID header extension would not be sent. Whereas today, I believe that the ORTC specification mandates that the RID header extension be sent if SVC is sent, even if simulcast is not used. That seems wrong.

robin-raymond commented 6 years ago

@aboba agreed. Good idea to keep the values independent so the meaning is clear and allow for the flexibility needed.