Mux Player features not (directly) in Media Chrome (but could be!)

[cjpillsbury]

(currently omitting themes and themes-related discussion such as breakpoints/player-size, automatic/well-defined export parts, well defined css vars with well defined semantics for component display, etc. Also currently omitting planned but currently unsupported features such as state management for timed metadata, multiple subtitles/CC, and rendition selection. For either of these, we can can add them to the list if centralization helps)

State Modeling and Functionality

Stream Type

• Definition/"Meaning" - Currently defines several things that could be broken up: live vs. on demand, "dvr" vs not, and low latency vs. "standard latency"
• Mux Player/Open Element Purposes
  • (currently) defines optimized playback-engine config before loading media content
  • defines chrome permutations for the default Mux Player theme
  • overrides standard mediaplayrequest behavior to also seek to live for live content (See also: §Seek To Live, below)

Is Live Edge

• Definition/"Meaning" - A boolean that is true if the playhead is within a computed range of values that define the live edge of live/DVR content
  • Implementation of computation fn
  • Recalculation conditions
• Mux Player/Open Element Purposes
  • Changes the visualization for Mux Player's custom live indicator/button
  • Disables the "play + seek to live" behavior of the custom live indicator/button

Seek To Live

• Definition/"Meaning" - A method that will seek to the live edge of any live/DVR media content.
  • Implementation of fn
• Mux Player/Open Elements Purposes
  • Used by Mux Player's custom live indicator/button to seek to live if not play live edge
  • (Hacky workaround) used when media-play-button dispatches a mediaplayrequest to also seek to live for any live/DVR media content

Errors

• Definition/"Meaning" - A state+event representing the latest error from Mux Player, including custom, Mux-Specific errors
• Mux Player/Open Elements Purposes
  • Conditions to show error dialog to users
  • Determines content shown in error dialog (NOTE: props.dialog object and values is derived from errors)
  • Provides custom error info for Mux Data

Shift Subtitle/CC Cues When Controls Are Showing

• Definition/"Meaning" - Tracks when controls are showing (assumed base on user-inactive and paused)
• Mux Player/Open Elements Purposes
  • Shifts cues up/down based on a (currently brittle position-wise) assumed height of the bottom controls when they are showing

Components & Related Architecture

(Error) Dialog

• Implementation
• Usage
• State/Architecture - Open/Closed State Disables UI (Search for all uses of isDialogOpen)

Live Indicator/Button

• Implementation (N/A, inline button in template)
• Usage (Also see corresponding attribute-driven CSS)
• State/Architecture - Various from above used (Seek To Live, Is Live Edge, Stream Type)

[heff]

Super helpful! 🎉

Finishing up Stream Type here (just the live vs. on-demand part of it).

(currently) defines optimized playback-engine config before loading media content

This feels pretty out of scope of media chrome. The implication of that is a player that wants to configure the media element differently based on stream type or latency desired will need to get that state another way. In Mux Player it looks like we're just using it to configure latency (aside from the other bullet points). Are there any UI impacts when low latency is desired?

overrides standard mediaplayrequest behavior to also seek to live for live content

It looks like in Mux player we only do this for the play-button. Is there any reason this shouldn't also happen on a media element click gesture? i.e. is this a global setting or a play button setting. I'm assuming the former and maybe both.

[gkatsev]

It looks like in Mux player we only do this for the play-button. Is there any reason this shouldn't also happen on a media element click gesture? i.e. is this a global setting or a play button setting. I'm assuming the former and maybe both.

That's an oversight we didn't get a chance to address yet.

[cjpillsbury]

That's an oversight we didn't get a chance to address yet.

It's actually because the theme doesn't "know about" seekToLive(). We can do this with the live indicator/button bc it's slotted.

[cjpillsbury]

This feels pretty out of scope of media chrome. The implication of that is a player that wants to configure the media element differently based on stream type or latency desired will need to get that state another way. In Mux Player it looks like we're just using it to configure latency (aside from the other bullet points).

I agree. Calling it out just because it needs to be resolved for a migration.

Are there any UI impacts when low latency is desired?

Hypothetically, yes? Currently, no. And it would likely just be "on the margins"/for pretty bespoke customization cases, imo, so I don't think we should plan on solving it architecturally in Media Chrome (or Media UI Extensions) unless it comes up.

[cjpillsbury]

Stream Type

Relates to Stream Type - Proposal
Relates to DVR State - Proposal

[cjpillsbury]

Seek To Live

Relates to #382

NOTE: Relies on assumption that a slotted media element's seekable will represent the seekable range for live, taking into account things like the implicit or explicit HOLDBACK or PART-HOLDBACK defined in the HLS spec.

[cjpillsbury]

Is Live Edge

Relates to #382

NOTE: This implementation uses a hard-coded offset value for computing the "live edge window" expediency. A more reliable/accurate implementation would require a Media UI Extension that allowed the slotted media element to advertise what that value should be, based on details of the manifest or playlists in question (e.g. low latency vs. "standard" live, segment durations, etc.)

[cjpillsbury]

Live Indicator/Button

Relates to #382

NOTE: Since the indicator relies on "Is Live Edge" to toggle the live edge indication and enable/disable button functionality, see "Is Live Edge" callout above on its current, simplified implementation.