Add additional state values for seekable start/end #218
Replies: 4 comments 11 replies
-
From the bottoms up technology perspective this makes sense to me. I'm still a little unclear what the specific user experiences we're trying to unlock are. Is there any more we can do to visualize those?
Doesn't the video element just convert the timeline to start at zero? When do you actually see an on-demand timeline that doesn't?
I'm not fully understanding what the UI result of this is. Is it a progress bar that you can only click on part of?
I'm assuming this can have multiple ranges, like buffered. How might the UI be impacted by multiple ranges, and does it matter enough to handle that?
This sounds like a pretty important UX detail to consider in the design. Is there prior art here denying a user from clicking on part of the progress bar? |
Beta Was this translation helpful? Give feedback.
-
Are |
Beta Was this translation helpful? Give feedback.
-
Addendum re: start time Looks like it's contingent on browser implementation details. (which still means we cannot assume it would be normalized to start time of 0). |
Beta Was this translation helpful? Give feedback.
-
Makes sense to me. I can concur, See https://github.com/videojs/mux.js/#keeporiginaltimestamps. This was used for live playback for another player I worked on so we could see how long the live stream had been going on for. There's also https://developer.mozilla.org/en-US/docs/Web/API/SourceBuffer/timestampOffset which Media Chrome wouldn't have control over.
Would these values essentially be what the |
Beta Was this translation helpful? Give feedback.
-
For a variety of use cases and media content, the seekable start and end of media content is both relevant and distinct from e.g. the media's (expected or actual) duration.
Current impl/status quo:
media.currentTime = 0
and that is assumed to both be a seekable time and to be the start time of the media).media.duration
is assumed to be a finite value and that it is identical to the seekable end of the mediaWhere these assumptions break down:
media.duration
will beInfinity
butseekable.end(0)
will represent the latest seekable value in the media timeline (andseekable.start(0)
will represent the earliest seekable value in the media timeline).Proposal:
media-seekable-end
andmedia-seekable-start
<media-time-range/>
(and<media-time-display/>
?), wheremedia-seekable-start
is provided, use it as the min value for<media-time-range/>
media-seekable-start
is provided, still assume the start time is 0 by defaultmedia-seekable-end
is provided, assumemedia-seekable-end === media-duration
media-duration
isInfinity
, treatmedia-seekable-end
as the max value for<media-time-range/>
.media-duration
andmedia-seekable-end
are finite numbers, update<media-time-range/>
to visually represent the total duration but disallow seeking past themedia-seekable-end
.Beta Was this translation helpful? Give feedback.
All reactions