LAV Filters - DirectShow Media Splitter and Decoders

[DragonQ]

Aspect ratio looks fine to me - the BBC thing will be 16:9 so fills the frame, the others are films which are usually wider than 16:9 so will have black bars top & bottom.

[strumf666]

Ok, thanks for explanation

[nevcairiel]

Hey,

Test version time!

x86: http://files.1f0.de/lavf/LAVFilters-...5-g17143fc.zip
x64: http://files.1f0.de/lavf/LAVFilters-...7143fc-x64.zip

In this version, i worked on fully moving the avcodec decoder to my new decoding worker thread which was introduced a few versions back, but was only completely used by the WMV DMO decoder until now.

The big advantage of this change is that decoding now runs completely independent of the main processing thread. This means that decoding and the processing can run in parallel.
What does that mean for you?
- Processing in LAV includes YADIF and any pixel format conversion, including YUV->RGB, etc.
- It also includes any processing done in another filter in the graph, which does not do its own multi-threading, like ffdshow.

You'll see the biggest advantages in single-threaded decoders, or when running with low threads. Single-threaded H264 decoding by itself is around ~5% faster.
In combination with YUV->RGB conversion or with YADIF, single-threaded H264 is significantly faster, activating both is now fully transparent on my system, which means the FPS does not change at all, no matter if you do the processing, or you do not. All thanks to just making it run in parallel to the decoding, instead of everything in a series.

Multi-threaded decoding does not benefit that much from it, because the decoding is already running in dedicated threads, however performance may still improve when doing very extensive processing.

The downside of it?
Multi-threaded decoding may be *slightly* slower then with a decoder which does not do this. The reason for this is the extra synchronization between the decoder thread and the main thread. Note that this synchronization does not use more CPU, it just has to wait on critical sections. During the wait, the CPU is given to any other threads that want it. So it may be slightly slower, but it doesn't use more CPU, so the CPU is still free for any other tasks (post-processing, etc).

