Don't mean to be rude, but this bug is of major importance to us.
It affects all of our interactive videos that are currently live.
Would really really appreciate it if someone could take a look.

Went over the change log, and I think this commit is probably related:
https://chromium.googlesource.com/chromium/src/+/e219f13c3619c1477c815f1db22aa4456d4d5f1c

Thanks!!!

Looks like this is happening because of the decoder instance getting torn down due to a config change being detected.

Thanks for looking into this!
Is a fix in the works?

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

commit 5795198277f6c7e1e5871d343c1dbadba1a505d6
Author: ananta <ananta@chromium.org>
Date: Tue Jun 07 04:40:11 2016

Fix black frames on segment boundaries in H/W decoded h.264 video on windows.

When we detect a segment boundary we reinitialize the decoder. Currently
on Windows that results in tearing down the decoder instance the
D3D9/D3D11 device objects, the output picture buffers etc.

We don't need to tear down the output picture buffers and the d3d device
objects. This fixes the black frame which shows up due to the picture
buffers getting destroyed and new ones getting created.

In any case if the resolution changes we do request new output buffers
anyways.

I tested the test case in bug 594266 which was the reason for the config
change code in the first place. That still works in D3d9 and D3D11.

BUG= 616349 

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

[modify] https://crrev.com/5795198277f6c7e1e5871d343c1dbadba1a505d6/media/gpu/dxva_video_decode_accelerator_win.cc

Thanks for the quick fix!
Is there any chance of this being merged into 51 and released as a hotfix?

Thanks again for the fix.
I tested with 53.0.2762.0, and while it's a million times better now (no black frames), it's still not as seamless as it used to be (or as it currently is on Mac).

You can see that there's a frame-freeze on segment boundaries.
It's subtle but noticeable.

In the provided link, which is comprised of 5 second segments, it's most noticeable on 10, 15, 20 seconds.

Would be great if this could be fixed as well.
Thanks!

I can try to comment on the frame-freeze issue: if we could detect in advance which drivers would crash when we don't re-create the decoder, then we could avoid this performance issue. However, since we didn't find a way to do that, there are no obvious workarounds. We have to pay the cost of setting up a new decoder each time there is a configuration change.

One theoretical option would be to build a whitelist of known-good driver/OS/config combinations, but just from the definition it's clear that that is a huge undertaking. Perhaps you have a narrower use-case that would be more approachable?

So the assumption is that the frame freeze is a performance issue?
Due to the cost of initializing a new decoder?

This is just a hunch, but from the looks of it,
I kinda thought that it might be a bug, where the output pictures buffer is cleared on config change, discarding frames that have not yet rendered.

It looks like you may be correct, I don't see any attempt to flush the decoder in this state. Re-opening.

Again - really appreciate you looking into this.
Was wondering if you guys have any updates... thanks!

Reviewers: sandersd
CL: https://codereview.chromium.org/2065323002/

Description:
Fix the frame freezing issue observed during a config change in the H.264
decoder on Windows

We need to drain the decoder of any pending output before tearing down the
instance of the decoder and recreating it during a configuration change.

Draining the decoder is done as part of a Flush operation. However this is
a decoder initiated flush which requires the following
1. Don't process pending input in this case as that is what caused the
config change.
2. Don't notify the client about the completion of the flush operation.

Added a member variable processing_config_change_ to track this state. We
mimic most of the logic we have to process the pending_flush_ state when
this flag is set.

BUG= 616349 

Base URL: https://chromium.googlesource.com/chromium/src.git@master

Thanks for the fix, it looks absolutely flawless on Canary!!

Would you consider merging this into Chrome 51 as a hotfix?
That would be incredible...!

Any word about releasing this as a hotfix?

It's important to note that this bug affects H264 videos all over the internet.
Here's an example from a NY Times video article:
http://www.nytimes.com/2016/06/15/dining/soft-serve-ice-cream.html

The video is here:
https://vp.nyt.com/video/2016/06/09/39533_1_clark-honey-icecream_wg_480p.mp4
Play it on Chrome 51 and see black frames on config changes at 20, 1:00, 1:20, 1:40.

It would be really awesome if this fix could be released as soon as possible - thanks!

