Not sure if this is a compositor issue or GPU issue.

CCing dalecurtis@ for triaging.

Issue still reproducible: Tested on Pit/Minnie device with Chrome OS 9438.0.0, 59.0.3064.0 (dev)

Seems a compositor issue to me.

songsuk:

Can you try a normal Youtube video and check whether you see similar issue?

Then back to Netflix, after the playback started, could you please open a new tab, go to chrome://media-internals, find the netflix player, and check what "video_decoder" it's using? Usually you'll see "GpuVideoDecoder" or "DecryptingVideoDecoder".

If it's using "GpuVideoDecoder", could you please go to "about://flags" and disable "hardware-accelerated video decode", restart Chrome, and see whether you can still repro? That will tell us whether this is related to hardware decoding path.

I'm not able to see the issue from youtube video. 
>> Can you try a normal Youtube video and check whether you see similar issue?

"video_decoder" is "DecryptingVideoDecoder"
>>  Then back to Netflix, after the playback started,...

DecryptingVideoDecoder is equivalent to a normal software decoder.

Are you in dev-mode or normal mode? If in normal mode, can you go to chrome://settings/contentExceptions#protectedContent to make sure netflix.com is allowed? If not, you can remove that entry and try Netflix again, where if you see a prompt, please click "Allow". After that, please check again in chrome://media-internals to see which video decoder is used. And please check whether you can still repro this issue.

Still see the issue after removing Browser data & ...protectedContent. And, video decoder is "DecryptingVideoDecoder"
>> Are you in dev-mode or normal mode?...


Please see the GPU info of the device, gpu.zip.

Deleted: gpu.zip 9.0 KB

gpu.zip 9.0 KB Download

The device is in dev mode, so it's always using DecryptingVideoDecoder, which is essentially a software decoder. I can't see how the decoder can cause flicking. I still feel this is related to compositing/gpu.

Able to reproduce the issue on Chrome 58.0.3029.66/CrOS 9344.40 - Kitty, Skate

For comment#5, 
when I changed the device to normal mode,  "video_decoder" becomes "GpuVideoDecoder" and able to reproduce the issue. 

When setting the "hardware-accelerated video decode" flag to "disable", I'm still seeing the issue. And "video_decoder" is "FFmpegVideoDecoder".

 

When you are using GpuVideoDecoder, the decoder really is just a clear decoder and doesn't do any decryption logic. Again, it's probably related to how the JS application interacts with compositing logic.

Since this issue is on CrOS only, add CrOS label.
xhwang@, I assign it to you for now in order to remove it from untriaged plate. Please feel free to re-assign appropriately.

jbauman: Do you know who's the best person to look into this from the compositor side?

I can reproduce the issue. It happens on all CrOS devices I tried even without entering full screen mode, just playing a video and clicking "Back to browse" seems to do it (it's more noticeable coming from fullscreen, but that might be since the animation from fullscreen to window triggers more page flips).

If I try to do the same on linux I get a different issue, that might be correlated: the last frame of the video is still visible with some gray quads on the corners.

Looking at the trace it seems that after we click "Back to browse" VideoPlayback ends immediately, soon after a lot of ClientNativePixmapDmaBuf are destroyed in the renderer on the media thread, then the renderer is busy with v8 (not producing any new frame) for 3 seconds while the flashing happens. Javascript code seems to be triggered by renderSession-/browse that ends up calling reactRender.

My guess would be we have a problem with the lifetime of the dmabufs we use for the videoframes. When VideoPlayback ends (VideoFrameCompositor::OnRendererStateUpdate with false gets called) we might end up destroying the video frame before we're done with compositing. This is made worse by the fact that the rendering of the next frame takes so long since the renderer is stuck for seconds, while the browser tries to display the old quads with the old videoframe resources that might have been destroyed at that point.

The decoder used seems to be DecryptingVideoDecoder, would it be possible to test the same scenario with another decoder (VpxVideoDecoder maybe) and check if it's possible to reproduce the issue?

In this case DecryptingVideoDecoder is not special since it's just a software decoder using shared memory to hold decoded VideoFrames. I agree it could happen with other software decoders (e.g. VpxVideoDecoder) based on the analysis above.

Note that the VideoFrame is ref-counted, the compositor probably should keep it alive if some old quads still needs to display it. 

+dalecurtis for thoughts around this.

Hmm, StopRendering() results in a SetNeedsRedraw() call and in the case where the frame is actually destroyed. For actual textures they should still hold refs? qiangchen@ recently fixed a similar issue here 

https://bugs.chromium.org/p/chromium/issues/detail?id=681006#c35

+danakj, qiangchen for commentary. I'm OOO soon, so won't be able to look into this.

> If I try to do the same on linux I get a different issue, that might be correlated: the last frame of the video is still visible with some gray quads on the corners.

Corner quads usually means something is transparent/translucent above the area bounded by those corners, but telling the compositor its opaque, so it skips drawing everything in that space except the corners.

Perhaps the texture backing the VideoFrame is being destroyed before the compositor makes a texture from the mailbox. The VideoFrame itself doesn't keep the texture alive. The producer of the mailbox needs to keep it alive until the release callback is called. If the texture is gone, then maybe we can't draw it and you see what's behind it (the corner quads) instead.

=>sandersd to triage while I'm OOO.

The compositor is using AcquireLockAndCurrentFrame() to hold both a ref and ostensibly a frame lock which is the time during which the compositor is using the frame, so it should still be alive.

I'm unsure if there's an alternate path by which the dmabufs disappear though.

yiningc@: Is this issue still reproducible?

it is not observed anymore.