LAV Filters - DirectShow Media Splitter and Decoders

[Pat357]

Originally Posted by nevcairiel

While i had that driver installed, i even tested Microsofts DXVA codec, and it too failed (black instead of green, but i can easily make it black if you wish)
Its just a driver bug, install another one if you want to use DXVA-CB. Not really worth spending my limited time on.

Debugging why DXVA fails is impossible, its a closed API, and only the driver developers could potentially tell you whats going on.

OK, I understand and agree with your point of view.
I also tested other DXVA decoders on the files that showed only green screens with LAV DXVA copy back.

ArcSoft decoder : h264/mpeg2 and wmv files play fine in dxva mode
Mainconcept decoders : h264/mpeg2 files play fine in dxva mode, wmv's falls back to softw in VC1 decoder.
Cyberlink PDVD9 decoder : h264/mpeg2 files play fine in DXVA and HAM mode. It looks that the HAM mode is somewhat similar to DXVA-CB ?
FFDshow DXVA : h264 files play fine, WMV didn't even connect.

Conclusion is that the above DXVA decoders do well on these files. Because the "direct" DXVA mode from LAV also plays these files OK, it's not clear as to why LAV DXVA-CB breaks on these files with the latest WHQL driver v285.36.
A newer driver seems to solve all problems with dxva-cb, so to me it seems that neither the driver or LAV-CB is the cause, but somehow in the interaction between LAV-CB and the 285.36 driver .

Nev, can you somehow check what info really goes to the renderer, or is this hidden due the DXVA API (like you send in a black box, but what happens after this is actually hidden).
Is it somehow possible to dump and read the dxva stream ?

[nevcairiel]

The DXVA decoder doesn't even indicate failure, it just produces a green image, but happily returning success.
It gives me no point to start looking.

Like i said before, its one broken driver, and there is no way to look into the driver what its doing there.
Its even listed as a documented bug in that driver.

It is quite interesting that native mode works (and the MS decoder doesn't), but i guess we should just be happy that it does work and not question the logic.
Maybe the copy-back mechanic is just broken for some reason, the driver only returns zeros when copying the frame - and in native mode it doesn't copy it.

[jmone]

I've not had the HW to try this (soon will)... what is the go with 3D BD playback in the direct show world these days or is it still only available from the commercial players?

[NikosD]

Signature System:

Two issues:

1) LAV DXVA native doesn't HW accelerate ANY H.264 clip of the type below (I have a lot of them as it is popular for movie trailers).
Movie Trailer

2) In latest DXVA checker 2.7.0, when you provide a non HW accelerated clip - like High10 H.264 - it enumerates LAV Video as "Unsupported", although it is supported of course in software mode.

It would be more convenient, if LAV Video was listed like CoreAVC, enumerating the supported restricted modes without red colour aka DXVA acceleration.

Try a High10 H.264 in DXVA checker to see what I mean.

[nevcairiel]

Originally Posted by NikosD

1) LAV DXVA native doesn't HW accelerate ANY H.264 clip of the type below (I have a lot of them as it is popular for movie trailers).
Movie Trailer

Fixed.

Originally Posted by NikosD

2) In latest DXVA checker 2.7.0, when you provide a non HW accelerated clip - like High10 H.264 - it enumerates LAV Video as "Unsupported", although it is supported of course in software mode

The software fallback has to be as reliable as possible, which means it'll fallback as early as possible. I won't be changing this for a "cosmetic" issue.

[VipZ]

Would it be possible to add support for WMA Lossless now as it seems ffmpeg support is much better with recent updates?

[nevcairiel]

Originally Posted by VipZ

Would it be possible to add support for WMA Lossless now as it seems ffmpeg support is much better with recent updates?

The decoder is still highly experimental, so no.
ffmpeg itself disables it unless i specifically ask it to enable experimental codecs.

[VipZ]

Originally Posted by nevcairiel

The decoder is still highly experimental, so no.
ffmpeg itself disables it unless i specifically ask it to enable experimental codecs.

ok thanks

[nevcairiel]

Here is a new test build:

http://files.1f0.de/lavf/LAVFilters-...2-g46ff9fb.zip

