Created attachment 407441 [details]
Image comparing iOS 14 Beta 6 to iOS 13.6.1
Overview: As recently as iOS 14 Developer Beta 6, Safari no longer renders textures from HLS streams in WebGL. This is critical for streaming video within popular WebGL frameworks such as three.js, A-Frame, babylon.js etc.
*Examples to Reproduce Issue*
three.js example: Visit https://8w.8thwall.app/hls-threejs on an iOS/iPadOS device running iOS 14 Developer Beta 6 or later. The rotating cube has a video texture applied from an HLS stream. The video in the top left corner is using the same HLS stream but rendering on top of the page outside WebGL.
babylon.js example: Visit https://www.babylonjs-playground.com/#9FSDC7#49 on iOS/iPadOS device running iOS 14 Developer Beta 6 or later. The plane has a video texture applied from an HLS stream.
Both examples work correctly on:
iOS 13.6.1 Safari (iPhone 11 Pro Max)
iPadOS 13.6.1 Safari (iPad Pro 11", 2018)
Safari Technology Preview Release 112 [Safari 14.0, WebKit 15610.1.25.5.1] (MacBook Pro 15-inch, 2017; 10.15.6)
However, both examples fail to produce a texture on iOS 14 Developer Beta 6 Safari (iPhone XR).
Here is an unlisted video comparing iOS 14 Beta 6 to iOS 13.6.1: https://youtu.be/jzjoHtADnmU
I can confirm that I also see this issue on iOS 14 Beta 6. Interestingly, this issue can also be seen on iOS 13.6 simulator but not on device.
Here's a fairly simple WebGL sample I've put together that has the issue: https://bit.ly/2EF2a6b
Thank you for the report! Could you please clarify if this worked in previous betas?
I believe this was working prior to iOS 14 Developer Beta 4.
Created attachment 408839 [details]
Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE
I also was able to reproduce this issue on iOS 14 Beta 6 with multiple WebGL applications that use HLS streaming
I tested the same projects on iOS 13.6 and they functioned properly.
We have many live projects which utilize HLS video playback within a WebGL context. These projects will break when iOS 14 goes fully live, so it would be very helpful if this issue were patched before that point.
I'm just compiling this for iOS hardware to confirm, but I think this is good to go.
Huh. Weirdly this works for me without the patch on ToT.
It's a shame we don't have a test.
But does not work with the patch applied! I might have screwed up but I'll need to investigate this.
This was using https://8w.8thwall.app/hls-threejs.
Created attachment 409291 [details]
Comment on attachment 409291 [details]
We should be able to make a test case for this. There are some HLS tests in http/tests/media/hls.
email@example.com does not have committer permissions according to https://svn.webkit.org/repository/webkit/trunk/Tools/Scripts/webkitpy/common/config/contributors.json.
Rejecting attachment 409291 [details] from commit queue.
> We should be able to make a test case for this. There are some HLS tests in http/tests/media/hls.
We don't know if we need add a test that would trigger any of the bugs in here.
Primarily the problem isn't whether there is a test case.
* _All_ gpu video image conversions failed with simulator, yet no test failed. I did file a bug about this.
* SW video conversion codepath failed on simulator and on device. I did file a bug about that. When this gets worked on, we need to come back here and understand why the sw codepath failed and use the content here to add a test case if existing video/hls tests wouldn't trigger the problem.
Further more, even if simulator tests would've worked, all video tests would have failed on device on gpu codepath. I think we have a bug about improving this situation too.
Committed r267520: <https://trac.webkit.org/changeset/267520>
All reviewed patches have been landed. Closing bug and clearing flags on attachment 409291 [details].
Great diagnosis and fix Kimmo. Filed https://bugs.chromium.org/p/angleproject/issues/detail?id=5104 to track upstreaming of the ANGLE changes.
*** Bug 216250 has been marked as a duplicate of this bug. ***
Good to hear this fix also addresses bug 216250. Do you happen to know if it's possible this fix will make it into iOS 14.2? Thanks.
(In reply to Dustin Kerstein from comment #20)
> Good to hear this fix also addresses bug 216250. Do you happen to know if
> it's possible this fix will make it into iOS 14.2? Thanks.
Apple does not comment on when a particular fix will be released to the public.
(In reply to Chris Dumez from comment #21)
> Apple does not comment on when a particular fix will be released to the
Ok, thanks for the info. Do you think it'd be possible to increase the importance of this bug to P1? Based on the rubric described on https://webkit.org/bug-prioritization it seems the behavior described in 215908 and 216250 would qualify as P1.
Hello. Faced with same issue on pixi.js. Could somebody clarify please, fix is still not available in the latest iOS 14.0.1, right? From what I can see examples from babylon and tree.js are not working as well, so, I'm wondering why is it marked as resolved and fixed?
FYI, I believe this fix has been pulled into iOS 14.2 beta 3 (18B5072f). Just tested in a 1st generation iPad Pro and the https://8w.8thwall.app/hls-threejs test works correctly, and the performance noted in bug 216250 has significantly improved.