Live Edge Window about media-ui-extensions

[gkatsev]

seekable.end(0)

seekable.end(seekable.length-1), right? Not sure if it's actually possible for seeking but it definitely matters for buffered.

Yes, it should be seekable.end(seekable.length-1), though, in practice they're going to be equivalent in most implementations for live streams.

[cjpillsbury]

seekable.end(seekable.length-1)

@heff - Per @gkatsev's callout, I believe this will always be identical to seekable.end(0) in browser implementations, but you're right, we might as well avoid unnecessary presumptions here and always refer to it as seekable.end(seekable.length-1)

[heff]

A couple of additional thoughts:

• If these are on the advanced side of settings, I don't hate being a degree more verbose. targetLiveSeekableWindow is pretty darn clear(er).
• "window" can also just be treated as synonymous with "duration", rather than requiring "offset" after it. It feels pretty intuitive/obvious that the live seekable and live edge windows end at "live". Or we can just use "duration".

With that I like targetLiveSeekableDuration. Also open to Window.

For the live edge, would it be better to do liveEdgeStart? Feels like the most common operation is going to be:

if (currenTime > seekableEnd - liveEdgeWindowOffset) {
  // show red light
}

When it could just be:

if (currenTime > liveEdgeStart) {
  // show red light
}

With that we could lean on progress or durationchange events for updates. Or just timeupdate would even be fine.

[heff]

This is a great writeup. 👍 Love the additions to HLS/DASH to support this cleanly. I don't understand all the implications of those specifically, but I'm sure others can weigh in.

Since this is the media-ui-extensions I think it's worth laying out the UI problems that are being solve more. It's gonna be hard for others to really evaluate the API without that clear context. As a summary pass:

• Indicator (red light) that informs the user when they're watching "live"
• Button that can seek into the live edge window
  • Logic that can inform when the button works, is disabled, is shown
• Anything else?

seekable.end(0)

seekable.end(seekable.length-1), right? Not sure if it's actually possible for seeking but it definitely matters for buffered.

liveWindowOffset

Definition and name feel good to me. 👍

The most accurate/verbose name might be liveEdgeWindowOffset, right? In order to avoid confusion with anything else that might be considered a "live window". I feel like we should never refer to the DVR window specifically as "live". It's intentionally "(R)ecorded", not live, once you get behind the live edge. i.e. "Live + DVR" feels more accurate than "Live DVR".

Is this repurposing of the event acceptable?

If we can't point to any real reasons why this number might change otherwise, it feels good to try to bundle it as a starting point at least. Either that or we just say that every new state gets its own change event, and be done with it. I could go either way. The latter would remove friction in any specific independent proposal.

[cjpillsbury]

I feel like we should never refer to the DVR window specifically as "live". It's intentionally "(R)ecorded", not live, once you get behind the live edge. i.e. "Live + DVR" feels more accurate than "Live DVR".

Not sure what you mean here. Per your suggested name here #4 (comment), our current mostly settled proposal on modeling DVR will rely on a property called targetLiveWindow. Is this you changing your mind? Am I misunderstanding something here?

[heff]

Is this you changing your mind? Am I misunderstanding something here?

No, you're right to be confused. :) From this context targetLiveWindow now sounds more misinterpretable. We're at least clearly using 'liveWindow' to mean two different things between the proposals now, and that's not great. I don't think we have to go change targetLiveWindow, but if we don't I'd lean towards something like liveEdgeOffset here instead. An alt for targetLiveWindow otherwise might be targetSeekableWindow. Open to either path, we should just avoid the double meaning.

[cjpillsbury]

we should just avoid the double meaning.

Agree 💯. I'm going back and forth on your rename proposals. As each hints at, the problem is both scenarios are about "windows" and both are related to live. One is the "live seekable window;" the other is the "live edge window." They're also both offsets. Since Names Are Hard™️, I'm leaning towards liveEdgeOffset. It unfortunately looses some context by dropping "window" that may introduce some ambiguity/confusion, but I think that'll be true for any renaming.

[luwes]

I might be missing something but why not just HTMLMediaElement.getLiveSeekableRange() ?

that covers both #4 and #6 in one familiar API.
it also a bit similar to how HTMLMediaElement and MediaSource both have duration

I def also am on board with that the naming should be close to that LiveSeekable naming

[cjpillsbury]

I might be missing something but why not just HTMLMediaElement.getLiveSeekableRange() ?

@luwes responded in the PR to keep the conversation there, both in comments and by updating the proposal to hopefully add some clarity. The short version:

There are actually two distinct "live windows" we're modeling in #4 vs. here.

1. The "Seekable Live Window," which is the range of presentation times a player may "seek to", either programmatically or via a UI. (this is primarily captured in #4)
2. The "Live Edge Window," which is the range of presentation times that should be treated as counting as "the live edge," effectively a "fudge factor" to account for the segmented, pull-based nature of HAS standards. (this is primarily captured in the proposal here and its corresponding proposal PR)

[luwes]

okay I thought somehow that this is true

start livestream time -> liveSeekableStart -> liveSeekableEnd -> real seekable.end(seekable.length-1)

and the proposed liveEdgeOffset = seekable.end(seekable.length-1) - liveSeekableEnd

is this not the case?

[cjpillsbury]

@luwes No that's not quite right. Check out the diagram I added here https://github.com/video-dev/media-ui-extensions/pull/7/files?short_path=6415912#diff-6415912cbdb551127eb5975514c274cb87904befd9ca77ec25808f682ab492d7 ("Diagram with HLS reference values for context") and let me know if that clears things up. Also, if you could, let's move the conversation to the PR to try to follow Gary's process.

[cjpillsbury]

Closing this Issue per our discussed process to avoid multi-channel conversations. Can re-open if corresponding proposal PR is rejected.