search

video-dev / media-ui-extensions

Extending the HTMLVideoElement API to support advanced player user-interface features
MIT License
29 stars 8 forks source link

proposal: live edge. #7

Closed cjpillsbury closed 1 year ago

cjpillsbury commented 1 year ago

Live Edge Proposal

(closes #6)

gkatsev commented 1 year ago

If you rebase, feel free to delete the proposals/.gitkeep file.

cjpillsbury commented 1 year ago

@gkatsev

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.

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).

@heff @luwes thoughts/concerns/preferences here?

heff commented 1 year ago

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.

cjpillsbury commented 1 year ago

If it's just reordering the changes in the proposal, that seems appropriate to me.

👍 I don't see any concern here other than the fact that liveEdgeStart refers to the constrained seekable.end() definition, which isn't enough reason to push back on this ask imo.

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?

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.