Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permanence issues #30

Open
jan-ivar opened this issue Aug 8, 2019 · 1 comment

Comments

@jan-ivar
Copy link

commented Aug 8, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Sep 15, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.