Tested the issue in Android and able to reproduce the issue. Similar behavior is observed since Chrome #60.0.3108.0.

Steps Followed:
1. Launched the Chrome Browser.
2. Navigated to the URL: https://www.google.co.kr/amp/amp.timeinc.net/nme/news/music/alice-in-chains-pay-tribute-to-layne-staley-on-what-would-have-been-his-50th-birthday-2129081%3fsource=dam
3. Play the video in full screen mode.
4. Tap on the device Home button.
5. Video is played in Picture-in-picture mode.
6. Observed that flickering is observed when video changes from full screen mode to Picture-in-picture mode.

Chrome versions tested:
60.0.3108.0, 62.0.3202.84 (Stable), 65.0.3284.0(Canary)

OS:
Android 8.0.0

Android Devices:
Pixel XL Build/OPM1.170623

This seems to be a Non-Regression issue as same behavior is seen since M60. Untriaged for further input's on this issue.

Please navigate to below link for log's and video--
go/chrome-androidlogs/791435

Note: This issue is not observed in Desktop.

+peconn@ who worked on PictureInPictureController

The title of the bug is a bit misleading. The PIP window is flickering when animating. We had a look at this in the past and couldn't find the source of the problem.

@mlamouri, 
Your comment in Comment 4 looks as if you can't fix it.
Am I correct?

I do not know a solution but it doesn't mean it's not possible to fix ;)

the squashing effect is happening because the window is changing aspect ratio as android animates it to the bottom.  it's unclear to me that we'll be able to do to much about this, since we can't relayout the video that fast.

i suppose that we could (somehow) remove the gutters / adjust them to be the final aspect ratio when the transition starts (if we can figure out when that is -- i'm not sure how the notifications from android are ordered).  however, that would result in squashing at the beginning of the animation.

plus, that might well need a blink relayout, which might take too long anyway.  hopefully for fullscreen, it's not so bad.

The PiP animation takes a rectangle from which to start the shrinking window and calculate the aspect ratio.

I calculate this rectangle using WebContents::GetFullscreenVideoSize() which is populated by logic added https://chromium.googlesource.com/chromium/src/+/257951527deb304ec71750102753c4166c265e1f.

This means that before the PiP animation starts the aspect ratio is that of the screen and then throughout the PiP animation, the aspect ratio is that of the video.

Does this make any of this easier?

>the aspect ratio is that of the screen

do you mean the aspect ratio of the webcontents?  i meant the output surface.  the output surface seems to go from taller than it is wide to wider than it is tall, based on the video.

does the blink relayout that gets rid of the gutters also start at the beginning of the pip animation?

also, is the surface still showing new output from chrome while the animation is in progress?  i can't tell from the video if the video frame is changing or if android is animating a screen shot.

if it's the latter, maybe we need to delay pip until we get the first frame from the compositor with the new aspect ratio.  it'll still squash a bit, but at least the gutters won't be there.  should be less noticeable.

Dear Chrome team, kindly pinging.

I'm talking about the aspect ratio of the video, not including the black bars (which I assume is the WebContents). The final PiP window (so output surface) should be sized to have an equal aspect ratio to the WebContents).

I believe the surface is updating throughout the animation.

Dear Chrome team, kindly pinging.