Repository navigation
Permanence issues #30
Description
Activity
It's a runtime knob because it can change at runtime (for instance when a tab cast switches from casting a spreadsheet to casting an Youtube video).
The effect of changing it at runtime should be to make things better for the new value of the hint (typically munge codec sharpness vs smoothness parameters).
track.clone() should inherit all properties by default, it makes sense to say explicitly that this is treated like other properties.The hint was defined because automatic detection is sometimes wrong. If it hadn't been needed, the asker wouldn't have asked for it.
The spec so far seems to derive appeal and simplicity from thinking of a
contentHintas an inherent property of the track. A"music"track; a"motion"video; invariant and ever-present.But it's not. In three respects:
contentHintis potentially a runtime knob. The JavaScript can modify it at any time, yet it's not specified anywhere what should happen then, or when observable effects may be expected, if any.contentHintdoesn't survive replication through sink->source pipes like a peer connection,element.captureStream(), web audio,MediaRecorder, or eventrack.clone(). Or does somehow it? The spec doesn't specify.contentHintoutright? If they ignore it, what happens to observable (testable) effects/settings?How should browsers behave if the JS twiddles the bit live over time?
How does it work with track.clone()? Can each clone have its own value?
Is JS expected to tack these hints back on like post-it notes that keep falling off?
In the end, I realize this may be up to individual specs using
contentHints, but I would expect guidance to be given in this spec to ensure consistency.