+sandersd to determine whether this would best be done in the video stack

The last frame should still be available to the compositor, so I'm surprised to see that there is a black frame shown here.

I have test ToT on Linux and Mac OS; they are exhibiting the expected behavior of preserving the old frame.

We're still marking DXVA-decoded frames as DECODER_OWNS_FRAME, but WMPI is ignoring that as of commit 2438e873e9f0e2788cf20ab89dcc6d8f6a45224d. If it's not working, something has probably gone wrong with the GLImages since then.

I haven't seen a black frame in a local testing, I think we can safely remove it with a stale last rendered frame in the description.

Alex had an idea of changing the look of the frame (by shadowing it or something) so that the user has a visual clue that Chrome is aware it doesn't have a new frame yet so it doesn't look like a bug.

Knowing when exactly the new frame is shown to the user is hard (IIUC even the video stack doesn't know the precise time as it delegates to the compositor that delegates to the gpu process) so we might want to do it in the video stack by outputting the modified last rendered frame to the compositor when the optimization is turned on so it's naturally painted over by the first new frame when the video is foregrounded.

Yah - I'm not sure how any of these would feel in practice, but I was hoping to find ways to avoid the black flash which I think my eyes would read as jank. 

There are a few example frame ideas in this thread: 
https://groups.google.com/a/google.com/d/msg/chrome-ui-review/cnrdc7yHKrY/6EsiQgp1AwAJ

there is no black frame present. The preserved frame is present for a while(the accurate time varies) then video proceed. This is more obvious in high resolution video.

Ok, we shouldn't focus on the non-existent black frame when foregrounded issue here.

When the video goes to the foreground, the last rendered video frame will be visible and stale until the decoder is reinitialized and outputs the new video frame and it's composited and rendered on screen.

It may look to the user like something's wrong, esp. because the audio will continue. So we should somehow indicate it's a feature, not a bug.

Overlaying the stale frame with something (like 50% transparent black) sounds good to me except for the cases when the actual frame is dark already so the overlay won't be easily seen by the user.

Modifying the frame directly from WMPI is problematic due to threading, but we can set flags on the compositing layer quite easily. We should be able to get most CSS-like effects easily, but we should be careful since overlay-only content would be broken. (Black frame is probably fine for those cases though, they are very specific.)

I suppose the standard UI is a spinner of some sort; ContentVideoView on Android even has a specific spinner feature.

Some sort of effect seems fine, but not be worth the trouble. I'd wait to see if there's any outcry. Ideally we're choosing cutoff thresholds that prevent any issues that last more than half a second or so.

I agree, let's  wait for the data first and see what type of timelines we are dealing with. At that point, we can make a call on what effect we do, if any.

Did data ever come in for this?