search

w3c / mst-content-hint

This is the specification for the content-hint attribute. This optional hint permits MediaStreamTrack consumers such as PeerConnection or MediaRecorder to encode or process track media with methods more appropriate to the type of content that is being consumed.
https://w3c.github.io/mst-content-hint/
Other
4 stars 14 forks source link

What is the value of degradationPreference over time? (replaceTrack, contentHint setter) #36

Open henbos opened 4 years ago

henbos commented 4 years ago

The spec says:

An RTCRtpSender transmitting a MediaStreamTrack for which a contentHint attribute has been set MUST use the following degradation preferences, unless an explicit degradationPreference attribute has been set in the sender's parameters: [...]

Use X unless otherwise specified sounds reasonable, but is not very well defined.

First of all, does using a particular "degradation preference" in this context mean that this is the value used internally, or does it mean that the following "degradation preference" is what will be exposed in the degradationPreference parameter?

Regarding degradationPreference: it is not nullable. So there is no way to tell the difference between "I don't care" and "I want X". getParameters() would presumably tell you the current degradationPreference that it defaulted to? If I do getParameters() followed by setParameters(), how would the implementation tell the difference between "X was set because it was what getParameters returned" and "X was set because that's the reason I called setParameters".

Second of all, the track is not a constant. If I initially send it with one track contentHint and then later send with another contentHint does the degradationPreference change accordingly? The language seems to imply this, but can we make it explicit?

For the sake of WPTs and implementations behaving the same, can we express these things on terms of an internal slot and explicitly say when it is updated and to what?

@Orphis @aboba

henbos commented 4 years ago

Another concern with not having internal slots and making this implicit is... what if you call getParameters(), then perform contentHint = 'foo'; and then setParameters(). Would this still be valid or would the degradationPreference implicitly have been changed between get and set, invalidating the params dictionary?

Orphis commented 4 years ago

degradationPreference is nullable, it has no default value.

It is just an override over the internal behaviour controlled by contentHint, so calling getParameters() will not return the internal value matching the sender's behaviour and the encodings parameters are then stable across get/setParameters() call, even if the contentHint is modified.

henbos commented 4 years ago

I see, we should clarify this