LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

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.

Yes, and no.
A mixer will be added, everything else not.

[FDisk80]

Yes, and no.
A mixer will be added, everything else not.

Wow, you are quick :) I just clicked submit.
Thanks, keep up the great work.

[fairchild]

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

Yeah my CPU can handle software decoding just fine, but I'd like to offload as much as possible to the GPU as I run Folding@home on my PC and I'd prefer the CPU having as much resources as possible. :D

[NikosD]

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)

It's simply impossible for any ATI card - as it is right now with any drivers released ever - to HW accelerate in DXVA native mode CrowdRun_1080p50 to 147 fps average.

It's simply impossible because with my overclocked UVD2.2 at 710MHz I only get 71 fps average.

Check your CPU load to see that software decoding is involved (maybe software fallback)

[fairchild]

It's simply impossible for any ATI card - as it is right now with any drivers released ever - to HW accelerate in DXVA native mode CrowdRun_1080p50 to 147 fps average.

It's simply impossible because with my overclocked UVD2.2 at 710MHz I only get 71 fps average.

Check your CPU load to see that software decoding is involved (maybe software fallback)

Hrm you are correct. When I select DXVA2 copy back mode and test with graphstudionext, it properly works and gives me an avg of 52 fps.

When I select DXVA2 native mode, it seems to fall back to software mode and I verified that 147 fps is what I get when I set Lav Video to software mode.

Is there some limitation or bug with either software or is there another way to benchmark that I'm not aware of?

[nevcairiel]

Is there some limitation or bug with either software or is there another way to benchmark that I'm not aware of?

You need to use EVR as renderer if you want to benchmark DXVA playback. As an alternative do it with DXVAChecker

[egur]

@Nev, try using r41, I've improved overall performance in all cases and especially on low (and zero) queue depth. Using higher than 8 BTW, doesn't improve anymore.

[Pat357]

Nev,

I just updated my drivers to 290.36, no "greens" anymore !
Thanks for figuring this out.
I'd never have known that the drivers were the issues until you told me so.

This file plays very choppy in both DXVA and DXVA CB, but plays smooth with MPC build in DXVA.
In all 3 cases the LAV-spitter is used, so it's not a splitter issue.
I also tried the MPC build in MPEG-spliiter and got the same result.

http://www.mediafire.com/?3z15d95b7j0j3jm

PS : It's one off these files that produced "greens"" with the 285 WHQL driver.
In mean time I also tested LAV with the FPS1 files that were on my disk : no issues concerning the decoding, MT seems to work fine.
I'll test the MT better by creating a 60 FPS 1080p file with fraps and than decoding it.

[Reino]

- Improved Fraps decoding with EVRFor FPS1(yuvj420p) files could you automatically apply TV-levels with VMR-9 Renderless as well as you've done for EVR.
The only thing left for both renderers now is BT.709->BT.601 luma conversion and LAV can perfectly decode Fraps files in YV12 mode.Not implemented yet with 16:01 test build I see. It is possible for VMR-9 Renderless, I hope?

I guess you haven't had time to look at the SNOW issue, or have you?

[Pat357]

Here are some more detailed results from the FRAPS-MT version in LAV-video :
#Threads FPS
1 28,5 fps
2 56,0 fps
3 83,2 fps
4 108,6 fps
5 128,4 fps
6 141,8 fps
7 155,0 fps
8 167,9 fps
9 182,9 fps
10 197,1 fps
11 207,9 fps
12 211,2 fps
14 211,5 fps
16 211,9 fps

With low numbers of threads, the scaling is almost linear.
Above 12 threads, there is no improvement anymore, probably because my CPU has "only" 6+6 cores (6 real + 6 hyper-threading).
Well done Nev !!

