Permanence issues

[jan-ivar]

The spec so far seems to derive appeal and simplicity from thinking of a contentHint as an inherent property of the track. A "music" track; a "motion" video; invariant and ever-present.

But it's not. In three respects:

1. A contentHint is 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.
2. Unlike the data it purports to describe, a contentHint doesn't survive replication through sink->source pipes like a peer connection, element.captureStream(), web audio, MediaRecorder, or even track.clone(). Or does somehow it? The spec doesn't specify.
3. The hint may be wrong. User agents may (someday) detect speech vs. music at run-time. Are they allowed to ignore the contentHint outright? 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.

[alvestrand]

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.