Hi Eric Carlson, Jer Noble, Could you please join the discussion to help assess whether the restriction on concurrent playback of multiple <video> elements with audio is still necessary on iOS? I’ve traced the origin of this restriction back to Bug 126780 <https://bugs.webkit.org/show_bug.cgi?id=126780>, which was addressed in this commit <https://github.com/WebKit/WebKit/commit/5ae5b76ad011a7ed3bd964184b268c672a61fdcc> by Eric Carlson in January 2014. Unfortunately, the bug description doesn’t clearly explain what was meant by “Some platforms do not allow more than one <video> element to play concurrently,” so the exact rationale remains unclear. Later, in October 2016, inline playback via <video> on iOS was introduced (blog post <https://webkit.org/blog/6784/new-video-policies-for-ios/>) through this commit <https://github.com/WebKit/WebKit/commit/99efb5e8e4efa797684804f65a4eeec119096f7c> by Jer Noble. However, the concurrent playback restriction for multiple audible videos still remains in effect on iOS. After digging through the history, the original motivation behind this restriction is still not fully clear. One possible explanation is that, prior to the introduction of playsinline, video playback on iOS was always fullscreen - so automatically pausing other videos might have made sense to avoid background playback. But in today’s usage patterns, this seems more like a concern for the web application to manage rather than something enforced by the platform. This restriction has repeatedly caused issues in scenarios such as WebRTC-based video conferencing, as noted in the bug tracker. While WebRTC is one example, my primary interest is in supporting concurrent playback of multiple <video> elements delivering audio/video over LL-HLS. In such cases, this restriction still applies and leads to playback interruptions - even though technically there are no hard constraints that should prevent smooth, simultaneous playback. So I’d like to ask: if there are no longer any technical or policy reasons to enforce this restriction, could it be reconsidered and potentially lifted? If it’s decided that this restriction is no longer needed, I’d be happy to begin working on a patch to lift it. Thanks for your time and consideration! On Wed, Apr 30, 2025 at 4:01 PM Yury Yarashevich <yura.yaroshevich@gmail.com> wrote:

Hi Jean-Yves,

Thanks for the quick and detailed response, and for the helpful links.

...

Are you referring to audible video elements requiring a user gesture for playback to start?

To clarify, I’m aware of the standard autoplay policies and user gesture requirements for unmuted playback, and I agree that those are well-documented and expected.

What I’m describing appears to be a distinct issue - not about autoplay initiation, but about ongoing playback being unexpectedly paused by the browser after it has already started, particularly when multiple unmuted <video> elements are playing concurrently. This happens even after a proper user gesture and successful play() call.

...

I’m not aware of any such restrictions.

After capturing logs and digging into the WebKit source code, I found that the restriction I’m referring to is implemented as follows:: 1. The `ConcurrentPlaybackNotPermitted` policy is enforced only on iOS, which explains why there’s no issue on macOS (I haven’t tested on iPad). Source code: https://github.com/WebKit/WebKit/blob/45d0c14d08a78058a88d16460f1fbc10946634... 2. The logic that iterates over all media elements and enforces pause is here: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/audio/Pla... 3. The implementation of the "can play concurrently" check, which effectively disallows concurrent playback of audible media unless the source is a MediaStream, is here: https://github.com/WebKit/WebKit/blob/45d0c14d08a78058a88d16460f1fbc10946634... 4. There are also tests that explicitly verify that calling play() on one video element pauses all others: a) https://github.com/WebKit/WebKit/blob/main/LayoutTests/media/video-concurren... ; b) https://github.com/WebKit/WebKit/blob/main/LayoutTests/media/video-multiple-... .

To demonstrate the issue, I’ve created a test page:

https://mstyura.github.io/webkit-issues/audible-video-concurrent-playback/in...

It contains 4 HLS video elements and two buttons: “Play All” and “Pause All.” Clicking “Play All” results in only one video playing effectively. Repeating the action multiple times shows that behavior is non-deterministic.

