I suspect this may be an issue with compositing. Adding some folks.

Might want to print the time between BeginFrame calls to see if it's accidentally getting in the throttled state.

Assigning to samans to triage/investigate this.  My suspicion is that this is top level viz / beginframe scheduling sorts of things.

This seems related to  issue 874676  and issue 874680 that we've had a ton of discussion on already.  It sounds like this is not fixed yet.

Something that fbeaufort@ shared over chat but may not be clear here: it's not related to VideoSurfaceLayer directly. The same video with VSL enabled played inline works fine. For some reasons, when sent to PIP the stutters happen.

FWIW, I can't repro on my Windows laptop.

I haven't started investigating but this does not look like a compositing bug.  Issue 874676  was so subtle that I couldn't see the dropped frames. However, based on #0 this issue is a lot worse. Given that the culprit affects visibility, plus comment #6, it is more likely that the client is voluntarily giving up BeginFrames when it is still visible.

Note that it is not reproducible with Picture-in-Picture for Android apps.

I've just built latest Chrome OS on Linux and reverted my change.
I was still able to reproduce this issue.

sadrul@ I wonder if https://chromium-review.googlesource.com/c/chromium/src/+/1320199 might be causing these kind of issues. WDYT? Do you have other ideas?

If the PIP window is visible (which it sounds like it is), then that CL should not be causing this. Some questions to help debug:
 1) is this a relatively recent issue, in the last few days, or has this been happening for longer (say since ~dec)?
 2) can I repro on a chromeos build on linux? When I go to https://googlechrome.github.io/samples/picture-in-picture/ (from OP), the 'picture in picture' button is disabled, and I can't even play the video. Do I need to turn on some gn flag and/or runtime-flags to make things work?
 3) does this repro on linux?

1) Since Chrome OS has not been updated during holidays, I'd say ~dec.
2) I can repro on Chrome OS build on Linux. You may want to build with proprietary_codecs=true gn args to be able to play h264 content. Regarding Picture-in-Picture, you will need #enable-picture-in-picture and #enable-surfaces-for-videos flags
3) I can't.

This is a bit weird but after running a long bisect, the tool told me that the culprit CL was https://chromiumdash.appspot.com/commit/3ddd534adc33cada51560d862d209f8a3abb1451

It does match the timeline but it is the CL that *reverts* single process mash. I tried on top of tree to enable single process mash and indeed it seems to fix the problem. The fact that the bug is fixed with single process mash will bisection very hard unless we can get a better window (Francois?).

In the meantime, jamescook@, samans@ and sadrul@, do you have any idea why this bug would be fixed with single process mash? Can this help pin point the problem?

Thank you Mounir! I've was able to reproduce your findings locally on my Chromebook with Chrome 73.0.3673.0 (canary)

By setting the experimental flag "single-process-mash" to Enabled, Picture-in-Picture video play back does NOT stutter anymore.
By setting the experimental flag "single-process-mash" to Disabled, Picture-in-Picture video play back does stutter.

I'm not sure sadly how I can help further though.

That's interesting. Can you share a trace with and without SingleProcessMash?

Are you talking about chrome://tracing or something else?

Yes just chrome://tracing with the relevant categories (media, viz, etc.)

As I'm not familiar, can you tell me which categories are relevant to a SingleProcessMash issue?
- media
- viz
- more?

The following categories would be useful:

media
blink
cc
gpu
toplevel
viz
benchmark
input
latency

Chrome OS Canary 73.0.3673.0 has currently some issues with the File Manager that doesn't want to open. In other words, I can't save any file to my disk from chrome://tracing.

Unless someone has a workaround, I'll wait for next update to share my trace ;(

Can you maybe switch to a more stable channel like dev? Not sure if there is any guarantee this would be fixed by the next canary release.

sky, who would be a good owner for this?

Is it possible SingleProcessMash *breaks* something (like occlusion computation) that makes this bug go away?

FYI SingleProcessMash was enabled twice on ToT in the last couple weeks (ranges inclusive):
1) r619508 to r620102 (never released to users because Chrome OS did not pick up new chrome), and
2) r621156 to r622232, OS 11556.0.0 to 11567.0.0, and Chrome 73.0.3667 to 3668 (did go to canary)

Was this features only turned on when SingleProcessMash was turned on? James gives the versions SPM was enabled in comment 24.

I believe Ria recently turned on viz hit testing. I'm not sure what the scope for that was (meaning which releases) and I don't know if that impacts this bug, but mention it for completeness.

If this was working fine without SingleProcessMash at some point, then I recommend trying to bisect again, but adding --disable-features=SingleProcessMash.

I'm not a good owner for this at it doesn't seem that mash negatively impacted this. Getting a trace as suggested by Sadrul seems the best bet.

Unfortunately, I can't get a trace either as chrome://tracing seems to be broken on ToT. I will attempt another bisect though.

MultiProcessMash seems to disable SurfaceLayer, should the same thing be done for SingleProcessMash?
https://cs.chromium.org/chromium/src/content/renderer/media/media_factory.cc?l=152
https://cs.chromium.org/chromium/src/ui/base/ui_base_features.cc?l=138

In this case, the problem happens when SingleProcessMash is disabled.

Is MPMash enabled then?

Re: MPMash. No. There are three modes: "classic" (the default on ToT), "single-process mash" (we're attempting to ship in M-74), and "multi-process mash" (long term plan, no milestone yet).

Better terminology might be "window service" and "out-of-process window service" but we're stuck with the current names.