DelightVR video playback failing in android
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox79 | --- | unaffected |
firefox80 | --- | disabled |
firefox81 | --- | disabled |
People
(Reporter: mortimergoro, Assigned: jnicol, NeedInfo)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
STR with remote WebGL enabled:
- Open https://delight-vr.com/video-player-module/
- Click the Play button on the Surf video at the bottom of the page
- Black screen while playing the video in WebXR
I saw these erros in logcat
2020-07-24 19:02:15.937 24842-24912/org.mozilla.vrbrowser.dev I/AdrenoGLES-0: Driver Path : /system/vendor/lib64/egl/libGLESv2_adreno.so
2020-07-24 19:02:16.541 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.541 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.541 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.541 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.541 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.541 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.541 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.542 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.542 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.542 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.542 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.542 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.542 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.542 24842-24912/org.mozilla.vrbrowser.dev E/libEGL: call to OpenGL ES API with no current context (logged once per thread)
2020-07-24 19:02:16.595 24842-24901/org.mozilla.vrbrowser.dev I/Gecko: Can't find symbol 'eglDupNativeFenceFDANDROID'.
Updated•4 years ago
|
Reporter | ||
Comment 1•4 years ago
|
||
Three.js VR video playback also shows a black screen: https://github.com/MozillaReality/FirefoxReality/issues/3727
Comment 2•4 years ago
|
||
Set release status flags based on info from the regressing bug 1607940
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 3•4 years ago
|
||
The severity field is not set for this bug.
:jgilbert, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Firefox reality is no longer supported
https://blog.mozilla.org/en/mozilla/news/update-on-firefox-reality/
Comment 5•2 years ago
|
||
This also applies to FF/Android
Comment 6•2 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)
This also applies to FF/Android
Indeed, thanks Emilio for bringing this back to life. Also note that, contrary to what is said in the 2nd comment by Imanol, it happens also with in-process WebGL. In particular, in Wolvic, we have to disable the GPU process because WebXR is broken in that case. We have the very same issues that FF/Android with those videos.
Related to this, https://github.com/playcanvas/engine/issues/4204. Also similar info in this other issue https://github.com/Igalia/wolvic/issues/370
Assignee | ||
Comment 7•2 years ago
|
||
I hadn't seen this before. The issue is that the texture format is GL_RGB
, meaning we prevent the fast-path blit here, meaning we attempt to take the slow path here. But the slow path fails on Android because we do not implement GetAsSourceSurface()
here.
See bug 1769747 for falling off the fast path on other platforms too due to the RGB format, though the slow fallback works so it's just a performance issue on other platforms.
Implementing GetAsSourceSurface()
would fix this, albeit with poor performance. And would also fix the similar canvas2d issue (bug 1526207). But as the comment alludes to, doing so would mean we could no longer render the video element. Perhaps that would be preferable.
Kelsey, my reading of the spec is that GL_RGB
is color-renderable on GLES 3.0+ and desktop GL 3.0+. (And on GLES 2 we could perhaps check for GL_OES_rgb8_rgba8
, though I'm not 100% if that is enough). Would a patch be accepted for allowing the blit to an RGB texture in those cases? (But not the other formats you expressed concerns about in bug 1769747)
Assignee | ||
Comment 8•2 years ago
|
||
On devices where GL_RGB is a color-renderable format, allow blitting
to GL_RGB textures to implement texture upload. This allows us to stay
on the fast-path when the source data is video and the target texture
format is GL_RGB. In fact, on Android this makes it work at all, as
the slow-path is not actually implemented.
Updated•2 years ago
|
Comment 9•2 years ago
|
||
(In reply to Jamie Nicol [:jnicol] from comment #8)
Created attachment 9312852 [details]
Bug 1655101 - Allow blit to GL_RGB texture for webgl texture uploads. r?jgilbertOn devices where GL_RGB is a color-renderable format, allow blitting
to GL_RGB textures to implement texture upload. This allows us to stay
on the fast-path when the source data is video and the target texture
format is GL_RGB. In fact, on Android this makes it work at all, as
the slow-path is not actually implemented.
I can confirm that this makes Wolvic really happy :-). Video is now properly rendered in DelightXR sites
Comment 10•2 years ago
|
||
Note that there are still some issues. For example when playing a video in https://mindvr.com, sometimes it happens that the video is not rendered and console spits many WebGL warnings like the following ones
XRWebGLLayer doesn't support no alpha value. Alpha will be enabled. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:52:30120
XRWebGLLayer doesn't support separate depth or stencil buffers. They will be enabled together. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:52:30120
WebGL warning: clear: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:17:27463
WebGL warning: drawElementsInstanced: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:18:7855
WebGL warning: drawElementsInstanced: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:18:7855
WebGL warning: clear: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:17:27463
WebGL warning: drawElementsInstanced: Framebuffer must be complete. 2 dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:18:7855
WebGL warning: clear: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:17:27463
WebGL warning: drawElementsInstanced: Framebuffer must be complete. 2 dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:18:7855
WebGL warning: clear: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:17:27463
WebGL warning: drawElementsInstanced: Framebuffer must be complete. 2 dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:18:7855
WebGL warning: clear: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:17:27463
WebGL warning: drawElementsInstanced: Framebuffer must be complete. 2 dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:18:7855
WebGL warning: clear: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:17:27463
WebGL warning: drawElementsInstanced: Framebuffer must be complete. 2 dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:18:7855
WebGL warning: clear: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:17:27463
WebGL warning: drawElementsInstanced: Framebuffer must be complete. 2 dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:18:7855
WebGL warning: clear: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:17:27463
WebGL warning: drawElementsInstanced: Framebuffer must be complete. 2 dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:18:7855
WebGL warning: clear: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:17:27463
WebGL warning: drawElementsInstanced: Framebuffer must be complete. 2 dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:18:7855
WebGL warning: clear: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:17:27463
WebGL warning: drawElementsInstanced: Framebuffer must be complete. 2 dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:18:7855
WebGL warning: clear: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:17:27463
WebGL warning: drawElementsInstanced: Framebuffer must be complete. dl8-c7f4d76df2a59bf0469e2a020e65ed8fcc50640e.js:18:7855
After reporting 32, no further warnings will be reported for this WebGL context.
``
Assignee | ||
Comment 11•2 years ago
|
||
Can you please file a separate bug about that? Thanks.
Comment 12•2 years ago
|
||
(In reply to Jamie Nicol [:jnicol] from comment #11)
Can you please file a separate bug about that? Thanks.
Sure, done
Comment 14•2 years ago
|
||
:jnicol: (In reply to Jamie Nicol [:jnicol] from comment #8)
Created attachment 9312852 [details]
Bug 1655101 - Allow blit to GL_RGB texture for webgl texture uploads. r?jgilbertOn devices where GL_RGB is a color-renderable format, allow blitting
to GL_RGB textures to implement texture upload. This allows us to stay
on the fast-path when the source data is video and the target texture
format is GL_RGB. In fact, on Android this makes it work at all, as
the slow-path is not actually implemented.
There is another issue in the patch. During a single execution, the first time I try to play any delightxr powered video, it isn't played (in immersive mode). I mean, I can hear audio after a while, but video is not played. However it does always work for any video after that first attempt. Does it make sense? Rings any bell?
Assignee | ||
Comment 15•2 years ago
|
||
No idea, sorry. Sounds like it's a separate bug rather than an issue with the above patch, though?
Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 16•1 year ago
|
||
Is this going to land?
Description
•