Re: Some ideas on SVC support in WebRTC 1.0

Inaki said:


"Apologies in advance if this is specified somewhere else, but:


How is RID related to SVC at all? I mean, do RTP packets belonging to
different SVC temporal or spatial layers have a different value within the RID
(RtpStreamId [1]) RTP extension header?

[1] https://tools.ietf.org/html/draft-ietf-avtext-rid-09#section-3.1"

[BA] Good question. Looking at the ORTC specification (and the proposal I posted, which is derived from it) there seems to be an assumption that the same attribute (rid in WebRTC 1.0, encodingId in ORTC) is used to differentiate both simulcast and SVC layers.

In the ORTC specification which includes the encodingId attribute, the definition suggests that it is synonymous with rid:

encodingId of type DOMString

An identifier for the encoding object. This identifier should be unique within the scope of the localized sequence of RTCRtpCodingParameters<http://draft.ortc.org/#dom-rtcrtpcodingparameters> for any given RTCRtpParameters<http://draft.ortc.org/#dom-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<http://draft.ortc.org/#dom-rtcrtpsender> places the value of encodingId into the RID<http://draft.ortc.org/#dfn-rid> header extension [RID<http://draft.ortc.org/#bib-RID>], and an RTCRtpReceiver<http://draft.ortc.org/#dom-rtcrtpreceiver> determines the encodingId that an RTP packet belongs to based on the value of the RID<http://draft.ortc.org/#dfn-rid> header extension. For a codec (such as VP8) using SRST<http://draft.ortc.org/#dfn-srst> transport which requires a compliant decoder to be able to decode anything that an encoder can send, it is not required that the encodingIdand dependencyEncodingIds be set in order to enable a receiver to decode scalable video coding, and if set, they are ignored by the receiver.

However, if SVC layers are always sent with the same SSRC/rid (which is how SVC works with VP8, VP9 and AV1), then the rid *cannot* be used as a layer identifier. So ORTC appears to be in error here.

I will post a revised proposal addressing this. Let me know if that looks more correct.

________________________________
From: Iñaki Baz Castillo <ibc@aliax.net>
Sent: Tuesday, July 3, 2018 3:49:27 PM
To: Bernard Aboba
Cc: WebRTC WG
Subject: Re: Some ideas on SVC support in WebRTC 1.0

On Tue, 3 Jul 2018 at 20:21, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:

dependencyEncodingIds of type sequence<DOMString>

The rid<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdraft.ortc.org%2F%23dom-rtcrtpcodingparameters-encodingid&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C93f8fd92b0124dad437108d5e1374332%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662549837146256&sdata=qFGPoWOm9iCs8jUqna4c7pVKS6ywhjmHIxXJBpyTs4I%3D&reserved=0>s on which this layer depends. In order to enable encoding of scalable video coding (SVC<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdraft.ortc.org%2F%23dfn-svc&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C93f8fd92b0124dad437108d5e1374332%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662549837146256&sdata=r70pXdFoJLJj7nByS77Q7zbCwi2O06cX9x%2BbDPw0rzs%3D&reserved=0>) bitstreams, both the rid and dependencyEncodingIds are required.

Apologies in advance if this is specified somewhere else, but:

How is RID related to SVC at all? I mean, do RTP packets belonging to different SVC
temporal or spatial layers have a different value within the RID (RtpStreamId [1])
RTP extension header?

[1] https://tools.ietf.org/html/draft-ietf-avtext-rid-09#section-3.1<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-avtext-rid-09%23section-3.1&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C93f8fd92b0124dad437108d5e1374332%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662549837156264&sdata=582sudhxjYyZ0sADGo8DkYaCxLEAtrbdqy2HAGY2WC8%3D&reserved=0>


--
Iñaki Baz Castillo
<ibc@aliax.net<mailto:ibc@aliax.net>>