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




2 years ago
2 years ago


(Reporter: cpeterson, Assigned: jya)



Firefox Tracking Flags

(firefox49 affected, firefox-esr45 affected, firefox50 affected, firefox51 affected, firefox52 affected)





2 years ago
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:

1. Load
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.

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

2 years ago
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

2 years ago
2ecd8bba19c668a2078da1ab402cdfcd53f45ad5 is the first bad commit
commit 2ecd8bba19c668a2078da1ab402cdfcd53f45ad5
Author: Joey Parrish <>
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

2 years ago
I've submitted a fix for the shaka code at

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

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

Comment 5

2 years ago
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

2 years ago
Thanks for testing and letting us know!
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.