shaka-project / shaka-player

JavaScript player library / DASH & HLS client / MSE-EME player
Apache License 2.0
7.21k stars 1.34k forks source link

Unloading event fired after loading event #2894

Closed MaikH closed 1 year ago

MaikH commented 4 years ago

Dear Shaka Team,

I Stumbled over a little issue regarding event management on shaka player on safari. As far as I see, these events are fired in a certain order:

onstatechange => state "attach" onstatechange => state "media-source" loading onstatechange => state "unload" unloading onstatechange => state "attach" onstatechange => state "src-equals-drm-engine" onstatechange => state "src-equals"

I am a little bit confused about that unloading event, that is fired after the loading event. Is there any reason why this should happen? My code, that was used for bitmovin before, does not really like that state change. That problem does not occur on chrome browsers.

Reproduced with shaka-player 3.0.4 on Safari on my own environment (only hls streams) Reproduced on the shaka demo page (safari, only hls streams)

Thanks in advance for your help!

MaikH commented 4 years ago

![Uploading image.png…]()

TheModMaker commented 4 years ago

When we create the Player, we pre-load the MediaSource in preperation for MES playback. If you then load src= content, we'll unload the MSE mode and switch to src= mode. This shouldn't affect anything and only changes internal states; what problems are you seeing?

MaikH commented 4 years ago

Well it’s more an internal problem on our side. We react to these state changes / events in a certain way and the Shaka player on safari acts kind of different to the Shaka player on chrome. On chrome I do not see the unloading event. If we see the unloading event, we update our internal store and on safari this leads to an unexpected behavior

TheModMaker commented 4 years ago

The onstatechange is not really meant to be used by apps, it is mainly used for testing. The changes in state are not stable; but the unloading event is a bit confusing. We should probably change this part to delay firing the event until we start loading instead of when the app calls this method. For the moment, you can use the loaded event to detect when we've finished loading.

theodab commented 1 year ago

I looked into this issue to see if the recent PR, #5752, fixed this. However, I found that I can reproduce this with v3.0.15, but not with v4.5.0. So we had already fixed it at some point without noticing. As it looks like #5752 did not cause a reversion, I suppose we can pronounce this fixed.