Test system :
FRAPS file 2.4 GB, bitrate 130 Mbps, 1920x1080@10fps, 2min 39,4s
GraphstudioNext v0.4.9.0 (32bit , LAV 0.46 (latest posted by Nev)
Win7 Prof. x64 (all updates)
CPU : i7-970@3.7 Ghz with 12MB on die L3 cache
24 GB of 2000 MHz trip. channel DDR3
Areca 1222 RAID6 controller / 8x 2TB 7.2k WD HD
OCZ Vertex 3 240GB SSD

PS: while writing this, something else comes in my mind : tranfer speed !
To get 211 fps, you probably also need a very fast HD or a fast SSD.
The file is recorded at 10FPS, so to get 211 fps, you need to read it at 21x, this is 7.5s to read a 2.4 GB file = + 330 MB/s.
I guess a single HD or even 2 HD in RAID0 can't keep up with this.

[CruNcher]

Nev,

I just updated my drivers to 290.36, no "greens" anymore !
Thanks for figuring this out.
I'd never have known that the drivers were the issues until you told me so.

This file plays very choppy in both DXVA and DXVA CB, but plays smooth with MPC build in DXVA.
In all 3 cases the LAV-spitter is used, so it's not a splitter issue.
I also tried the MPC build in MPEG-spliiter and got the same result.

http://www.mediafire.com/?3z15d95b7j0j3jm

PS : It's one off these files that produced "greens"" with the 285 WHQL driver.
In mean time I also tested LAV with the FPS1 files that were on my disk : no issues concerning the decoding, MT seems to work fine.
I'll test the MT better by creating a 60 FPS 1080p file with fraps and than decoding it.

Must be a MBAFF decoding problem you also have that on Intel with Lavs DXVA works with CoreAVC DXVA and others

[nevcairiel]

Not implemented yet with 16:01 test build I see. It is possible for VMR-9 Renderless, I hope?

There is nothing to be done. All i changed was to assume that Fraps would be RGB, and do the initial connection from the decoder to the renderer in RGB. EVR is stupid and doesn't allow a reconnection, so it'll stay RGB. VMR is not stupid, and allows me to reconnect, so it'll switch to YV12.
This is working as intended.


I guess you haven't had time to look at the SNOW issue, or have you?
Thats not something i can fix, report the problem to ffmpeg/libav, the decoder is having the issue.


This file plays very choppy in both DXVA and DXVA CB, but plays smooth with MPC build in DXVA.
In all 3 cases the LAV-spitter is used, so it's not a splitter issue.
I also tried the MPC build in MPEG-spliiter and got the same result.

http://www.mediafire.com/?3z15d95b7j0j3jm


That file must be broken somehow, it complains about missing reference frames a lot.
Not sure why it causes this odd decoding behaviour, maybe it should be skipping some of the broken frames instead of trying to decode them. The HW decoder seems to "hang" on some frames for a short while

[nevcairiel]

@Nev, try using r41, I've improved overall performance in all cases and especially on low (and zero) queue depth. Using higher than 8 BTW, doesn't improve anymore.

Looks good here.
The difference between queue depth is very marginal now, and even on depth 0 the old samsung clip plays nearly as fast as on depth 16 before.

I'll run a full set of tests.

[Aleksoid1978]

That file must be broken somehow, it complains about missing reference frames a lot.
Not sure why it causes this odd decoding behaviour, maybe it should be skipping some of the broken frames instead of trying to decode them. The HW decoder seems to "hang" on some frames for a short while

http://aleksoid.tosei.ru/Test/Sample/Blind_Fury.m2ts - Also play very bad in software and DXVA with LAV. I think - it's a ffmpeg issue. Some times ago you fix ffmpeg to normal playback MBAFF H264.

[nevcairiel]

http://aleksoid.tosei.ru/Test/Sample/Blind_Fury.m2ts - Also play very bad in software and DXVA with LAV. I think - it's a ffmpeg issue. Some times ago you fix ffmpeg to normal playback MBAFF H264.

In Software it plays just fine for me.

[egur]

Looks good here.
The difference between queue depth is very marginal now, and even on depth 0 the old samsung clip plays nearly as fast as on depth 16 before.

I'll run a full set of tests.

Great. It wasn't an easy task :(
Aside from some very small layers of fat in the code, the trick was to lengthen the decode queues (no effect on latency - just how many frames the HW decoder can fill before it stalls), this helps performance when the decoder speed is very variable on a frame basic (as each frame can have very different bitrate). The other thing, which took most of my time to find, was the order of D3D surfaces sent to the decoder. Very weird as it should change nothing. I still don't fully understand why adding long output queues help in this case expect mandate a specific order of D3D frames.

Another performance enhancement would be to remove my dependency on PostThreadMessage for passing/queuing jobs for both decode and frame processing. VTune shows a lot of waiting is done there. I'll investigate this route soon.

[Aleksoid1978]

In Software it plays just fine for me.

Yes - my fall. Software & CUVID ok. I sorry for the misinformation

[mrg155]

Hi, couldn't find this specific questions asked before, apologies if I missed it:

I have ripped BDs in MKV. I tend to keep all English audio and PGS subtitle streams in the rip. I would like to set up LAV splitter such that the following happens:

1) If English audio then use default English subtitles but pass only those with forced flag

