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: fix for encodingId and addition of rid attribute #861

Closed aboba closed 5 years ago

aboba commented 6 years ago

Fix for Issue https://github.com/w3c/ortc/issues/860

Preview of this PR: https://rawgit.com/aboba/ortc/master/index.html

ibc commented 6 years ago

I don't understand this PR. It still uses a separate entry in encodings for each SVC layer. I strongly dislike this approach since it requires that all the encodings with same rid have also the same ssrc (if any), codecPayloadType (if any) and so on.

I expected that this PR was gonna include, instead, the spatialLayers and temporalLayers fields instead.

robin-raymond commented 6 years ago

@ibc reason spatialLayers and temporalLayers isn't good enough. You lose ability to describe interleaving and how you want to protect layers (e.g. just protect base with RTX or FEC).

aboba commented 6 years ago

@ibc We will see how the WebRTC 1.0 debate on SVC turns out (we will probably discuss this issue in a future WEBRTC WG virtual interim after IETF 102). Today the RID header extension is defined only for use with simulcast - it's not clear to me that it makes sense to include a RID header extension when sending an SVC stream (temporal, spatial or temporal + spatial).

In theory, ORTC can be used to support MRST today (by using a distinct SSRC for each encoding). But that does not make sense for VP8, VP9 or AV1 or even for most implementations of H.264/SVC. So while it can be done, I would expect that most implementations will not support it.

ibc commented 6 years ago

it's not clear to me that it makes sense to include a RID header extension when sending an SVC stream (temporal, spatial or temporal + spatial).

I thought it was already clear that RID MUST not be used for each SVC layer, but just for each simulcast stream (regardless a simulcast stream uses SVC). That' why we moved from encodingId to rid + encodingId, which IMHO makes 100% sense.

Regarding the original issue (how to specify SVC layers) what I don't want at all is having RTCRtpEncodingParameters for defining both, streams and SVC layers. IMHO, we should assume SRST so SVC is a property of a specific stream. This is, SVC layers should be defined within a single encoding.