h/w decoding related.

Are both ends Linux?

I was able to reproduce this with both ends running Linux (same machine), but it doesn't matter what you have on the client side and should repro with non-linux client as well.

I assume then by 'Hardware Accelerated', you mean hardware accelerated compositing is enabled on the remote end?

When I uncheck "Use hardware acceleration when available" check box in chrome://settings on the _host_ side (where youtube.com is open) then everything works. I don't know if that check box affects anything beside compositing.

I am unable to reproduce this on my machines using any combination of Chrome versions and --ignore-gpu-blacklist. Can you be more precise about the versions, flags, and hardware, and include the contents of chrome://gpu and chrome://media-internals for the host side?

I've got the same problem both in beta and stable. Upgrading from M49 to M50 makes any animated content to not render anything, it plays audio correctly but not the video, the webpage space is "dead" (moving another window above does not repaint the space properly). I simply downgrade to M49 again to solve this issue.

I include M49 and M50 chrome://gpu printouts.

Deleted: chrome-gpu m49.pdf 130 KB

chrome-gpu m49.pdf 130 KB Download

Deleted: chrome-gpu m50.pdf 133 KB

chrome-gpu m50.pdf 133 KB Download

Chrome version on the client side doesn't matter. The bug will reproduce even with our android client. 
here is chrome://version :

Google Chrome	51.0.2704.7 (Official Build) dev (64-bit)
Revision	a8bebc2b0cd3e3018b7c9f6ac698f04dd226abba-refs/branch-heads/2704@{#48}
OS	Linux 
Blink	537.36 (@a8bebc2b0cd3e3018b7c9f6ac698f04dd226abba)
JavaScript	V8 5.1.281.6
Flash	21.0.0.217
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.7 Safari/537.36
Command Line	/opt/google/chrome-unstable/google-chrome-unstable --user-data-dir=/usr/local/google/home/sergeyu/.config/google-chrome-unstable --user-data-dir=/usr/local/google/home/sergeyu/.config/chrome-remote-desktop/chrome-profile --user-data-dir=/usr/local/google/home/sergeyu/.config/chrome-remote-desktop/chrome-profile --window-depth=24 --window-depth=24 --flag-switches-begin --flag-switches-end

I've attached chrome://gpu and chrome://media-internals. 

Note that the problem will not reproduce in Remote Assistance mode, when chrome renders to a real X session. It's only an issue with chrome running in a virtual Xvfb session.

Deleted: gpu.html 49.2 KB

gpu.html 49.2 KB View Download

Deleted: media-internals.html 10.3 KB

media-internals.html 10.3 KB View Download

I was finally able to reproduce this. The root of the behavior is actually the contents of the 'Local State' file in the user data dir, which means that the first time you launch Chrome with a profile, it works fine.

Specifically, if I delete the {"gl_vendor_string": "VMware, Inc."} entry before launching Chrome (or set it to its non-CRD setting on my machine, {"gl_vendor_string": "NVIDIA Corporation"}), everything works fine.

dcastagna: Can you suggest someone who knows about these sorts of GPU configuration settings?

I am not using CRD, I don't even know what it is, however I came across this bug report which seems related to the issue I am having so I am adding this comment.

Everything was normal with Chrome up to version 49.x, however with Chrome version 50:
videos in Youtube and Facebook: I get sound but no video (it messes up the screen a bit)
gifs in Facebook don't work (it messes up the screen a bit)

Per comment #5 I unchecked "Use hardware acceleration when available" tick box in chrome://settings and that fixed my issues.

I am using Fedora 23, Nouveau driver, “nouveau.noaccel=1” boot option.

Comment 11 by grok...
>I am not using CRD

Yes mee too, I forgot to write that.

>Per comment #5 I unchecked "Use hardware acceleration
> when available" tick box in chrome://settings and that fixed my issues.

Yes, fixed it for me too!
Most likely something changed between M49 and M50 in the code that checks if the HW-accel *actually* works or not.

Sten, glad that worked for you.

Anyway, I re-enabled hardware acceleration and removed "gl_vendor_string": "VMware, Inc." per comment 10, restarted Chrome, and that also solved my issues... however after I closed Chrome again and restarted it, the issues came back! The reason is that Chrome put back in Local State the "gl_vendor_string": "VMware, Inc." that I had removed.

In other words, of the two workarounds mentioned here only the one in comment #5 really works after one restart.

Unrelated to this issue, I have no clue why the vendor is "VMware, I thought it was Google! :-)

zmo@: you seemed to have implemented the GL strings caching logic long time ago, do you have any idea what the problem described in #10 could be?

groknok, what you are looking at is the "GL" Vendor.