Youtube videos may freeze when tab has no focus with WebRender

RESOLVED FIXED in Firefox 59

Status

()

defect
P1
normal
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: lorenzofersteam, Assigned: vliu)

Tracking

(Blocks 1 bug, {nightly-community})

Trunk
mozilla59
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox57 unaffected, firefox58 unaffected, firefox59 fixed)

Details

(Whiteboard: [wr-reserve][video-related])

Attachments

(2 attachments)

I'm on ArchLinux 64bit, kernel linux-covolunablu-gaming, and Firefox 59 Nightly
I have  webrender active with the following options from about:config:
turn on gfx.webrender.enabled
turn on gfx.webrender.blob-images
turn on layers.acceleration.force-enabled

Reproduction:
Open a tab with youtube playing  a video.
Open other tabs and navigate.
After a while (it may take also some minutes to trigger this issue, and I was not able to find a specific timing) switch back to the youtube tab.
(In some cases I was only able to repro this when letting youtube change video off-focus).

I'm using this playlist  if it can interest: https://www.youtube.com/watch?v=YNvdphVMEJU&index=166&list=PL_jlNRrayn_e_8mXk_evSxp2ogPnUi2Eg

Expected behaviour:
Video still play normally, when switching to youtube tab.

Actual behaviour:
The video is frozen, but the audio is still playing well.
If the autoplay is active and youtube change video when without focus, when switching back to the youtube tab show the same blocked frame over.
If the video change when I have focus on the youtube tab, it return to normality.
Component: Bookmarks & History → Untriaged
Component: Untriaged → Graphics: WebRender
Product: Firefox → Core
Whiteboard: [wr-mvp] [triage]
Version: unspecified → Trunk
Whiteboard: [wr-mvp] [triage] → [wr-reserve]
See Also: → 1424747
Can we reproduce this on other platforms?
Priority: P3 → P1
I asked to a friend that use nightly too and doesn't seem to happen on windows
The issue I saw on my today's mac build is:

1. Played the recommended link below and make sure video/audio worked normally.

   https://www.youtube.com/watch?v=YNvdphVMEJU&index=166&list=PL_jlNRrayn_e_8mXk_evSxp2ogPnUi2Eg

2. Switched to other tab to surf internet.
3. When audio started playing next song, switched back to youtube tab to observe.

The video got frozen, but the audio is still playing well. Switched to full screen could make the frozen video back to normal. If I set gfx.webrender.enabled to false, the issue disappeared.
Assignee: nobody → sotaro.ikeda.g
After talked to Sotaro on irc, I would take this bug to work into it.
Assignee: sotaro.ikeda.g → vliu
Whiteboard: [wr-reserve] → [wr-reserve][video-related]
(In reply to Vincent Liu[:vliu] from comment #3)
> The issue I saw on my today's mac build is:
> 
> 1. Played the recommended link below and make sure video/audio worked
> normally.
> 
>   
> https://www.youtube.com/
> watch?v=YNvdphVMEJU&index=166&list=PL_jlNRrayn_e_8mXk_evSxp2ogPnUi2Eg
> 
> 2. Switched to other tab to surf internet.
> 3. When audio started playing next song, switched back to youtube tab to
> observe.
> 
> The video got frozen, but the audio is still playing well. Switched to full
> screen could make the frozen video back to normal. If I set
> gfx.webrender.enabled to false, the issue disappeared.

The above issue happens between two video files played in youtube. When the first song started to play, [1] was called to create AsyncImage WR Command associating with a ImageContainer to add a pipeline. In MediaDecoder thread, [2] was called to update video data.
The thing is, 

a. About 5~8 seconds after the first song started, there was another AsyncImage WR Command was created building another pipeline with the same ImageContainer. I am not sure what it is purpose for. Guess there was another video/image other than the youtube file we cared.
b. When the second song started to play under no focus, I didn't see [1] was called to build up pipeline for the second song. In MediaDecoder thread, [2] was keep running with a new ImageContainer instead of the first song used.

From above, It might have issue in Framebuilder phase. I will keep investigating from the current info I found.

[1]: https://searchfox.org/mozilla-central/rev/f42618c99dcb522fb674221acfbc68c2d92e7936/gfx/layers/wr/WebRenderUserData.cpp#176
[2]: https://searchfox.org/mozilla-central/rev/f42618c99dcb522fb674221acfbc68c2d92e7936/gfx/layers/ImageContainer.cpp#326
(In reply to Vincent Liu[:vliu] from comment #5)

> From above, It might have issue in Framebuilder phase. I will keep
> investigating from the current info I found.
> 

It should be CommandBuilder phase in EndTransaction.
Comment on attachment 8940968 [details] [diff] [review]
update mPipelineId for different image container.

Review of attachment 8940968 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/layers/wr/WebRenderUserData.cpp
@@ +185,5 @@
>                                                        bool aIsBackfaceVisible)
>  {
>    MOZ_ASSERT(aContainer->IsAsync());
> +
> +  if (!mPipelineId || mContainer != aContainer) {

When we move to next video(we change to the next image container), we might still try to use the original pipeline. Then, the original pipeline is still associated to the old image container.
Hi Sotaro,

I think Jerry pointed out the root cause based on Comment 5. Thanks for his great help. I would change a little bit for the patch to make it clear. Could you please have a review for the patch? Really thanks.
Attachment #8941305 - Flags: review?(sotaro.ikeda.g)
Comment on attachment 8941305 [details] [diff] [review]
0001-Bug-1418999-Update-PipelineId-to-associate-the-lates.patch

Looks good!
Attachment #8941305 - Flags: review?(sotaro.ikeda.g) → review+
Pushed by vliu@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a4e1e729857b
Update PipelineId to associate the latest ImageContainer. r=sotaro
https://hg.mozilla.org/mozilla-central/rev/a4e1e729857b
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.