Sections 9.4 & 9.8: Quality-related parameters

[aboba]

There is a question of whether we are expecting ORTC API implementations to support Quality scalability. If not, should we remove maxQualityLayers in RTCRtpCodecCapabilities (Section 9.4) and qualityScale in RTCRtpEncodingParameters (Section 9.8)?

[aboba]

Proposed resolution is to remove maxQualityLayers and qualityScale.

[pthatcherg]

Can't implementations that don't support it set maxQualityLayers = 0? That way, the JS knows if it's supported or not, and if an implementation does support it, it can do so in a standard way. I'd propose we leave it.

[aboba]

Justin asked if we could remove it at the last ORTC CG meeting, but it is ok to leave it in.

On Jul 18, 2014, at 12:02 PM, pthatcherg <notifications@github.commailto:notifications@github.com> wrote:

Can't implementations that don't support it set maxQualityLayers = 0? That way, the JS knows if it's supported or not, and if an implementation does support it, it can do so in a standard way. I'd propose we leave it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/109#issuecomment-49467663.

[aboba]

Oh, right. Thanks for jogging my memory. I'm fine leaving it out as well,
especially if we've already removed it. It would be easy to add back in if
someone is actually going to implement it.

Either way, it's small potatoes.

On Fri, Jul 18, 2014 at 1:42 PM, Bernard Aboba Bernard.Aboba@microsoft.com
wrote:

Justin asked if we could remove it at the last ORTC CG meeting, but it
is ok to leave it in.

On Jul 18, 2014, at 12:02 PM, pthatcherg notifications@github.com wrote:

Can't implementations that don't support it set maxQualityLayers = 0?
That way, the JS knows if it's supported or not, and if an implementation
does support it, it can do so in a standard way. I'd propose we leave it.

—

Reply to this email directly or view it on GitHub
#109 (comment).