Unable to repro this issue on Windows 10 for Google Chrome Stable Version - 52.0.2743.116

Screen-recording is attached.

@stuart.elliott: Could you please re-test the same on a clean profile [chrome://settings -> Add Person -> Do not Login] and let us know your observations.

Also. update your Canary to Latest - 54.0.2823.0

Thank you.

Deleted: 635319.mp4 3.1 MB

	635319.mp4 3.1 MB View Download

Created a new profile, didn't load any extensions, and same issue.

"Version 54.0.2823.0 canary (64-bit)
 
Google Chrome is up to date."

That said... My PC in work, which logs into the same Google account, with same extensions, doesn't exhibit the same issue, but I don't get the image corruption with anything else on THIS PC, just animated GIFs played via Chrome.

Thank you for providing more feedback. Adding requester "rnimmagadda@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

I'm seeing this on 54.0.2824.0 dev-m (64-bit) as well as 54.0.2832.2 canary (64-bit), both of which are up to date as of right now. I am *not* seeing any trouble with MS Edge or FF. The problem appears to affect all "gifv" files from imgur. I'm running Windows 10 1607 with an Nvidia 960 and the latest drivers. My Chrome dev has lots of flags and extensions, but my Canary has only a couple extensions and no flags.

I observe that there's significant dark blockiness at the beginning of the video, somewhat diminishing as the video plays, depending on the amount of motion present. However, in the case of a looping gifv from imgur, once the video finishes the first playthrough and begins looping, all subsequent playthroughs are just fine. The blockiness is not consistent, and varies somewhat with each reloading of the file.

My theory: it appears that either the first i-frame is missed, or the video is reset to black shortly after the first i-frame is decoded.

Screencap showing MS Edge and Chrome Canary side by side, including multiple video loops (Caution: very large, 4k @ 60fps): https://drive.google.com/open?id=0B2mgJRcjBdVUb3ZubVBUX0JQNFE

Yep, that is exactly what I'm seeing.

 Issue 623887  has been merged into this issue.

Can repro in 54.0.2840.8 dev Win x64.

+windows 

Possibly a dup of issue 625011?

Possibly.  That bug is a bit confusing because sometimes the reporter talks about "dark" (and the darkness in the video in comment 1 looks like this bug) but sometimes talks about "pink and green".

I can repro this on YouTube and Imgur, so it's affecting fairly major sites.  I have a Geforce 970 and updated my drivers two weeks ago (Nvidia GeForce drivers version 372.54), so not an obscure or outdated card/software, or AMD-specific.

Let me know if I can provide more info.

Thanks, Have you tested with --disable-zero-copy-dxgi-video --disable-nv12-dxgi-video?

(Sample URL in comment 0 is removed, another sample is http://imgur.com/gallery/70Zcn5A )

Adding those two switches makes the bug disappear.

Alright, next question: do either of the flags alone solve the problem?

(Don't really want to blacklist the 970 from these features though...)

I posted issue 625011 with Chrome 52, originally about black distortion. I was asked to test Canary, which was when I discovered Chrome 53+ had pink and green html5. Those two switches fix the pink and green for me, but the original issue of black distortion persists.

--disable-zero-copy-dxgi-video alone fixes the issue.  --disable-nv12-dxgi-video alone has no effect.

--disable-zero-copy-dxgi-video fixes the issue for me also. [Version 55.0.2853.0 canary (64-bit)]

 

From: pkast… via monorail [mailto:monorail+v2.2899342933@chromium.org] 
Sent: 06 September 2016 20:36
To: stuart.elliott@gmail.com
Subject:  Issue 635319  in chromium: Videos (converted gifs) corrupt for first few seconds

 


Comment #18 on  issue 635319  by pkasting@chromium.org <mailto:pkasting@chromium.org> : Videos (converted gifs) corrupt for first few seconds
https://bugs.chromium.org/p/chromium/issues/detail?id=635319#c18

--disable-zero-copy-dxgi-video alone fixes the issue. --disable-nv12-dxgi-video alone has no effect.

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

commit d47c4314fc4eb97082790714281b9e3cc5b45c9c
Author: jbauman <jbauman@chromium.org>
Date: Thu Sep 08 01:29:00 2016

Disable zero-copy DXGI video on NVIDIA GPUs

This seems to sometimes be causing videos to initially display black.

BUG= 635319 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/d47c4314fc4eb97082790714281b9e3cc5b45c9c/gpu/config/gpu_driver_bug_list_json.cc

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

commit d47c4314fc4eb97082790714281b9e3cc5b45c9c
Author: jbauman <jbauman@chromium.org>
Date: Thu Sep 08 01:29:00 2016

Disable zero-copy DXGI video on NVIDIA GPUs

This seems to sometimes be causing videos to initially display black.

BUG= 635319 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/d47c4314fc4eb97082790714281b9e3cc5b45c9c/gpu/config/gpu_driver_bug_list_json.cc

Verified the fix on Windows 7 & 10 for Google Chrome Canary Version - 55.0.2859.0 

Screen-recording is attached.

TE-Verified Labels are added.

@jbauman: Could you please change the status accordingly.

Thank you.

Deleted: 635319.mp4 1.0 MB

	635319.mp4 1.0 MB View Download

I posted issue 625011 and wanted to check out if anything was fixed for my computer in 55.0.2861.0 (64-bit). The pink and green videos issue was fixed without any command line switches needed. The issue with some videos starting black and distorted is still present for me, with or without switches.

I've never had an issue with this happening on videos opened on their own pages. I used 9gag as an example, because it seems to occur when scrolling and gifs attempt to autoplay.

The same gifs that start out black while scrolling, start fine if opened on their own page. 

The black distortion typically lasts 5-10 seconds and does not persist all the way through the first loop for anything longer.

Attached latest Dev screen record.

Deleted: Chrome-Dev.mp4 11.9 MB

	Chrome-Dev.mp4 11.9 MB View Download

Just wanted to point out this bug has made it into the stable channel if that wasn't already known. I am getting the black corruption on `Version 54.0.2840.71 m` but not `Version 56.0.2900.0 canary (64-bit)`.

I have the same problem on Windows 10 x64. My video card is Nvidia GTX 960 and the driver is 375.63

https://imgur.com/DqJWQlm?r

Deleted: Image 2016 10 28 12 35 23.png 216 KB

	Image 2016 10 28 12 35 23.png 216 KB View Download

sandersd@, could you merge d47c4314fc4eb97082790714281b9e3cc5b45c9c into M54?

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

Merge is ready to go (https://codereview.chromium.org/2457243002) pending approval.

 Issue 659795  has been merged into this issue.

LGTM, approved for merge into M54

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

commit b4a1aa2027fe32397fa67e59fedf49c78481188c
Author: Dan Sanders <sandersd@chromium.org>
Date: Sat Oct 29 00:26:25 2016

Disable zero-copy DXGI video on NVIDIA GPUs

This seems to sometimes be causing videos to initially display black.

TBR=dalecurtis@chromium.org
BUG= 635319 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

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

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

Cr-Commit-Position: refs/branch-heads/2840@{#799}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/b4a1aa2027fe32397fa67e59fedf49c78481188c/gpu/config/gpu_driver_bug_list_json.cc

This isn't only happening with Nvidia GPU's. I posted one of the first issues about this issue 625011. After updating my AMD graphics drivers to the last/latest version, a lot of issues were fixed, but automatically started gifs/videos still occasionally begin black and distorted. 

It happens pretty frequently and predictably, meaning it tends to happen in the same types of gifs on the same sites. The two flags mentioned here:
--disable-zero-copy-dxgi-video --disable-nv12-dxgi-video
don't resolve this issue.

Firefox (Nightly) doesn't have any issues with the same gifs/sites and yes, I checked and hardware acceleration is enabled and working well in both browsers for everything other than this one issue in Chrome.

GPU readout

Deleted: gpu.html 99 KB

gpu.html 99 KB View Download

this issue happens on youtube.com on some videos

Supposedly Nvidia pushed a hotfix for this issue in driver 375.76:

http://nvidia.custhelp.com/app/answers/detail/a_id/4250

We may want to test whether this driver would allow us to re-enable zero-copy DXGI, as well as fixing other artifacts connected with this bug.

Issue 662094 has been merged into this issue.

I am able to reproduce on my Windows 10 desktop. My Surface Pro 4 doesn't have the issue though (both using Chrome on Windows 10). Google's auto-updater is running normally on both, so I assume I'm on the latest stable build. And it didn't start happening until a couple months ago (late summer 2016).

I'm using an nVidia GTX 980TI on my affected desktop computer, manufactured by EVGA.

My theory for why they look corrupt as they do is that the first frame, being the keyframe, fails to load completely/correctly, and since video encoding is based on differences between frames, all subsequent frames look super corrupted until it either starts over (and reloads the first frame) or is long enough to reach another keyframe.

My workaround has been to manually refresh the GIF/GIFV (so both GIF and webM) right away which hasn't failed me yet. Super annoying but faster than waiting for the entire GIF to play once through.

lask, could you try installing NVIDIA driver 375.76 (or newer) on your desktop computer to see if that fixes the problem?

Any news? We're at driver version 385.69 now and #34 suggested you could try re-enabling zero-copy DXGI + others again at driver version 375.76 (almost a year ago).

Thanks for pinging; though I'm unclear if you're still hitting the original issue or if you just want DXGI zero copy. Can you elaborate?

Dan, John: Can you either drop an updated note on why we haven't re-enabled this or go ahead and limit the blacklist to < 375.76?

I'm testing Chrome with --disable-gpu-driver-bug-workarounds switch which re-enables all the features and see no problems on 38x.xx drivers.
GeForce GTX1060.

#39: The main reason is that we were never able to reliably reproduce this issue across the range of hardware it has been found to have problems on. Therefore it's hard to know if we've actually fixed them.

For NVidia/zero-copy in particular, it probably does make sense to update the black list. I'll prepare a CL for that.

The overall issue here is fixed and I have a CL out to enable this for >= 375.76: https://chromium-review.googlesource.com/c/chromium/src/+/804634

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

commit c08b495ff60822e1eb89c4ddb481107de500ef5c
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Sat Dec 02 02:08:21 2017

Re-enable DXGI sharing on NVIDIA drivers >= 375.76.

Verified on my 1050 that this is working; pulled the NVIDIA driver
version from DisplayDriver/nv_dispi.inf in the 375.76 package, which
contains the fix for this.

BUG= 635319 
TEST=verified no corruption with https://imgur.com/DqJWQlm on 388.13.

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I759f628d2cef250e867fc17aaee51aff1a6e4bb9
Reviewed-on: https://chromium-review.googlesource.com/804634
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521178}
[modify] https://crrev.com/c08b495ff60822e1eb89c4ddb481107de500ef5c/gpu/config/gpu_driver_bug_list.json

Tested the issue on windows 7 & 10 x64 using chrome M65 #65.0.3284.0 and observed no black patches on the video ...using the test url from comment #25.

Attached screencast for reference.

Adding TE-Verified labels.

Thanks!

Deleted: 635319.mp4 7.5 MB

	635319.mp4 7.5 MB View Download

I can confirm with latest nvidia drivers and forcing zero-copy that no issues are present in the latest beta version of Chrome.