W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2015

Re: Add drop option for RTCQualityDegradationPreference (#370)

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Sun, 1 Nov 2015 19:06:01 +0000
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <B0779292-CA90-42C9-8C81-736270C37B09@microsoft.com>
On Nov 1, 2015, at 07:32, Mathieu Hofman <notifications@github.com<mailto:notifications@github.com>> wrote:

At the TPAC meeting last Friday, @martinthomson<https://github.com/martinthomson> suggested we add a drop option to the quality degradation preference for simulcast parameters.

[BA] The degradation preference relates to the tradeoff between framerate and resolution in response to congestion.  At TPAC there were questions about how this works for simulcast. If the preference is set consistently between simulcast streams, the requested framerateScale /resolutionScale ratios can be maintained under degradation. However, if simulcast streams are requested to degrade differently, then the requested ratios may not be attainable - this could result in an over-constraint. So I would question whether we fully understand how degradation preference works in simulcast.

An alternative is stop sending one or more simulcast streams. This could be controlled from the SFU (e.g. PAUSE/RESUME) or the browser.  Our experience that in simulcast/SVC this works better than attempting to degrade some or all streams.

IMHO an RtpSender should be allowed to stop sending simulcast streams at its discretion, even if active=true is set on the stream.  In that case, do we really need an explicit drop preference?

This would also require the encoding entries in the Plan X sendEncodings sequence (#353<https://github.com/w3c/webrtc-pc/pull/353>) to be ordered according to their priority. This actually makes sense since, from what I understand, the order in SDP is representative of the priority.

[BA] RTCPriorityType is orthogonal to the simulcast/SVC stream relationship, so we should be clear that one is not inferred from the other. However, I do agree that the ordering is meaningful.
Received on Sunday, 1 November 2015 19:06:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:10 UTC