What video exactly? What build of Chrome?

We won't suspend videos that have keyframe distance longer than 10s by default and for some other reasons. However, it could be a bug since the video is suspended the first time.

There was an issue like this for disabling video tracks (that was fixed) because of resetting the keyframe distance average on each suspend/resume (then it takes a few keyframes to calculate the new average in order to suspend video). Hm, maybe pausing resets the average by recreating the stream traits object or something?

watk@, can you take a look the questions on c#1?

 Sorry for the vague bug report. Still repros at ToT today (abca979183940d03e4852ddb8b84ce3dfe363e24). Video: buck720p30_h264noaudio.mp4 on http://storage.googleapis.com/watk/v

Repro steps as in original report.

Key frames are at seconds: 0, 4, 5, 10, 15, 16, 20, 25, 27.

Talking to Chris and trying to repro:
- one really needs to wait until the player is suspended (on desktop it has to be paused for 15s)
- then switch the tab back to the video and away fast

Seems like the pipeline does lose the stats about the keyframe distance so doesn't suspend the video. I'll look into updating the paused/disabled decoding state when the stats are there but IIRC the pipeline doesn't get an event when the stats update...

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

commit eecec52c10dffeebd35d273a8999388f98089b80
Author: avayvod <avayvod@chromium.org>
Date: Tue Feb 14 01:25:09 2017

[Media, Video] Update WMPI when the pipeline gets a new average keyframe distance.

BUG= 688618 
TEST=manually followed the repro steps from the bug

Review-Url: https://codereview.chromium.org/2688383006
Cr-Commit-Position: refs/heads/master@{#450186}

[modify] https://crrev.com/eecec52c10dffeebd35d273a8999388f98089b80/media/base/mock_filters.h
[modify] https://crrev.com/eecec52c10dffeebd35d273a8999388f98089b80/media/base/pipeline.h
[modify] https://crrev.com/eecec52c10dffeebd35d273a8999388f98089b80/media/base/pipeline_impl.cc
[modify] https://crrev.com/eecec52c10dffeebd35d273a8999388f98089b80/media/base/pipeline_impl.h
[modify] https://crrev.com/eecec52c10dffeebd35d273a8999388f98089b80/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/eecec52c10dffeebd35d273a8999388f98089b80/media/blink/webmediaplayer_impl.h
[modify] https://crrev.com/eecec52c10dffeebd35d273a8999388f98089b80/media/filters/pipeline_controller_unittest.cc
[modify] https://crrev.com/eecec52c10dffeebd35d273a8999388f98089b80/media/test/pipeline_integration_test_base.h

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

If possible, could you please merge your CL into M57 branch 2987 before 5 PM PT today, Wednesday (02/15/17). Thank you.

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

commit 7837cbd3bb82ec56e15ca5f041ad59bf7d88a85d
Author: Anton Vayvod <avayvod@google.com>
Date: Wed Feb 15 19:32:03 2017

[Video] Fix keyframe distance average calculations.

Found a few problems with the way the keyframe distance is calculated and
passed from the decoder to WMPI:
1. as soon as the video decoder is stopped we reset the average - meaning we
will stop considering optimizing playback for the video
2. we have to wait for more than 4 keyframes to start optimizing video
playback, this can take seconds
3. audio decoder resets the average to 0 in pipeline's shared state

BUG= 688618 
TEST=Manual

Review-Url: https://codereview.chromium.org/2643103002
Cr-Commit-Position: refs/heads/master@{#444955}
(cherry picked from commit 8127a839bf18e618aaf7a8cad95440c6cd3f9f76)

Review-Url: https://codereview.chromium.org/2701513002 .
Cr-Commit-Position: refs/branch-heads/2987@{#526}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/7837cbd3bb82ec56e15ca5f041ad59bf7d88a85d/media/base/pipeline_impl.cc
[modify] https://crrev.com/7837cbd3bb82ec56e15ca5f041ad59bf7d88a85d/media/base/pipeline_status.h
[modify] https://crrev.com/7837cbd3bb82ec56e15ca5f041ad59bf7d88a85d/media/filters/decoder_stream_traits.cc

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

commit 6c5650f651734955ee5daa6a7c5e025cdca6e054
Author: Anton Vayvod <avayvod@google.com>
Date: Wed Feb 15 20:13:17 2017

[Media, Video] Update WMPI when the pipeline gets a new average keyframe distance.

BUG= 688618 
TEST=manually followed the repro steps from the bug

Review-Url: https://codereview.chromium.org/2688383006
Cr-Commit-Position: refs/heads/master@{#450186}
(cherry picked from commit eecec52c10dffeebd35d273a8999388f98089b80)

Review-Url: https://codereview.chromium.org/2697123002 .
Cr-Commit-Position: refs/branch-heads/2987@{#529}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/6c5650f651734955ee5daa6a7c5e025cdca6e054/media/base/mock_filters.h
[modify] https://crrev.com/6c5650f651734955ee5daa6a7c5e025cdca6e054/media/base/pipeline.h
[modify] https://crrev.com/6c5650f651734955ee5daa6a7c5e025cdca6e054/media/base/pipeline_impl.cc
[modify] https://crrev.com/6c5650f651734955ee5daa6a7c5e025cdca6e054/media/base/pipeline_impl.h
[modify] https://crrev.com/6c5650f651734955ee5daa6a7c5e025cdca6e054/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/6c5650f651734955ee5daa6a7c5e025cdca6e054/media/blink/webmediaplayer_impl.h
[modify] https://crrev.com/6c5650f651734955ee5daa6a7c5e025cdca6e054/media/filters/pipeline_controller_unittest.cc
[modify] https://crrev.com/6c5650f651734955ee5daa6a7c5e025cdca6e054/media/test/pipeline_integration_test_base.h

avayvod@/watk@: Followed below steps to test this on Ubuntu 14.04 using 57.0.2987.74 and was unable to decide whether its working fine or not.
1) Open Chrome
2) Open the video and play
3) Opened another tab and waited at least 15 seconds
4) Switched back to the video tab the tab was paused
5) Switched tabs with in 1 seconds again(making the video background and foreground)

Could you please take a look into the screencast and let us know if its fine or anything is missed here.

Deleted: 688618_Feb_22.ogv 10.9 MB

	688618_Feb_22.ogv 10.9 MB View Download

Hi,

Have you enabled "Background video track optimization" in chrome://flags? You don't have the flag in chrome://version.

Instead of using a timer you could open chrome://media-internals, click on the player and wait until it changes state to kSuspended after the PAUSE event.

Then quickly switch to the video and back. chrome://media-internals should show the PLAY event when the video was foregrounded and then a PAUSE event a few seconds later after it was backgrounded.

 avayvod@ I don't see any flag by the name "Background video track optimization" in Chrome://flags on Chrome version 57.0.2987.74. All I see is the flag "Optimize background video playback." 

Please let us know as we are holding the M57 Beta launch on this. 

verified the issue on Chrome version 57.0.2987.74 on Linux(ubuntu 14.04Lts)

Steps followed :
1. Install and launch chrome 
2. enable "Optimize background video playback" from Chrome://flags
3. Visit "http://storage.googleapis.com/watk/v" and select and play "Video: buck720p30_h264noaudio.mp4"
4. Open another tab and visit "chrome://media-internals"  and select Player(default page where you land)
5. After few min observe that Event : Changes from PLAY to PAUSED and then we see pipeline_state : Ksuspended" 

Make sure whenever the Video tab is in foreground we see the even as PLAY and in background Paused and Ksuspended.

avayvod@/pbommana@ : Thanks for updating and verifying it.