Re: Add drop option for RTCQualityDegradationPreference (#370)

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.