Closed aboba closed 5 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.
@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).
@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.
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.
Fix for Issue https://github.com/w3c/ortc/issues/860
Preview of this PR: https://rawgit.com/aboba/ortc/master/index.html