Open Bug 1655101 Opened 4 years ago Updated 1 year ago

DelightVR video playback failing in android

Categories

(Core :: Graphics: CanvasWebGL, defect)

All
Android
defect

Tracking

()

REOPENED
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)

STR with remote WebGL enabled:

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'.
Regressed by: 1607940
Has Regression Range: --- → yes

Three.js VR video playback also shows a black screen: https://github.com/MozillaReality/FirefoxReality/issues/3727

Set release status flags based on info from the regressing bug 1607940

The severity field is not set for this bug.
:jgilbert, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jgilbert)
Severity: -- → S4
Flags: needinfo?(jgilbert)
No longer blocks: remote-webgl
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE

This also applies to FF/Android

Severity: S4 → --
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Summary: DelightVR video playback failing in Firefox Reality → DelightVR video playback failing in android

(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

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)

Flags: needinfo?(jgilbert)

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.

Assignee: nobody → 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?jgilbert

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.

I can confirm that this makes Wolvic really happy :-). Video is now properly rendered in DelightXR sites

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.
``

Can you please file a separate bug about that? Thanks.

Flags: needinfo?(svillar)

(In reply to Jamie Nicol [:jnicol] from comment #11)

Can you please file a separate bug about that? Thanks.

Sure, done

Flags: needinfo?(svillar)
Duplicate of this bug: 1794750

: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?jgilbert

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.

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?

No idea, sorry. Sounds like it's a separate bug rather than an issue with the above patch, though?

Is this going to land?

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: