+jbauman@, don't think we have hardware overlay support on these cards but you might try --enable-features=DirectCompositionComplexOverlays on 60+ to see if it helps.

I wonder if we're hitting one of our copy cases through this.

jbauman@ also just landed a361008fed7d9652a62fb548c7ea9a89fc3d2ce5, which is in 61.0.3113.0 or higher, so you might try canary.

Haha whoops no I just misread the media-internals page. It's not hardware-accelerated, because of 

https://cs.chromium.org/chromium/src/media/gpu/dxva_video_decode_accelerator_win.cc?rcl=0efa58326c8a9203c0d44a5266b64742e9ad01ed&l=1294

Hah. I wonder if we can just use the same H264 capabilities probing code we have for VP9? I'll experiment tomorrow and see.

Hmm, seems like the H264 code doesn't check 8k either, so probably need to add that too :)

cc: sandersd, hubbe in case they want to take a stab. Otherwise I'll find time tomorrow to try and take a look.

https://chromium-review.googlesource.com/c/520228/ should do the trick, don't have a windows box today so that probably doesn't even compile though. Not sure if we actually need to test all those resolutions for vp9 since we previously had a flat max of 4k. 

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

commit 20e5380ed3158207bc2820b2438c632e1c726a3c
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon Jun 05 20:20:46 2017

Test for 8K resolutions in H264, add VP8/9 resolution testing.

This expands the Windows hardware decoder to allow up to 8K
hardware decoding for both VP8/9 and H264.

BUG= 728296 
TEST=tbd

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: Ia56aa19fec6a8e6cb0694992eb0b69f453d4768e
Reviewed-on: https://chromium-review.googlesource.com/520228
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: John Bauman <jbauman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#477068}
[modify] https://crrev.com/20e5380ed3158207bc2820b2438c632e1c726a3c/media/gpu/dxva_video_decode_accelerator_win.cc
[modify] https://crrev.com/20e5380ed3158207bc2820b2438c632e1c726a3c/media/gpu/dxva_video_decode_accelerator_win.h

jbauman@ commented on the review in c#9:

"Using a GTX 1080 in Chrome it's working pretty poorly, but with the Intel Kaby Lake it seems pretty good (maybe because of the overlay support). It's a dual-GPU system, so Edge seems to always be using the Intel GPU, which works well for it."

+nvidia folks who might care about this.

To be clear, we're not sure if it's a compositing issue or decoding issue; so it may be totally our fault.

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

commit aecefa0882b4fe9dc4bf01e271991a289b7f99a7
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Jun 07 17:01:48 2017

Remove support for 8k h264; doesn't seem to work anywhere.

BUG= 728296 ,730016
TEST=none

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: I5b4bf59b41f253cac5965f14844a1321615adcd2
Reviewed-on: https://chromium-review.googlesource.com/526395
Reviewed-by: John Bauman <jbauman@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#477686}
[modify] https://crrev.com/aecefa0882b4fe9dc4bf01e271991a289b7f99a7/media/gpu/dxva_video_decode_accelerator_win.cc

8k vp9 is enabled on latest canary; only seems to work well on Intel Kaby Lake at present, not the 1080 nvidia cards per jbauman@ -- so renaming this issue back to its original to reflect the choppiness issue.

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

commit d7f3b9d8756dde36a6e551186e04fb879b2ea9e2
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Fri Jun 09 17:08:34 2017

Bump maximum tile sizes for libvpx video decoding.

We're starting to see experiments with videos beyond 4k, so bump
the maximum useful number of threads for these rare clips.

BUG= 728296 
TEST=manual

Change-Id: I080b73837fffac62c77f5c71de970a273db8561f
Reviewed-on: https://chromium-review.googlesource.com/525134
Reviewed-by: Thomas Guilbert <tguilbert@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#478314}
[modify] https://crrev.com/d7f3b9d8756dde36a6e551186e04fb879b2ea9e2/media/filters/vpx_video_decoder.cc

Navigated to "https://www.youtube.com/watch?v=1La4QzGeaaQ" on Windows 10 Creator update (Version 1703 OS Build 15063.296) withIntel Core i5-2400 CPU @ 3.10 GHz with 8.00 GM RAM on a 64 - bit operating system.
Used NVIDIA Quadro 400 Direct 3D11 vs_4_1 ps_4_1.

The videos played were HD (Resolution: 1920 x 1080 @ 60) played very smoothly without any lagging or choppy. Please let me know if any more information is required.

@dalecurtis -- Could you please confirm so that we can go ahead by adding Verified labels which would help us in triaging the issue.
Thank You.

msrchandra@ you don't have the right hardware to test this. You'll need a NVidia 10 series or Kaby Lake CPU to verify. You'll need to manually adjust the quality to 8K too.

strobe: I can't seem to get the 8K option on my home computer. Is this an internal IPs only stream?

nm, I had HDR enabled.

I can repro jbauman@'s results, the video generally plays well with my GTX 1080 on the latest canary, but at ~t=20-30s and t=1m33s there are severe underflows.

Picture quality is great though :)

dalecurtis@, thank you for the update!

