I'm not sure what is happening...
chrome://media-internals/ doesn't show any logs that indicates that video track was disabled due to background optimizations.

 Issue 921912  has been merged into this issue.

mlamouri, running Chrome Canary with --disable-features=BackgroundSrcVideoTrackOptimization did not help. See https://bugs.chromium.org/p/chromium/issues/detail?id=663999#c36

I still can't repro on Windows. +liberato@ in case of that rings any bell.

fbeaufort@, do you think you could bisect to find which Canary had the regression first?

+tmathmeyer@ as it's suspiciously close to the landing of background optim enabled by default even if I can't see why it would be Mac-only.

Note that I can reproduce on YouTube as well, which uses MSE. This comforts me in the fact that BackgroundSrcVideoTrackOptimization enabled by default is not the culprit.

As found in https://bugs.chromium.org/p/chromium/issues/detail?id=921912,

    This is a regression issue broken in M-73:
    Good Build : 73.0.3668.0 (Revision : 621860)
    Bad Build : 73.0.3669.0 (Revision : 622247)

+dalecurtis.

doesn't ring any bells that would be mac only.

dale is modifying how page visibility interacts with cc::surfaces (yesterday).  does behavior change @ToT?

either way, the questions are:

 - does VideoFrameSubmitter get a StopRendering call when the tab is hidden?
 - does VideoFrameSubmitter::UpdateSubmissionState get called, and if so is it saying 'true' or 'false' to SetNeedsBeginFrame?

if we get a StopRendering, then it's something on the pipeline side shutting down.  otherwise, it might be a state issue in VFS.

Able to reproduce the issue on the reported chrome 73.0.3670.0,latest chrome 73.0.3672.0 using Mac 10.14.0. Issue not seen on latest chrome stable 71.0.3578.98 and chrome beta 72.0.3626.53.Below is the bisect information for same.
NOTE: Issue not observed on Windows and Ubuntu.

Bisect Info:
================
Good Build : 73.0.3668.0 
Bad Build : 73.0.3669.0

CHANGELOG URL:
You are probably looking for a change made after 622001 (known good), but no later than 622002 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/9c14227e998c49fe237f2a4eec796aab02faeda8..4ccb547b7ff46b30a7a8fcc59e2ecc8f1094fef4
Change-Id: If3788ce89f55e22af59bc69a6a52cd2a3309c518
Reviewed-on: https://chromium-review.googlesource.com/c/1400803

François Beaufort:Please confirm the issue and help in re-assigning if it is not related to your change.
Adding RBS label for M-73 feel free to change it if not required. 

Thanks..!

dalecurtis@, can you, liberato@ or someone else who has a mac build handy can confirm that https://chromium.googlesource.com/chromium/src/+/4ccb547b7ff46b30a7a8fcc59e2ecc8f1094fef4 is actually the culprit here and maybe do some basic investigation? If our instinct is correct, there may be some weird thing happening here that is far away from Picture-in-Picture (we don't have anything mac-specific).

Bisect is pretty clear and I don't think the linked CL is correct. It's not enough to just have force submit to have PiP work, letting the tab go in the background like this will lower its priority and cause all sorts of other throttling behavior (that's not even media specific) to kick in. If it has audio some of that may be avoided, but a muted video would probably start to struggle in bg with that patch in place.

fbeaufort@ can you explain a bit more about why you made that change? I don't have a mac today, so can't test this. Do you know if this happens if you use --disable-gpu ? What about with disabling gpu memory buffers:
https://cs.chromium.org/chromium/src/content/public/common/content_switches.cc?l=145

+ccameron/sdy in case there's some mac specific background optimization I'm unaware of. 

Mac has a pathway that marks NSViews that are hidden as being hidden via
https://cs.chromium.org/chromium/src/content/browser/web_contents/web_contents_view_cocoa.mm?rcl=6d6d3adf6fe76581e388245c073640fa7d73596b&l=283

This is overridden in WebContentsImpl via capturer_count_
https://cs.chromium.org/chromium/src/content/browser/web_contents/web_contents_impl.cc?rcl=2433d79ee698e74733485dc93917ed539e14dd46&l=1446

Does PiP use capturer_count_?

dalecurtis@ I was able to reproduce issue on Google Chrome Canary 73.0.3674.0 with --disable-gpu and --disable-gpu-memory-buffer-compositor-resources flags.

We've made this change because we want to the blink PictureInPictureController to react to page visibility changes. See https://chromium-review.googlesource.com/c/chromium/src/+/1380533 and https://bugs.chromium.org/p/chromium/issues/detail?id=917303.

ccameron@ We don't use the capturer_count_ as we want to notify blink that page is hidden, while Picture-in-Picture window is visible.

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

commit 0e27cee0958bb04cd14067c4a2b1eeca4b8b9f64
Author: François Beaufort <beaufort.francois@gmail.com>
Date: Fri Jan 18 13:21:35 2019

Don't throttle hidden tab in Picture-in-Picture

This CL makes sure a tab is not throttled when hidden if it has a
Picture-in-Picture video. Renderer is still informed though that the tab
was hidden.

Bug: 917303,  921460 ,  921478 
Change-Id: Ia0c5c4841b48d8f62f8ddbc12653522e0b59f6b5
Reviewed-on: https://chromium-review.googlesource.com/c/1419841
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: François Beaufort <beaufort.francois@gmail.com>
Cr-Commit-Position: refs/heads/master@{#624096}
[modify] https://crrev.com/0e27cee0958bb04cd14067c4a2b1eeca4b8b9f64/content/browser/web_contents/web_contents_impl.cc

https://chromium-review.googlesource.com/c/1419841 fixes this issue in latest Chromium build on macOS 73.0.3677. See #17.

Able to reproduce the issue on chrome reported version# 73.0.3670.0(Build without fix)
Verified the fix on Mac 10.14 on Chrome version #73.0.3679.0
Attaching screen cast for reference.
Observed "Picture-in-Picture video playback continues on switching the tabs"
Hence, the fix is working as expected.
Adding the verified label.

hanks!

Deleted: 921478.mp4 6.1 MB

	921478.mp4 6.1 MB View Download