Thanks for the report, we've enabled this feature by default for MSE now, but it definitely should not be breaking the stream. I'll take a look.

Setting appropriate labels so we either disable or fix this before release.

Seems to be working fine on Linux, so maybe something specific with Windows hardware decoder.  human.peng@ can you try disabling accelerated video decode in chrome://flags and see if that helps you? I'll work on reproducing on Windows now.

Hmm, doesn't repro for me on Windows either. +gpu folk in case the error messages in the log are responsible for these errors.

Did you at least see some delay, lagging, or fast-forwarding effect when switching back? While i can constantly reproduce it on my Win 7 Desktop, it's much better on my Win 10 laptop: still have weird video fast-forwarding or pause problem when switching back, but totally freezing is rare.

The about:gpu messages seem unrelated - they'll happen occasionally even without video at all.

There's some fast-forwarding, but for me it only lasts a ~hundred milliseconds or so which about what we expect. How long would you estimate you see it lagging / fast forwarding for?

I sometimes can have fast-forwarding or pause effect lasting for 2 sec+ on my laptop (tested just now). 

Regardless, I will test my desktop (which will freeze) with the flag mentioned before disabled later today and focus on that, since that is the core problem I have.

Also, per comment #1 does it mean there is no way to disable "Optimize background video playback" for MSE video/stream any more? Because even if it's just a few hundred ms, it is still quite annoying if you're switching back and forth frequently, not to mention the fast-forwarding effect is unpleasant (compared to just pause).

2 sec is much higher than expected. Did you test with that twitch stream in your original link on 1080p60? What are the specs on your laptop?

Yes, we turned off the ability to disable this for MSE since test results since experiment showed little to no difference in time to return to a valid frame; 2 seconds is way beyond the expected time to return though.

Fast-forwarding is an artifact of how twitch is serving their stream, but we can definitely do better. I'll put a fix so that it just freezes on the last frame until ready instead of fast-forwarding.

Just did a few more tests. Disabling "Hardware-accelerated video decode" seems to fix it on my desktop. Actually, with this flag disabled, there is virtually no delay of video *at all* when I switch back.

My laptop is with Intel Core i7-7500U Processor + 12GB RAM + 256 SSD (it has a GeForce 940MX too, but it doesn't get used by browsers).

OK after more testing, I'm confident to say "Optimize background video playback" still plays a role despite what you said (it can't be disabled for MSE) at least for Twitch.

Here is some brief results:

"Optimize background video playback" disabled + "Hardware-accelerated video decode" disabled: 

As I mentioned in last comment, it makes that there is no delay or whatnot AT ALL no matter I'm switching from another tab, or from another program.

"Optimize background video playback" disabled + "Hardware-accelerated video decode" enabled:

My original problem. There is no video delay when I switch back from other *tabs*, but if I put the whole Chrome on background for too long time, the video freezes or have long (>2s) pause when I switch back.


"Optimize background video playback" enabled + "Hardware-accelerated video decode" disabled: 

It will have delay ANYTIME I switched back from other *tabs*, even when I just switched there for 1 sec. But, the delay is short (a few hundred ms as you said), and never freezes. And, switching from other program doesn't have any effect (i.e. no delay if the video is in the foreground tab).

"Optimize background video playback" enabled + "Hardware-accelerated video decode" enabled: 

Basically same to the previous one, just slightly worse. Sometimes there is some weird "shaking" problem when recovering the video. Doesn't seem to freeze, either. Again, switching from other program doesn't seem to have effect.

When you were reproducing, did you actually disable "Optimize background video playback"? Because it does make difference (see above) here.

>Did you test with that twitch stream in your original link on 1080p60 

Yes.

Thanks for the tests, the optimize flag will only affect non-twitch/YT playbacks right now; it's disconnected from MSE playbacks like Twitch/YT use.

You might try checking if there are video driver updates for your graphics cards; it seems like there are some issues with the hardware decoding pipeline if the software one is working better.

