LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

@Nevcairiel:
Are you also planning to support frame doubling/smooth video for 1080p23,976 content in the future?

No, never.

[Gleb Egorych]

It doesn't work for me
:(
Does it work for anybody?
I suppose it could be a channel problem (neither cable provider problem nor DVBViewer/LAV problem). I see sometimes such problem even on analog TV.

[ryrynz]

No, never.

We could always hope for Avisynth support I guess.
Would that be much work to implement? Then it would be bye bye ffdshow :D

[madshi]

Everything ffmpeg related is compiled with gcc in Windows (LAV, ffdshow, madVR...). x264 has suffered gcc bugs in the past too.
I'm not sure what nevcairiel uses, but madVR is a mixture of MSVC++ and Delphi compiled exe/dll files. I'm not using gcc at all, except for creating the external ffmpeg dlls.

[nevcairiel]

Same here, only the ffmpeg dlls are compiled with GCC, libbluray and LAV itself are compiled with MSVC2010, but i think thats what he meant.

[madshi]

It read to me as if he meant LAV and madVR themselves would be compiled with GCC, too. But that could have been a misunderstanding on my part. Anyway...

[kalston]

@Nevcairiel:
Are you also planning to support frame doubling/smooth video for 1080p23,976 content in the future?

You can always use ffdshow post processing with avsynth for that.

I did try that because I was curious but I really don't think nev should bother implementing that in LAV, it butchers films and not that many people want it.
There are a lot of TVs that do it much better than software implementations anyway.

[STaRGaZeR]

I'm not sure what nevcairiel uses, but madVR is a mixture of MSVC++ and Delphi compiled exe/dll files. I'm not using gcc at all, except for creating the external ffmpeg dlls.

I was obviously talking about the ffmpeg dlls that all of them use.

[madshi]

Well, at least LAV is very much "ffmpeg related", too, seeing that in its core it's basically a DirectShow wrapper around ffmpeg/libav, so what you said was not that obvious. Anyway, doesn't matter, it's cleared up now.

[STaRGaZeR]

madVR is the same after all. You're the only one that knows what the hell is a decoder doing inside a DirectShow video renderer after all that talk about the correct place of putting things :D

[e-t172]

I'm trying to open a raw RGB24-in-AVI file (FourCC: "DIB") in LAV Splitter. The file plays correctly using the Microsoft AVI/WAV File Source and with VLC. LAV Splitter opens it but I can't connect it to anything (apart from ffdshow video in raw mode, but it crashes when I start playback). LAV Splitter exposes the {00000000-0000-0010-8000-00AA00389B71} subtype in its output pin and nothing else, whereas Microsoft AVI/WAV File Source exposes MEDIASUBTYPE_RGB24, which seems much more appropriate. Is this normal?

[nevcairiel]

I'm trying to open a raw RGB24-in-AVI file (FourCC: "DIB") in LAV Splitter. The file plays correctly using the Microsoft AVI/WAV File Source and with VLC. LAV Splitter opens it but I can't connect it to anything (apart from ffdshow video in raw mode, but it crashes when I start playback). LAV Splitter exposes the {00000000-0000-0010-8000-00AA00389B71} subtype in its output pin and nothing else, whereas Microsoft AVI/WAV File Source exposes MEDIASUBTYPE_RGB24, which seems much more appropriate. Is this normal?

Try with this?
http://files.1f0.de/lavf/LAVFilters-0.39-50-g6692e18.zip

[e-t172]

Problem solved, thanks!

[MokrySedeS]

I have a problem with Lav Video Decoder, with "Use Stream Aspect Ratio" option to be exact. Here (http://www.mediafire.com/?4vva0ay2iomnq91) are 3 sample files of x264 anamorphic encodes for you to reproduce the issue.
One of them plays at correct AR only with this option disabled, another one only with it being enabled and the last one plays correct either way.
I guess that it's a bug and hope that it will be fixed :-)

[nevcairiel]

I have a problem with Lav Video Decoder, with "Use Stream Aspect Ratio" option to be exact. Here (http://www.mediafire.com/?4vva0ay2iomnq91) are 3 sample files of x264 anamorphic encodes for you to reproduce the issue.
One of them plays at correct AR only with this option disabled, another one only with it being enabled and the last one plays correct either way.
I guess that it's a bug and hope that it will be fixed :-)

The only file that even display different behavior here is "Use.Stream.AR.Disabled.mkv", which i assume is supposed to run at 16:9. The problem with such files is that the AR is only properly flagged in the container, with a wrong AR in the bitstream. Sadly, this is quite common for MKV H264 files, and there is no easy fix.
One option would be to ignore the stream AR for files in MKV, however this is not always a good solution, as you could remux live tv into MKV, which could then change AR mid stream...

The other two files decode properly no matter what the option is set to.
"Use.Stream.AR.Enabled&Disabled.mkv" decodes at 16:9 with a target rectangle of 640x362, and "Use.Stream.AR.Enabled.mp4" decodes at 2.35:1 with a target rectangle of 1018x432
This of course depends on what splitter you use, because if "Use Stream Aspect Ratio" is off, the AR as defined by the splitter is used instead. I tested everything with LAV Splitter, of course.

Use.Stream.AR.Disabled.mkv is just a bad encode, while the other two work fine for me.

[MokrySedeS]

My bad, I wasn't using Lav Splitter for mp4 :o

[mindbomb]

i have this problem with a handful of files, where lav splitter can't seek through them
this one was muxed with haali, but the other files were muxed with mkvmerge.
I can't make a sample of it, so I'm posting the whole thing, in 2 zip pieces ( it is relatively small, lucky enough)

http://www.megaupload.com/?d=TT2YF81F
http://www.megaupload.com/?d=WWGJ44ZP

[nevcairiel]

1.6G is relatively small for you? :p
I'll see about download those later.

[Xaurus]

nev,

I have a few files here with double english audio tracks, one is marked "default" (says madvr trayicon) and is only 2.0 AAC, the other one is 5.1 AC3.

Now, lav audio selects the 2.0 by default - is there a way to override this?

[nevcairiel]

I have a few files here with double english audio tracks, one is marked "default" (says madvr trayicon) and is only 2.0 AAC, the other one is 5.1 AC3.

Now, lav audio selects the 2.0 by default - is there a way to override this?

A "default" flag overrides any other decisions based on audio stream quality.
So, no, there is not.

[Xaurus]

A "default" flag overrides any other decisions based on audio stream quality.
So, no, there is not.
Hmm would it be possible to add an "if_then" function, something like "if there exist several audio tracks of the same language and the higher channel track is not flagged as default, select this track anyway", as an option in control panel.

Just a thought.

[CruNcher]

Nev lav Splitter is somehow crashing MPC-HC (test builds) with Mainconcepts Mpeg-2 Decoder (SDK 9 DXVA) when drag and drop loading is involved while still playing back (tested so far only the .ts parsing part) doesn't happen with MPC-HC parser (and heavy drag and dropping) :(

Its easy reproducible with this simple order

1. Prefer Mainconcept Mpeg-2 Decoder
2. Prefer Lav Splitter
3. Load Mpeg2 ts
4. Start Playback
5. Drag and Drop same Mpeg-2 ts

Result: MPC-HC Window doesn't respond anymore and finally the program doesn't react anymore window appears.

Working:

1. Prefer Mainconcept Mpeg-2 Decoder
2. Select Internal .ts Parser
3. Load Mpeg-2 ts
4. Start Playback
5. Drag and Drop same Mpeg-2 ts

Result: MPC-HC cleanly closes the playing stream and opens the drag and drop one without issues

[nevcairiel]

Nev lav Splitter is somehow crashing Mainconcepts Mpeg-2 Decoder in MPC-HC when drag and drop loading is involved while still playing back (tested so far only the .ts parsing part) doesn't happen with MPC-HC parser :(

A crash is *always* the fault of the code actually crashing. No code should ever be able to crash just from some external input, or its just bad code.

[CruNcher]

Not sure what actually crashes what in the end just stops responding :) and its just the reaction to the task i try in different scenarios (Decoder) lav splitter is 0.39-47

tried Cyberlink DXVA as decoder it doesn't crash with MPC-HC in this task order with Lav Splitter i would say it's ultimate hard now to pinpoint who is doing it wrong on which side (MPC-HC, Lav Splitter or Mainconcept) :(

Gonna also try non MPC-HC test builds (as they have known init and clean close issues)

With the trunk MPC-HC builds the not responding (Lav Splitter + Mainconcept Mpeg2 Decoder SDK 9) doesn't happen with the Drag and Drop operation but with File->Close it shows the same symptoms as Drag and Drop in the test builds and again using the Internal Parser no problems :(

Also still lavsplitter-freeze.mp4 is still in 0.39-47 the Internal Parser still doesn't freeze

PS: tried also 0.39-50 same 2 issues that Internal parsers show no issues with, and also used another ffmpeg based splitter (av splitter 1.1.8.14 that as well doesn't show crash issues with Mainconcept and the Drag and Drop load while playing back test though it shows the same freeze issue with the mp4 and mov streams)

[nevcairiel]

i have this problem with a handful of files, where lav splitter can't seek through them
this one was muxed with haali, but the other files were muxed with mkvmerge.

It looks like the files are lacking Cue points (or ffmpeg fails at finding/parsing them), which ffmpeg sadly relys on for seeking.
The MKV spec says they are not required for seeking, but they do make it a whole lot easier.

It would be great to fix that in ffmpeg so that seeking without Cue points works, not sure when/if i'll have time for that, though.

Edit:
On second thought, it seems the Metaseek/Seekhead block is missing, which could certainly cause it to just not find the Cue data.
ffmpegs matroska parser is really rather limited. :(

[CruNcher]

Btw AV splitter has Programm Stream support, something really lacking in Lav Splitter compared to Potplayer parser, Mpc-hc splitter and now Av Splitter as well (though it can't instantly switch needs to restart the selected stream, its more crashy than potplayers parser, and it has a ton of black screen *.ts issues that are fixed in lav splitter (first by Video Stream Parsing later without)) :)

[madshi]

A crash is *always* the fault of the code actually crashing. No code should ever be able to crash just from some external input, or its just bad code.
Oh well, I don't 100% agree here. E.g. imagine you send an uncompressed video frame downstream with incorrect width/height information. This could result in the downstream filter reading over the bounds of the allocated IMediaSample buffer, resulting in an access violation. In this situation the crash would be your fault, IMHO. Or imagine the pitch you're using is smaller than the pitch the downstream filter is expecting. If the pitch you're using is too small, once again a potential access violation would be your fault.

Of course I'm not saying that any of this is happening between LAV Splitter <-> Mainconcept Mpeg-2 Decoder. After all in these cases you're sending bitstream and there's not so much that can go wrong there (no width, height, pitch involved etc). So I would say that it's very likely that the crash is the fault of the Mainconcept Mpeg-2 Decoder.

[Weirdo]

Hi nevcairiel, do you think it'd be possible to add audio/speaker delay settings separately for each channel to LAV Audio? It'd be of great help to us with crappy audio card drivers not giving the option. The only way I can do it now is to use ffdshow and its delay setting.

[nevcairiel]

Oh well, I don't 100% agree here. E.g. imagine you send an uncompressed video frame downstream with incorrect width/height information. This could result in the downstream filter reading over the bounds of the allocated IMediaSample buffer, resulting in an access violation. In this situation the crash would be your fault, IMHO. Or imagine the pitch you're using is smaller than the pitch the downstream filter is expecting. If the pitch you're using is too small, once again a potential access violation would be your fault.

IMHO, the consumer of the data should do some basic validations, like checking the size of the buffer. It would already catch alot problems and avoid crashes.
I at least validate that the renderer provides a buffer big enough for what i think should be the stride, and if it doesnt fit, i just refuse instead of crashing. Granted, this only applys to your examples - but you get the point. :)

Hi nevcairiel, do you think it'd be possible to add audio/speaker delay settings separately for each channel to LAV Audio? It'd be of great help to us with crappy audio card drivers not giving the option. The only way I can do it now is to use ffdshow and its delay setting.

Not going to happen, sorry.
Global delay is easy, per channel delay is exponentially more complicated.

[madshi]

IMHO, the consumer of the data should do some basic validations, like checking the size of the buffer. It would already catch alot problems and avoid crashes.
I at least validate that the renderer provides a buffer big enough for what i think should be the stride, and if it doesnt fit, i just refuse instead of crashing. Granted, this only applys to your examples - but you get the point. :)
You're right in that a few security checks definitely don't harm. But I still don't agree that a crash is always the fault of the code actually crashing. You could argue that if the code is crashing then it is obviously missing a necessary security check. But that's like saying that if you shoot me then it's my own fault for not wearing a bullet proof vest. Or if memset crashes when being called with "memset(buffer, 0, tooLarge)" then it's the fault of memset that there's a crash, and not the fault of the code calling memset. That is a weird way of seeing things, IMHO.

[nevcairiel]

Good code should be able to cope with any input data, no matter how corrupted. It can try to recover or just bail out, i don't care, but crashing is never acceptable.
I'm not saying my filters would qualify for this, however, if i find a crash that is caused by a broken file or bad interaction with something else, i at least add checks to avoid the crash, even if i cannot fix the root problem.

[SEt]

A crash is *always* the fault of the code actually crashing. No code should ever be able to crash just from some external input, or its just bad code.
Good code should be able to cope with any input data, no matter how corrupted.
Seriously, if you crash in CoTaskMemFree - it's your fault, not the one's who passed you memory allocated with malloc regardless of documentation. :devil: (Oh, no, it's actually MS fault - it throws exception in ntdll.)
And good luck avoiding crash by calling ->Release() on pUnknown pointer in some structures when caller wasn't bothered by initializing it to zero.

[nevcairiel]

Seriously, if you crash in CoTaskMemFree - it's your fault, not the one's who passed you memory allocated with malloc regardless of documentation. :devil:

The exception that proves the rule. :D
Granted, if some API a filter exposes is not honoring the contract in such a *bad* way, its nothing you can do, and the crash would still show up as being your fault - even if it isn't. Especially if there isn't even a check you can do to make sure its all secure.

Apparently the original issue that caused this discussion wasn't even a crash, but a hang - Cruncher just cannot express himself in a way that anyone would understand. :rolleyes:

[SamuriHL]

It is always the responsibility of the crashing code to handle the exception gracefully. That's why exception handling exists in the first place. And if the crashing code involves memory management then it should definitely have proper exception handling! Developers get lazy in this area... To the detriment of their users.

Sent from my Xoom using Tapatalk

[nevcairiel]

With such very bad mistakes like allocating the memory with the wrong function, i would even say its better to crash then to try to hide it, because its the only way to find such problems immediately and hope for the programmer on the other side trying to fix it. Its not a "random" condition, its a 100% occurrence, and should be fixed or some hidden problems occur later on.

[SamuriHL]

Yea I've heard that theory before from coworkers. I've never been a fan of the "let it crash to expose the bug" methodology. The exception should be caught and logged properly imo, but that is a religious debate to be sure. ;)

Sent from my Xoom using Tapatalk

[SEt]

"Proper exception handling" is utopia invented by some high-level programmers. If you can catch any C++ exception doesn't mean you also can handle something actually serious, like completely wrong stack pointer after return to your code.

[madshi]

"Proper exception handling" is utopia invented by some high-level programmers. If you can catch any C++ exception doesn't mean you also can handle something actually serious, like completely wrong stack pointer after return to your code.
Agreed.

I'm all for adding security checks and trying to catch exceptions where they happen. But blame should be put where it belongs. A missing security check is a *much* smaller "error" than code which produces grossly invalid data, writes over the bounds of allocated memory, corrupts the stack or jumps to random addresses. All of which are things which happen surprisingly often in real life.

[SamuriHL]

As I said... A religious debate. :) My personal philosophy as a developer is that the customer should not see a crash. Yes the code is broken and should be fixed. No one is arguing against that. I just think that it should be handled a bit more gracefully. But then I'm focused on user experience. In any case, broken code... Needs to get fixed.

Sent from my Xoom using Tapatalk

[madshi]

Now we've moved from "who is to blame for a crash?" to "should crashes be hidden from the user or not?". Totally separate topic. I've my own opinion on that, too, but maybe we should stop here.

[nevcairiel]

LAV Filters 0.40

LAV Splitter
- Improved demuxing of raw PCM streams
- Fixed VC-1 in MP4 with the MS WMVideo Decoder
- Improved playback of files with TrueHD audio streams
- Added support for a requested stop time from the player
- Improved playback of Blu-ray rips created by EasyBD
- Added support for RGB24 raw video in AVI

LAV Audio
- Improved decoding of formats with extremely large audio frames

LAV Video
- Added YADIF software deinterlacing
- Rewritten Interlaced options
- Added new "Aggressive" deinterlacing mode
- Moved many interlaced related options to global level
- Fixed an issue with stream compatibility detection in the CUVID decoder, causing a software fallback when not required


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

There we go, already the third release this month.

Noteworthy this time around might be the YADIF deinterlacing.
I've gotten reports that its better quality then ffdshow, however due to not being multithreaded, it could be slower. On my PC, it did seem to run just fine with not much added CPU load - but results will differ, i'm sure.

In addition to YADIF, the handling of interlaced streams was revised quite a bit, which is also evident by the re-factored options on the matter. Alot of the options that previously only affected CUVID deinterlacing are now applicable to YADIF deinterlacing, as well as the flags applied to frames before sending them to the renderer (and still CUVID of course).

Anyway, not much to say.
If you run into trouble, as always, please report with as much details as you can.

Have fun!

[mindbomb]

It looks like the files are lacking Cue points (or ffmpeg fails at finding/parsing them), which ffmpeg sadly relys on for seeking.
The MKV spec says they are not required for seeking, but they do make it a whole lot easier.

It would be great to fix that in ffmpeg so that seeking without Cue points works, not sure when/if i'll have time for that, though.

Edit:
On second thought, it seems the Metaseek/Seekhead block is missing, which could certainly cause it to just not find the Cue data.
ffmpegs matroska parser is really rather limited. :(

do you know why the problem just seems to disappear when the file is muxed again?

To me, the formation of these unseekable files is rare and random, but they sure are annoying.

[nevcairiel]

do you know why the problem just seems to disappear when the file is muxed again?

Thats obvious, on muxing the muxer will write the missing parts (Cue & Seek Heads)
The more important question is - why did it not do so from the start?

There are plans in motion to be able to seek those files at some point, note however that this will mean opening these broken files will be significantly slower, because it will have to build up a seeking index first.

[mindbomb]

alright, and lastly, does it make sense that this is video and muxer agnostic?

i have a vc-1 file muxed with mkvmerge that shows the same problem as this h264 file muxed with haali.

and on a totally different note, for lav video, it appears that the only output formats that perform well with the mpc hc subtitle renderer are the yuv formats. is that correct? i get a massive drop in performance rendering subtitles with rgb32 output, but I love lav's HQRGB conversion. :(

[rica]

Hi nev.

Normally pcm files muxed to m2ts need a decoder while they don't need any decoder when they are muxed into an mkv container.
I can directly connect those PCM_mkv files to ReClock via Haali or MPC matroska splitter and no issues.

But when i use Lav Splitter, even directshow automatically connects the audio pin to ReClock (btw ReClock is configured to bitexact streaming see: http://forum.doom9.org/showpost.php?p=1534720&postcount=188) i get this popout and no sound at all:

http://img827.imageshack.us/img827/2678/notsupported.png (http://imageshack.us/photo/my-images/827/notsupported.png/)

And i need to use a decoder like lavaudio or ffdshow.

Here is a test file:

96_24 pcm mkv:

http://www.mediafire.com/?het2xcoug60hvni

Thanks in advance.


Should be fixed for the next version. Raw PCM was not getting the appropriate media type in some cases.


Thanks for the new build but no fix for LavSplitter > raw pcm mkv > ReClock issue yet. Hoping for 040 build.
Best.


Great, raw pcm included in mkv container issue is fixed with this build.
Thanks a lot for trying to meet all of our expectations and thx for all new stuff too!

http://img215.imageshack.us/img215/6861/lav040.png (http://imageshack.us/photo/my-images/215/lav040.png/)

_ _ _ _

[DragonQ]

LAV Filters 0.40

LAV Splitter
- Improved demuxing of raw PCM streams
- Fixed VC-1 in MP4 with the MS WMVideo Decoder
- Improved playback of files with TrueHD audio streams
- Added support for a requested stop time from the player
- Improved playback of Blu-ray rips created by EasyBD
- Added support for RGB24 raw video in AVI

LAV Audio
- Improved decoding of formats with extremely large audio frames

LAV Video
- Added YADIF software deinterlacing
- Rewritten Interlaced options
- Added new "Aggressive" deinterlacing mode
- Moved many interlaced related options to global level
- Fixed an issue with stream compatibility detection in the CUVID decoder, causing a software fallback when not required


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

There we go, already the third release this month.

Noteworthy this time around might be the YADIF deinterlacing.
I've gotten reports that its better quality then ffdshow, however due to not being multithreaded, it could be slower. On my PC, it did seem to run just fine with not much added CPU load - but results will differ, i'm sure.

In addition to YADIF, the handling of interlaced streams was revised quite a bit, which is also evident by the re-factored options on the matter. Alot of the options that previously only affected CUVID deinterlacing are now applicable to YADIF deinterlacing, as well as the flags applied to frames before sending them to the renderer (and still CUVID of course).

Anyway, not much to say.
If you run into trouble, as always, please report with as much details as you can.

Have fun!

Great work, thanks. :)

P.S. The "Force Deinterlacing" tickbox needs to move up one pixel. :p

[STaRGaZeR]

New treat as progressive option working perfectly, thanks for adding it. Image quality aside, from an HTPC perspective it saves quite a bit of power (and associated heat) when watching badly flagged non interlaced HD streams. Waiting for those shortcut options to be added now :p

[psymed]

By any chance, are there any speed increases or better performances?

[CruNcher]

Yea I've heard that theory before from coworkers. I've never been a fan of the "let it crash to expose the bug" methodology. The exception should be caught and logged properly imo, but that is a religious debate to be sure. ;)

Sent from my Xoom using Tapatalk

Im seeing this all the time in NT6 (Win7) happening oh my gosh it registers so many applications fails in the background (watson is absolute silently working) though the user would never realize something is happening it's totally silent and working with the application doesn't get interrupted it feels absolutely non invasive http://forum.doom9.org/showthread.php?t=162986 :)

But yeah as Nev said it's no crash but a hang as i said the "application is not reacting message" is coming up after some clicks into the unresponsive window.

[SamuriHL]

Im seeing this all the time in NT6 (Win7) happening oh my gosh it registers so many applications fails in the background (watson is absolute silently working) though the user would never realize it http://forum.doom9.org/showthread.php?t=162986 :)

We've ended this discussion in this thread for good reason. :) I'm not suggesting we simply ignore errors. I'm simply saying we should strive to make it a bit friendlier for the end user. Blatant crashing is generally NOT user friendly. :D Giving the user a way to help the developer with a nice log and graceful exit.....that should be the ideal. But, again, this is a religious debate among developers and really doesn't belong in this thread.