2) If non-English audio then pass full English subtitle track.

As far as I can see, the advanced selection mode allows you to automatically select a forced track but not to use the default track and pass only titles within it that have the forced flag?

Selecting the forced flag titles option in the "Blu-ray subtitles" section works perfectly for (e.g.) District 9. Presumably though with this setting enabled a foreign language film will get no English subtitles as these aren't usually marked with a forced flag?

Currently am having to extract forced titles as separate track in MakeMKV and then edit the header to mark the track as forced.

Any ideas if the advanced selection mode can be used to achieve the above?

Thanks

[VipZ]

http://aleksoid.tosei.ru/Test/Sample/Blind_Fury.m2ts - Also play very bad in software and DXVA with LAV. I think - it's a ffmpeg issue. Some times ago you fix ffmpeg to normal playback MBAFF H264.

This sample works fine in Software and DXVA2 Native + CB for me.

[nevcairiel]

This sample works fine in Software and DXVA2 Native + CB for me.

Maybe its just an NVIDIA thing.
Not to worry then, NVIDIA users should prefer cuvid anyway :)

[Aleksoid1978]

Maybe its just an NVIDIA thing.
Not to worry then, NVIDIA users should prefer cuvid anyway :)

But - MPC DXVA play fine. Then it's not a bug in the Nvidia driver.
Ati also have this bug on DXVA

[Tacio]

I have notebook with Core i5 (Sandy Bridge) and NVIDIA GT520M (VP5) inside. What is the most power efficient hardware decoder QuickSync or CUVID? Power efficiency is more preferably for me than speed.

[nevcairiel]

I have notebook with Core i5 (Sandy Bridge) and NVIDIA GT520M (VP5) inside. What is the most power efficient hardware decoder QuickSync or CUVID? Power efficiency is more preferably for me than speed.

Use QuickSync, it should be faster and more efficient.

[CruNcher]

Tacio also try to avoid any 3rd party renderer but fully make use of Intels Hardware chain, so avoid EVR-CP and MadVR for example, and use DXVA (wherever possible) all of this is combined is gonna save a lot of power (though its unavoidable that you also get more speed with this ;))

[Tacio]

Thanks, I thought about DXVA, but MadVR produces very good quality :) So I will use QuickSync.

[nevcairiel]

DXVA on Intel is a bad suggestion. Stick with QuickSync, the very minor overhead is irrelevant for a much smoother experience.

[CruNcher]

Nev what about a Quicksync mode without copy back it wont be the same as the current Native DXVA2 as it still going through Intels API wouldn't it, did you tried it and compared both ?

I guess this could be a very nice compromise if it fixes a lot of issues without needing to fix all of them in the DXVA2 part again, why doing it if Intel already did it (via the driver), also the overhead should be pretty much the same except those fixes ;)

[The Seeker]

I'm wanting to use only Media Player Classic and the LAV Filters. Once both are installed, should I disable everything under 'Internal Filters' within MPC?

Edit: D'oh! Just saw the 'Advanced MPC-HC Setup Guide' in the initial post. As you were.

[NikosD]

But - MPC DXVA play fine. Then it's not a bug in the Nvidia driver.
Ati also have this bug on DXVA

There is no bug on ATI's DXVA HW acceleration for that clip.

[chros]

I'm wanting to use only Media Player Classic and the LAV Filters. Once both are installed, should I disable everything under 'Internal Filters' within MPC?

Edit: D'oh! Just saw the 'Advanced MPC-HC Setup Guide' in the initial post. As you were.

No. Add the 'Lav Video decoder' to the 'External filters' and set it to 'prefer'.

