SourceHandlers need a way to specify that they are not ready to it's tech

[imbcmdth]

Right now, it is assumed that the source handler is ready once it has returned from the handleSource function. It would be helpful if the parent Tech waited for an event or a call back from the sourceHandler before it signals to the world that it is ready to start playing.

There are sources which are fetched and processed asynchronously. The current work around seems to be to set the isReady_ variable to false in the handleSource function and then calling triggerReady when you are actually ready.

[dmlap]

That's not the way I'd recommend building your source handler (or tech). The video element guarantees all properties and methods are available immediately, though many of them have asynchronous effects. It has to do long-running jobs like fetching video data to begin playback, too. It expresses that asynchronicity through networkState, readyState, and a host of standardized events however, not isReady_.

[heff]

What's the specific error that's happening here? What is trying to do what with the source handler before it's ready and what happens?

[imbcmdth]

It expresses that asynchronicity through networkState, readyState, and a host of standardized events however, not isReady_.

@dmlap That is true but the video element also has internal behavior like acknowledging that play was called even though it hasn't finished loading (meta)data and then actually playing once it really is ready. In video.js, the only way to defer functions called on the Html5 tech right now is to set isReady_ to false. The player doesn't take into account the readyState or networkState of the underlying tech when it is deciding whether to defer function calls.

What's the specific error that's happening here? What is trying to do what with the source handler before it's ready and what happens?

@heff It's been a while, but it was related to a plugin (playlist if I recall) that called src() and then immediately called play() on the tech. Since the source being set was a dash manifest, the SourceHandler was invoked and it started the first of several asynchronous processes - fetching the manifest, waiting for the needsKey event, fetching a license, setting the mediaKeys - all asynchronous processes.

As a result, the play() was called long before any MSE were setup. The video element ate the play function and then did nothing (since no source was setup). The video never played.

[dmlap]

I agree that writing source handlers/techs is tough and we could do a better job helping manage asynchronous loading processes. isReady_ has a meaning though, and it's incompatible with the state the player is in while the video or related metadata is being fetched. Today, you could build an effect-deferring system into your source handler (events and callbacks are pretty popular...). We should definitely discuss what helpers we need to build to reduce the complexity of developing future source handlers, I just don't think isReady_ is one of them.

[heff]

As a result, the play() was called long before any MSE were setup

Wow, that's a shame. There's no reason I can think of why dash.js would need to asynchronously set up a media source, except that it's probably looped that in with creating source buffers. Maybe that wouldn't fix the issue anyway if there's still no source buffers, but it might, if there's any way to feed dash.js an existing media source. Can we look into that, because otherwise we might be complicating source handlers just for dash.js.

[heff]

Also, if this means you can't call play() on the video element synchronously after create a dash player, and we can fix that, it might be something we can push back to dash.js to change.

[dmlap]

@imbcmdeath is convincing me that we should manage something like "requested tech state" in the base tech and expose it to source handlers. The dash handler could query that snapshot when it finished booting up and attaching its Media Source, and the Flash tech could use the snapshot to initialize itself once the SWF loaded. We might be able to get rid of isReady_ entirely if we played our cards right...

It's more complexity for the base tech but I think it would make Source Handlers significantly easier to write. HLS has some async startup shenanigans it has to deal with too, for instance.

[Fresa]

Is there any update on this matter since 6.0.0 was released including async source selection?