New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 792632 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug



Sign in to add a comment

On High Sierra, detached mode (FSLP) may start wildly flickering

Project Member Reported by sdy@chromium.org, Dec 6 2017

Issue description

Chrome Version: 65.0.3286.0
OS: macOS 10.13.2 — **10.13+ only!**

What steps will reproduce the problem?
(1) Open the attached thinvideo.mp4 or thinvideo.webm (they're the same).
(2) Make the video fullscreen.
(3) Hit play.

What is the expected result?
The controls hide after a few seconds.

What happens instead?
The controls hide after a few seconds, and the video's horizontal alignment starts changing wildly. You can set the video to loop if you want it to keep happening.

(I think this is at least partly a macOS bug, will post a comment shortly with more info.)
 
thinvideo.mp4
802 KB View Download
thinvideo.webm
192 KB View Download
detached_flicker.mp4
3.6 MB View Download

Comment 1 by sdy@chromium.org, Dec 6 2017

Attached a full demo video.

You can reproduce this on crbug if you hit "view" to open it in a new tab. Making it fullscreen inline doesn't work because the video has blue borders in fullscreen (probably just a monorail CSS issue).

Also, it also only seems to happen if:

1. A dual GPU MBP is running on integrated graphics.
2. The system is in native 2x resolution, which isn't the default for new installs — you have to set your resolution to the middle option in System Preferences > Displays, which is labeled "Looks like 1440x900".
3. You're running 10.13+.

I haven't tried this on other Mac hardware but have tried it on two different MBPs.
detached_flicker_demo.mp4
8.1 MB View Download

Comment 2 by sdy@chromium.org, Dec 6 2017

Status: Started (was: Assigned)
CL with more detail about what triggers this:
https://chromium-review.googlesource.com/c/chromium/src/+/812114
Hey Sidney! thanks for working on this fix. Just a heads up that this is marked as RB-Beta and we are promoting to Beta on Thursday. Next M64 Dev is also scheduled for tomorrow. Is fix in #2 already in Canary? Is it ready to be merged to M64 branch yet?
Cc: shrike@chromium.org
sdy@, do we have any latest update on this? If it's not a 'Beta' blocker please feel free to change the priority as we are targeting M64 Beta release tomorrow.

Thank you!
Project Member

Comment 5 by bugdroid1@chromium.org, Dec 13 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/30999dd424c2e897fbe53e606189f55d83b98a4f

commit 30999dd424c2e897fbe53e606189f55d83b98a4f
Author: Sidney San Martín <sdy@chromium.org>
Date: Wed Dec 13 22:49:46 2017

Work around a High Sierra fullscreen bug by getting rid of fractional pixel differences in video aspect ratio.

When a 720x1280 video is made fullscreen on a 1440x900 DIP screen, this
happens to its dimensions:

    720x1280 -[scale]-> 506.25x900 -[integer]-> 506x900

The AVSampleBufferDisplayLayer used for video content layers has its
videoGravity set to AVLayerVideoGravityResize, which doesn't preserve
aspect ratio. Under certain circumstances, the small difference in
aspect ratio triggers a macOS bug with low power detachment where the
video's x position changes rapidly each frame as long as the window
stays in detached mode. I've been able to make it happen if:

- The machine is a MacBook Pro.
- The OS is at least 10.13.
- The display is set to native 2x resolution ("Looks like 1440x900").
- The machine is running on integrated graphics if it has dual graphics.

A recording of the issue is attached to the crbug.

This workaround is sort of terrible and maybe Apple can suggest a better
one: when a video layer's aspect ratio can be made to exactly match the
source aspect ratio by adding a fractional pixel to either dimension, do
so (making sure to keep the video centered).

Bug:  792632 
Change-Id: I8b149606cbccb6033c36d3ad400f7a63a4d462ce
Reviewed-on: https://chromium-review.googlesource.com/812114
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523924}
[modify] https://crrev.com/30999dd424c2e897fbe53e606189f55d83b98a4f/ui/accelerated_widget_mac/ca_layer_tree_unittest_mac.mm
[modify] https://crrev.com/30999dd424c2e897fbe53e606189f55d83b98a4f/ui/accelerated_widget_mac/ca_renderer_layer_tree.h
[modify] https://crrev.com/30999dd424c2e897fbe53e606189f55d83b98a4f/ui/accelerated_widget_mac/ca_renderer_layer_tree.mm