>Thanks for the tests, the optimize flag will only affect non-twitch/YT playbacks right now; it's disconnected from MSE playbacks like Twitch/YT use.

As I mentioned in comment 12, my test shows otherwise:

when the flag is default/enabled (has "optimization"), every time I switch to another tab and switch back, there is a small delay or fast-forwarding to recover the video. 
When the flag is disabled (no "optimization"), there is no such delay at all when switching from another tab.

Also, the resource usage (CPU) supports my observation: 

When "Optimize background video playback" is disabled, switching to another tab will NOT reduce CPU usage (stay at ~20%);
When "Optimize background video playback" is enabled, switching to another tab WILL reduce CPU usage (to ~10%).

So, this flag is NOT disconnected from MSE playbacks like Twitch/YT: it still has effect to it. I also tested with newest canary: 62.0.3178.0 (Official Build) canary (64-bit) (cohort: Clang-64) All the testing is with that channel: https://www.twitch.tv/dota2ti (1080p60), software decoding (hardware video decoding flag disabled).

If you don't believe me, I can record another video.

Before we go any further, we need to reach consensus about this flag. You tell me it won't affect Twitch at all, but it does here.

Video to support my observation: https://www.youtube.com/watch?v=pQBV9o0Je08

Ah, you're right it looks like it was only disconnected from setting the value, but still controls if the feature is enabled or not:

https://cs.chromium.org/chromium/src/media/blink/webmediaplayer_impl.cc?l=131

Sorry for my confusion.

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

commit a75a7894ee30bee8676c4f2db0fc171c7d5b5948
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Aug 09 20:21:51 2017

Only optimize background video after a timeout.

After some further testing, I concur that it's super annoying for
background tab optimizations to kick in and out if you happen to
be moving between tabs relatively frequently. Say for watching a
live stream, it may take a second or so to resume even though you
just left that tab.

As such, impose a 10s delay before background "disable track"
optimizations. Pause optimizations are left in place since pause
w/o suspend is expected to be very low cost for resume.

Additionally if we add this deferred timeout we eliminate part of
the reason we didn't ship this feature for src=. It's not possible
to trigger track changes fast enough that we will lose av sync.
Unfortunately src= track changes still work by returning the next
keyframe, which may be up to 5s ahead which is too far, so we still
can't enable until http://crbug.com/709302 is fixed.

BUG=678663,752726
TEST=manually verify that bg opts don't occur until after 10s.

Change-Id: I8cc4b81bbc91bd9a1f0777dd137d9c2940325e86
Reviewed-on: https://chromium-review.googlesource.com/607154
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493122}
[modify] https://crrev.com/a75a7894ee30bee8676c4f2db0fc171c7d5b5948/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/a75a7894ee30bee8676c4f2db0fc171c7d5b5948/media/blink/webmediaplayer_impl.h

[Bulk Edit]
URGENT - PTAL.
Your bug is labelled as M61 Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP.

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label.

Thank you.

dalecurtis@ can you please merge request of CL from comment#19 to M61(branch: 3163),so that we can pick the change to M61 beta refresh this week.

human.peng@ can you try Chrome Canary and see what you think of the new behavior? You'll need to wait 10s for disable track to kick in now.

[Bulk Edit]
URGENT - PTAL.
Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Thank you!

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label or move to M62.

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

commit dcbb81a3ed5ff9bff681d3227bbb30e403239eea
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Fri Aug 18 01:06:12 2017

Ensure delayed background optimize calls are actually cancelled.

When delayed background optimization was added, the shown call
did not properly cancel the outstanding disable call since it
didn't call the full background state update function.

BUG=752726
TEST=new unittest

Change-Id: Ic1b7f4a49ebaf3192c6de0fcd67f35414ed70ed8
Reviewed-on: https://chromium-review.googlesource.com/619615
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495410}
[modify] https://crrev.com/dcbb81a3ed5ff9bff681d3227bbb30e403239eea/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/dcbb81a3ed5ff9bff681d3227bbb30e403239eea/media/blink/webmediaplayer_impl_unittest.cc