[Automated comment] Request affecting a post-stable build (M51), manual review required.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

[Automated comment] Request affecting a post-stable build (M51), manual review required.

Requesting the merge to M52 branch as per # 14 since it is verified in Canary.

ananta@, can you please merge the CL in to M52 branch by EOD so that it gets picked up for beta promotion scheduled this week.

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

commit faf72f7be4cb958e249e5a6da6fdf30571487ce1
Author: Anantanarayanan G Iyengar <ananta@chromium.org>
Date: Mon Jun 20 20:02:06 2016

Fix the frame freezing issue observed during a config change in the H.264 decoder on Windows

Merging to M52

We need to drain the decoder of any pending output before tearing down the
instance of the decoder and recreating it during a configuration change.

Draining the decoder is done as part of a Flush operation. However this is
a decoder initiated flush which requires the following
1. Don't process pending input in this case as that is what caused the
   config change.
2. Don't notify the client about the completion of the flush operation.

Added a member variable processing_config_change_ to track this state. We
mimic most of the logic we have to process the pending_flush_ state when
this flag is set.

BUG= 616349 

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

Review URL: https://codereview.chromium.org/2081643003 .

Cr-Commit-Position: refs/branch-heads/2743@{#409}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/faf72f7be4cb958e249e5a6da6fdf30571487ce1/media/gpu/dxva_video_decode_accelerator_win.cc
[modify] https://crrev.com/faf72f7be4cb958e249e5a6da6fdf30571487ce1/media/gpu/dxva_video_decode_accelerator_win.h

Tested the same on win8.1 chrome version 53.0.2774.2 playing the video in http://storage2.interlude.fm.s3.amazonaws.com/dev_temp/tomer/chrome_mse_win_blackframe_bug/index.html - observed that video played fine continuously without ant black screen in between.

Fix works as expected

Please find the screencast

Deleted: Recording #3.mp4 1.2 MB

	Recording #3.mp4 1.2 MB View Download

Issue is still seen on win8.1 chrome version 52.0.2743.49 - observed black screen for every 5 seconds

Please find the screencast

ananta@, Could you please confirm on the fix

Deleted: Recording #4.mp4 853 KB

	Recording #4.mp4 853 KB View Download

 Issue 621909  has been merged into this issue.

need to merge the earlier commit to M52. This one https://codereview.chromium.org/2040093002

Your change meets the bar and is auto-approved for M52 (branch: 2743)

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

commit 1f9b16ef7e1d1ad069331705a08eaf59cea7897a
Author: Anantanarayanan G Iyengar <ananta@chromium.org>
Date: Wed Jun 22 22:20:52 2016

Fix black frames on segment boundaries in H/W decoded h.264 video on windows.

Merging to M52

When we detect a segment boundary we reinitialize the decoder. Currently
on Windows that results in tearing down the decoder instance the
D3D9/D3D11 device objects, the output picture buffers etc.

We don't need to tear down the output picture buffers and the d3d device
objects. This fixes the black frame which shows up due to the picture
buffers getting destroyed and new ones getting created.

In any case if the resolution changes we do request new output buffers
anyways.

I tested the test case in bug 594266 which was the reason for the config
change code in the first place. That still works in D3d9 and D3D11.

BUG= 616349 

Review-Url: https://codereview.chromium.org/2040093002
Cr-Commit-Position: refs/heads/master@{#398226}
(cherry picked from commit 5795198277f6c7e1e5871d343c1dbadba1a505d6)

Review URL: https://codereview.chromium.org/2082383003 .

Cr-Commit-Position: refs/branch-heads/2743@{#449}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/1f9b16ef7e1d1ad069331705a08eaf59cea7897a/media/gpu/dxva_video_decode_accelerator_win.cc

What's the status of this getting into M51? 

+Caleb for FYI.

Tested the same on win8.1 chrome version 52.0.2743.60 playing the video in http://storage2.interlude.fm.s3.amazonaws.com/dev_temp/tomer/chrome_mse_win_blackframe_bug/index.html - observed that video played fine continuously without ant black screen in between.

Fix works as expected

Please find the screencast

Deleted: Recording #6.mp4 892 KB

	Recording #6.mp4 892 KB View Download

Merge approved for M51 (branch 2704)

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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