I think some of the remaining issues might be compositing related, as 8k vp9 playback @ 1080p scaling plays smoothly. But 8k @ 4k still sees some hitches.

John do you expect any of your newer zero copy work to improve the playback here?

Unfortunately VP9 is still stuck at 1-copy on NVIDIA, both due to limitations in microsoft's MFT and in NVIDIA's drivers. On Intel with overlays it should be more efficient, though.

checking with driver folks on NVidia side. 

amalp@ any updates on the driver side of things?

dale, sorry haven't received an concrete update yet but will provide some update soon. 

When streaming 8K Youtube videos on Chrome it does not maintain video aspect ratio, it happens only when desktop resolution is 8K and video stream resolution is 8k.
Observed on Google Chrome release and Canary build

Hmm, I don't have an 8K monitor. strobe@, did you ever get one?

I did. The issue reported in #27 is  crbug.com/728303  .

Doh, right I forgot about that one. Sorry!

After a bit more looking, I don't there's anything more we can do until zero-copy can be supported with Microsoft's VP9 MFT; per the comments in the source code:

  // The MS VP9 MFT doesn't pass through the bind flags we specify, so
  // textures aren't created with D3D11_BIND_SHADER_RESOURCE and can't be used
  // from ANGLE.

https://cs.chromium.org/chromium/src/media/gpu/dxva_video_decode_accelerator_win.cc?l=1732

The MSDN docs say the MFT is welcome to ignore these flags unfortunately:
https://msdn.microsoft.com/en-us/library/windows/desktop/hh162890(v=vs.85).aspx

I played around this this a bit more and it still seems broken. Forcing zero-copy on for a GTX 1050 Ti + Windows 10 Creators, just crashes the GPU process unfortunately:
[1201/141601.992:ERROR:gles2_cmd_decoder.cc(16392)] : Onscreen context lost via ARB/EXT_robustness. Reset status = GL_UNKNOWN_CONTEXT_RESET_KHR
[1201/141601.994:ERROR:gles2_cmd_decoder.cc(4460)] : GLES2DecoderImpl: Context reset detected after MakeCurrent.
[1201/141601.995:ERROR:gpu_command_buffer_stub.cc(492)] : Context lost because MakeCurrent failed.
[1201/141601.996:ERROR:gpu_channel_manager.cc(200)] : Exiting GPU process because some drivers cannot recover from problems.
[1201/141601.998:ERROR:gpu_channel_manager.cc(200)] : Exiting GPU process because some drivers cannot recover from problems.
[1201/141601.999:ERROR:gpu_channel_manager.cc(200)] : Exiting GPU process because some drivers cannot recover from problems.
[1201/141602.000:ERROR:gpu_channel_manager.cc(200)] : Exiting GPU process because some drivers cannot recover from problems.
[1201/141602.001:ERROR:gpu_channel_manager.cc(200)] : Exiting GPU process because some drivers cannot recover from problems.
[1201/141602.003:ERROR:gpu_channel_manager.cc(200)] : Exiting GPU process because some drivers cannot recover from problems.
[1201/141602.004:ERROR:gpu_channel_manager.cc(200)] : Exiting GPU process because some drivers cannot recover from problems.
GpuProcessHostUIShim: The GPU process crashed!

Seems to work fine for H264 though, so we should probably update the blacklist to allow dxgi sharing with newer nvidia drivers, fix here:
https://chromium-review.googlesource.com/c/chromium/src/+/804634

+ericde do we have a contact at Microsoft for VP9 MFT we can reach out to about this?

@amalp/nvidia: Please let us know if NVIDIA has any insight to this.

Microsoft got back to us and indicated that the problem was we were setting the bind flags after calling SetInputType/SetOutputType. The flags must be set before that point to ensure their propagated correctly. They also indicated they'll look at updating the MSDN documentation to indicate this.

With https://chromium-review.googlesource.com/c/chromium/src/+/855532 I was able to play 8K60 VP9 smoothly on my GTX 1050 Ti.

Notably the above should improve power and performance for VP9 at all resolutions where zero-copy is supported. Additionally it may help some H264 cases where we may have been ending up with multiple surfaces created due to our previous call ordering.

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

commit da423c06083f11051f266f7cb535b7eb40f6458d
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Tue Jan 09 19:50:01 2018

Enable zero-copy dxgi sharing for vp9 mft. Requires setup reorder.

Per discussions with Microsoft we need to set these bind flags
before calling SetInputType/SetOutputType. Doing so fixes the
crashes we get with DXGI sharing and the VP9 MFT!

With this 8K60 VP9 playback is now flawless and likely uses
much less power since it's zero copy! Tested on GTX 1050Ti.

BUG= 728296 
TEST=8K60 vp9 playback is smooth.

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: I936295aa9e84fbdf5290435c93b437807cfb3625
Reviewed-on: https://chromium-review.googlesource.com/855532
Reviewed-by: Frank Liberato <liberato@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528079}
[modify] https://crrev.com/da423c06083f11051f266f7cb535b7eb40f6458d/media/gpu/dxva_video_decode_accelerator_win.cc

This is present in 65.0.3317.0+, let me know if you see any issues.