1510464 - Media playback broken in GVE

Status: RESOLVED FIXED

Description

[Eugen Sawin [:esawin]]

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

Comment 1

[James Willcox (:snorp) ([e-mail]) (he/him)]

I suspect this is due to bug 1486659.

Comment 2

[John Lin [:jhlin][:jolin]]

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.

Comment 3

[Eugen Sawin [:esawin]]

(In reply to James Willcox (:snorp) ([e-mail]) 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.

Comment 4

[Eugen Sawin [:esawin]]

Backing out bug 1486659 seems to fix video playback.

Comment 5

[John Lin [:jhlin][:jolin]]

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.

Comment 6

[Eugen Sawin [: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.

Comment 7

[Chris Peterson [:cpeterson]]

P1 because this is a regression. This bug is temporarily disabled because regressing bug 1486659 was backed out.

Comment 8

[John Lin [:jhlin][:jolin]]

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.

Comment 9

[Chris Peterson [:cpeterson]]

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

Comment 10

[John Lin [:jhlin][:jolin]]

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