Closed DedZasshu closed 1 month ago
Confirm. Blocky artifacts clearly visible. Most obvious segment 00:18 to 00.21 and starting at 01:48
Also happens with DXVA2-cb.
Confirm. Blocky artifacts clearly visible. Most obvious segment 00:18 to 00.21 and starting at 01:48
Also happens with DXVA2-cb.
Yeah, I also tried using that and D3D11 (Copyback) and still got the same results.
I can see the artifacts when I use nvidia card to decode (d3d11 native or copyback), but not when I use integrated intel 750 (d3d11 copyback).
I can see the artifacts when I use nvidia card to decode (d3d11 native or copyback), but not when I use integrated intel 750 (d3d11 copyback).
My A380 can playback without much issues using d3d11 copyback, too. So it probably is some NVIDIA hwdec bug or something. Which, again, makes me wonder how YouTube got it to work properly with NVIDIA hwdec...
test with ffplay -hwaccel vulkan don't have the artifact
all others either have artifacts or just don't display anything, the no display part is due to ffplay uses vulkan renderer when hwaccel is enabled, and some hwaccel is incompatible with it, I think.
then I use ffmpeg to do hwdec then transcode, every hwaccel that is compatible with my hardware can output image, vulkan decoder is still the only one that have no artifact, others are dxva2, d3d11va, d3d12va and cuda (nvdec I guess), all have artifact.
I also tried the deprecated (iirc) cuvid method, like ffmpeg -c:v vp9_cuvid -i xxx
and also found no artifact. lavfilters also have it.
And browsers use Media Foundation interface, not DXVA/D3D11/D3D12.
And browsers use Media Foundation interface, not DXVA/D3D11/D3D12.
So I'm guessing it's a DirectX/Direct3D related bug?
Media Foundation uses D3D11/12.
The main difference is the decoder implementation that feeds the hardware decoder. FFmpeg vs MS.
Media Foundation uses D3D11/12.
The main difference is the decoder implementation that feeds the hardware decoder. FFmpeg vs MS.
Ah, so it's an FFmpeg bug.
Please try https://files.1f0.de/lavf/nightly/LAVFilters-0.79.2-2.exe, it seems to work now on my end.
There is also this patch https://patchwork.ffmpeg.org/project/ffmpeg/patch/CZHCF9QL07FJ.3VOACXA14QCVF@yukari.in/ that possibly fixes more hwdecs than patching in dxva2_vp9.c
.
For reference: https://github.com/mpv-player/mpv/issues/13533 https://github.com/mpv-player/mpv/issues/14193
Please try https://files.1f0.de/lavf/nightly/LAVFilters-0.79.2-2.exe, it seems to work now on my end.
Oh wow, it works! Can't wait for it to be integrated into MPC-HC (w/ K-Lite Codec Pack!)
There is also this patch https://patchwork.ffmpeg.org/project/ffmpeg/patch/CZHCF9QL07FJ.3VOACXA14QCVF@yukari.in/ that possibly fixes more hwdecs than patching in
dxva2_vp9.c
.For reference: mpv-player/mpv#13533 mpv-player/mpv#14193
That would be great to improve LAV as much as possible.
I think this should be good enough to close this issue since it's been noticed and being taken cared of.
Edit: Actually, just going to reopen until the fix is pushed on a stable release.
Issues are historically closed when fixed, releases happen when they happen.
I've noticed that in some YouTube videos, when trying to watch in HDR, they show blocky artifacts when trying to playback using hardware decoding on MPC-HC (or even MPV's d3d11va). They playback fine if I disable hardware decoding, which would make me assume that it's a hardware bug or something, but somehow YouTube can playback the same videos just fine using hardware decoding without any blocky artifacts.
Here's one example of what's going on:![Gamut Rings_ A better way to measure color 5_19_2024 10_05_43 AM](https://github.com/Nevcairiel/LAVFilters/assets/100014532/62fb2f13-d2e4-4578-b5a2-74b0b7eb4214)
And here's the mediainfo for that video: mediainfo.txt