Calls to pause() while video is buffering are ignored

[DanielBaulig]

Calling pause() on the video node while it's buffering DASH segments will be ignored. After the video has buffered enough data it will continue playback regardless of the previous call to pause().

The reason for this is pretty clearly the unconditional call to play here:
https://github.com/google/shaka-player/blob/05e593d5e8f7597de4ac133d1514b91b5d34cdae/lib/player/player.js#L930

However, since the video is also explicitly paused when it enters the buffering state, subsequent calls to pause do not cause the video to emit the "pause" event, so I don't see how Shaka could be informed about this call to pause on the video node, see:
https://github.com/google/shaka-player/blob/05e593d5e8f7597de4ac133d1514b91b5d34cdae/lib/player/player.js#L871

I don't see an easy fix to this, other than adding pause and play methods to the player instance that have to be used instead of the video node pause and play methods.

[joeyparrish]

Yes, this is a tricky area.

From a user's perspective, I can see that buffering and pausing are separate concepts. When my connection is insufficient and I see a video buffering, I sometimes want to pause, wait for data to buffer to my satisfaction, then unpause, assuming I am sufficiently motivated and want to try to work around the bad connection.

But in a DASH scenario, this only makes sense if my bandwidth is below the bandwidth requirements for the lowest-resolution stream. Otherwise, pausing to force extra buffering would be unnecessary.

We made the decision a long time back not to duplicate functionality of the video element, such as seeking, play/pause, etc. Given that, there are two ways I see that we could choose to implement a buffering state: one is via pause(), and the other is via playbackRate=0.

Using pause(), as we do now, means we can't layer a pause() on top of buffering state. Using playbackRate=0 may be somewhat better, but is complicated by the design of Shaka 1.

Currently, playbackRate=0 is used by StreamVideoSource to inhibit playback during stream startup. Meanwhile, buffering state is controlled by Player without knowledge of what StreamVideoSource is doing. Using playbackRate for buffering conflicts with this, and I'm not sure how to resolve this cleanly within the existing design.

I see this as a design bug in Shaka 1. In Shaka 2, buffering and stream startup will both be controlled by one class called StreamingEngine. (Startup is really a special case of buffering anyway.) Player will no longer be responsible for buffering state at all. That should give us the freedom to implement buffering using playbackRate, which should allow us to play and pause independent of buffering state.

High-level design docs for Shaka 2 were recently announced on the mailing list if you're interested in the broad strokes. We hope to publish a preview of our progress on Shaka 2 to github by the end of the month.

[DanielBaulig]

Thanks for the great feedback!

Buffering and pausing are not only separate concept from the users perspective but also from a product perspective. Let's say I want to temporarily pause the video under certain circumstances, e.g. when the window looses focus. If the user switches into a different tab while the video is buffering the call to pause will not have any effect and the video will resume playback in the background once it's done buffering.

I've currently solved the problem by adding a small setResumeAfterBuffering method to Shaka player that set's a flag that is then checked to make the play() call at the end of the buffering state conditional.

I call this from the 'bufferingStart' event handler and set it to true from there. Then, whenever I call play or pause I also make sure to set this value correctly, so that once the video is done buffering it will do the correct thing.

[joeyparrish]

I just verified that this is no longer an issue with the latest code from the master branch. You should see the new behavior in v2 beta.