[Bulk Edit]
URGENT - PTAL.
M61 Stable promotion is coming soon and your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. 

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label or move to M62. Thank you!

Note: We will only have 2 beta releases before Stable promotion. Plan is to cut M61 Stable RC on 08/31/17.

There are a few too many issues here, so let's go ahead and revert df848adb8eb6bf9be13ed82e1b2156b8ae93615a from the M61 branch and try again for M62. Merge-Request-61 to disable this feature for M61.

This bug requires manual review: M61 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid@(ChromeOS), govind@(Desktop)

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

Thank you  dalecurtis@.

Will this be a (df848adb8eb6bf9be13ed82e1b2156b8ae93615a) safe revert from the M61 branch? 

Yes, it just disable the feature again.

Approving merge to M61 branch 3163 based on comment #29. Please merge ASAP. Thank you.

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

commit 98a3688d7f731de09493cd37d57b51612dae8f22
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon Aug 21 20:49:18 2017

Revert "Enable background video track optimization for MSE content."

This reverts commit df848adb8eb6bf9be13ed82e1b2156b8ae93615a for
the M61 branch due to bugs.

BUG=752726
TEST=none
TBR=tguilbert

Change-Id: I200d16cdbbe982b2723f066414cfb5f64159fd77
Reviewed-on: https://chromium-review.googlesource.com/624663
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#712}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/98a3688d7f731de09493cd37d57b51612dae8f22/content/renderer/media/media_factory.cc
[modify] https://crrev.com/98a3688d7f731de09493cd37d57b51612dae8f22/media/base/media_switches.cc

Disabled for M61, but should be fixed now in M62.

@human.peng can you verify the fixed behavior? I've tried it on canary and the experience is much better.

I didn't comment before because it seems to me your fix (Aug 9 one at least) is about adding more time before "Optimize background video playback" kicked in? 

But my original report is about video being totally freezing when switching back, WITHOUT even using "Optimize background video playback" option (also see Comment 12 for a comprehensive test results).

If you think your patch(es) will help in that regard, sure I'm more than happy to do another batch of tests later. 

Only one of the patches delays the feature until the tab is in the background for a while. The rest should improve that experience, so it'd be helpful to see if they resolved your issues.

The issues where the feature is not even enabled are interesting and may need more work, but should be helped by my changes too.

Just did a quick test again with the repro in comment #1 with newest canary (call settings default, except "Optimize background video playback" disabled).

The problem consists: once I switched from outside (other program) the video-playing Chrome, the video starts to lag and eventually stops for a few seconds. Good news is, now it will resume after those long pause (i.e. not totally freeze anymore), but still doesn't look like the intended behavior.

Tested the issue on Windows-7 using chrome latest Beta M61-61.0.3163.59 by following steps mentioned in the original comment. Observed that video lags & stuck and playing with delay.Please find the screen cast for reference.

Steps Followed:
--------------
1.Install chrome and disable "Optimize background video playback" flag in chrome://flags.
2.Navigate to provided URL: https://www.twitch.tv/dota2ti and video played.
3.Switch to other programs and wait for a few minutes.
4.Back to video.

@ dalecurtis: Could you please let me know if i have missed anything and if possible,Please provide the missing steps of the issue which would help us to verify the issue further.

Thanks in Advance!




Thank you!

Deleted: 752726.mp4 13.0 MB

	752726.mp4 13.0 MB View Download

Thanks will take a closer look at the disabled-bg optimize case and see if we need to do anything for M61.

human.peng: Was this on Windows 7 or Windows 10?

I don't see any issues on Windows 10 with this feature disabled and putting things in the background.

@rbasuvula: Can you retest using Chrome M60 on Windows 7? I'd like to see if this is a regression or not. If it's not we can remove the ReleaseBlock M-61 label. I don't have a Windows 7 test machine so I won't be able to test this for a couple days.

As per above comment, rechecked this issue on chrome stable version# 60.0.3112.113 on Windows 7. Below are the observations