As a quick summary, since 0.46 this is new:

- DXVA2 native, of course. Quite a bunch of issues fixed since the last test build
- Performance enhancements across the board (mostly for 8-bit content)
- Tweaked QuickSync settings
- Fraps multi-threading

Especially the Fraps multi-threading could also use a bit of testing to check that nothing breaks. I'm confident that it'll work ok, but my testing is somewhat limited.
Of course, DXVA2 native also likes being tested, but so far it looks pretty good.

I'm looking into releasing tomorrow, if nothing big comes up, so i can start working on new features without blocking release.

[dukey]

tested the dxva2 mode with my custom EVR presenter, works fine. Only comment is, could dxva be automatically selected upon install ? Or whatever is best for the end user.

[nevcairiel]

Who am i to judge whats best for the user?

[dukey]

Well good point, but if its available it would make sense to select it instead of software decoding by default

[NikosD]

Really good and fast DXVA native implementation

From my first preliminary test, looks like it is optimized for high bitrate clips.

Only one WMV3 clip with artifacts in both copy-back and native mode, on signature system

Download it here

[nevcairiel]

Originally Posted by NikosD

Only one WMV3 clip with artifacts in both copy-back and native mode, on signature system

Download it here

I couldn't find any hardware decoder that properly decoded this. ffmpegs software decoder also cannot.
Thats a kind of special file that was encoded with a beta version of the WMV encoder, which is not 100% compliant with WMV9/VC-1 specs.

[CruNcher]

Microsofts first ever released WMV9 demo streams (the kelsy streams) also show this issue with any decoder only Microsofts own Decoder isn't affected though it seems what ever causes these strange blocking for every other 3rd party decoder was never used later on again, It only shows itself in high motion every scene that suffers from this is high motion though mostly the scenes are short except for a stream that appeared on mplayers sample server that is even older then the kelsy streams (and i absolutely dont remember this one being a official Microsoft Release back then) their you even see it much longer in a high motion scene (Video_Smoothing.wmv) .

[nevcairiel]

Obviously Microsoft used their own beta encoder to encode the first demo streams.
The fact remains that its not compatible with the WMV9/VC-1 specs

[aufkrawall]

No problem with multithreaded FRAPS decoding (how can I be certain that it's really MT?).
At least there is no noticeable difference to previous builds, ST was already fast enough.
Of course there's still the "issue" that FRAPS YV12 videos don't look right, neither with madVR as renderer compared to EVR *sigh*.

The problem when decoding x264 RGB with Avisynth seemed to be related to VirtualDub.
If I feed x264 with the same script like VD, decoding works flawlessly.

[fairchild]

I just watched Friday the 13th Blu-ray using the new test file and DXVA2 Native + EVR CP and playback was flawless. During the credits I seeked back using the MPC-HC D3D Fullscreen seek bar and it wasn't as smooth as when using software decoding, but I think this is standard with all DXVA2 decoding since the GPU has to catch up or something of the sort?

So now that this is implemented, is this one step closer to having native DXVA2 GPU decoding + MadVR in the future or is that just never gonna happen? I know DXVA2 copyback works with MadVR but it's decoding on my ATI is not as efficient as native DXVA2 decoding. (52 fps with DXVA2 copyback vs 147 fps with DXVA2 native on the crowdrun_1080p50 test file)

[nevcairiel]

Originally Posted by fairchild

During the credits I seeked back using the MPC-HC D3D Fullscreen seek bar and it wasn't as smooth as when using software decoding, but I think this is standard with all DXVA2 decoding since the GPU has to catch up or something of the sort?

On most PCs, software decoding is significantly faster then hardware decoding, which also accelerates seeks.

Originally Posted by fairchild

So now that this is implemented, is this one step closer to having native DXVA2 GPU decoding + MadVR in the future or is that just never gonna happen?

You have to ask madshi about that.
Note that copy back doesn't have to be that slow, should complain to ATI/AMD more. The 7000 series seem to have improved on that front.

[FDisk80]

Hi nevcairiel, amazing work on the LAV Filters.
Are there plans for LAV Audio to give us some controls on audio channels like AC3 Filter has? And features like Auto Gain Control, Normalization... and so on.