Here's a screen record. AMD GPU if that's a factor.

Deleted: 2016-07-01_20-26-15.mp4 13.1 MB

	2016-07-01_20-26-15.mp4 13.1 MB View Download

Yeah, seems to look about the same as my issue I think (that one https://bugs.chromium.org/p/chromium/issues/detail?id=623887#c2 ) ^^ Also got a AMD GPU.

I can't repro this issue on my Win7+Chrome53.0.2785.8. I have NVIDIA Quadro K600 video card. Can you save the problem video and open the video directly on Chrome browser, Firefox and Opera, also on window media player, to see if there is any difference?
thanks

The similar issue linked here: https://bugs.chromium.org/p/chromium/issues/detail?id=623887#c2 states that the issue occurs "when loading and after being off-screen". I haven't had any issues "when loading" (no issue with their example link at all), but html5 loops start blackish and distorted when they are auto-playing as they're coming on screen, as you can see in the screen record.

Vids affected seem pretty random. Some are, some aren't. To answer your question (I think), if I right click and copy the vid url, and then open it in a new window, there's no issue.

I typically use Chromium stable, but before posting I double-checked that Chrome stable had the same issue, which it did. In the other thread, someone mentioned:

Seems it's now broken in dev (53.0.2783.4 dev-m (64-bit)) and working in Canary 54.0.2787.0 canary (64-bit) :D So I suppose it's fixed, provided dev will get the canary build somewhere down the line

so I was curious and tried 54.0.2793.0 (64-bit). It seems the html5 issues are way worse in the latest Dev. Most vids are green and purple and stay that way. Some still appear as they should, but most are all jacked up. 

Screen record: 

Deleted: Chromium-Dev.mp4 22.3 MB

Chromium-Dev.mp4 22.3 MB Download

Thank you for providing more feedback. Adding requester "yiningc@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

therealdoctorgonzo@gmail.com, in #4, you said "if I right click and copy the vid url, and then open it in a new window, there's no issue.", do you mean you right click the looped video, copy link address, then open address in a new Chrome window or tab, but you don't see any problem?

No, not "link address". I'm talking about "copy video address" and then opening in its own tab. I thought that's pretty close to what you meant by "save the problem video and open the video directly on Chrome browser".

I just double-checked that the issues in Chromium-Dev are also a problem in Chrome Canary, and they are. Almost all videos are green and pinkish-purple. Oddly enough, some videos still play fine.

It's definitely a GPU/hardware acceleration issue, since if I turn off hardware acceleration, videos play correctly using a ridiculous amount of CPU.

GPU related. dan, can you take a look?

Looks like a pixel format error; assigning to jbauman who knows more about that on DXVA than I.

therealdoctorgonzo@gmail.com, could you attach the contents of about:gpu here? Ideally capture it in Chrome Canary after you reproduce the problem, as that might log some useful error messages.

Sorry for the delay, I didn't receive a notification. Here's the results of a fresh Chrome Canary install with no customizations after playing a few html5 vids (which were pink and green):

 Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Software only. Hardware acceleration disabled
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
WebGL: Hardware accelerated
Driver Bug Workarounds
clear_uniforms_before_first_program_use
disable_direct_composition
disable_discard_framebuffer
disable_dxgi_zero_copy_video
disable_framebuffer_cmaa
exit_on_context_lost
force_cube_complete
scalarize_vec_and_mat_constructor_args
texsubimage_faster_than_teximage
Problems Detected
Some drivers are unable to reset the D3D device in the GPU process sandbox
Applied Workarounds: exit_on_context_lost
TexSubImage is faster for full uploads on ANGLE
Applied Workarounds: texsubimage_faster_than_teximage
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
ANGLE crash on glReadPixels from incomplete cube map texture: 518889
Applied Workarounds: force_cube_complete
Framebuffer discarding can hurt performance on non-tilers: 570897
Applied Workarounds: disable_discard_framebuffer
Direct composition flashes black initially on Win <10: 588588
Applied Workarounds: disable_direct_composition
Zero copy DXGI video hangs on shutdown on Win < 8.1: 621190
Applied Workarounds: disable_dxgi_zero_copy_video
Zero copy DXGI video hangs on AMD drivers: 623029
Applied Workarounds: disable_dxgi_zero_copy_video
Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198
Applied Workarounds: disable_framebuffer_cmaa
Accelerated rasterization has been disabled, either via blacklist, about:flags or the command line.
Disabled Features: rasterization
Native GpuMemoryBuffers have been disabled, either via about:flags or command line.
Disabled Features: native_gpu_memory_buffers
Version Information
Data exported	7/23/2016, 1:01:55 AM
Chrome version	Chrome/54.0.2803.0
Operating system	Windows NT 6.3.9600
Software rendering list version	11.7
Driver bug list version	8.77
ANGLE commit id	1be913cff832
2D graphics backend	Skia
Command Line Args	SxS\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Driver Information
Initialization time	203
In-process GPU	false
Sandboxed	false
GPU0	VENDOR = 0x1002, DEVICE= 0x9641 *ACTIVE*
GPU1	VENDOR = 0x1002, DEVICE= 0x6741
Optimus	false
AMD switchable	false
Desktop compositing	Aero Glass
Diagonal Monitor Size of \\.\DISPLAY1	15.5"
Driver vendor	Advanced Micro Devices, Inc.
Driver version	13.251.9001.1001
Driver date	7-4-2014
Pixel shader version	5.0
Vertex shader version	5.0
Max. MSAA samples	8
Machine model name	
Machine model version	
GL_VENDOR	Google Inc.
GL_RENDERER	ANGLE (AMD Radeon HD 6620G Direct3D11 vs_5_0 ps_5_0)
GL_VERSION	OpenGL ES 2.0 (ANGLE 2.1.0.1be913cff832)
GL_EXTENSIONS	GL_OES_element_index_uint GL_OES_packed_depth_stencil GL_OES_get_program_binary GL_OES_rgb8_rgba8 GL_EXT_texture_format_BGRA8888 GL_EXT_read_format_bgra GL_NV_pixel_buffer_object GL_OES_mapbuffer GL_EXT_map_buffer_range GL_EXT_color_buffer_half_float GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_float GL_OES_texture_float_linear GL_EXT_texture_rg GL_EXT_texture_compression_dxt1 GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_OES_compressed_ETC1_RGB8_texture GL_EXT_sRGB GL_ANGLE_depth_texture GL_OES_depth32 GL_EXT_texture_storage GL_OES_texture_npot GL_EXT_draw_buffers GL_EXT_texture_filter_anisotropic GL_EXT_occlusion_query_boolean GL_NV_fence GL_EXT_disjoint_timer_query GL_EXT_robustness GL_EXT_blend_minmax GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_pack_reverse_row_order GL_OES_standard_derivatives GL_EXT_shader_texture_lod GL_EXT_frag_depth GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_EXT_discard_framebuffer GL_EXT_debug_marker GL_OES_EGL_image GL_OES_EGL_image_external GL_NV_EGL_stream_consumer_external GL_EXT_unpack_subimage GL_NV_pack_subimage GL_OES_vertex_array_object GL_KHR_debug GL_ANGLE_lossy_etc_decode GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_sync_query
Disabled Extensions	
Window system binding vendor	Google Inc. (adapter LUID: 000000000000861a)
Window system binding version	1.4 (ANGLE 2.1.0.1be913cff832)
Window system binding extensions	EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture_nv12
Direct rendering	Yes
Reset notification strategy	0x8252
GPU process crash count	0
Compositor Information
Tile Update Mode	One-copy
Partial Raster	Enabled
GpuMemoryBuffers Status
ATC	Software only
ATCIA	Software only
DXT1	Software only
DXT5	Software only
ETC1	Software only
R_8	Software only
BGR_565	Software only
RGBA_4444	Software only
RGBX_8888	Software only
RGBA_8888	Software only
BGRX_8888	Software only
BGRA_8888	Software only
YVU_420	Software only
YUV_420_BIPLANAR	Software only
UYVY_422	Software only
Diagnostics
0
b3DAccelerationEnabled	true
b3DAccelerationExists	true
bAGPEnabled	true
bAGPExistenceValid	true
bAGPExists	true
bCanRenderWindow	true
bDDAccelerationEnabled	true
bDriverBeta	false
bDriverDebug	false
bDriverSigned	false
bDriverSignedValid	false
bNoHardware	false
dwBpp	32
dwDDIVersion	11
dwHeight	768
dwRefreshRate	60
dwWHQLLevel	0
dwWidth	1366
iAdapter	0
lDriverSize	1318552
lMiniVddSize	0
szAGPStatusEnglish	Enabled
szAGPStatusLocalized	Enabled
szChipType	AMD Radeon HD 6620G (0x9641)
szD3DStatusEnglish	Enabled
szD3DStatusLocalized	Enabled
szDACType	Internal DAC(400MHz)
szDDIVersionEnglish	11
szDDIVersionLocalized	11
szDDStatusEnglish	Enabled
szDDStatusLocalized	Enabled
szDXVAHDEnglish	Not Supported
szDXVAModes	ModeMPEG2_A ModeMPEG2_C
szDescription	AMD Radeon HD 6620G
szDeviceId	0x9641
szDeviceIdentifier	{D7B71EE2-D501-11CF-5377-8715BEC2C535}
szDeviceName	\\.\DISPLAY1
szDisplayMemoryEnglish	4067 MB
szDisplayMemoryLocalized	4067 MB
szDisplayModeEnglish	1366 x 768 (32 bit) (60Hz)
szDisplayModeLocalized	1366 x 768 (32 bit) (60Hz)
szDriverAssemblyVersion	13.251.9001.1001
szDriverAttributes	Final Retail
szDriverDateEnglish	7/21/2014 22:04:16
szDriverDateLocalized	7/21/2014 10:04:16 PM
szDriverLanguageEnglish	English
szDriverLanguageLocalized	English
szDriverModelEnglish	WDDM 1.2
szDriverModelLocalized	WDDM 1.2
szDriverName	aticfx64.dll,aticfx64.dll,aticfx64.dll,aticfx32,aticfx32,aticfx32,atiumd64.dll,atidxx64.dll,atidxx64.dll,atiumdag,atidxx32,atidxx32,atiumdva,atiumd6a.cap,atitmm64.dll
szDriverNodeStrongName	oem2.inf:cb0ae414d22316d5:ati2mtag_Sumo_Mobile:13.251.9001.1001:pci\ven_1002&dev_9641
szDriverSignDate	
szDriverVersion	8.17.0010.1247
szKeyDeviceID	Enum\PCI\VEN_1002&DEV_9641&SUBSYS_358D103C&REV_00
szKeyDeviceKey	\Registry\Machine\System\CurrentControlSet\Control\Video\{6A7D33E9-9EB7-4DD2-A63D-5D5AC62A5E37}\0000
szManufacturer	Advanced Micro Devices, Inc.
szMiniVdd	n/a
szMiniVddDateEnglish	n/a
szMiniVddDateLocalized	n/a
szMonitorMaxRes	
szMonitorName	Generic PnP Monitor
szNotesEnglish	No problems found.
szNotesLocalized	No problems found.
szOverlayEnglish	Not Supported
szRankOfInstalledDriver	00DA2001
szRegHelpText	
szRevision	
szRevisionId	0x0000
szSubSysId	0x358D103C
szTestResultD3D7English	Not run
szTestResultD3D7Localized	Not run
szTestResultD3D8English	Not run
szTestResultD3D8Localized	Not run
szTestResultD3D9English	Not run
szTestResultD3D9Localized	Not run
szTestResultDDEnglish	Not run
szTestResultDDLocalized	Not run
szVdd	n/a
szVendorId	0x1002
Log Messages
GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.

I won't pretend to understand the GPU analysis, but there's no flag or command line switches. There are switchable graphics, but I don't Know if that even applies to Chrome. 

My computer: http://support.hp.com/us-en/product/HP-Pavilion-dv6-Entertainment-Notebook-PC-series/5082212/model/5118955/drivers

OS was fresh install of Win8.1 and the drivers were installed through Windows update. They've been pretty decent. Very rarely I'll get a glitch that AMD Catalyst has stopped responding, which usually recovers immediately. 

I have no issues with Firefox video playback, nor did I have any prior to Chrome v51+. I'm currently on Chromium Version 52.0.2743.82 (64-bit), which has the same issue as the previous version where videos that start auto-playing while scrolling start off black and distorted. Both Canary and Chromium Dev are far worse, with the majority of vids being green and pink and remaining that way, making them unusable.

It's been a few weeks, so I tested in Canary 54.0.2829.0. Same problem with pink and green html5 videos. chrome://gpu contents attached.

Deleted: gpu.html 99 KB

gpu.html 99 KB View Download

#15: I'm a little surprised, since recent canaries disable the newest pixel format changes on AMD hardware. Can you try running Chrome with --disable-zero-copy-dxgi-video --disable-nv12-dxgi-video?

I don't believe that there are chrome://flags entries for those, so you would need to do it by modifying a Chrome shortcut to add them or directly with Run or cmd. Let me know if you need help with that! You can check chrome://version to verify that they are being detected.

Yeah, I tested Version 54.0.2831.0 canary (64-bit) with/without those command line switches. Without them most vids are pink and green, and with them they appear normal. 

Unfortunately, even with the command line switches, the original issue of some auto-playing html5 gifs starting black and distorted is still present. 9gag is a good example because it seems to start happening after 1 or 2 dozen scrolls, and even then it's fairly consistent but random. Because of that, my SWAG would be that it has something to do with memory, but I don't know what I'm talking about.

I'm attaching the GPU readout of Canary w/command line switches.

Deleted: gpu.html 4.4 KB

gpu.html 4.4 KB View Download

My bad, I don't think that html file was saved right. I'll try again.

Deleted: gpu.html 99 KB

gpu.html 99 KB View Download

jbauman@: This device clearly cannot support the NV12 copy path, do you see anything obvious we can use to blacklist it?

As for the black corruption, it's consistent with the first (key) frame being replaced with black (and then working correctly on the second loop through). This isn't something that Chrome has any control over, so I'm surprised that Firefox does not have the same issue. Perhaps Firefox has already blacklisted this device and is actually using software decode?

Have you compared the CPU usages for Chrome vs. Firefox for these videos?

Yes, I monitor CPU in systray and they're both about the same, so I'm pretty sure hardware acceleration is still working in FF. Also, it usually corrects itself before making it through the first loop, especially longer loops.

As I said before, I can click the link above, which opens it on a new page and it auto-plays fine.

Hmm, I'm not sure what we could use to identify this to blacklist it. I've only seen one report of this pink/green bug, so unless we want to blacklist this precise driver/gpu configuration (which would be a bit silly) it's hard to know everything that could be affected.

This issue has obviously been deemed "not that important", since it doesn't affect many users, but I wanted to pass on a fix for the pink/green html5 on AMD GPU's if anyone else experiences it. Mine was caused by a driver issue. The graphics are switchable and deemed "legacy" (60xx series, but a few others are included). The drivers Windows installed were a fairly old 13.xx version. 

The problem with updating was that the most recent version of Catalyst 15.7.1 isn't compatible with switchable graphics. It was all kinds of buggy and unusable.

After a lot of digging, I found that AMD had made one last legacy driver that is compatible with switchable graphics:

http://support.amd.com/en-us/kb-articles/Pages/AMD-Radeon-Software-Crimson-Edition-16.2.1-for-Non-GCN-Products-Release-Notes.aspx

I did have to tweak the display temperature from 6400k to 6500k, but the pink/green html5 issue is resolved (without any command line switches).

Unfortunately the issue with some gifs starting black and distorted is still present (regardless of command line switches). It does seem to occur less often and for shorter amounts of time, but is still incredibly annoying. 

If anyone has any ideas about switches/flags to try, I'd be more than happy to try them.

#23: The only major difference between FF and Chrome's use of hardware decode on Windows is that Chrome uses a low-latency mode. Perhaps this mode is buggy on non-GCN hardware? (c.f. https://bugzilla.mozilla.org/show_bug.cgi?id=1141139)

We may be able to build a toggle for this and test out on Canary; the only other alternative I see is blacklisting non-GCN switchable devices.

Your previous gpu.html does not show that switchable was detected. Is this still true with the driver you linked to?

Doe VP8/VP9 videos experience any corruption?

Thanks for the response. Switchable graphics are disabled for browsers by Catalyst/Crimson. It only uses the on-board graphics. If low latency was recently introduced and it's the only real difference between Chrome and FF, that sounds promising. 

Blacklisting altogether would suck. Hardware acceleration works really well besides this one issue, and without it CPU usage skyrockets. 

By VP8/VP9 do you mean Webm? Either way, I've only ever noticed it with mp4's.

Unfortunately, low latency is not a recent feature, Chrome has been using it for a very long time.

Just to reiterate, for the most part gifs/vids that start black/distorted are typically only ones that either autoplay on their own, or autoplay when hovered, like video previews.

Well, the prevalence of autoplaying gif/videos is a fairly recent practice, so maybe it's exposing an issue that was already dormant? 

I found another example site where I can reproduce this bug with amazing accuracy. Obviously NSFW: http://yourporn.sexy/

Exactly every 6th hover preview hovered starts black and distorted. Every preview hovered after that does as well until the page is reloaded.

It's worth noting that the site seems to be coded horribly in general. I tested it on my other computer (which has never had graphics issues), and it is buggy in different ways. Once you start hovering previews, CPU never seems to fully release. The more you hover, the worse it gets. After hovering a lot on my other computer, the playback of the hover previews started to glitch and stutter, and eventually CPU skyrocketed and Chrome crashed.

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

commit 57d5eddcbc0407ee50a2b63acc3eac5ffb4f27cc
Author: sandersd <sandersd@chromium.org>
Date: Tue Nov 08 00:28:36 2016

DXVA: Add --disable-low-latency-dxva to disable low latency decoding

BUG=625011
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/2472173002
Cr-Commit-Position: refs/heads/master@{#430439}

[modify] https://crrev.com/57d5eddcbc0407ee50a2b63acc3eac5ffb4f27cc/content/common/gpu_host_messages.h
[modify] https://crrev.com/57d5eddcbc0407ee50a2b63acc3eac5ffb4f27cc/content/public/browser/gpu_utils.cc
[modify] https://crrev.com/57d5eddcbc0407ee50a2b63acc3eac5ffb4f27cc/content/public/common/content_switches.cc
[modify] https://crrev.com/57d5eddcbc0407ee50a2b63acc3eac5ffb4f27cc/content/public/common/content_switches.h
[modify] https://crrev.com/57d5eddcbc0407ee50a2b63acc3eac5ffb4f27cc/gpu/command_buffer/service/gpu_preferences.h
[modify] https://crrev.com/57d5eddcbc0407ee50a2b63acc3eac5ffb4f27cc/media/gpu/dxva_video_decode_accelerator_win.cc
[modify] https://crrev.com/57d5eddcbc0407ee50a2b63acc3eac5ffb4f27cc/media/gpu/dxva_video_decode_accelerator_win.h

thereal...@: This new flag has now shipped in Canary (56.0.2913.0). Can you test with --disable-low-latency-dxva and report on the result? (Probably best to include a copy of chrome://gpu as per usual) Thanks!

Had my hopes up, but no joy. The two example sites are still the same. 9gag.com autoplay gifs randomly start black and distorted, typically after having scrolled quite a bit. And yourporn.sexy hover previews do the same, but start like clockwork on every 6th preview hovered, and every subsequent preview hovered until a reload.

I really appreciate the effort. I'll attach the readout:

Deleted: gpu.html 100 KB

gpu.html 100 KB View Download

It may be worth mentioning that when I posted this issue, I was using an older driver. Firefox worked fine with that one, but when I updated to the last/latest driver, Firefox had it blacklisted. I kept checking releases, and they appear to have fixed whatever was wrong, because the beta I have now (v50) isn't blacklisted anymore. Hardware acceleration works well and it doesn't have any graphics issues. Perhaps they figured something out.

The problem is I really prefer to use Chromium. This issue isn't bad enough to make me switch, since it happens infrequently on a few sites, but it'd really suck if it gets worse.

I'll take a look through Mozilla's blacklist history to see if there is something specific I am missing.

Looking back through this thread, I don't see D3D11 mentioned at all. Have you tested --disable-d3d11?

FYI: As far as I can tell, AMD driver version 15.301.1901.0 is still blacklisted in Firefox: https://hg.mozilla.org/mozilla-central/file/aea5b4c3d165/widget/windows/GfxInfo.cpp#l942

Still blacklisted in stable, yes, but version 50+ (beta, dev) both have hardware acceleration working well with no issues. I can tell by CPU consumption alone, but also verified in about:support.

I hadn't tried that flag, but I just did. No such luck.

I looked up the original bug report listed in the blacklist you linked:

https://bugzilla.mozilla.org/show_bug.cgi?id=1301615
 
It confirms that it was de-blacklisted in v50+. There didn't appear to be any useful revelations though. It mostly says that it was confirmed that the blacklist was too broad and that the driver bug affected a small amount of users and mostly only Win10.

Another observation on this issue. Like I mentioned previously, I can reproduce the issue on 9gag.com, but it always occurs after viewing multiple gif/videos and scrolling quite a bit. I can reproduce the issue on [NSFW] yourporn.sexy like clockwork on every sixth hovered preview. 

I was scrolling through 9gag and inevitably a gif started black and distorted, so I opened the other problem site in another tab, and the hover previews were immediately distorted on hover. I closed the 9gag tab and reloaded the yourporn.sexy page and it was back to every sixth hovered preview starting distorted. 

I tested the same scenario multiple times with the same results. I won't pretend to know how browsers function internally, but it certainly seems like some buffer/memory limit is being exceeded because it isn't clearing/resetting properly, or something along those lines. 

I mention recently that I could repro the issue to the exact number (6) of hover-previews hovered on [NSFW] yourporn.sexy, which certainly makes it seem like there is some sort of limit being reached. I've been occasionally checking out Canary releases to see if anything is improved, and while the issue is still present, whatever limit appears to have doubled.

Version 54.0.2840.99 (64-bit) = 6th hovered preview begins corrupted

Version 57.0.2926.0 (64-bit) = 12th hovered preview begins corrupted

Every page-load, like clockwork.

Something must have been altered slightly, so I figured it may be insightful. 

Also, once the 6th (stable) or 12th (Canary) start corrupted, all subsequent previews hovered do as well, but returning to hover one of the previous ones before the first corrupt one, results in it playing fine like it did the first time.

I was googling this issue again to see if I could find anything new, and I found something old instead:

http://www.tomsguide.com/answers/id-2699782/videos-dark-run-play-normal.html

About halfway down the page, user "liquidzorch" posted pretty much an identical issue. Same OS, AMD, pics and description look the same. They even sited the videos on 9gag as I did. 9gag and the other site mentioned here are the only places it happens regularly. This post was made a full year before I posted this issue here, which may be insightful.

They "solved" it by disabling hardware acceleration, which isn't really solving anything, and what I'd prefer to avoid since my CPU isn't all that powerful. Since the bug is limited to a couple sites, utilizing hardware acceleration is still very worth it.

https://www.reddit.com/r/RESissues/comments/58nclf/bug_gifswebm_showing_out_pixelated_at_the_start/d9acpba/

Like OP says, on AMD it seems to occur when a limit is reached.

This is still an issue in stable right through dev for me. As I've previously stated, I have no issues with regular videos, only certain sites with auto-play gifs or hover previews. There is definitely a very consistent hard limit which, when it's reached, from then on they all begin corrupted until the page is reloaded. 

For instance NSFW http://www.porntrex.com/

Every 10th or 11nth hover preview begins corrupted, as are all subsequent hover previews until the page is reloaded. 

The reason I'm making a new plea is that I do have some new info that I'm hoping will be enlightening to someone more knowledgeable. My previous GPU readouts didn't have much to go on as far as errors. 

When playing around with drivers to correct these issues, I found a leshcat modded version of the last non-GCN AMD made available. The bonus was it had a quicker boot time and unlocked some options, like specifying switchable graphics for particular programs which were previously locked. I tried switching Chromium to the more powerful graphics card at the time, but it wasn't compatible at all. I figured it had been a while so I should give it another shot, and now it works pretty well, but it also has issues in the exact same scenarios, but handles them differently.

On the above test site, it also glitches on the 10th or 11nth hover preview, but instead of corruption from then on, it has a very quick mini crash/recovery, so there's a more informative readout. When I say quick, I mean like a second, and it doesn't even register with Radeon settings.

Anyway, like I've mentioned before, this laptop isn't really powerful enough to disable hardware acceleration. The bug is really annoying, but the scenarios in which it occurs are rare, and I really prefer Chromium, so I've learned to live with it. I am really hoping that this new readout info will help somebody figure out why this is happening, and finally provide any type of solution. I've tried so many flags and switches, but I keep thinking I just haven't tried the right one, or combo. TIA

Deleted: gpu.htm 120 KB

gpu.htm 120 KB View Download

Cleaning up sheriffbot label "Needs-Review" label as a part of modified "Needs-Feedback" sheriffbot rule. [ref bug for cleanup 684919]

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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