AV1 hardware decode not being used on Tigerlake (warning lots of images).

[nathanielcwm]

The built in filters on clsid2/MPC-HC 1.9.10.44 were replaced with the release of 0.75 Using a test clip I observed that frames were being dropped and that the video was unable to be played in sync with the audio.

Forced on D3D11:

Forced on DXVA2 copy:

Only video processing is loaded not video decode:

Same video being played on the Microsoft shit:

Video being played through Edgium:

i5-1135G7 Windows 10 20H2

[nathanielcwm]

BTW looks like Tigerlake supports grain synthesis in hardware. Using the Netflix Sparks test clip a noticable amount of grain is added when played through the Microsoft app.

CPU usage remains < 5% throughout the entirety of playback unlike when played through VLC,which doesn't support hardware acceleration of AV1, where CPU is always around 5-20%

It looks like the Netflix sparks clip plays fine with hardware acceleration in MPC-HC so here's the test clip that I was using: https://cdn.discordapp.com/attachments/677266163994198020/800842367929286676/llama-song.webm

[nathanielcwm]

If I switch to madVR the issue goes away so it may be a problem with MPC-HC's directshow output.

[clsid2]

D3D11 native is only supported by madVR and MPC-VR. Other video renderers will use D3D11 copyback.

[nathanielcwm]

With LAVFilters 75-2 I can confirm that forcing copy back for D3D11 makes it use hardware decode. @clsid2

Unfortunately it's still experiencing video freezing and desyncs that aren't experienced with madVR.

DXVA2 native and copyback still doesn't appear to be working

[nathanielcwm]

Something else I found that's extremely weird. Even with forced copyback on D3D11 using both EVR and madVR H264 is not using hardware acceleration. Both native and copyback DXVA2 use hardware acceleration perfectly fine tho...

Main@L3.1 so I doubt it's an issue with the video.

[clsid2]

EVR-CP is an inferior renderer compared to madVR and MPC-VR.

If either DXVA2 or D3D11 is not working, you need to go complain to Intel to fix their drivers. Only test with 8-bit H264, because acceleration is not possible with 10-bit.

[nathanielcwm]

Yes as I said in my comment, albeit after the edit, it was an 8 bit H264 track.

Ye prolly good idea to check for GPU driver updates, I'm currently using the one from Windows Update which is expected several versions old.

Looks like in the versions between what I had and the latest there have been some fixes related to video playback so it may have well and truly just been borked drivers from Intel.

[Nevcairiel]

I heard some talk about Intel discontinuing D3D9/DXVA2 support. Not sure if thats true.

[nathanielcwm]

Chromium only supports AV1 decode with DXVA2 rn so I doubt that a lack of support is the issue.

Looks like DXVA2 is broken in madVR too.

[nathanielcwm]

Unfortunately, both issues still persist on latest driver.

It looks like h264 being broken is exclusive to the test vid I was using tho... https://billwurtz.com/might-quit.mp4

AV1 issues persist on other AV1 clips I have on this machine tho...

[Nevcairiel]

The driver probably rejects that file due to the odd dimensions, which are technically invalid for the format its using.

[nathanielcwm]

Strange that the Microsoft shit and VLC are using hardware decode...

Oh well H264 is very light now so it doesn't really matter.

I'm literally only getting around 3% cpu playing the bill wurtz vid and my cpu freq is only 2ghz vs 1.5ghz when using the hardware acceleration.

vlc.log

[ale5000-git]

@clsid2: Why MPC-HC still saying Playing [H/W] on might-quit.mp4 even though hardware acceleration is not used?

Is this a bug?