Comment 6 by sdy@chromium.org, Dec 13 2017

Labels: Merge-Request-64
Status: Fixed (was: Started)
Project Member

Comment 7 by sheriffbot@chromium.org, Dec 14 2017

Labels: -Merge-Request-64 Hotlist-Merge-Approved Merge-Approved-64
Your change meets the bar and is auto-approved for M64. Please go ahead and merge the CL to branch 3282 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
sdy@, Please merge the above fix to M64 branch: 3282 when you get a chance. Also i'm not able to replicate this issue on reported chrome version# for OS X 10.13.x and wondering this might be specific to 2017 GPU config (which test team doesn't have at the moment)?

Thank you!

Comment 9 by sdy@chromium.org, Dec 16 2017

manoranjanr@: Merging now. It's possible that it's GPU-specific, but I'm not sure. What's the machine you're testing with? It's also important that resolution is set to "Looks like 1440x900" and a screen recording isn't in progress.

If you have Quartz Debug (or can download it from the Apple Developer site, it's part of Additional Tools for Xcode), try running it and turning on "Show Detached Regions" in the Tools menu. The screen should be tinted rad, and the tint should disappear or change to blue or green when the video is playing fullscreen. If that doesn't happen, something is stopping the window from becoming detached (a screen recording, the system is running on the discrete GPU, the video controls are visible, etc.). If the tint changes but the flicker doesn't happen, then either the resolution isn't right, or it only happens with the 2017 hardware (which would be interesting to know).
Project Member

Comment 10 by bugdroid1@chromium.org, Dec 16 2017

Labels: -merge-approved-64 merge-merged-3282
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cc59dcdeb9807c6c16f08527651ded12acf5d289

commit cc59dcdeb9807c6c16f08527651ded12acf5d289
Author: Sidney San Martín <sdy@chromium.org>
Date: Sat Dec 16 20:01:34 2017

Work around a High Sierra fullscreen bug by getting rid of fractional pixel differences in video aspect ratio.

When a 720x1280 video is made fullscreen on a 1440x900 DIP screen, this
happens to its dimensions:

    720x1280 -[scale]-> 506.25x900 -[integer]-> 506x900

The AVSampleBufferDisplayLayer used for video content layers has its
videoGravity set to AVLayerVideoGravityResize, which doesn't preserve
aspect ratio. Under certain circumstances, the small difference in
aspect ratio triggers a macOS bug with low power detachment where the
video's x position changes rapidly each frame as long as the window
stays in detached mode. I've been able to make it happen if:

- The machine is a MacBook Pro.
- The OS is at least 10.13.
- The display is set to native 2x resolution ("Looks like 1440x900").
- The machine is running on integrated graphics if it has dual graphics.

A recording of the issue is attached to the crbug.

This workaround is sort of terrible and maybe Apple can suggest a better
one: when a video layer's aspect ratio can be made to exactly match the
source aspect ratio by adding a fractional pixel to either dimension, do
so (making sure to keep the video centered).

TBR=sdy@chromium.org

(cherry picked from commit 30999dd424c2e897fbe53e606189f55d83b98a4f)

Bug:  792632 
Change-Id: I8b149606cbccb6033c36d3ad400f7a63a4d462ce
Reviewed-on: https://chromium-review.googlesource.com/812114
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#523924}
Reviewed-on: https://chromium-review.googlesource.com/830899
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#253}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/cc59dcdeb9807c6c16f08527651ded12acf5d289/ui/accelerated_widget_mac/ca_layer_tree_unittest_mac.mm
[modify] https://crrev.com/cc59dcdeb9807c6c16f08527651ded12acf5d289/ui/accelerated_widget_mac/ca_renderer_layer_tree.h
[modify] https://crrev.com/cc59dcdeb9807c6c16f08527651ded12acf5d289/ui/accelerated_widget_mac/ca_renderer_layer_tree.mm

Labels: TE-Verified-65.0.3299.0
sdy@, thank you for providing all debugging info. I spent sometime today to figure it out the actual issue and able to see some difference before and after fix (It's not exactly same as the reported one, however there is a renderer glitch while full screen entering into detaching mode).

Bad# 64.0.3274.0
Good# Latest Build with the above fix (> #65.0.3293.0)

PS: Recently got my personal 2017 MBP, i'll try to see if i can replicate the same issue there.

Thank you!

Sign in to add a comment