RFC: remove autoplay mechanism from playback constructor

[kslimani]

Disclaimer: this is a proposition, i don't known if this issue is already solved in future Clappr versions.

Currently, the autoplay attempt is made in the playback constructor, and since it is asynchronous, it goes out of control.

I think it would be nice to expose some mechanism (maybe in core ?) to be able to control when the playback can start to play (when autoplay is enabled).

For example, i am working on an ad plugin and, in order to get the best user experience, it require to prevents playback to autostart, to display video ad and then start playback.

This new mechanism should also be coupled to the "play intent" event (to handle initial play when autoplay is disabled), to control if playback can start to play. (or couse, if plugin prevents playback to start, it is plugin responsability to start the playback).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kslimani]

Nice try little bot !

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kslimani]

Bad little bot !

[joaopaulovieira]

Let me see if I understand: Do you want a way to configure Clappr to have autoplay but be able to stop play before starting the video?

[kslimani]

Yes, something to signal to not start the video, even if autoplay is permitted.

In an ad plugin scenario (but it may be also usefull for other scenarios), common recommendations are to listen for "play" event, pause the content video, then play video advert and finally restore previous video state.

But in the case of "preroll" sometimes, the content video starts to play, then is immediatly stopped to display advert. I think it degrade user experience. (may happen on slow mobile devices)

Therefore, i am looking for a way to prevents video to start (if there is an ad available to display) to first display video ad and restore video content when ad is ended.

To solve this issue, there are, i think, several solutions.

The first which comes to my mind is to add a mechanism (a function ?) in core to signal to prevent playback to autoplay. But to achieve this, i think the autoplay "decision" mechanism should be moved to core : currently it is in the playback constructor and therefore out of control. (the mechanism which "check" if autoplay is permitted can stay inside the playback)

It may be usefull if this mechanism could be exposed by/or at "play_intent" event. And also it would be nice if "play_intent" event was triggerred when autoplay is permitted and core start the playback; currently "play_intent" event is only trigger when user click on poster/mediacontrol play button.

Currently i use a trick which store autoplay configuration option and set it to false in core. (it is an ugly trick, but it work ^_^) So the issue only may happen when autoplay is not permitted.

[kslimani]

(some random ideas, maybe out of this issue scope)

Maybe all playbacks should trigger a new event to signal core they are ready, also passing an object, with for example a property "canAutoplay".

This event may also allow playback to load any external dependencies.

And when core receive this event, it can decide if it call play method on playback or not.

Note; this logic could be also applyed to any plugins. (ie: core wait for all plugin to be ready before trigger core_ready event, or processing stuff requiring all plugin loaded and ready).

[joaopaulovieira]

Maybe I have not understood correctly your idea, but this mechanism to core waits the playback state ready seems like the inversion of Clappr architecture.

Clappr creates core first, then create the container and then the playbacks.

For the problem with the autoplay mechanism, we have plans to create a new one reactive mechanism to deal with autoplay policies. We plan to do this in the Clappr-core (🤞)

About configure the playback with the autoplay option and the possibility to block play, at the first moment looks like a wrong approach to me. I agree to have one way to not play the main content if you need to play a pre-roll advertisement, but I see other approaches to handle this case. One idea is a Playback abstraction to choose what the playback implementation you need to play (to play ad pre-roll or video) and this abstraction block the play according to your business rules.

I don't know what the other guys think about this option to block autoplay. @leandromoreira @towerz @jhonatangomes ?

[kslimani]

@joaopaulovieira i agree, my approach may not be a valid one.

Creating a new reactive mechanism is a great idea : just make sure it work alongside the video DOM reclycler feature from Utils module. (unless you want to drop support for old mobile devices)

Autoplay policies can sometimes be a pain because it differs between browsers but also between devices. (i do know a lot about it)

Do you mind if i catch you on video-dev slack next week to discuss about it ?

[leandromoreira]

I agree with @kslimani maybe we should do that (discuss)

[joaopaulovieira]

@kslimani, sure! I just need to remember my Slack login 😅