Cannot show this 360 video https://vimeo.com/channels/360vr/355120249 at Android
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
People
(Reporter: liwedol, Assigned: sotaro)
References
Details
(Whiteboard: [qa-triaged] )
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Steps to reproduce:
Open Firefox (last release version)
Actual results:
Cannot show 360 video in https://vimeo.com/channels/360vr/355120249 or https://vimeo.com/channels/360vr/331446244
Audio work well. But video are all black. Full screen has the same result
However, this video has no problem https://vimeo.com/channels/360vr/662186655
Not all 360 video in vimeo.com have issue
Expected results:
Play https://vimeo.com/channels/360vr/355120249 video well
Comment 1•1 year ago
|
||
Hello,
I was able to reproduce the issue on the latest Nightly build (117.0a1) from 12th of July 2023. The issue is also reproducible in Beta (116.0b4) and RC (115.2.0).
Devices used for testing: Google Pixel 7 Pro (Android 14), Motorola Moto G9 plus (Android 11).
Thank you!
Updated•1 year ago
|
Updated•1 year ago
|
Comment 2•1 year ago
|
||
Changing the component to Core-Audio/Video to get more input related to the potential reason(s) for this bug, if possible.
Comment 3•1 year ago
|
||
I can reproduce this on my Pixel 6. Here is the profiled result, I can see Firefox decoded video successfully and we did send those video frames to the compositor (some drop frames though) Not sure if this is media or graphic issue, John, Sotaro, would y'all mind to help me take a look on this bug? Thank you so much.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 4•1 year ago
|
||
With the STR, ClientWebGLContext::TexImage() used fallback path. Since format is not RGBA in BlitPreventReason(). This part is related to Bug 1708006.
And SurfaceTextureImage does not support GetAsSourceSurface().
I try to use nightly build (https://downzen.com/en/android/firefox-preview/versions/?page=24) to narrow down issue
Find it's regress issue
affected 210114-1700 - Nightly 210114 17:00 (Build #2015787337) AC: 71.0.20210114143040, 96d4bc2e3 GV: 86.0a1-20210113100240 AS: 67.2.0
unaffected: 210113-1701 - Nightly 210113 17:01 (Build #2015787145) AC: 71.0.20210113143107, 6e0ffb55e GV: 86.0a1-20210113100240 AS: 67.2.0
Hope this can speed up issue analysis
Assignee | ||
Updated•1 year ago
|
Comment 6•1 year ago
|
||
The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.
Assignee | ||
Comment 7•1 year ago
•
|
||
There were other issues besides Comment 4.
There were occasional cases that video was used both with WebRender and WebGL. SurfaceTexture could be attached to only one GL context. Then when SurfaceTexture was used by WebRender, surfaceTexture->AttachToGLContext() in GLBlitHelper::Blit() was failed.
To address the problem, Bug 1649110 needs to be addressed. But it is low priority now.
Assignee | ||
Comment 8•1 year ago
|
||
Other web sites normally does not have the problem of using video both with WebRender and WebGL, web site also seemed to have a problem.
(In reply to Sotaro Ikeda [:sotaro] from comment #8)
Other web sites normally does not have the problem of using video both with WebRender and WebGL, web site also seemed to have a problem.
Hi sotaro,
Some questions:
- "web site also seemed to have a problem."
I can play the same video in firefox Desktop version(Win/Linux) . Why this issue only happen in Android version? - "video was used both with WebRender and WebGL"
Could you describe this more?
Thank you,
Assignee | ||
Comment 10•1 year ago
•
|
||
(In reply to Liwe Pan from comment #9)
(In reply to Sotaro Ikeda [:sotaro] from comment #8)
Other web sites normally does not have the problem of using video both with WebRender and WebGL, web site also seemed to have a problem.
Hi sotaro,
Some questions:
- "web site also seemed to have a problem."
I can play the same video in firefox Desktop version(Win/Linux) . Why this issue only happen in Android version?
Win and Linux, video data could be consumed by both WebGL(upload to WebGL texture) and WebRender(compositing). Android SurfaceTexture has a limitation that it is consumed by only one GL context. Then if video data is consumed by both WebGL and WebRender(compositing), only one of either could consume the video data. The limitation could be removed by using AImageReader and AHardwareBuffer (Bug 1649110).
- "video was used both with WebRender and WebGL"
Could you describe this more?
There were cases that video data is used for rendering at WebRender(upload to WebGL texture) and WebGL(compositing). WebRender and WebGL exist in different threads(RenderThread and CanvasRenderThread) and use different GL contexts.
-
RenderAndroidSurfaceTextureHost::Lock() is used for WebRender rendering.
-
GLBlitHelper::Blit() is used for uploading video data to WebGL texture.
Normally, when video data is consumed by WebGL, the video data is presented only via WebGL.
WebGL architexture is like the following.
Assignee | ||
Comment 11•1 year ago
|
||
Part of the problem might be addressed in either Bug 1845781 or Bug 1655101.
Comment 12•1 year ago
|
||
Sotaro, is it appropriate that this remain an S2?
Assignee | ||
Comment 13•1 year ago
|
||
S3 looks appropriate. Bug 1655101 is trying to land a fix.
Comment 14•10 months ago
|
||
The videos appear working on 123+ after Bug 1655101 was fixed. This might be able to be marked as a duplicate.
Comment 15•10 months ago
|
||
Thanks!
Description
•