search

shaka-project / shaka-player

JavaScript player library / DASH & HLS client / MSE-EME player
Apache License 2.0
7.23k stars 1.34k forks source link

LIVE DASH streams with non-zero start PTS don't start playing #1651

Closed mikrohard closed 6 years ago

mikrohard commented 6 years ago

Have you read the FAQ and checked for duplicate open issues?: Yes

What version of Shaka Player are you using?: 2.4.4

Can you reproduce the issue with our latest release version?: Yes

Can you reproduce the issue with the latest code from master?: Yes

Are you using the demo app or your own custom app?: Both

If custom app, can you reproduce the issue using our demo app?: Yes

What browser and OS are you using?: latest Chrome on macOS, Chromecast, LG webOS

What are the manifest and license server URIs?: I'm unable to provide sample streams to you right now... but I'll do it later if necessasry.

What did you do? Try playing LIVE DASH stream.

What did you expect to happen? Playback to start.

What actually happened? Playback didn't start.

Let me explain this a little bit more. We're dynamically generating live DASH streams using IPTV multicasts as source. We remux the mpeg TS to fMP4 on the fly but leave the PTS/DTS values untouched for specific reasons. Which means that our initial segment has a baseMediaDecodeTime greater than zero. At this point I should also note that our MPD's don't provide any presentationTimeOffset information (I guess this is the root issue why the stream isn't working with shaka player... am I right?). If we offset the PTS values to 0 during remuxing from TS to fMP4 playback works fine (but we would like to avoid this).

Our streams play without any issues with ExoPlayer on Android & system player on Samsung Tizen. They also start playing with dash.js (but fail later dua to other reasons).

This streams also play fine with shaka if we just replace the MPD manifest with HLS manifests (same segment, just different manifests). But this works only because in HLS shaka downloads the initial segments of all the variants to determine the PTS offset (somehow ugly in my opinion). But this just proves my point that segments are fine and the issue is probably somewhere in the manifest (presentationTimeOffset???).

Jump large gaps also doesn't do the trick for us. Probably because the PTS diff is too large?

Doesn't shaka have any fallback for this kind of DASH streams? Wouldn't it be possible to somehow offset the presentationTimeline if the initial timestamp in buffered range is different than expected?

Is there anything else we could try without modifying our streams?

What would you suggest we do? Add presentationTimeOffset to our dash manifests (would that fix our issue)? Should we offset the baseMediaDecodeTime during remuxing?

Thanks in advance for any help.

TheModMaker commented 6 years ago

The times in the media need to match the times in the manifest. So if the manifest says the segment starts at 30 seconds, then the baseMediaDecodeTime needs to be 30 seconds. You can use the presentationTimeOffset to adjust the media time to be the correct presentation time. So if the segment starts at 60 seconds and you want it to start at 30 seconds within the presentation, you can set the presentationTimeOffset to 30 * timescale.

You can read more about this here: https://github.com/google/shaka-player/blob/master/docs/design/dash-manifests.md

mikrohard commented 6 years ago

Thanks for your response. I guess we'll have to fix our streams somehow.