It all comes down to benchmarking vs. real world applications. In the real world, this design is much better in all cases, just in benchmarks where only the decoder is measured and not the whole playback system, there may be a very minor disadvantage (we're talking usually less then 1% here)

I wanted to draw a picture of the processing flow before (and with most other decoders), and after the change, but my art skills suck too much. Maybe i'll do it for the release version.

@Test Version:
Obviously i posted the version because i think its a good idea to test it. If you encounter any weird decoding failures, or even crashes, which did not happen with the previous version, please report them directly.

[SamuriHL]

8>Build started 8/2/2012 12:20:22 PM.
8>InitializeBuildStatus:
8> Creating "c:\dev\projects\lavfilters\bin_Win32\LAVSplitter\LAVSplitter.unsuc
cessfulbuild" because "AlwaysCreate" was specified.
7>decoders\avcodec.cpp(511): error C2065: 'm_bDXVA' : undeclared identifier
7> dxva2dec.cpp

Nev, I'm getting that when I build the latest. Any ideas?

[Sebastiii]

Thanks Nev, nice feature and i will try ASAP :P

[nevcairiel]

Originally Posted by SamuriHL

Nev, I'm getting that when I build the latest. Any ideas?

Works just fine here.

[SamuriHL]

Lovely. I'll blast it and pull clean.

[andyvt]

Originally Posted by nevcairiel

Works just fine here.

Would you consider including a feature that refuses connections from the splitter to specific filters?

[Sebastiii]

Originally Posted by nevcairiel

Works just fine here.

Fine too

[nevcairiel]

Originally Posted by andyvt

Would you consider including a feature that refuses connections from the splitter to specific filters?

If you don't want to use a specific filter, just unregister it?

[andyvt]

Originally Posted by nevcairiel

If you don't want to use a specific filter, just unregister it?

It would break the application that uses it.

[nevcairiel]

Lower the merit then, so its not used unless directly requested?

I don't think its the splitters job to do graph-construction related decisions.

[andyvt]

Originally Posted by nevcairiel

Lower the merit then, so its not used unless directly requested?

It's a preferred filter in the process, so merit doesn't come into play.

The use case is WMC + the MS Audio Decoder. I can't make it not load w/o breaking TV, but it likes to connect to lav for files where I would prefer lav audio.

Originally Posted by nevcairiel

I don't think its the splitters job to do graph-construction related decisions.

I wholeheartedly agree in concept, but reality is a bitch.

TBC, I wasn't asking you to do the work, just if I did it and submitted a patch if it would be considered. Obviously I don't need approval to run it locally, but since my git skills are crap I was hoping to avoid having to continuously merge in your changes.

[mzso]

I had decoding speed issues with the test version of a an interlaced TS file. Jerkyness or slow motion, depending on renderer. I use CUVID, with adaptive interlacing and doubling mode. Reinstalling old version fixed the problem.

  General #8900
    ID : 8900 (0x22C4)
    Complete name : 
    Format : MPEG-TS
    File size : 5.68 GiB
    Duration : 1h 27mn
    Overall bit rate mode : Variable
    Overall bit rate : 9 299 Kbps
  Video #391
    ID : 391 (0x187)
    Menu ID : 1591 (0x637)
    Format : AVC
    Format/Info : Advanced Video Codec
    Format profile : Main@L4.0
    Format settings, CABAC : Yes
    Format settings, ReFrames : 4 frames
    Codec ID : 27
    Duration : 1h 27mn
    Bit rate : 8 586 Kbps
    Width : 1 920 pixels
    Height : 1 080 pixels
    Display aspect ratio : 16:9
    Frame rate : 25.000 fps
    Standard : Component
    Color space : YUV
    Chroma subsampling : 4:2:0
    Bit depth : 8 bits
    Scan type : Interlaced
    Scan order : Top Field First
    Bits/(Pixel*Frame) : 0.166
    Stream size : 5.25 GiB (92%)
    Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
    Transfer characteristics : BT.709-5, BT.1361
    Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177
  Audio #491
    ID : 491 (0x1EB)
    Menu ID : 1591 (0x637)
    Format : AAC
    Format/Info : Advanced Audio Codec
    Format version : Version 4
    Format profile : LC
    Muxing mode : ADTS
    Codec ID : 15
    Duration : 1h 27mn
    Bit rate mode : Variable
    Bit rate : 251 Kbps
    Minimum bit rate : 6 000 bps
    Maximum bit rate : 283 Kbps
    Channel(s) : 2 channels
    Channel positions : Front: L R
    Sampling rate : 48.0 KHz
    Compression mode : Lossy
    Delay relative to video : -1s 275ms
    Stream size : 157 MiB (3%)

Edit: So now after restart and reisntalling again there is no problem. Looks like I hit the (unidentified) transient problem where the video plays back jerkily for seemingly no reason.

[Boltron]

Nev, I ran your test version LAVFilters-...5-g17143fc.zip and I have encountered a problem I have never had before. After about 25 minutes of play, playback just locks up very hard. This never happened before. I am running MC17 with Lav and madVR on Win7 64 but I use you x86 package. I am watching a 720p TV show.

I can't say for sure that you test version is the cause, but just to repeat, I have never had a lock up like this. I will put 51.3 back and see if the issue reoccurs.

[noee]

Same problem here, but only after a seek, with MC17, MC18 and MPC-HC. But I just built the latest git and it's working as expected again.

[ryrynz]

Just throwing this out there.. Nev would you add Avisynth scripting support if enough users contributed payments to implement it? Also, who here would be interested enough in this feature that you would consider funding the development of it? Cheers.

[nevcairiel]

Originally Posted by Boltron

Nev, I ran your test version LAVFilters-...5-g17143fc.zip and I have encountered a problem I have never had before. After about 25 minutes of play, playback just locks up very hard.

Originally Posted by noee

Same problem here, but only after a seek, with MC17, MC18 and MPC-HC.

I found a potential race condition resulting in a deadlock in the revised threading code in the last test version, which could possibly cause this.

Here is a new version:
x86: http://files.1f0.de/lavf/LAVFilters-...8-g840eda7.zip
x64: http://files.1f0.de/lavf/LAVFilters-...40eda7-x64.zip

[nevcairiel]

Originally Posted by ryrynz

Just throwing this out there.. Nev would you add Avisynth scripting support if enough users contributed payments to implement it?

If only money could buy additional time to do it. I have a full-time job, and all the time that remains is not for sale.

I'm not ruling it out completely, it may happen eventually, but i had a brief look at the AviSynth API a while ago, and it seemed rather horribad, so motivation quickly faded.

[mzso]

Originally Posted by nevcairiel

If only money could buy additional time to do it. I have a full-time job, and all the time that remains is not for sale.

I'm not ruling it out completely, it may happen eventually, but i had a brief look at the AviSynth API a while ago, and it seemed rather horribad, so motivation quickly faded.

How about an own scripting for LAV? (Guess it would be even more work)