1) Navigated to chrome and disabled flag "Optimize background video playback"
2) Navigate to provided URL: https://www.twitch.tv/dota2ti and observed that Video is not played (a 404 error is displayed in console). Screen shot attached.
3) Hence Navigated to another URL from the same website: https://www.twitch.tv/videos/166172514
4) Switched to other application or tabs and waited for few time (60 to 110 Seconds)
5) Re navigated back to the video

On stable as well we are observing the delay or lag while playing the video. How ever did not observe any freeze. Please do let us know if any other details are required.

Thanks.!

Deleted: 404 Error.png 2.4 MB

	404 Error.png 2.4 MB View Download

Well dota2ti channel is not streaming any more. Please use any of the live channel here:　https://www.twitch.tv/directory/all

@ranjitkan, can you confirm you are seeing the same issues as the video in c#36? I'm not clear on what you mean by seeing delay and lag but not temporary freezing since those are the same to me :)

In any case it seems like this is not a new issue unfortunately, so we can drop the RBS label. I'm working on getting a Windows 7 machine to dig into this more.

You might try closing the chat window on left hand screen to see if things improve. Since it may be contending for video resources due to the way MSE works.

liberato@ is looking into the Windows 7 issues. Seems we may have larger h264 decoder issues there.

@human.peng: does the video play smoothly while you're watching it, or do you see video frames that seem to be out of order sometimes?  on my win7 laptop, with hw decoding enabled on twitch/dota, i see some of out of order frames.  i.e., what should be smooth motion has some discontinuities in it.

turning off hw decoding seems to fix it.

I don't seem to find obvious frame skipping phenomenon when watching.

According to the “video stats” provided by Twitch, frame skipping does happen from time to time; but since it is 60fps, it is not noticeable here. 

it's likely that my laptop is having an entirely different issue.  dale mentioned that out-of-order timestamps could result in the freezing that you're seeing, which is why i thought that they might be related.

i don't see any out of order frames coming out of the decoder, or later in the pipeline locally.  so, my issue might be related to displaying the wrong image for the right video frame.  i.e., it could be a GL fence issue or something.

yours seems to be higher in the pipeline.  i'll try to repro it more exactly.

i've managed to get it to freeze once or twice.

what i've noticed is that, while it's in the background, the difference between the frame deadline (VideoRendererAlgorithm::Render) and the only queued VideoFrame keeps getting bigger, up to > 1 second.  this happens regardless of whether it freezes when it's brought back to the foreground.

when the video is playing, that doesn't happen.  it stays bounded at 1/10 sec or so.

will keep looking.

on my next attempt, i got it to freeze with more debugging enabled.  the general sequence was:

- VRA::Renderer reports a growing delta between current time and the queued frame.
- At about ~1 second of difference, the decoder quits getting new bitstream buffers via Decode()
- ~six picture buffers are re-used in the VDA after decoding stops.
- VRA continues to report the delta growing in realtime.
- when un-minimized, VideoLayerImpl starts rendering on vsync again, but it has no new frames.

it seems that the 'source' quality stream is required to get either of the weird behaviors that i was seeing locally.  on anything else (e.g. 720p60), the out-of-order frame issue is gone, and i can no longer repro the OP issue.

with "source" quality, the underlying cause of the stalls was that the video decoder couldn't keep up with real-time playback.  when chrome is put into the background, the audio would play perfectly but the (unseen) video would fall further and further behind it.  when chrome is brought back to the foreground, playback would pause / stutter trying to catch up the video to the audio.

however, for this to be the same problem, foreground video / audio playback would have to stall regularly.  the difference is that, in foreground mode, chrome is willing to pause the audio to let the video catch up; the video decoder still can't keep up with real-time.

based on c#46, it sounds like foreground playback is working fine.

so, it seems like i don't have a repro case.

Is this still an issue? It's out of SLO for a P1 bug; which must be closed in 30 days. Please close as fixed or mark as P3.