I concur with danrossi. I provided some critical insight, testing and workarounds to users and developers on this exact bug report, and was publicly shunned by one of apple's own developers. Completely and utterly disrespectful and unprofessional, considering that the bug has not be fixed or assigned in the 2 YEARS since its been filed, and very little response otherwise on a status how/when it will be fixed.
VR is exploding right now. Many of us companies and developers who have created VR technologies for web and apps are being held back because Apple has not yet fully embraced compliancy with the way CORS should work. All other major browsers now fully support CORS correctly for webgl video textures (FF, Chrome, Edge, Opera), which I have personally tested and verified. However, with Apple Safari failing to support CORS correctly for webgl and holding 50% of the marketshare, we cannot develop a unified solution for our technologies. Our clients need solutions and we can't provide any, or any timeline for that matter.
Bottom line, here is how I understand the issue with webgl video texturees as it stands: To paint a video frame on to the webgl texture, typically the video needs to be on the same domain as the renderer itself (e.g. www.example.com). However, in reality this concept is completely dated. No one serves video or images for that matter off their webservers anymore. We use CDNs and other media services (e.g. cdn.example.com). Because the sub-domain does not match the parent domain, this causes Safari to crap out. Typically the way around this is to set the header on the cdn to: "Access-Control-Allow-Origin: http://www.example.com" and then in the <video> tag setting video.crossOrigin="anonymous" and that should work. In fact it does for all major browsers listed above, except Safari on OSX and iOS.
Now, from what I understand, there is a back and forth between webkit and AVFoundation on who's to blame for the lack of support. Supposedly, AVFoundation is what loads the video and does not support CORS, so it ends up tainting the cavas. There doesn't seem to be proper support or communication between webkit and AVFoundation to handle initial and subsequent video handling to make this work. From an engineering standpoint, this should have been handled by the webkit browser and not AVFoundation. They are two completely separate systems.
So we're all stuck right now until Apple decides to make VR and WebGL a priority and get this resolved. I would really appreciate some response from Apple on this, and a timeline on when it will be fixed. Otherwise, a workaround would be in order. The use of a reverse proxy is just not feasible for a scaled solution.
Thanks for your attention to this matter.
Here is the radar for the Apple bug. They closed it as duplicate but there is no means to comment on someone elses bug ticket.
Basically IOS/Iphone/Safari is completely crippled for WebVR. So is Android Chrome I'm afraid. It is having WebGL canvas rendering issues also and I've spent months trying to get them replicating it to fix it !
VR on mobile is a shambles right now which is the whole point of the phone glasses right ? hahah.
You have Firefox on Android working and that is it but they fixed an orientation bug in Nightly. So Firefox nightly LOL.
hopefully you got that last reply, this dodgy forum software had troubles posting the links.
This was my last reply. I might have to setup another ticket to tackle the Inline Video problem on Iphone rendering WebGL useless ? " The Webkit people are still stuffing around as per that ticket. WebVR is still very much broken on IOS/Iphone with CDN delivered video unless there is intervention and a quick release. We also have the problem with intentional disabling of inline video playback , breaking the display of any webGL canvas and rendering WebVR useless. Iphone NEEDS to play INLINE. Do I need to provide another ticket for this ? IOS/Iphone cannot market WebVR at the very least until these issues are fixed. "
Here is that webkit bug ticket just in case https://bugs.webkit.org/show_bug.cgi?id=125157#c2
I don't seem to get notifications for responses either.
You can see my efforts here. It has VR toggling for Safari to turn on a reverse proxy url of the same video hosted on cloudfront. You are right it sounds like all this ancient stuff was developed without CDN delivery in mind. The use of a proxy is not production worthy. I do the same technique here for the video capture feature but one frame is a bit different to HD video playback of a 360 stitched video ! https://flowplayer.electroteque.org/vr360/fp6 Absolute disgrace. They should just give up with VR until both these issues are intervened and fixed especially Iphone inline video playback. The inline video hacks for Iphone is beyond stupid. I mean they are trying to draw frame by frame to 2D canvas not WebGL and constantly seeking and uptime times. That would never work with Dash well. The audio has to play in a second audio tag and drops frames and becomes out of sync. So from research there is no way to get WebGL displaying even with the proxy hack on Iphone.
I am developing a navite IOS application with an embedded UIWebView displaying THREE.js scene (loaded from locally bundled html/js sources) where I am using video textures and would greatly appreciate being able to stream the videos.
Yes this is also a major blocker for web delivery of 360 video.
I agree with the rest of the board. I can successfully play a progressive mp4, but with HLS it is a no-go. This is a serious blocker, and not just for 360 video delivery, but for any kind of WebGL that has assets from CDNs, which for most content providers is the norm, and not the exception. It's nice to see that Apple has been consistent over the years in ignoring this issue, and stifling innovation in their ecosystem.
The real question is, is the Safari project dead? And if so, why force other browsers (such as Chrome) to wrap Safari on iOS, instead of giving people with iOS devices real freedom in choosing their technology? A solid answer on this will help those of us trying to develop and innovate real solutions, so we can in turn let our audience/stakeholders know that Apple has deprecated Safari and internet browsing in general in favor for (fill in the blank).
Could you elaborate on how you are able to sucessfully play a progressive mp4 with webGL?
I am passing my video to a gl.texImage2D function to render and getting the security error due to the video url being on a different CDN/domain.
How is progressive play working any different? I would love to avoid a solution that involves a reverse-proxy which is what I have read many developers are doing just to serve content to ios.