Intervention change: allow autoplay of muted videos on mobile

[mounirlamouri]

/CC @ojanvafai @foolip @avayvod @xxyzzzq @jernoble @padenot @hober

This isn't your usual intervention. This is actually an intervention relaxation but this is probably the right place to discuss about it because it is related to a common intervention.

The current status of the autoplay restrictions on mobile is that Chrome Android and Safari iOS both block autoplay. IE/Edge and Firefox Android do not as far as I know.

In a nutshell, both browsers require that a user gesture is being processed (ie. in JS stack) in order for a call to play() to be successful and the usage of the autoplay attribute will be ignored.

Chrome Android is going to introduce a change that will relax the autoplay intervention on mobile the following way:

• videos marked as muted will be allowed to play without a user gesture;
• videos marked as muted and with the autoplay attribute will start playing when they are visible (in the viewport);
• when unmuting a video, if it did not receive a user gesture when playback started or when the mute change happened, volume will change but the video will pause.

Note that Chrome Android will disable this feature via a couple of settings.

The following minor changes could be added to the HTML specification:

• when the autoplay attribute is checked to start playback when enough data is available, it should be said that the UA may wait for the element to be visible.
• when the muted state is changed, the specification should allow the UA to pause the playback if playback is currently not allowed, following the same wording as the play() algorithm (step 1).

WDYT? :)

[padenot]

The current status of the autoplay restrictions on mobile is that Chrome Android and Safari iOS both block autoplay. IE/Edge and Firefox Android do not as far as I know.

Firefox for Android has an option (disabled by default) that blocks auto-play in its settings, under "Advanced".

I like this proposal. Would author be notified of the pause/play using the regular events ? I think that would be fine. Maybe a simple message in the developer console or some similar mechanism could be used to inform authors of this relaxation ?

[mounirlamouri]

Yes, events would be propagated as normal and the promise returned by play() would also behave as usual.

[ojanvafai]

@toddreifsteck

[toddreifsteck]

Thanks, Ojan! I'd previously started an internal thread on this with Microsoft Edge owners. Will share more after we've discussed.

[iandevlin]

I am concerned that this will be massively abused, with huge videos autoplaying on mobile, devouring people's data plans.

[marcoscaceres]

I am concerned that this will be massively abused, with huge videos autoplaying on mobile, devouring people's data plans.

Can't be worst than yiffs - which are already everywhere and could not be worst a video format.

[paulirish]

I am concerned that this will be massively abused, with huge videos autoplaying on mobile, devouring people's data plans.

FWIW there are significant users of commercial solutions that decode video assets to canvas, all in javascript, in order to work around this restriction. As you can imagine, this consumes the CPU entirely and drains battery quite successfully. Between this and yiffs, i estimate that first-class support for muted autoplay is a win for users.

[iandevlin]

Hmm, I guess so. Perhaps it's the lesser of two evils.

[padenot]

(cc @cpearce)

[nolanlawson]

I am concerned that this will be massively abused, with huge videos autoplaying on mobile, devouring people's data plans.

GIFs are already a much bigger source of abuse IMO. Check out http://giphy.com in a mobile browser – every pagescroll is like 3MB. (Video to demonstrate).

Ironically, the WEBM video itself I'm using to demonstrate this is 820kB. 😛

[kornelski]

Right, intention of this is to stop the abuse that is currently happening.

Autoplaying videos are already possible with GIFs, which use 10 times as much bandwidth and use more battery, because of increased amount of data to decode (single-threaded!) and they don't have hardware acceleration.

Ads already today use autoplayed videos. When they can't use the video element, they fall back to using JavaScript or CSS animations to animate frames in gigantic JPEG filmstrips. This uses a lot of bandwidth (JPEG's not as bad as GIF, but still that's not even as good as MPEG-1) and awful amounts of memory, that a proper video codec wouldn't need.

[addyosmani]

This would be a huge win for battery, memory and (possibly) bandwidth savings. Are there any considerations being made for poor network connectivity/Data Saver mode? I'm unsure what the current constraints (if any) we apply to autoplaying GIFs are in DS so this may not be as much of a concern.

[giannoudak]

Hello, this is going to be a nice feature and skip us from loading animated gifs or playing sprite images to simulate video playing until the user taps to play. In which chrome version you are going to introduce this feature?

[foolip]

Just a note that in terms of the spec, all logic should be hooked to the "autoplaying flag", not the autoplay attribute directly. This is because any call to play() or pause() before autoplay kicks in should disable the autoplay logic.

[toddreifsteck]

@jdsmith3000 is our guy on this. I'll defer to him. I prefer anything that reduces CPU on the UI thread, battery usage overall and total memory while not sacrificing the interoperable web but this space is too complex for me to be confident in how any decision will shake out.

[jdsmith3000]

Windows phone ignores autoplay to preserve power. I've not seen many sites that try to work around this with others, less efficient methods. How prevalent is this?

[ojanvafai]

It is increasingly more and more prevalent. In the past year, decoding video in JS on mobile has become popular for ads. Unfortunately, that makes it hard to just share links to bad examples since the ads on a page change on each page load.

Regarding power usage, we've discussed autopausing when muted videos go offscreen, but there's some disagreement among us on whether it's worth the developer confusion. We plan to answer that question by measuring the amount of offscreen muted video that plays and will possibly consider doing that as a followup step depending on what the numbers show.

@KenjiBaheux do you have any links you can share to examples?

[cpearce]

I think the intervention proposed above is a good idea.

[foolip]

While reviewing https://github.com/whatwg/html/pull/1409 I noticed something that I think needs wider feedback.

Per the current spec, the order of events for <video autoplay> (and <audio autoplay>) is canplay, play, playing, canplaythrough. By making autoplay wait until the element intersects the viewport, the order would change to canplay, canplaythrough, play, playing. That cannot be avoided unless the canplaythrough event is artificially delayed.

Should we try to ensure this event order also for <audio autoplay>? A divergence would be unfortunate, but whatever we do we'll inflict two different event orders on web developers until the new behavior is ubiquitous.

[mounirlamouri]

Given that the spec is fairly clear that playing media with the autoplay attribute is optional, I think it would be better if these steps were run after the canplaythrough event so doing the optional step or not will have lesser consequences. WDYT?

[foolip]

I also think that order makes sense, and it is what you would get if playing in response to the canplaythrough event. There is some compat risk in making that change which is very hard to quantify, so that's why I wanted to ask for objections here. If there are no objections soonish, then let's give it a try and reconsider only if something breaks.

[RByers]

First shipped in Chrome 53

@mounirlamouri is there outstanding spec work that should be done for this? Safari shipped this too, so all browsers now agree on this behavior, right? Just wondering when we can call this issue "fixed".

[mounirlamouri]

Indeed, it shipped in Safari and Chrome. It's also part of the HTML specification. I thought it was closed. It should be :)

[RByers]

Great, thanks!

[jdsmith3000]

@mounirlamouri Please point me at the HTML documentation for this feature. I'm aware of implementations, but not documentation.

[foolip]

@jdsmith3000, the HTML spec change allowing for this were made in https://github.com/whatwg/html/pull/1409 and https://github.com/whatwg/html/pull/2324 and are now live at https://html.spec.whatwg.org/multipage/embedded-content.html#ready-states, under "If the new ready state is HAVE_ENOUGH_DATA"