There’s also a “workaround mode” that starts all videos muted. In that case, all 4 videos initially play—but later WebKit sometimes detects concurrent playback (during media element time updates from HTMLMediaElement::updatePlayState https://github.com/WebKit/WebKit/blob/156848f5d55261b92551457dec064ff946ca45...) and starts pausing them again. This leads to the observed ping-pong effect between JavaScript and WebKit.

Demo source: https://github.com/mstyura/WebKit-Issues/blob/main/audible-video-concurrent-...

My question is: Is this behavior still considered desirable in 2025, especially given that developers can bypass it with more complex (but less power-efficient) workarounds like WebCodecs + <canvas> or/and VideoTrackGenerator + AudioContext.createMediaStreamDestination()?

Thanks again for your time and insights!

On Wed, Apr 30, 2025 at 2:28 PM Jean-Yves Avenard < jean-yves.avenard@apple.com> wrote:

...

On 30 Apr 2025, at 9:57 pm, Yury Yarashevich via webkit-dev < webkit-dev@lists.webkit.org> wrote:

Hi WebKit team,

I’m curious about the original rationale behind the restriction that prevents concurrent playback of multiple <video> elements. Was it primarily introduced to save battery life?

I’m not aware of any such restrictions.

Here is a test page that will literally let you play hundreds of video elements at the same time.

It works on any Apple devices: iPhone, iPad, Vision Pro, Mac .

In practice, this behavior appears to have unintended side effects. There’s a reproducible issue where playback can be started with the video muted and then immediately unmuted, effectively bypassing the restriction. However, this often results in videos being randomly paused later—sometimes very frequently—leading to a “play/pause ping-pong” between Safari/WebKit and JavaScript restarting playback. This erratic behavior may actually *increase* battery consumption, despite appearing to work smoothly from the user’s perspective.

Are you referring to audible video elements requiring a user gesture for playback to start?

This behaviour isn’t erratic and is well defined and and up to know I thought it was well understood. For an audible element to play, the user needs to first interact with the video element such as clicking on the video or its controls. This behaviour is even defined through HTML5 specifications including how you can detect if the User Agent will allow video to start autoplaying without a user gesture.

Similar policies are implemented by other user agents such as Firefox and Chrome. There’s an article on MDN on how to deal with them [image: mdn-social-share.d893525a4fb5fb1f67a2.png]

Autoplay guide for media and Web Audio APIs - Media technologies on the web | MDN <https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Autoplay> developer.mozilla.org <https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Autoplay> <https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Autoplay>

Here is a more WebKit-focus article Auto-Play Policy Changes for macOS <https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/> webkit.org <https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/> [image: apple-touch-icon-precomposed.png] <https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/> <https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/>

Here is a similar article written by the Chrome team on the same topic

[image: liam-neeson-will-find-a2c50097288a9.jpeg]

Autoplay policy in Chrome | Blog | Chrome for Developers <https://developer.chrome.com/blog/autoplay/> developer.chrome.com <https://developer.chrome.com/blog/autoplay/> <https://developer.chrome.com/blog/autoplay/> Here is the HTML5 specifications related to this matter

HTML Standard <https://html.spec.whatwg.org/multipage/media.html#eligible-for-autoplay> spec.whatwg.org <https://html.spec.whatwg.org/multipage/media.html#eligible-for-autoplay> <https://html.spec.whatwg.org/multipage/media.html#eligible-for-autoplay> <https://html.spec.whatwg.org/multipage/media.html#eligible-for-autoplay>

Even if this workaround is eventually blocked, developers who rely on concurrent playback (e.g., outside of WebRTC contexts) will turn to more complex solutions, such as decoding video and audio using WebCodecs or/and WebAssembly, and rendering via <canvas> and AudioContext. While technically feasible, these approaches are likely to be significantly less power-efficient than simply allowing multiple <video> elements to play concurrently. Another similarly inefficient workaround would be to synthesize a MediaStream using the VideoTrackGenerator API and AudioContext.createMediaStreamDestination().

Lastly, another issue is that creating a MediaElementSource from a <video> element and routing its audio through a shared AudioContext also does not disable the playback restriction—whereas it *is* disabled when the <video> element itself is muted. This feels inconsistent and may point to a separate bug.

Could you please clarify the motivation behind this restriction, and whether there are any plans to revisit or improve its behavior?

I believe I answered this question above, and through the various links provided.

Cheers JY

Hi Jer, Thank you very much for your response and clear explanation!

This is a longstanding policy whose intent was to match the overall system behavior where multiple apps are prevented from playing audible content simultaneously.

That makes perfect sense in the context of multiple different native apps, and for Mobile Safari, it's also reasonable that only one active web app (tab) is allowed to play audio at a time. However, this becomes an unfortunate limitation within a single web app (or PWA) that aims to implement more advanced media playback scenarios - such as concurrently playing multiple LL-HLS streams (i.e., without using MediaStreams).

However, IMO relaxing this policy for all video elements with no opt-in would lead to some pretty terrible behavior on unsophisticated web sites.

I also agree that simply lifting this restriction - which doesn't exist in any other mobile web browser - could unintentionally break web apps that have already implemented workarounds specific to Mobile Safari. In that case, would it be viable to introduce a non-standard mechanism to explicitly opt out of this restriction? For example, perhaps a custom value in the Permissions-Policy header could signal that concurrent playback is intentional. What do you think?

some pretty terrible behavior on unsophisticated web sites.

What kind of worst-case misbehavior do you envision? Perhaps there's a tradeoff to consider between the potential downsides and the new possibilities this change would enable - especially for more advanced applications. It might be worth leaning slightly in favor of those new use cases if the risks can be managed.

All that said, we’re currently investigating the idea of assigning particular AudioSessions to individual HTMLMediaElements. When multiple elements share a single AudioSession, that seems to be a good signal that those media elements can play simultaneously. Let’s figure out if that kind of more declarative, opt-in approach can solve the video conferencing use case.

I briefly mentioned this in my first email, but I'll reiterate it here. Would it be possible to improve the integration between HTMLMediaElement and WebAudio? Specifically, if a <video> or <audio> element's audio is routed through an AudioContext, could it be treated as "silent" for the purposes of the canPlayConcurrently check - thus not interfering with other playing elements? What’s your opinion on this approach? All the best, Yury. On Wed, May 14, 2025 at 10:49 PM Jer Noble <jer.noble@apple.com> wrote:

Hi Yury,

This is a longstanding policy whose intent was to match the overall system behavior where multiple apps are prevented from playing audible content simultaneously.

While it is true that, originally, all video+audio playback required that playback to take place in fullscreen mode. But since fullscreen mode itself was something of a singleton, that mechanism already prevented multiple video elements from playing simultaneously.

I am sympathetic to the video conferencing use case to allow multiple MediaStream-backed video elements to play simultaneously. However, IMO relaxing this policy for all video elements with no opt-in would lead to some pretty terrible behavior on unsophisticated web sites.

All that said, we’re currently investigating the idea of assigning particular AudioSessions to individual HTMLMediaElements. When multiple elements share a single AudioSession, that seems to be a good signal that those media elements can play simultaneously. Let’s figure out if that kind of more declarative, opt-in approach can solve the video conferencing use case.

-Jer

On May 13, 2025, at 5:12 AM, Yury Yarashevich <yura.yaroshevich@gmail.com> wrote:

Hi Eric Carlson, Jer Noble,

Could you please join the discussion to help assess whether the restriction on concurrent playback of multiple <video> elements with audio is still necessary on iOS?

I’ve traced the origin of this restriction back to Bug 126780 <https://bugs.webkit.org/show_bug.cgi?id=126780>, which was addressed in this commit <https://github.com/WebKit/WebKit/commit/5ae5b76ad011a7ed3bd964184b268c672a61fdcc> by Eric Carlson in January 2014. Unfortunately, the bug description doesn’t clearly explain what was meant by “Some platforms do not allow more than one <video> element to play concurrently,” so the exact rationale remains unclear.

Later, in October 2016, inline playback via <video> on iOS was introduced (blog post <https://webkit.org/blog/6784/new-video-policies-for-ios/>) through this commit <https://github.com/WebKit/WebKit/commit/99efb5e8e4efa797684804f65a4eeec119096f7c> by Jer Noble. However, the concurrent playback restriction for multiple audible videos still remains in effect on iOS.

After digging through the history, the original motivation behind this restriction is still not fully clear. One possible explanation is that, prior to the introduction of playsinline, video playback on iOS was always fullscreen - so automatically pausing other videos might have made sense to avoid background playback. But in today’s usage patterns, this seems more like a concern for the web application to manage rather than something enforced by the platform.

This restriction has repeatedly caused issues in scenarios such as WebRTC-based video conferencing, as noted in the bug tracker. While WebRTC is one example, my primary interest is in supporting concurrent playback of multiple <video> elements delivering audio/video over LL-HLS. In such cases, this restriction still applies and leads to playback interruptions - even though technically there are no hard constraints that should prevent smooth, simultaneous playback.

So I’d like to ask: if there are no longer any technical or policy reasons to enforce this restriction, could it be reconsidered and potentially lifted?

If it’s decided that this restriction is no longer needed, I’d be happy to begin working on a patch to lift it.

Thanks for your time and consideration!

On Wed, Apr 30, 2025 at 4:01 PM Yury Yarashevich < yura.yaroshevich@gmail.com> wrote:

...

Hi Jean-Yves,

Thanks for the quick and detailed response, and for the helpful links.

...

Are you referring to audible video elements requiring a user gesture for playback to start?

To clarify, I’m aware of the standard autoplay policies and user gesture requirements for unmuted playback, and I agree that those are well-documented and expected.

What I’m describing appears to be a distinct issue - not about autoplay initiation, but about ongoing playback being unexpectedly paused by the browser after it has already started, particularly when multiple unmuted <video> elements are playing concurrently. This happens even after a proper user gesture and successful play() call.

...

I’m not aware of any such restrictions.

After capturing logs and digging into the WebKit source code, I found that the restriction I’m referring to is implemented as follows:: 1. The `ConcurrentPlaybackNotPermitted` policy is enforced only on iOS, which explains why there’s no issue on macOS (I haven’t tested on iPad). Source code: https://github.com/WebKit/WebKit/blob/45d0c14d08a78058a88d16460f1fbc10946634... 2. The logic that iterates over all media elements and enforces pause is here: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/audio/Pla... 3. The implementation of the "can play concurrently" check, which effectively disallows concurrent playback of audible media unless the source is a MediaStream, is here: https://github.com/WebKit/WebKit/blob/45d0c14d08a78058a88d16460f1fbc10946634... 4. There are also tests that explicitly verify that calling play() on one video element pauses all others: a) https://github.com/WebKit/WebKit/blob/main/LayoutTests/media/video-concurren... ; b) https://github.com/WebKit/WebKit/blob/main/LayoutTests/media/video-multiple-... .

To demonstrate the issue, I’ve created a test page:

https://mstyura.github.io/webkit-issues/audible-video-concurrent-playback/in...

It contains 4 HLS video elements and two buttons: “Play All” and “Pause All.” Clicking “Play All” results in only one video playing effectively. Repeating the action multiple times shows that behavior is non-deterministic.

There’s also a “workaround mode” that starts all videos muted. In that case, all 4 videos initially play—but later WebKit sometimes detects concurrent playback (during media element time updates from HTMLMediaElement::updatePlayState https://github.com/WebKit/WebKit/blob/156848f5d55261b92551457dec064ff946ca45...) and starts pausing them again. This leads to the observed ping-pong effect between JavaScript and WebKit.

Demo source: https://github.com/mstyura/WebKit-Issues/blob/main/audible-video-concurrent-...

My question is: Is this behavior still considered desirable in 2025, especially given that developers can bypass it with more complex (but less power-efficient) workarounds like WebCodecs + <canvas> or/and VideoTrackGenerator + AudioContext.createMediaStreamDestination()?

Thanks again for your time and insights!

On Wed, Apr 30, 2025 at 2:28 PM Jean-Yves Avenard < jean-yves.avenard@apple.com> wrote:

...

On 30 Apr 2025, at 9:57 pm, Yury Yarashevich via webkit-dev < webkit-dev@lists.webkit.org> wrote:

Hi WebKit team,

I’m curious about the original rationale behind the restriction that prevents concurrent playback of multiple <video> elements. Was it primarily introduced to save battery life?

I’m not aware of any such restrictions.

Here is a test page that will literally let you play hundreds of video elements at the same time.

It works on any Apple devices: iPhone, iPad, Vision Pro, Mac .

In practice, this behavior appears to have unintended side effects. There’s a reproducible issue where playback can be started with the video muted and then immediately unmuted, effectively bypassing the restriction. However, this often results in videos being randomly paused later—sometimes very frequently—leading to a “play/pause ping-pong” between Safari/WebKit and JavaScript restarting playback. This erratic behavior may actually *increase* battery consumption, despite appearing to work smoothly from the user’s perspective.

Are you referring to audible video elements requiring a user gesture for playback to start?

This behaviour isn’t erratic and is well defined and and up to know I thought it was well understood. For an audible element to play, the user needs to first interact with the video element such as clicking on the video or its controls. This behaviour is even defined through HTML5 specifications including how you can detect if the User Agent will allow video to start autoplaying without a user gesture.

Similar policies are implemented by other user agents such as Firefox and Chrome. There’s an article on MDN on how to deal with them <mdn-social-share.d893525a4fb5fb1f67a2.png>

Autoplay guide for media and Web Audio APIs - Media technologies on the web | MDN <https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Autoplay> developer.mozilla.org <https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Autoplay> <https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Autoplay>

Here is a more WebKit-focus article Auto-Play Policy Changes for macOS <https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/> webkit.org <https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/> <apple-touch-icon-precomposed.png> <https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/> <https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/>

Here is a similar article written by the Chrome team on the same topic

<liam-neeson-will-find-a2c50097288a9.jpeg>

Autoplay policy in Chrome | Blog | Chrome for Developers <https://developer.chrome.com/blog/autoplay/> developer.chrome.com <https://developer.chrome.com/blog/autoplay/> <https://developer.chrome.com/blog/autoplay/> Here is the HTML5 specifications related to this matter

HTML Standard <https://html.spec.whatwg.org/multipage/media.html#eligible-for-autoplay> spec.whatwg.org <https://html.spec.whatwg.org/multipage/media.html#eligible-for-autoplay> <https://html.spec.whatwg.org/multipage/media.html#eligible-for-autoplay> <https://html.spec.whatwg.org/multipage/media.html#eligible-for-autoplay>

Even if this workaround is eventually blocked, developers who rely on concurrent playback (e.g., outside of WebRTC contexts) will turn to more complex solutions, such as decoding video and audio using WebCodecs or/and WebAssembly, and rendering via <canvas> and AudioContext. While technically feasible, these approaches are likely to be significantly less power-efficient than simply allowing multiple <video> elements to play concurrently. Another similarly inefficient workaround would be to synthesize a MediaStream using the VideoTrackGenerator API and AudioContext.createMediaStreamDestination().

Lastly, another issue is that creating a MediaElementSource from a <video> element and routing its audio through a shared AudioContext also does not disable the playback restriction—whereas it *is* disabled when the <video> element itself is muted. This feels inconsistent and may point to a separate bug.

Could you please clarify the motivation behind this restriction, and whether there are any plans to revisit or improve its behavior?

I believe I answered this question above, and through the various links provided.

Cheers JY