Ticket #1644 (new feature)

Opened 13 months ago

Last modified 2 days ago

Support "sliding window" DVR in HLS

Reported by: jeroen Owned by: jeroen
Priority: Normal Milestone: Backlog
Component: streaming Keywords:
Cc: sanil Forum thread:

Description (last modified by jeroen) (diff)

With HLS, live streams are implemented using a sliding window model. If this window is large (e.g. >5min), we could layer additional UX on top of the player to support seeking into this window and jumping back to the Live playhead.

  • Attached are screenshots from other DVR interfaces. Note that some of these don't work for us, since the interface presumes knowledge of the start + duration of a DVR stream.
  • Also attached are mockups of the timeslider playback state for different stream types.

In order to implement this correctly, we have to make updates to the providers, API and controlbar.

Providers

On a provider level, we should ensure that the correct onTime() and getDuration() events are fired:

  • For VOD, we do what we do today: duration is the media duration and onTime() is fired multiple times / second when playing.
  • For live (RTMP + HLS + HTML5 iOS/Safari), we set duration to -1 for live streams and fire a single onTime() event every time the PLAYING state is entered.
  • For DVR (only HLS in Flash), HLS, we:
    • Set duration to -(dvr seeking range), where the DVR seeking range is defined as the duration from the oldest fragment until N-2 (the live head). This because we shouldn't allow users to seek beyond the live head and trigger buffer underruns.
    • Set position to -(distance from live head)
    • Fire time ticks every fragment load (not multiple times/second), in both PLAYING and PAUSED state (not just PLAYING).

Note the difference between HLS Live and DVR is the window size. Live playlists that have > 60s data are DVR, others are live.

API

On an API level, we can support the different playback states as follows:

  • Idle (before playback starts): getDuration() returns 0 and no time ticks.
  • Ondemand: getDuration() > 0 and multiple time ticks / second on playing.
  • Live: getDuration() = -1 and only a single time tick on playing.
  • DVR: getDuration() < -60 and time ticks every fragment load on playing AND paused.

Note that components and scripts shouldn't have to listen to the onMeta() call to determine which stream type a playlistItem is. simply listening to the first onTime() tick will tell them enough.

Controlbar

A mockup of the controlbar for the 4 stream states is attached. The live and dvr states are new:

  • For live, we display the text with the same styling as elapsed/duration texts. Note a separate ticket (#1690) is available for this.
  • For dvr, we can re-use all existing skinning elements. Since timing is only updated every fragment load, it should feel like a slow version of the vod state. If the fragments are always the same length, nothing should move during playback and the thumb should jump backward every fragment load when pausing.

Attachments

dvr-screens.jpg Download (97.7 KB) - added by jeroen 5 days ago.
Stream states.png Download (22.0 KB) - added by jeroen 5 days ago.

Change History

comment:1 Changed 10 months ago by pablo

  • Type changed from enhancement to feature

comment:2 Changed 7 months ago by jeroen

  • Summary changed from Support "sliding window" DVR to Support "sliding window" DVR in HLS

comment:3 Changed 7 months ago by jeroen

  • Component changed from general to ads

comment:4 Changed 7 months ago by jeroen

  • Component changed from ads to streaming

Changed 5 days ago by jeroen

Changed 5 days ago by jeroen

comment:6 Changed 5 days ago by jeroen

  • Description modified (diff)

comment:7 Changed 4 days ago by jeroen

  • Description modified (diff)

comment:8 Changed 2 days ago by jeroen

  • Cc sanil added
  • Description modified (diff)
Note: See TracTickets for help on using tickets.