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

[stuartflanagan]

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

[stuartflanagan]

I will email a test stream and License config.
I am also having trouble finding the default values for some of the streaming config options:
https://shaka-player-demo.appspot.com/docs/api/shaka.extern.html#.PlayerConfiguration

stallThreshold
stallEnabled

One other thing I am noticing is that the gap does not seem to be detected or skipped in newer versions of chrome.

Jumping forward 0.046 seconds because of gap before start time of 0.046

Is never reported and playback begins immediately. But with Tizen 3 (2017) the above occurs and the very long stall occurs.

[stuartflanagan]

Email sent with a test configuration.
We are also seeing this with our Youbora logs:

log.js:113 [Youbora][06:28:09.974] n: /pause at 0.046s
log.js:113 [Youbora][06:28:10.028] v: XHR Req: //infinity-c11.youboranqs01.com/resume?pauseDuration=-1&playhead=0.046&timemark=1609896490026
log.js:113 [Youbora][06:28:10.039] n: /resume -1ms

Which suggests the pause and resume are not in sync somehow?

[joeyparrish]

Seeking tends to be very slow on devices like this, and not every gap needs to be jumped over. Can you please try disabling gap-jumping to see if that resolves the issue?

player.configure('streaming.smallGapLimit', 0);
player.configure('streaming.jumpLargeGaps', false);

[stuartflanagan]

I think it helps a bit but still a very long stall time on the video.

Can I email another manifest to check with please?

[stuartflanagan]

Have emailed Manifest and License for this issue.

[stuartflanagan]

Hi @joeyparrish The above config does not stop this particular issue from occurring. Just wondering if you were you able to replicate on Tizen 2017 with the supplied Manifest and License? Any help here appreciated.

[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?

[shaka-bot]

@stuartflanagan Does this answer all your questions? Can we close the issue?

[shaka-bot]

Closing due to inactivity. If this is still an issue for you or if you have further questions, you can ask us to reopen or have the bot reopen it by including @shaka-bot reopen in a comment.

[stuartflanagan]

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?

I have not tried this yet as I just saw it. Thank you for following up though @joeyparrish I will give it a go

[stuartflanagan]

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 Do you have an example of how and when to set this please? Is it in the configuration?

[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.