LAV Filters - DirectShow Media Splitter and Decoders

[NikosD]

In this recorded video, it seems that Cybelink's H.264 DXVA decoder works fine, without errors using Polaris cards.

For the same clip LAV filters DXVA H.264 decoding gives errors.

https://drive.google.com/file/d/0B2T...83bmRPYkU/view

There are only two cases for the video above:

1) Cyberlink has managed to use H.264 DXVA in a different way than LAV filters for Polaris cards, without errors.

2) Cyberlink has managed to identify the specific clips that cause trouble to Polaris cards and use CPU as a fallback to DXVA HW acceleration, without warning to the users.
So although it says that it uses DXVA HW acceleration in general, the truth is that for those specific clips it falls back to SW decoding.

I personally believe it's the second case, so in order to be sure, someone can show us CPU usage for the specific clip using Cyberlink H.264 DXVA and LAV filters H.264 DXVA.

UPDATE:

It seems that Cyberlink's H.264 DXVA decoder works with 2% CPU usage, so there is probably an incompatibility with LAV DXVA H.264 decoder and Polaris HW decoder/driver.

[clsid]

That file does not contain H.264 video. It is H.263.

[NikosD]

How do you know ?

And there is no HW acceleration for H.263 files.

In AMD's forum there are a lot of H.264 files including mine, that can play fine with Cyberlink's H.264 DXVA decoder.

The issue could be a proprietary non standard implementation of DXVA H.264 decoder by AMD for Polaris driver/HW that causes problems with free/ open source projects like LAV filters that Cyberlink has managed to resolve.

[huhn]

it is not that clear that the video shows the problem but is not the problem it self.
and there is hardware acceleration for h263.

[nussman]

"Cyberlink's DXVA Decoder" always works "different" with special workarounds for special circumstances.
Especially for LiveTV this is very well known.

Anyway ... LiveTV H.264 is working with LAV (and MS Decoder) for years now with every other hardware. I still think its AMD to blame ...

[huhn]

i guessing doesn't fix this issue and if AMD polaris needs special treatment why isn't AMD providing a patch for FFmpeg this is the really strange part!

[nevcairiel]

There is so many things AMD could do to resolve such issues -

- Fix them in the drivers
- Send patches to open-source projects like FFmpeg to work-around their quirks
- Or at the very least, document their quirks somewhere so developers can work around them themselves.

Of course anything but the first option feels a bit silly, vendor-specific quirks for *new* hardware in 2017 is just crazy, but if they can't do 1, then any other option is better then doing nothing.

There is also the simple option of it being a subtle bug somewhere in FFmpeg or LAV and not an actual quirk, but then again AMD could follow option 2 or 3 and reach out to FFmpeg, which powers the large majority of all media players out there.

[NikosD]

I tried today MS DS and MS MFT H.264 DXVA decoders and have both the same problems as LAV during playback and seeking.

It would be a crazy coincidence if the decoders of the developers of Microsoft and FFMPEG (LAV) had exactly the same bug.

Also, I think now that it's not proprietary DXVA implementation because you couldn't use it at all.

It's probably what you call quirks, but hopefully it's not hardware (since Cybelink seems to work OK)

[clsid]

Hi nev, which toolchain are you currently using? I tried MSYS2 since the MSYS pack from XhmikosR that I used has some old libs (like openssl, which gives issues, see mpc-hc tracker). FFmpeg builds fine. But VS gives "error LNK2026: module unsafe for SAFESEH image" for x86 build. Disabling SAFESEH is of course bad idea. Do you perhaps have any tips?

[nevcairiel]

I use MSYS2 with my own compiler (https://files.1f0.de/mingw/ - which is the same compiler build XhmikosR packages in his MSYS1 zips)

I doubt that MPC-HC uses OpenSSL though, and LAV certainly doesn't (it uses the Windows TLS/SSL support, and no, I'm not interested in silly reports of XP not supporting websites which require new encryption schemes).

[clsid]

It is working properly again with your GCC build. Thanks. Should have tried that earlier. I am curious why their vanilla mingw build didn't work.

[aufkrawall]

Would "native" CUDA decoding require a backend in the video renderer?
I tried it with mpv and it seems to give me by far the lowest overhead on both GPU and CPU, compared to copyback modes (on Linux too, btw.).

[nevcairiel]

Yes, it would. If you want absolutely minimal overhead then DXVA Native is your only choice.

[MisterXDTV]

Does or will LAV Video support DXVA for VP9 Profile 2 (10 bit) videos from youtube? I can't hardware decode it with LAV decoder no matter what I select (native, copy-back, NVIDIA CUVID). With another decoder it works fine

[NikosD]

OK...

So, with the release of the new non-WHQL AMD driver 17.2.1, the decoding problem of corrupted image during playback and seeking with DXVA ffmpeg based decoders, like LAV and the H.264 video files (MBAFF, progressive, interlaced) using Polaris cards, has gone.

The image is fine like all other HW decoders from AMD, Nvidia, Intel.

The only compromise is a black screen for about 2 secs in the beginning of the file, while you can hear the sound and when you seek you get a frozen image for about 1 sec before normal playback starts again (while you can hear the sound).

[NikosD]

According to AMD and based on some Jellybean samples, there is a bug in FFMPEG DXVA H.264 decoder (and LAV of course)

Based on the clip provided:

When the user performs a seek, the player is supposed to locate the key frame first. The first frame that the decoder received is indeed a key frame and the output is displayed without corruption.

However, the issue starts happens with the next frame player sends out – the reference frame. While the bitstream is correct, the picture parameter sent by the player is not correct and not following DXVA2 specs supported by Microsoft.

The picture parameter provided for the second frame shows 4 frames in reference list. However, there should only be 1 because this frame is right after the I-frame

This triggers the driver code that when it detects a frame is outside the reference list, it marks this frame as an error frame and trying to hide the error by copying from the latest frame in reference frame buffer. This propagates the error and results in image flipping and corruption.

In software decode, the reference frame in always kept in memory, so it is always able to find the reference frame even though it is outside the limit.

[nevcairiel]

Thats the same silly explanation you posted weeks ago, and it still has holes. Software decoders don't have access to any extra reference frames, neither does any other hardware.
If references are missing, there will be corruption, there is no doubt about that, but for some reason AMD never manages to recover afterwards, which it should.

[NikosD]

Ok, but is the DXVA2 specification restricted the way it's described and ffmpeg DXVA2 respects that restriction?

[nevcairiel]

The decoder works in accordance to the H264 specification. If a reference frame is missing, a dummy frame is generated (ie. a blank one) to take its place, so its very well possible that the second frame after a seek already lists 4 references - 3 of those may just be empty dummy frames that are not available due to the seek.

That entire explanation is not logical, it talks about having too many reference frames and then talks about a missing reference frame. Thats not even the same thing.
Not to forget that the Microsoft decoder showed the same behavior, you would think Microsoft would implement their own DXVA2 specification correctly, right?

[ibius]

Originally Posted by MisterXDTV

Does or will LAV Video support DXVA for VP9 Profile 2 (10 bit) videos from youtube? I can't hardware decode it with LAV decoder no matter what I select (native, copy-back, NVIDIA CUVID). With another decoder it works fine

Same here, is it by design? The hint says VP9 decoding is experimental, on what hardware exactly?

Win 8.1 x64, GP107 on Nvidia 376.33 drivers.