Long wait time for Stalled Playback: Reference Issue https://github.com/google/shaka-player/issues/2131

Have you read the Tutorials? Yes

Have you read the FAQ and checked for duplicate open issues? Yes I am refering to a closed issue that I am still having some issue with.

What version of Shaka Player are you using? Shaka 3.0.6

Please ask your question A long while ago I raised a support ticket that got quite a bit of attention. It seems this has been fixed and i can confirm that on the device I reported the issue from (2017 Tizen 3 TV) that playback is working.

Unfortunately it can take anywhere for between 30seconds to more than a minute for playback to start though.

I can see in the logs that stalls are detected and attempts to move the playhead are done but there are some reports of this not being possible:

Jumping forward 0.046 seconds because of gap before start time of 0.046
streaming_engine.js:635 (all): seeked: buffered seek: presentationTime=0.046
streaming_engine.js:977 (video:5) buffered to end of presentation
streaming_engine.js:977 (audio:1) buffered to end of presentation
18streaming_engine.js:635 (all): seeked: buffered seek: presentationTime=0.046
playhead.js:501 Stall detected at 0.046 for 1.2030000686645508 seconds.
playhead.js:504 Seeking forward 2 seconds to break stall.
2streaming_engine.js:635 (all): seeked: buffered seek: presentationTime=2.045999
Failed to move playhead from 0.046 to 0.046

We have detected an issue where our manifest segments have a negative start time. We discovered this with FFPROBE. Unfortunately re-transcoding everything is not an option for us and this only seems to affect Tizen2.4 & Tizen 3 with Shaka. The Tizen player handles the start time without a long stall. Essentially we would like to use the same player where possible though so I am asking if you have any tips on how we can prompt the playback to begin more quickly. It seems that the 0.046 seconds is the gap start time in each playback attempt too. I am not sure if this helps.

From FFPROBE the Audio track always starts at: -0.0464400

// inspect audio track
$ ffprobe before_fixed~~audio-en~~mpegdash.mp4
...
Duration: 00:00:20.06, start: -0.046440, bitrate: 136 kb/s

But the video track starts at 0

// inpsect the video track
$ ffprobe before_fixed~~iview-180-clean~~220k~~mpegdash.mp4
...
Duration: 00:00:20.00, start: 0.000000, bitrate: 172 kb/s

It seems that Shaka is not taking the negative segment start into account as the playhead move is from positive 0.046.

At present we are using this config to get playback occurring:

this.player.configure('streaming.stallSkip', 2);

But it can still take much longer than 2 seconds for playback to begin. Approximately 30-40 seconds

Any help you could provide for config options that might help speed the stall up would be great.

Kind regards,

Stuart

[joeyparrish]

Sorry for losing track of this issue.

If the problem is caused by the negative timestamps, you could offset them by modifying the manifest. The presentationTimeOffset attribute in DASH is used to adjust how timestamps are interpreted by the browser. Could you try adjusting that in lieu of re-encoding the content?

[joeyparrish]

It’s an attribute on certain elements in the DASH manifest. If you can control the generation of the MPD or edit it after the fact, you can try adding/manipulating presentationTimeOffset.