6

A webpage containing video element with src attribute set to a Data URI containing a video file does not play the video in Safari on iOS 15.

Inspecting the device/simulator with Safari Dev Tools suggests the browser repeatedly issues requests with Range: bytes N-M headers, reading the whole video file multiple times, leading to huge memory consumption and eventual failure to start the playback.

If the video is small enough and does manage to start, the playback appears sluggish and takes enormous time to even start.

Is there any workaround for this problem?

P.S. Keeping the video in Data URI is inherent to the task I am trying to solve, so please refrain from suggesting to keep the video file as a separate resource :)

Anton
  • 2,483
  • 2
  • 23
  • 35
  • **(1)** No Safari for my OS Windows, but from [quick research](https://www.google.com/search?q=%22ios+15%22+video+playback+issue) it seems like there's some issues/bugs in iOS 15. See if some mentioned workarounds are helpful to you. It's not obvious how you've setup your page code (_eg:_ using any extra frameworks?) which might affect playback. – VC.One Oct 18 '21 at 06:22
  • **(2)** So you have the video data in base64 format? What happens if you skip Data URI way and just keep the B64 data in a String variable, then decode B64 into some bufferArray (blob) that you `load` into the video tag using `createObjectURL`? eg: `var vidBytes = new Uint8Array( atob( yourB64string) );` then to make usable as video src it is `path = (window.URL || window.webkitURL).createObjectURL( vidBytes );` and finally `load()` the video element with `your_vid_element_byID.setAttribute("src", path); your_vid_element_byID.load();` – VC.One Oct 18 '21 at 06:36
  • @VC.One this is exactly what we are doing now, it seems to be working better, however, we still see repetitive requests and the playback _appears to be_ a bit laggy. – Anton Oct 19 '21 at 07:49

1 Answers1

2

The webkit bug tracking this issue is here (looking at the user names I suspect you reported it over there too): https://bugs.webkit.org/show_bug.cgi?id=232076

The workaround we used was to use a Service Worker to deliver the video data via a "normal" URL, even though the data was still provided directly from Javascript. I posted some sample code for the service worker side on that WebKit bug.

The service worker does need to be hosted as a separate resource, and with the same https origin, so I know that won't be a solution for every use case (including yours Anton).

Unfortunately I don't think there are any other workarounds, it just looks like yet another Safari regression. iOS 15 has been particularly bad for that. I almost expect it to be a slide in the iOS 16 keynote... "Safari is now 25% faster, plays back videos for 30% more hours, and now has 35% more bugs than ever before!"

tangobravo
  • 898
  • 10
  • 24
  • 1
    Yeah that's me over there in bugs.webkit.org :) anyway, let's see, maybe someone found some crazy combination of something that makes this bug go away – Anton Oct 24 '21 at 16:32