[egur]

Nev what about a Quicksync mode without copy back it wont be the same as the current Native DXVA2 as it still going through Intels API wouldn't it, did you tried it and compared both ?

I guess this could be a very nice compromise if it fixes a lot of issues without needing to fix all of them in the DXVA2 part again, why doing it if Intel already did it (via the driver), also the overhead should be pretty much the same except those fixes ;)

Sure it possible, I've even conducted a pole a few weeks ago whether to implement this feature or start with HW deinterlacing. The latter won. Quality will be identical to what QS decoder offers and power/performance will be better.

Some limitations apply to pure DXVA2 decode:
* Decoder must connect to EVR (or compatible) for this to work.
* Renderer must be on the same GPU (no hybrid stuff).
* No filters between decoder and renderer.
* LAV decoder can't change the output frames (they are ref frames used by the decoder).

There are of course other complexities involved :(
Usually not worth the trouble (and limitations) unless there's a substantial gain in battery life over current QS decoder operation. I don't have these numbers.

[NikosD]

Sure it possible, I've even conducted a pole a few weeks ago whether to implement this feature or start with HW deinterlacing. The latter won. Quality will be identical to what QS decoder offers and power/performance will be better.

Some limitations apply to pure DXVA2 decode:
* Decoder must connect to EVR (or compatible) for this to work.
* Renderer must be on the same GPU (no hybrid stuff).
* No filters between decoder and renderer.
* LAV decoder can't change the output frames (they are ref frames used by the decoder).

There are of course other complexities involved :(
Usually not worth the trouble (and limitations) unless there's a substantial gain in battery life over current QS decoder operation. I don't have these numbers.

The limitations you describe are not really limitations.
They are "limitations".

Besides the meaningless use of madVR for HD files, which are true limitations ?

The scheme of direct connection between decoder and EVR compatible renderer is perfect for simple decoding without all the fanfare of useless filtering for HD content.

[nevcairiel]

Even HD content needs chroma upsampling, and if the latest generation of AMD cards and their drivers have shown us one thing - don't rely on the GPU to do it.
Not to mention that quite a lot of people still watch DVDs.

Anyway, the main point is that Intels GPU is so fast that the overhead from Erics implementation is so minimal that there is just no advantage in doing it any other way.
This way, you can use EVR if you want to, but someone else can also use madVR if they want to.

[egur]

Even HD content needs chroma upsampling, and if the latest generation of AMD cards and their drivers have shown us one thing - don't rely on the GPU to do it.
Not to mention that quite a lot of people still watch DVDs.

Anyway, the main point is that Intels GPU is so fast that the overhead from Erics implementation is so minimal that there is just no advantage in doing it any other way.
This way, you can use EVR if you want to, but someone else can also use madVR if they want to.

I completely agree.
BTW I saw a nice improvement in your bench scores (http://docs.google.com/spreadsheet/ccc?key=0Ajo8vvjNtaZ5dC1abjBSeVlmcnZXSjYwampfamk3ZWc#gid=0) using your latest build + QS 0.28.
If it's not too much trouble, can you post pure DXVA results as well (for reference)?
Does pure DXVA2 it even work in GraphStudioNext using NULL EVR?

[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?

The PJ has arrived. Is my assumption correct that the only option for 3d (yes I know it is a gimick) is the commercial players?

[nevcairiel]

If it's not too much trouble, can you post pure DXVA results as well (for reference)?
Does pure DXVA2 it even work in GraphStudioNext using NULL EVR?

I can benchmark DXVA results later, however benchmarking DXVA only really works with DXVAChecker, so the conditions may not be 100% the same. Also, a DXVA decoder may not be 100% optimized for full multi-threaded decoding, so i kind of expect performance to be lower.

The PJ has arrived. Is my assumption correct that the only option for 3d (yes I know it is a gimick) is the commercial players?

Thats right.

[madshi]

Is my assumption correct that the only option for 3d (yes I know it is a gimick) is the commercial players?
For now. 3D rendering is on the madVR to do list, but it might take a while until I get to that. When I get there, by that time a decoder might be available, too, eventually...

[egur]

3D (h264-MVC) is supported in SandyBridge via DXVA2 and has Media SDK support in IvyBridge. There's a code sample within the Media SDK 2012 on how to do this (IvyBridge). I'm not sure if future SNB drivers will support MVC via the Media SDK.

[madshi]

Yeah, there's also a pure software MVC decoder in the Intel Media SDK 3.0, IIRC. So I think the main problem is to have a 3D capable renderer. The decoder is less of a problem, thanks to Media SDK.

[Pat357]

Nev,

I noticed the DXVA does (sometimes?) not fallback to software in case of too high resolutions for the HW to handle :
Filter : LAV Video Decoder - CLSID : {EE30215D-164F-4A92-A4EB-9D4C13390F9F}

- Connected to:

CLSID: {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
Filter: Enhanced Video Renderer (custom presenter)
Pin: EVR Input0

- Connection media type:

Video: DXVA 4096x2304 23.976fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_NV12 {3231564E-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 14155776
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(4096,2304)
rcTarget: (0,0)-(4096,2304)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083
The playback stalls at the start of the video with a black screen.
DXVA-CB did correctly fall back.

Should the condition to fallback for dxva and dxva-cb not be about the same ? (with exclusion non-dxva capable render and maybe a few things)

[nevcairiel]

The problem is that native DXVA has to decide right away if a fallback is needed, and it cannot wait until the decoder is created. There currently is no resolution check in place because DXVA-CB didn't need it (it can always fall back).
I'll try to let it probe the hardware automatically, otherwise i'll just black list high resolution material until i can come up with a hardware white list which supports which.

[nevcairiel]

I added a quick check to deny DXVA2-native for anything above 1920x1200. I'll have to come up with a proper check probing hardware support later.

[wanezhiling]

nev, vp5 vp5~~~:cool:

[nevcairiel]

LAV Filters 0.47

LAV Audio
- Fixed seeking in COOK audio with the MPC-HC RealMedia splitter

LAV Video
- New DXVA2 "native" decoder (see release notes)
- Updated Intel QuickSync decoder and tweaked configuration (0.28, r41)
- Overall performance improvements
- Multi-threaded decoding for Fraps
- Fixed a regression that resulted in only single-threaded playback on certain H264 files
- Fixed a crash in the CUVID decoder introduced in 0.46 under certain circumstances


Download: Installer (both x86/x64) (http://files.1f0.de/lavf/LAVFilters-0.47.exe) -- Zips: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.47.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.47-x64.zip)

This version includes a big ffmpeg update. Two of the libraries have been renamed, so you might want to check that no duplicates remain.

DXVA2 Native
This works like any other DXVA2 decoder, with the same limitations, and probably the same performance - but it completes the set of decoders available, and concludes the series of HW decoders.

It seems to work reasonably well with NVIDIA and ATI, but has some bugs with Intel. Sandy Bridge users are recommended to stick to the QuickSync decoder, and all previous Intel generations should probably stick with the Microsoft DXVA decoder.

Other changes
All other changes are of the usual kind, performance tweaks and bug fixes, yet another updated Intel decoder .. nothing breathtaking.

Now that DXVA2 development is concluded, i hope to be able to start on new features entirely.

Have fun.

[DragonQ]

Great work Nev, gonna try it now. Looking forward to some new features (*cough* audio mixer *cough*). ;)

[fastplayer]

Thanks a lot for 0.47, nev! :)

[Shark007]

LAV Filters 0.47

- Updated Intel QuickSync decoder and tweaked configuration (0.28, r41)

Although the zipfiles contain the updated Intel QuickSync decoder, the installer still contains an old version.

download source - http://code.google.com/p/lavfilters/downloads/detail?name=LAVFilters-0.47.exe
untested source - http://files.1f0.de/lavf/LAVFilters-0.47.exe

[nevcairiel]

The version should've been the same, just compiled earlier.
To make everyone happy, i repackaged it. :p

[Shark007]

The version should've been the same, just compiled earlier.
To make everyone happy, i repackaged it. :p

it contained .26 compiled on the 12th of Feb.
Thanks for the correction. :)

[DragonQ]

Hmm, I enabled DXVA2 Native on my laptop, it played fine for about 15 seconds then the screen turned off. Had to manually power it off. :(