LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

Originally Posted by 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.

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

[FDisk80]

Originally Posted by nevcairiel

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]

Originally Posted by nevcairiel

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.

[NikosD]

Originally Posted by fairchild

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]

Originally Posted by NikosD

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]

Originally Posted by fairchild

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]

Originally Posted by CoRoNe

For 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]

Originally Posted by 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.

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

[nevcairiel]

Originally Posted by CoRoNe

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.

Originally Posted by CoRoNe

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.

Originally Posted by Pat357

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]

Originally Posted by 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.

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]

Originally Posted by nevcairiel

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]

Originally Posted by Aleksoid1978

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]

Originally Posted by nevcairiel

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]

Originally Posted by nevcairiel

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]

Originally Posted by Aleksoid1978

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]

Originally Posted by VipZ

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