-
Notifications
You must be signed in to change notification settings - Fork 28
Intervention change: allow autoplay of muted videos on mobile #23
Comments
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 ? |
Yes, events would be propagated as normal and the promise returned by |
Thanks, Ojan! I'd previously started an internal thread on this with Microsoft Edge owners. Will share more after we've discussed. |
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. |
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. |
Hmm, I guess so. Perhaps it's the lesser of two evils. |
(cc @cpearce) |
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. 😛 |
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. |
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. |
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. |
Just a note that in terms of the spec, all logic should be hooked to the "autoplaying flag", not the |
@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. |
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? |
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? |
I think the intervention proposed above is a good idea. |
While reviewing whatwg/html#1409 I noticed something that I think needs wider feedback. Per the current spec, the order of events for Should we try to ensure this event order also for |
Given that the spec is fairly clear that playing media with the |
I also think that order makes sense, and it is what you would get if playing in response to the |
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". |
Indeed, it shipped in Safari and Chrome. It's also part of the HTML specification. I thought it was closed. It should be :) |
Great, thanks! |
@mounirlamouri Please point me at the HTML documentation for this feature. I'm aware of implementations, but not documentation. |
@jdsmith3000, the HTML spec change allowing for this were made in whatwg/html#1409 and whatwg/html#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" |
/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 theautoplay
attribute will be ignored.Chrome Android is going to introduce a change that will relax the autoplay intervention on mobile the following way:
autoplay
attribute will start playing when they are visible (in the viewport);Note that Chrome Android will disable this feature via a couple of settings.
The following minor changes could be added to the HTML specification:
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.play()
algorithm (step 1).WDYT? :)
The text was updated successfully, but these errors were encountered: