proposal: live edge. #7
Conversation
|
If you rebase, feel free to delete the |
cjpillsbury
force-pushed
the
proposal/live-edge
branch
from
ef7832f to
841cea4
Compare
There was a problem hiding this comment.
I understand why this tries to clarify that seekable.end() means the "live sync point" in hls.js terminology, but it still feels a bit out of place here. It's like, we're on a road to the live edge, but there's an unexpected detour. I think it feels extra weird to me because my reading of seekable.end() is already this.
proposals/0007-live-edge.md
Outdated
| ## Definitions | ||
|
|
||
| - __Advertised Live Edge__ - This is the latest available media time as represented in a manifest, playlist, or simiilar. This will not be exposed by any API defined in this proposal, but is defined here for reference in the recommended computations for Seekable Live Edge. | ||
| - __Seekable Live Edge__ - This is the latest available media time a player should attempt to seek to or play, typically some offset from the Advertised Live Edge, determined in part by things like the `HOLD-BACK` or the `suggestedPresentationDelay`. |
There was a problem hiding this comment.
should this mention that this is reflected via video.seekable.end(video.seekable.length-1)?
There was a problem hiding this comment.
Added to the "Live Edge Window" and "Live Seekable Window" definitions, but I'll add here as well.
While many native/MSE-based players/playback engines do implement this, it is not explicitly defined anywhere (hence the hls.js deviation, though there may be others that we don't yet know of). Because of that, and since this proposal explicitly depends on that constraint, I think this needs to be in a media-ui-extension proposal somewhere. I'm definitely amenable to it being broken out into a separate proposal/PR if folks would prefer that (though that means that proposal needs to be settled before this one is accepted). |
|
I'm not totally following the concern. Is it that defining seekable.end doesn't belong, or that it's a lot before getting to the actual new API being proposed? If it's just reordering the changes in the proposal, that seems appropriate to me. Is an option to reframe the seekable.end definition as assumed-to-be-true, but then call out the actual and potential deviations from it? It seems clear that we can't ignore the seekable.end detail in this proposal all together. I feel fine leaving it in. If we think we're going to be pushing the seekable.end defintion on its own to various groups, it could be worth its own extension, when that happens. |
👍 I don't see any concern here other than the fact that
I'd rather keep the definition as is, since it currently defines the constraint based on what it is expected to be and not based on an ad hoc list of deviations from that expectation. |
…s referencing ref definitions.
Live Edge Proposal
(closes #6)