Closed Bug 1510464 Opened 2 years ago Closed 2 years ago

Media playback broken in GVE

Categories

(GeckoView :: General, defect, P1)

51 Branch
All
Android
defect

Tracking

(geckoview64 unaffected, firefox63 unaffected, firefox64 unaffected, firefox65 disabled, firefox66 fixed)

RESOLVED FIXED
Tracking Status
geckoview64 --- unaffected
firefox63 --- unaffected
firefox64 --- unaffected
firefox65 --- disabled
firefox66 --- fixed

People

(Reporter: esawin, Assigned: jhlin)

References

Details

(Keywords: regression)

Video playback is broken in latest GVE builds. I see repeated error log entries including:

I Gecko   : [Parent 13723, Compositor] WARNING: failed to lock front buffer: file /home/esawin/dev/g/gfx/layers/composite/ImageHost.cpp, line 204
I suspect this is due to bug 1486659.
Depends on: 1486659
The patch shouldn't affect usual video playback as long as nothing blits the texture in the child process. Probably some gfx behavior that I missed or misunderstood.
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #1)
> I suspect this is due to bug 1486659.

I think it should block in this case.
I can also confirm rbarker's error log locally.
Blocks: 1486659
No longer depends on: 1486659
Backing out bug 1486659 seems to fix video playback.
Eugen, do you have reliable STR for this? I've been playing video on YT but so far only managed to reproduce the problem once.
Assignee: nobody → jolin
Flags: needinfo?(esawin)
(In reply to John Lin [:jhlin][:jolin] from comment #5)
> Eugen, do you have reliable STR for this? I've been playing video on YT but
> so far only managed to reproduce the problem once.

Loading any videos on imgur.com or 9gag.com failed for me.

STR:
1. Open http://me73.com/media
2. Push play on the H.264/MP4 (Video) video

Expected: video plays.
Actual: I think it was resizing the surface but no video playback, it stayed white.
Flags: needinfo?(esawin)
P1 because this is a regression. This bug is temporarily disabled because regressing bug 1486659 was backed out.
Finally reproduced it and found the cause: the texture handles in parent and child processes will be out of sync after child process recreation, and compositor will get the wrong (used) handle. To address this, I'll update the patches in bug 1486659 to make the texture in the child process uses the same handle as the original texture to avoid the situation.
Product: Firefox for Android → GeckoView

(In reply to John Lin [:jhlin][:jolin] from comment #8)

Finally reproduced it and found the cause: the texture handles in parent and
child processes will be out of sync after child process recreation, and
compositor will get the wrong (used) handle. To address this, I'll update
the patches in bug 1486659 to make the texture in the child process uses the
same handle as the original texture to avoid the situation.

John, is this bug still a problem? Or did your patches in bug 1486659 fix this issue?

Flags: needinfo?(jolin)

So sorry for forgetting to update this bug. Yes, the patch in bug 1486659 fixed this issue.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(jolin)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.