W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2019

[webrtc-pc] Simulcast alternative layers do not have an API surface. (#2061)

From: Amit Hilbuch via GitHub <sysbot+gh@w3.org>
Date: Wed, 16 Jan 2019 18:33:40 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-399940758-1547663619-sysbot+gh@w3.org>
amithilbuch has just created a new issue for https://github.com/w3c/webrtc-pc:

== Simulcast alternative layers do not have an API surface. ==
[Creating a separate issue for this, even though it is somewhat discussed in #2035 .]
Simulcast spec discusses the ability to specify alternatives for a simulcast layer.
a=simulcast: send 1,2;3,4;5
should be interpreted as:
"I want to send 3 layers:
layer1 will contain **only one** of the streams described by RIDs 1 and 2
layer2 will contain **only one** of the streams described by RIDS 3 and 4
layer3 will contain the stream described by RID 5"

To summarize, each layer may specify alternatives for the media that will be sent.

There is currently no API surface for the user to specify alternatives for the various layers. The user specifies the layers in the `send_encodings` either when calling `addTransceiver()` or using `setParameters()`.

Since the description of the layers is not very clear from the negotiated SDP (see #2053 and #2054) there might not be a lot of value in specifying alternatives. 
Based on the examples in the spec, the alternatives may indicate:
1. Different codecs
2. Different sampling methods for creating the layers (temporal vs spatial)

However, in both cases, there would be dependencies (or 'sets') of alternatives that work well together. It won't make sense to use spatial sampling for one layer and temporal for another, or it won't make sense to use a different codec for only one of the layers.

My suggestion would be not to use layer alternatives in WebRTC.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2061 using your GitHub account
Received on Wednesday, 16 January 2019 18:33:46 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:46 UTC