Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reduce HLS startup latency #1558

Closed
joeyparrish opened this issue Aug 23, 2018 · 1 comment
Closed

Reduce HLS startup latency #1558

joeyparrish opened this issue Aug 23, 2018 · 1 comment
Assignees
@michellezhuogg
Labels
component: HLS The issue involves Apple's HLS manifest format status: archived Archived and locked; will not be updated type: enhancement New feature or request
Milestone
v3.0

Comments

@joeyparrish
Copy link
Member

Currently (v2.4) we try to determine the start time of the first segment in each playlist. This is time-consuming and adds latency to startup. There are some details in the HLS spec which we may be able to exploit to reduce this significantly.

This could also allow us to skip timestamp parsing in text cues, which contain no timestamps if empty, or in raw AAC or MP3, which may not have parseable timestamps at all.

For VOD, we may assume that all playlists are aligned, and we only need to get the timestamp of the first segment from one playlist. https://tools.ietf.org/html/rfc8216#section-6.2.4

If the Playlist contains an EXT-X-PLAYLIST-TYPE tag with the value of VOD, the first segment of every Media Playlist in every Variant Stream MUST start at the same media timestamp.

For live, things are more complicated.

We can't use the media sequence numbers / segment numbers for alignment in a live stream. https://tools.ietf.org/html/rfc8216#section-6.3.2

A client MUST NOT assume that segments with the same Media Sequence Number in different Variant Streams or Renditions have the same position in the presentation; Playlists MAY have independent Media Sequence Numbers. Instead, a client MUST use the relative position of each segment on the Playlist timeline and its Discontinuity Sequence Number to locate corresponding segments.

It seems that date-time mappings would help, if present, but they are optional.
https://tools.ietf.org/html/rfc8216#section-6.2.4

If any Media Playlist in a Master Playlist contains an EXT-X- PROGRAM-DATE-TIME tag, then all Media Playlists in that Master Playlist MUST contain EXT-X-PROGRAM-DATE-TIME tags with consistent mappings of date and time to media timestamps.

This would appear to state that playlists need not start at the same point in time in the general case. But it also seems to say that sync will never be off by more than one segment.
https://tools.ietf.org/html/rfc8216#section-6.2.4

Content that appears in a Media Playlist of one Variant Stream but not in another MUST appear either at the beginning or at the end of the Media Playlist file and MUST NOT be longer than the target duration.

If we assume that the first segment in each live playlist is no more than one segment out of sync with the other playlists, then we can probably just parse one segment. If our segment indices are off by one segment, we may wind up jumping over a gap or fetching an extra segment at some point.
@joeyparrish joeyparrish added type: enhancement New feature or request component: HLS The issue involves Apple's HLS manifest format labels Aug 23, 2018
@joeyparrish joeyparrish added this to the Backlog milestone Aug 23, 2018
@joeyparrish joeyparrish mentioned this issue Aug 28, 2018
Closed
@joeyparrish joeyparrish mentioned this issue Nov 6, 2018
Closed
@joeyparrish joeyparrish mentioned this issue Nov 20, 2018
Closed
shaka-bot pushed a commit that referenced this issue Feb 25, 2019
@vaage
Refactor HLS getStartTime to avoid unnecessary requests
0fb75cc 
In the hls parser's |getStartTime_|, we make network requests to
to determine a stream's start time.

To make the code easier to understand, this CL changes the code to
makes requests differently for each codec, to:
  - allow mp3 to make no requests
  - clarify mp4 to make 1 or 2 requests

Issue #1558

Change-Id: I7c83f5e326cd5408ff33576a958aee2f2b50fb60
@TheModMaker TheModMaker mentioned this issue Apr 24, 2019
Closed
@TheModMaker
Copy link
Contributor

Also, we probably make multiple network request for the same segments. The current algorithm is to iterate through each variant and check its audio and video. This means when streams appear in multiple variants, we make multiple requests.

@TheModMaker TheModMaker mentioned this issue Aug 7, 2019
Closed
shaka-bot pushed a commit that referenced this issue Aug 7, 2019
@michellezhuogg
HLS Refactor: Flatten createPeriod_() logic
1d417ff 
Our previous approach:
For every variant tag, find the associated media tags(with the same
group id), create stream info for each media tag, and then create stream
info for variant tag based on that, and create variants.
This approach has duplicate calls for the media tags with the same group
id to create stream infos.

New approach:
1. Get codecs from variant tags
2. Create stream info from each media tag (with the codecs from variant
tags)
3. Create stream info for each variant tag, and then create variants.
This creates stream info for each media tag once, and avoids duplicate
calls to guess the codecs.

Issue #1558
Closes #2066

Change-Id: Icdf3133b1b15d1baf60624ff449e0a61fdb78d8a
@michellezhuogg michellezhuogg self-assigned this Aug 8, 2019
@joeyparrish joeyparrish modified the milestones: Backlog, v2.6 Aug 9, 2019
This was referenced Aug 9, 2019
Closed
Closed
@shaka-project shaka-project locked and limited conversation to collaborators Nov 29, 2019
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@michellezhuogg michellezhuogg

Labels
component: HLS The issue involves Apple's HLS manifest format status: archived Archived and locked; will not be updated type: enhancement New feature or request
Projects
None yet
Milestone
v3.0
Development

No branches or pull requests
4 participants
@TheModMaker @joeyparrish @shaka-bot @michellezhuogg