1313806 - Shaka Player stalls when trying to seek, buffering for one minute before resuming

Status: RESOLVED INVALID

(Core :: Audio/Video: Playback, defect)

Description

[Chris Peterson [:cpeterson]]

Someone reported on GitHub that Shaka 2.0.1 stalls buffering for one minute when seeking in Firefox, but Shaka 2.0.0 seeks correctly:

https://github.com/google/shaka-player/issues/569

STR:
1. Load http://shaka-player-demo.appspot.com/demo/
2. Select a stream, such as YouTube's "Car" or Unified Streaming's "Tears of Steel".
3. Wait for the stream to start playing.
4. Seek to the middle of the video.

RESULT:
The player stalls. After buffering for about one minute, the video resumes playing at the new position.

Seeking in Chrome, IE11, and Edge works correctly, buffering for less than one second. Safari (macOS 10.12.1) has a different seeking problem: the audio begins playing at the new position, but the video doesn't start playing unless you manually pause and resume playback.

I don't think this is a Firefox regression because I can reproduce this problem in old versions of Firefox (at least back to 45) on Windows and Mac. One could argue this Shaka 2.0.1 regression is a Shaka bug, but if their code works in Chrome and Edge we should be compatible.

Comment 1

[Jean-Yves Avenard [:jya]]

Using the "car" stream.
After pressing "Load", data gets appended to the sourcebuffer, init segment indicates that video is 181.63s long.
I then seeked to 127s.

At this time the video source buffer contains [0.000000, 15.015322) and the audio source buffer [0.000000, 20.015600)

then the following occurs:
audiosb.remove(0, 97.06)
videosb.remove(0, 97.055325)

after this the player loads audio [20,015600, 30.000181) and we end with audiosb=[20.015600, 30.000181)
video is loaded with [15.015000, 20.020322)

then data is removed from the audio sourcebuffer:
audiosb.remove(0.000000, 181.630000)
same for the video sourcebuffer

then audio sb is loaded with [110.016145, 120.000725). Remove is called again on remove(0, 181.63)

the steps followed are rather always the same.

1.Seek to x
2. load [x-20. x-10)
3. clear source buffer
4. x -= 0.001s
5. goto step 1.

Comment 2

[Jean-Yves Avenard [:jya]]

2ecd8bba19c668a2078da1ab402cdfcd53f45ad5 is the first bad commit
commit 2ecd8bba19c668a2078da1ab402cdfcd53f45ad5
Author: Joey Parrish <[e-mail]>
Date:   Wed Oct 19 13:07:47 2016 -0700

    Flush Chromecast pipeline after clearing buffer
    
    To work around a bug in Chromecast, seek after clearing the buffer.
    This forces the device to flush the pipeline and remove any decoded
    data from the old representation.
    
    Closes #544
    
    Change-Id: I3c34d344bfd856b429a360fc41ce7288791716bb

Comment 3

[Jean-Yves Avenard [:jya]]

I've submitted a fix for the shaka code at https://github.com/google/shaka-player/issues/569

It's not something we can fix on our side easily; first because there's nothing to fix, and 2nd because our MSE is fully asynchronous so we can't guarantee the order at which the events will be fired.

So may as well fix shaka instead

Comment 4

[joeyparrish]

Jean-Yves, I didn't see your fix anywhere.  If you have a PR, we are very interested.

Comment 5

[joeyparrish]

I just managed to reproduce this bug on Chrome by rapidly seeking. The system got stuck in a seek loop, which eventually resolved after many hundred iterations.

I think the real bug is in Shaka Player.  I recommend closing this issue.

Comment 6

[Chris Peterson [:cpeterson]]

Thanks for testing and letting us know!