Seeking race condition on Firefox

[boredom2]

Hi there,

Version 2.0.0 was running fine on Chrome and Firefox.
Version 2.0.1 runs fine on Chrome, but on Firefox, I receive hundreds of "seeking", "seeked", "seeking"... Messages and a very long "stalled" Period afterwards. By Hitting Pause/Play, if then works, but without, it simply does not start anymore.
Additionally - since 2.0.1, the highest Quality is ALWAYS chosen initially. Is this intended?

Thanks,
Christoph

[joeyparrish]

v2.0.1 makes faster adaptation decisions than v2.0.0 did. This is intentional, and based on feedback that Shaka sometimes took tens of seconds to adapt when playback started. See 8152e64 for the commit.

It's not instant, though. The time first choice is very low, less than one second for fast connections. The time to that choice being visible on screen depends on many factors, but primarily buffering goal and segment size. In my tests with 4 second segments, 10 second buffering goal, and ample bandwidth, I see visual changes after 8 seconds. Until then, the resolution is determined by the default bandwidth estimate, which is configurable.

I haven't seen any issues with seeking events on Firefox. Can you reproduce with our demo app, or only with your own app? Can you provide a steps to reproduce? (Next time you file an issue, please use our template.)

[cpeterso]

@boredom2: on which operating systems do you see this Firefox seeking problem? Do you see this problem with all streams?

[boredom2]

Hi there, sorry - you are right, I should have used the Template (was too early for me :P).

I can reproduce this Issue also on your Demo Page - but not with all Manifests. The YouTube Manifests run fine, the Azure Media Services Trailer has the same Effect. Due to the fact, that we are also using Azure Media Services heavily - there might be the Problem.

I use: Firefox 49.02 on Windows 10, Anniversary Update with all available Updates.
The Connection is a 7MBps Connection - not extremely fast, but for sure fast enough to run YT HD nearly without Delay, so that shouldnt be an Issue...

[danpeters76]

We're seeing the same issue with 2.0.1 on Firefox 49.0.2 for streams generated by Unified Streaming Platform both for our own content and the sample content within the shaka demo player (Tears of Steel - Widevine). In both cases we've tested so far on OSX.

These streams are working fine using Shaka 2.0.1 on Chrome.

Steps to replicate:

1. Load a unified streaming platform generated stream
2. Scrub to middle of video file
3. In most cases video will pause and not restarting, throwing the warning "The last segment should not end before the end of the Period." in the console.
4. In some cases if you leave the file playback restarts 1 or 2 minutes later

thanks,

Dan

[cpeterso]

Using the steps provided by @danpeters76, I can reproduce the buffering problem with Firefox on Windows 10 and Mac OS X 10.12, though I don't see any console errors. The stream resumes within 1-2 seconds in Chrome and Edge, but buffers for about 1-2 minutes in Firefox before resuming.

I reproduce the problem any of the Shaka demo streams, not just the United Streaming streams. I don't think this is a Firefox regression because I can reproduce the stall with older versions of Firefox (45-49).

Are older versions of the Shaka demo player archived online? That would make regression testing easier. I only tested the current Shaka v2.0.1-debug demo player:

http://shaka-player-demo.appspot.com/demo/

[cpeterso]

I filed Firefox bug 1313806 to investigate this problem from the Mozilla side. The Shaka 2.0.1 code works in Chrome, IE11, and Edge, so Firefox should try to be compatible.

Safari (macOS 10.12.1) has a different seeking problem with current Shaka demo: the audio begins playing at the new seek position, but the video doesn't start playing unless you manually pause and resume playback.

[jyavenard]

2ecd8bb is the first bad commit
commit 2ecd8bb
Author: Joey Parrish joeyparrish@google.com
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

[jyavenard]

Here is a quick fix. I'm not familiar with shaka code so it may not be how you would have done it.
The issue at hand here is that the media pipeline is flushed when a seek is initiated. However, this flushing is done by seeking again. So you get something like seek -> clear -> flush (seek) -> seek -> clear -> flush (seek) -> repeat

The current code is racy in such that it relies on an event (seeking/seeked) be fired in a specific order, order not defined in the spec.

So the work around is to not attempt to clear the media pipeline while we're seeking. It's more efficient that way anyway as when you're seeking there's no need to flush the pipeline (it's already been flushed). This will speed up seeking on all user agents.

It fixes the issue mentioned by @cpeterso above with Safari slightly, but there's still something wrong there. Sometimes after seeking it displayed the Halloween message until you pause and play again. But this appears to be irrelevant of 2.0.0 vs 2.0.1

[joeyparrish]

@jyavenard, can you please clarify what your fix is? I don't see any code here. Can you submit a PR?

[jyavenard]

The link was above: jyavenard@2310754

Will do a PR

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

@cpeterso, I believe this is not Firefox's fault. I hope you haven't spent too much time investigating on the Mozilla side.

[joeyparrish]

I pushed a commit that should fix this. Please let us know if that's not the case, and I can reopen.