Closed Bug 1842735 Opened 1 year ago Closed 10 months ago

Cannot show this 360 video https://vimeo.com/channels/360vr/355120249 at Android

Categories

(Core :: Graphics: CanvasWebGL, defect)

Firefox 117
All
Android
defect

Tracking

()

RESOLVED DUPLICATE of bug 1655101
Tracking Status
firefox115 --- affected
firefox116 --- affected
firefox117 --- affected

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

Summary: Cannot how this 360 video https://vimeo.com/channels/360vr/355120249 at Android → Cannot show this 360 video https://vimeo.com/channels/360vr/355120249 at Android
See Also: → 1841948

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!

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [qa-triaged]

Changing the component to Core-Audio/Video to get more input related to the potential reason(s) for this bug, if possible.

Severity: S3 → --
Component: Browser Engine → Audio/Video
Product: Fenix → Core

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.

Severity: -- → S2
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(jolin)
Priority: -- → P3
Assignee: nobody → sotaro.ikeda.g
Flags: needinfo?(sotaro.ikeda.g)

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().

See Also: → 1708006

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

Component: Audio/Video → Graphics: CanvasWebGL

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.

Priority: P3 → --
See Also: → 1845781

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.

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.

See Also: → 1655101

(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:

  1. "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?
  2. "video was used both with WebRender and WebGL"
    Could you describe this more?

Thank you,

(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:

  1. "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).

  1. "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.

Normally, when video data is consumed by WebGL, the video data is presented only via WebGL.

WebGL architexture is like the following.

Part of the problem might be addressed in either Bug 1845781 or Bug 1655101.

Sotaro, is it appropriate that this remain an S2?

Flags: needinfo?(sotaro.ikeda.g)

S3 looks appropriate. Bug 1655101 is trying to land a fix.

Severity: S2 → S3
Flags: needinfo?(sotaro.ikeda.g)

The videos appear working on 123+ after Bug 1655101 was fixed. This might be able to be marked as a duplicate.

Flags: needinfo?(jgilbert)

Thanks!

Status: NEW → RESOLVED
Closed: 10 months ago
Duplicate of bug: 1655101
Flags: needinfo?(jolin)
Flags: needinfo?(jgilbert)
Resolution: --- → DUPLICATE
Duplicate of this bug: 1709726
You need to log in before you can comment on or make changes to this bug.