Calling Player#unload followed by Player#load allows loading to proceed even though Player#mediaSource_ and Player#mediaSourceOpen_ are null
See original GitHub issueHello!
As part of our application’s preparation process before playback, we call Player.prototype.unload
, then perform some other work before calling Player.prototype.load
. We have observed this produces a race condition when you attempt to load content while content is currently being played. Since load
also calls unload
, it is possible for the player to get into a state where both this.mediaSource_
and this.mediaSourceOpen_
are null
, but the loading process is allowed to proceed. This is because when load
calls unload
, which in turn calls resetStreaming_
it observes that nothing is being played and simply returns Promise.resolve()
.
I believe we exclusively see this problem with protected content. I was able to produce it in the Shaka demo app with this content:
- Sintel 4k (multicode, Widevine)
- Tears of Steel (Widevine)
Simply add a call to unload
before load
in shakaDemo.load:
player.unload();
// Load the manifest.
player.load(asset.manifestUri).then(function() {
...
Steps to reproduce in the demo app (with the above change):
- Select content for playback
- Press Load
- Observe video is playing
- Press Load again
Observed behaviour: Assertion failed, and Cannot read property 'readyState' of null
. (The MediaSource object being passed into the MediaSourceEngine constructor is null.)
Expected behaviour: Player should load video normally.
The proposed fix is to store the unloading process on the player as a Promise. When unload
is called, check if the player is already unloading. If so, do not initiate a new unloading process, but instead continue with the existing one.
I have submitted PR #613
I wrote a test in the player_integration suite which correctly fails, though it is not included in the PR. Truthfully, I am not aware of the prevailing wisdom around testing for race conditions, and at any rate the test would need some more work before being included.
The PR is accepted by the compiler, however it nukes a few player_unit tests. I am unsure about how to proceed with regard to these now-failing tests and am open to feedback/suggestions.
Issue Analytics
- State:
- Created 7 years ago
- Comments:7 (7 by maintainers)
The fix for this has just been released in v2.0.3.
I take it back. I kept toying with it, and after several tries it finally blew up. For me, it fails if I select “Dig the Uke”, click “Load”, wait a second or two, then click “Load” again.