HLS playback with start time != 0

[dalecurtis]

What version of Shaka Player are you using: Latest CDN version.

Are you using the demo app or your own custom app: Turtle Tube.

What browser and OS are you using: Chrome, repros in Safari too.

What are the manifest and license server URIs:

Shaka version:
http://storage.googleapis.com/dalecurtis/shaka/shaka.html?src=buck_master.m3u8

HLS.js version:
http://storage.googleapis.com/dalecurtis/shaka/hls.html?src=buck_master.m3u8

Native version (has trouble in Chrome on Android, but not Safari)
storage.googleapis.com/dalecurtis/shaka/hls_native.html?src=buck_master.m3u8

What did you do?
Tried to play a clip :)

What did you expect to happen?
The clip to play!

What actually happened?
Clip never starts, though some duration information is present. No errors reported in either media-internals or Shaka. Since Android has trouble too, maybe I'm doing something wrong. File was created from buck480p w/o audio using Apple's tools:

$ mediafilesegmenter --video-only --iso-fragmented -i buck.m3u8 -B buck480_ ../buck480_dashinit.mp4
$ variantplaylistcreator buck.m3u8 buck480_dashinit.plist

[dalecurtis]

Android doesn't support fmp4 based HLS, so that's why it doesn't work there. Maybe the version of shaka I tried doesn't either?

[dalecurtis]

Still happens on the master branch, so not sure what the deal is.

[joeyparrish]

Shaka plays HLS (and everything at the moment) through MSE, which means only fMP4 would work on Chrome. Playing through MSE also means Android's built-in HLS playback isn't part of the equation.

We'll look into it, though. Thanks!

[vaage]

There appears to be a large gap at the start of the content. If you enable jump large gaps in the shaka player configuration, the content will play. The content will also play if you seek further into it with jump large gaps disabled.

[dalecurtis]

How did you determine that there's a gap at the start of the content? I'm having trouble seeing that when inspecting the file with MP4Box.

[vaage]

If you open up the console you should see a message "Ignoring large gap at 0". If you enable "Jump large gaps", the content can play. For more information on how gap jumping works in Shaka Player check out shaka.media.Playhead.prototype.onPollGapJump_ in shaka-player/lib/media/playhead.js.

[dalecurtis]

Thanks, I took the first couple segments and ran them through ffmpeg. Seems like a "bug" in mediafilesegmenter, it always starts the first segements at T=10s for some reason:

https://stackoverflow.com/questions/29005340/mediafilesegmenter-inserts-timed-metadata-id3-tags-in-hls-stream-but-at-the-wron

There doesn't seem to be any option to fix this, so I'll switch to ffmpeg for generating the segments.

[joeyparrish]

This is a little more nuanced than "bad content", and ultimately, we will have to make some changes.

Apple's own tools create content starting at t=10, with no option to change that, which seems crazy and broken.

hls.js can play this content. We would like our users not to need multiple player solutions to cover DASH & HLS, so we should be able to handle this.

Currently, we have an option in Player to compensate for this in VOD content: manifest.hls.defaultTimeOffset. If you know your content starts at something other than 0, use this configuration to tell us so we can offset it back to 0. So you can solve this already with current versions of Shaka Player and a little bit of configuration.

As we have been working on HLS live, though, we find that things get more complicated. A media playlist will give the URLs of available segments and the durations of those segments, but not their start time. Although there is a maximum segment duration in the playlist, older segments which have already disappeared may have had smaller durations than the maximum. So there is no way to know (accurately) the start time of the first available segment in a live manifest.

This means that for live, we will have to fetch the first available segment, parse it to find the start time, then use that to derive the start times for the rest of the segments and build our segment index. Once we are doing that, the need for an application to inform us of VOD start time goes away, and we will deprecate manifest.hls.defaultTimeOffset.

[joeyparrish]

I'm removing the "bad content" label, even though it pains me, and marking this as "HLS" and "enhancement". In the meant time, you can work around it through configuration.

[joeyparrish]

I have a CL in review that parses content to get the start time, rather than relying on configuration. But for content that doesn't start at 0, a gap-jumping configuration is still required. If I go one step further and offset VOD content back to 0, apps won't have to be specially-configured for HLS.