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.
-
The first thing that comes to mind is Flash 😆. The second is with ad-supported media, where you can't necessarily seek forward past sections with ads. |
Beta Was this translation helpful? Give feedback.
-
Might be easier to think about it as a single seekable range (in practice it's generally a single range) but in the code we'd probably want to make sure we use the last seekable that's available for the true seekable-end. |
Beta Was this translation helpful? Give feedback.
-
No. Unfortunately the media timelines are based on whatever is defined within the supported container. I've locally generated a valid mp4 by concatenating an init segment + additional segments, but omitted the first couple of segments and loaded that as a
Yes, the idea is a region of the progress bar would not be seekable (See designs/conversation provided out of band for an example of this.)
Theoretically, yes, though I believe we can assume 0-1 one TimeRange currently, as that will be most common for MSE + native playback use cases. If we wanted a slightly safer assumption, we could use
Also see designs/conversation provided out of band for an example of this, though it's broadly consistent with other prior art (can try to find additional examples "in the wild" if this is a blocker for the conversation). |
Beta Was this translation helpful? Give feedback.
-
|
The additional context was helpful, thanks. In general this feels safe since it's a relatively standardized concept, and how we use seekable in time-range doesn't have to be set in stone. I also feel pretty safe exposing a single range, whether that's the first or a combined range. I mostly can't see that the added complexity of multiple ranges has enough value to justify it. I still have questions about the right user experience around these concepts, but I think that's a higher level concern. 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Are |
Beta Was this translation helpful? Give feedback.
-
I think for this iteration/incarnation at least, yes, and it would be the responsibility of the custom element implementor (e.g. |
Beta Was this translation helpful? Give feedback.
-
|
@gkatsev Are you concerned about the browser native silliness w/HLS live + Chrome for Android so we could have a workable Media Chrome solution for that without requiring a custom element? If yes, I I'd lean toward treating that as a separate proposal, though I am amenable to including it if that's your worry and you feel otherwise. |
Beta Was this translation helpful? Give feedback.
-
|
Basically, was wondering where this behavior should be handled, like if you have a live stream and the media element says that the duration is Infinity but then media-controller is saying that the media duration is 300. And it sounds like you're saying that it should be pushed into the media slotted element that should be reconciling these values. |
Beta Was this translation helpful? Give feedback.
-
|
that was at least my thought, but I def can see value in supporting it at the Media Chrome level, esp since it starts bleeding into the "this is about a visual representation/UI" thing, saying something like:
With that mental model, I can def see an argument for it being "baked in" to Media Chrome. Since we have a workable solution for Mux Player without including that, I'd still lean towards treating that as a separate proposal just to avoid "muddying the waters" and including additional details that would need some level of consensus. What do you think, @gkatsev? |
Beta Was this translation helpful? Give feedback.
-
|
yeah, I think we can ignore that as a separate proposal. I think I was overthinking things a bit and thought that we wanted the "implementors will be able to stipulate an "anticipated" duration of the media" as part of this settable via the media-controller props, but after coming back to it, I realize that isn't part of your current proposal |
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.
-
Yeah, you're exactly right. I agree, consistency would be better, though we may want greater precision than seconds for seekable since it isn't merely cosmetic. Sold. |
Beta Was this translation helpful? Give feedback.
-
|
oooh I misread your colon syntax (looking at code now). Even more sold. |
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 = 0and that is assumed to both be a seekable time and to be the start time of the media).media.durationis assumed to be a finite value and that it is identical to the seekable end of the mediaWhere these assumptions break down:
media.durationwill beInfinitybutseekable.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-endandmedia-seekable-start<media-time-range/>(and<media-time-display/>?), wheremedia-seekable-startis provided, use it as the min value for<media-time-range/>media-seekable-startis provided, still assume the start time is 0 by defaultmedia-seekable-endis provided, assumemedia-seekable-end === media-durationmedia-durationisInfinity, treatmedia-seekable-endas the max value for<media-time-range/>.media-durationandmedia-seekable-endare 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