Re: Some ideas on SVC support in WebRTC 1.0

On Wed, 4 Jul 2018 at 01:07, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
>
> 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 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 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.

Sure, I'll do.

BTW, IMHO RID should not be used to identify SVC layers and/or
relationship between
them. RID means RtpStreamId, which is basically a way to identify
media streams by
looking first at its RID header extension value (so the SSRC can
change at any time
due to SSRC conflits and bla-bla-bla that never happen).

AFAIK SVC layers are carried by a single stream (single SSRC) so RTP
packets of any
SVC layer must also have the same RID value (if used).

I wouldn't reuse the `rid` or `encodingId` (in ORTC) setting for SVC
stuff. In the
"Example of 2-layer spatial simulcast combined with 2-layer temporal
scalability"
example in your first email, there are 4 rid values (L0, E0, L1, E1).
One may assume
that there will be 4 RtpStreamId values in the wire, but it's not true. In fact,
I assume there would be just two (L0 and E0), but this is terribly
confusing IMHO.

I wouldn't signal SVC layers as separate entries within
`RTCRtpParameters.encodings`.
Instead, I'd propose that entries in `RTCRtpParameters.encodings` represent a
separate stream (so different SSRC and rid/encodingId, period).

And, I would add new fields within RTCRtpEncodingParameters that define the SVC
layers within *that* stream. Something like:

var encodings = [
  {
    rid: "L0",
    temporalLayers: [
      {
        scaleFramerateDownBy: 2.0
      },
      {
        scaleFramerateDownBy: 1.0
      }
    ],
    spatialLayers: [
      {
        scaleResolutionDownBy: 4.0
      },
      {
        scaleResolutionDownBy: 2.0
      },
      {
        scaleResolutionDownBy: 1.0
      }
    ]
  }
];

Obviously, each entry withon temporalLayers and spatialLayers depends
on the previous
ones. If, instead, more complex use cases are required (such as more
complex layers
relationships), an `id` and `dependencyIds` fields should be needed.

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

Received on Tuesday, 3 July 2018 23:28:02 UTC