Back-jumping of playhead in Chrome

Have you read the FAQ and checked for duplicate open issues?: Yes What version of Shaka Player are you using?: v2.5.0-beta2 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?: custom If custom app, can you reproduce the issue using our demo app?: python throws an error when compiling demo app…) What browser and OS are you using?: Win 7 Professional/Chrome 71.0.3578.98 (64bit) What are the manifest and license server URIs?: sent by email [e-mail] What did you do? play a HLS stream What did you expect to happen? no freezes & back-jumping of playhead What actually happened?

Flushing media pipeline due to stall inside buffered range
Playhead past end.
Moving playhead... currentTime=77231.943309 targetTime=77227.80437779427
Playhead in safe region or in buffered region.
Seek to 77227.804377
(all): seeked: buffered seek: playheadTime=77227.80837774277

(It is on Chrome & Opera, on Firefox no bugs) the player jumps back from time to time, w\o any defined intervals. There is no such behavior in the previous release v2.4.5

Besides that jumping, player often stops for half a second and shows the loader. This happens thereabouts of fetchAndAppend_ moment (and that was in v2.4.5)

[joeyparrish]

Here’s a snippet of what we found in chrome://media-internals:

Timestamp	Property	Value
00:00:10.496	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:10.497	pipeline_state	kPlaying
00:00:10.593	audio_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:10.765	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:10.765	for_suspended_start	false
00:00:10.765	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:11.238	warning	Large timestamp gap detected; may cause AV sync to drift. time:16998929791us expected:16997479125us delta:1450666us
00:00:12.524	debug	Media segment did not contain any coded frames for track 221, mismatching initialization segment. Therefore, MSE coded frame processing may not interoperably detect discontinuities in appended media.
00:00:15.816	warning	Large timestamp gap detected; may cause AV sync to drift. time:17003921791us expected:17002044458us delta:1877333us
00:00:19.374	warning	Large timestamp gap detected; may cause AV sync to drift. time:17009041791us expected:17005607125us delta:3434666us
00:00:23.810	warning	Large timestamp gap detected; may cause AV sync to drift. time:17014481791us expected:17010044458us delta:4437333us
00:00:34.309	seek_target	17024.733799
00:00:34.309	pipeline_state	kSeeking
00:00:34.309	audio_buffering_state	BUFFERING_HAVE_NOTHING
00:00:34.311	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:34.311	pipeline_state	kPlaying
00:00:34.395	audio_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:34.551	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:34.551	for_suspended_start	false
00:00:34.551	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:35.060	info	Effective playback rate changed from 1 to 0
00:00:35.310	info	Effective playback rate changed from 0 to 1
00:00:51.331	warning	Large timestamp gap detected; may cause AV sync to drift. time:17042961791us expected:17041489790us delta:1472001us
00:00:56.794	audio_buffering_state	BUFFERING_HAVE_NOTHING
00:00:56.795	for_suspended_start	false
00:00:56.795	pipeline_buffering_state	BUFFERING_HAVE_NOTHING
00:00:57.847	seek_target	17046.728025
00:00:57.848	pipeline_state	kSeeking
00:00:57.849	seek_target	17046.714799
00:00:57.850	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:57.850	pipeline_state	kPlaying
00:00:57.850	pipeline_state	kSeeking
00:00:57.851	pipeline_state	kPlaying

From Chrome’s internal logging, it appears that something is wrong with the media which causes these stalls. These are different from a buffering event, because we are inside a buffered region at the time. The playback pipeline stalls, possibly related to the “Large timestamp gap detected” warning message.

I would consult with the encoder vendor and see if you can resolve this with them. There is nothing obviously wrong with Shaka Player. We are doing our best to recover from a bad situation that we can’t directly control (small seek range, stalled browser).

[vaage]

@Kogoruhn I believe I am now seeing what you are talking about using:

• Shaka Player 2.5-beta2
• Chrome 71.0.3578.98 (Official Build) (64-bit)
• Linux

I saw our stall detection logic firing. Out of curiosity, I forces it to wait even longer before kicking in. Doing this, the video was able to resume without stall detection’s intervention, but remained in a stall for longer.

When looking at the “Jumping forward…” behaviour, it appears that the seek window is only 3 seconds. That is pretty small. The player keeps falling behind and needing to jump forward. Every now and then, the player gets too far ahead which causes a visual stall. I played with how the player handles falling behind and getting ahead, but in the end a 3 second window looks like it is too small for the player.

The player is doing its best to play the content, but it appears that a 3 second seek window may be too small.

To make sure what I found is accurate, I will have @joeyparrish look at what I found.