Zijie, can you see if you can repro this using WebRTC? You might need to borrow a Kevin machine from Wez.

Still cannot reproduce on my device. Are you using a Samsung Chromebook Plus (Arm) or Pro (X64)?

Deleted: Screenshot 2017-11-06 at 18.04.13.png 2.0 MB

	Screenshot 2017-11-06 at 18.04.13.png 2.0 MB View Download

Wez, do you think this might be related to  bug 780701 ? It looks like the same device, and although that bug doesn't mention VP9 and the symptom is a white screen rather than garbage, it seems like it might be related.

I was using a Chromebook Plus (ARM). This issue only repro'd for me with VP9; VP8 worked fine on the same device.

OK, wrong device again. I will loan a plus and have another shot.

Let me know if I should bring in my Plus for you to try out. :)

Got a clear and loud reproduce when decoding VP9 in Chrome. It looks like a hardware specific issue and should be fixed in VP9 decoder.

Deleted: Screenshot 2017-11-08 at 16.57.17.png 529 KB

	Screenshot 2017-11-08 at 16.57.17.png 529 KB View Download

Possibly related to 780701. It's the same device, although that bug is for vp8 decode and results in a blank screen rather than garbage pixels.

I am not an appropriate owner for this. I can't be sure that this isn't a bug in the way we encode vp9 video in Chrome Remote Desktop (specifically, we were not able to reproduce the problem playing back a VP9-encoded video), but we've only been able to repro it on this device, and it repros with either the Pepper video decode/render APIs and with WebRTC+<video>.

zijiehe: Can you confirm that you were able to repro this issue both with Chromoting configured for VP9, and with WebRTC configured that way?

If so then this sounds like a issue for the ChromeOS team to look into.

I have not found a way to configure WebRTC to use VP9. We can enable VP9 through WebRTC + <video>, but it still goes through Chromoting encoding pipeline.

Do you mean that that is running over WebRTC, but using the VideoEncoderVpx
(https://cs.chromium.org/chromium/src/remoting/codec/video_encoder_vpx.cc)
to do the actual encoding?

If so then I'd suggest checking whether things are still broken with
different combinations of lossless colour & encode enabled/disabled.  You
might also try hacking the encoder not to try to use "cyclical" encoding:
https://cs.chromium.org/chromium/src/remoting/codec/video_encoder_vpx.cc?q=VideoEncoderVpx&sq=package:chromium&l=148
when running in lossy mode.

any update on this bug?

What's the latest status here?

Ping for triaging.