LAV Filters - DirectShow Media Splitter and Decoders

[madshi]

Originally Posted by nevcairiel

I will eventually change the way i import the functions from the ffmpeg libs to do it manually, directly referencing the libs sitting in the exact same dir as the .ax.

That won't help if they have the same name. Let's say DirectShow filter XYZ loads its own files with LoadLibrary("c:\xyz\avcodec-53.dll"). Then afterwards you load yours with LoadLibrary("c:\lav\avcodec-53.dll"). Windows will not load your dlls, but instead return a handle to the XYZ copy of the dll to you, because Windows technically cannot load a dll with the same name twice (even if the path is different). You *have* to rename the files, if you want to make sure that you get to load your own private dll copies.

Originally Posted by nevcairiel

However, until then, its easier to simply change the name of the dlls then the extension - ffmpeg's configure script offers an option for that already, check the "--build-suffix" option.

Didn't know that option, thanks!

Originally Posted by SamuriHL

I was wondering about that, too, madshi. J River is downloading private copies of LAV filters and madVR. Which set of DLL's gets used in that case? Who knows?

I do. Since madVR's libav/ffmpeg dlls were renamed from *.dll to *.mvr there's no collision at all. Not between LAV filters and madVR at least.

[SamuriHL]

Originally Posted by madshi

I do. Since madVR's libav/ffmpeg dlls were renamed from *.dll to *.mvr there's no collision at all. Not between LAV filters and madVR at least.

That's probably good then. We still need to convince J River to whitelist both madVR's decoder and LAV Video decoder so that we can start testing them in MC16.

[Sven75]

I tested your current release and the problems with LAV Video Decoder not connecting to the default renderer are of the past. It was not the interlaced flags, but instead (as you noted in the tracker) the AR info which did the trick. Great!

Now, I was very confident that this will also solve my PowerPoint 2010 issue with one of videos you downloaded from our server (25_Video_MPEG2_Not_working_with_LAVSplitter_in_PowerPoint2010_Native.mpg), but no luck with this one.

However, it does play fine if I use
Elecard -> ffdShow or
Elecard -> MS DTV-DVD Video Decoder -> ffdShow (raw)

It's not working in the follwing cases:

Elecard -> LAV Video Decoder
LAV Splitter -> ffdShow
LAV Splitter -> LAV Video Decoder
LAV Splitter -> MS DTV-DVD Video Decoder
LAV Splitter -> MS DTV-DVD Video Decoder -> ffdShow (raw)
Elecard -> MS DTV-DVD Video Decoder

PowerPoint will refuse to insert the clip or (if I use an existing Presentation already containing the clip) it will either state "medium not available" or freeze the App completely.

At least today I only tested it on my Intel 4 Express Chipset Graphics, but as I had this issue already before LAV Video Decoder came out I know that it will also occur with ATI Graphics.

I uploaded a pptx-presentation with the linked clip and some Graph Studio reports:

http://www.mediafire.com/?9ry9aim077p4f6z

If you can please have a look at it. The problem also happens with the PowerPoint Viewer 2010 so there is no need to install the full version of the App.

P.S.: I also tried changing AR, interlace and threading options in LAV Video Decoder to no avail...

[e-t172]

Originally Posted by madshi

BTW, is there any worry about multiple DirectShow filters using different versions of the libav/ffmpeg dlls? I'm wondering because I ran into trouble myself. madVR's libav/ffmpeg dlls had the same file names as the LAV dlls, but were a different version, and one of the APIs (which I modded) was not compatible. So I got a crash. I've now solved it by renaming the dlls from *.dll to *.mvr (some additional patching is necessary). This way my version of libav/ffmpeg can happily sit next to anybody else's. Would it make sense to do a similar thing for the LAV filters, just to make sure there won't be any collision with any other DirectShow filters now or in the future? E.g. you could rename them to *.lav. Just a thought, though.

Well, the logical thing to do would be to rename any modded DLLs, but keep the original names for vanilla libav/ffmpeg. Also, the Side-By-Side assemblies feature of Windows is designed to address this kind of issues, but considering the complexity of it all, that's killing a fly with a thermonuclear device IMO.

Originally Posted by SamuriHL

I was wondering about that, too, madshi. J River is downloading private copies of LAV filters and madVR. Which set of DLL's gets used in that case? Who knows?

Typically, the first loaded wins.

[SamuriHL]

Originally Posted by e-t172

Typically, the first loaded wins.

Sure, I get that, but, it's difficult to know for sure what the "first loaded" process is. I suppose it probably goes by how the graph is built in which case LAV would "win". However, I agree with madshi's approach of renaming the DLL's that are changed.

[madshi]

Originally Posted by e-t172

Well, the logical thing to do would be to rename any modded DLLs, but keep the original names for vanilla libav/ffmpeg.

How do you define vanilla, though? The default static lib files produced for MSVC++ link to index numbers instead of function names. Which means that even if everything else is the same, if the index tables differ, getting a "wrong" vanilla libav/ffmpeg dll can already make your software crash, even if it's the same version family. I've already had this pleasant experience (2 different vanilla avcodec-53.dll files having different index tables).

[SamuriHL]

Originally Posted by madshi

How do you define vanilla, though? The default static lib files produced for MSVC++ link to index numbers instead of function names. Which means that even if everything else is the same, if the index tables differ, getting a "wrong" vanilla libav/ffmpeg dll can already make your software crash, even if it's the same version family. I've already had this pleasant experience (2 different vanilla avcodec-53.dll files having different index tables).

YIKES! Then in that case, yes, everything should be renamed and the entire ffmpeg/libav chain should be kept private.

[e-t172]

Originally Posted by madshi

That won't help if they have the same name. Let's say DirectShow filter XYZ loads its own files with LoadLibrary("c:\xyz\avcodec-53.dll"). Then afterwards you load yours with LoadLibrary("c:\lav\avcodec-53.dll"). Windows will not load your dlls, but instead return a handle to the XYZ copy of the dll to you, because Windows technically cannot load a dll with the same name twice (even if the path is different). You *have* to rename the files, if you want to make sure that you get to load your own private dll copies.

MSDN disagrees:

Originally Posted by MSDN

If lpFileName does not include a path and there is more than one loaded module with the same base name and extension, the function returns a handle to the module that was loaded first.

Meaning, if it does include a path, LoadLibrary will always load the specified module with the full path.

[madshi]

Originally Posted by e-t172

Meaning, if it does include a path, LoadLibrary will always load the specified module with the full path.

Wow, you're right!!! Learned something new today...

[nevcairiel]

Originally Posted by CoRoNe

I have two samples where the audio part is badly processed by the LAV Splitter;
- Tomsk_512x384_490kbit (v320).mpg
- tomsk_sky_512x384_600kbit(v430kbit).mpg
Both files contain AAC audio, albeit in a non-standard form.

Those files are just broken.
For one, they are MPEG-TS files, but named .mpg? Oh well, that wouldn't break anything.
However, the audio is flagged as stream_type=4, which is the ID for mpeg audio. If someone encodes stuff like this, it just will not work, sorry. I cannot support every broken file out there..

[Xaurus]

madshi/Nevcariel,

I don't remember if you recall me having real trouble with ts files.

I filmed my computer during a test so that you can see what
happens.

First I open a normal mkv file (in this case the first episode of The Borgias). As you can see, nothing strange going on, it works fine.

Then I open Underworld m2ts which is just one of many ts files that can't be played. The sound is garbled, the video it self runs at least twice as fast as it should.

You can verify the filters used that they are all in use by
going to the end of the video.

You can download my film here:
http://www.tcec-chess.org/xaurus_ts_video_truble.mp4

(filmed in 720p)

Hopefully we can try to fix this, as of right now I am not
even sure if the problem is with LAVfilters or madvr.

I am using mpc-hc (latest build), madvr 69 (same with previous verisons), LAVfilters 0.30 and earlier LAVcuvid 0.9 (now LAV video isntead, but same problem with both).

[nevcairiel]

I would need a sample file that doesn't play properly to tell you anything.

Otherwise, the audio renderer is responsible for maintaining the reference clock that dictates when frames are shown - try using another audio renderer?
On Windows XP, the renderes are directly linked into the audio drivers - bad drivers = bad renderer. On Vista/7 Microsoft put a proper mixer in between, where this wouldn't be a great problem. If you're on XP, try a renderer like ReClock - in fact, try it on whatever system you're on.

[Xaurus]

Originally Posted by nevcairiel

I would need a sample file that doesn't play properly to tell you anything.

Otherwise, the audio renderer is responsible for maintaining the reference clock that dictates when frames are shown - try using another audio renderer?
On Windows XP, the renderes are directly linked into the audio drivers - bad drivers = bad renderer. On Vista/7 Microsoft put a proper mixer in between, where this wouldn't be a great problem. If you're on XP, try a renderer like ReClock - in fact, try it on whatever system you're on.

Nev,

Thank you. What I did was to remove AC3filter and add LAVaudio instead.

And guess what?

Now it works. And I have sound too. I remember asking you
earlier why I couldn't get any sound into my external DAC with
LAVaudio, but now I do. Did you add/change anything in the
latest 0.30 version? Also, the DRC feature is great!

[nevcairiel]

AC3Filter does not work with DTS-HD (its a crappy implementation, instead of just ignoring the HD extension like any good decoder, it just fails miserably), maybe thats why it broke for you?

[Xaurus]

Originally Posted by nevcairiel

AC3Filter does not work with DTS-HD (its a crappy implementation, instead of just ignoring the HD extension like any good decoder, it just fails miserably), maybe thats why it broke for you?

Yes, perhaps. Actually it didn't cross my mind that it was an audio filter problem. In any case, I simply love LAV.

Thanks for all your help!

[Reino]

Originally Posted by nevcairiel

Those files are just broken.
For one, they are MPEG-TS files, but named .mpg? Oh well, that wouldn't break anything.
However, the audio is flagged as stream_type=4, which is the ID for mpeg audio. If someone encodes stuff like this, it just will not work, sorry. I cannot support every broken file out there..

No big deal. I picked these up from a Russian website some years ago for testing purposes. It was just the fact the MPC-HC Mpeg Splitter had no problems with these 2 videos that I thought I'd mention.

[Selur]

small bug report: LAV Filters (0.3) interferes with SIF1 (v1.20) as soon as I install the x86 splitter (even if I disable .avi support for the Splitter; may be the disabling optio in the installer doesn't work correctly) playback of SIF1 doesn't work properly. (If I disable the x86 splitter everything works fine.)

Cu Selur

[nevcairiel]

The version is 0.30 (read: zero dot thirty), not 0.3 (read: zero dot three). 0.3 is about a year old.

Anyway, the only thing LAV Splitter does when you install it, it sets itself up to be the source filter that handles AVI files. It doesn't do anything that would break anything else.
Sounds to me like that filter you're talking about just doesn't like working with LAV Splitter, is all.

[CruNcher]

Originally Posted by CoRoNe

No big deal. I picked these up from a Russian website some years ago for testing purposes. It was just the fact the MPC-HC Mpeg Splitter had no problems with these 2 videos that I thought I'd mention.

Those are Moonlight Demos back from the early research days of AAC you can be sure those are buggy muxed and non standard they where experimenting with AAC back then it seems, these should be more iso compliant http://www.elecard.com/en/download/videos.html :P

Originally Posted by CruNcher

Nice if this fixes the 30 fps lock for .ts @ Encoding that would be perfect (Playback/Transcoding)

I now also separated all of those special aac laatm muxes (bad ones, correct ones) testing them in combination with DivX AAC Decoder (Mainconcept) and the splitter/parser

PS: It looks crazy good so far in Player (Dshow) test of the 30 fps lock test shows @ 2x fast forward it gets crazy fast and doesn't locks to 30 fps max anymore after some second speedup like it used todo previously, it accelerates to the full 60 fps without problems now almost instantly under 1 sec (audio/video) that looks perfect Nev great work (now it seems even better then Cyberlinks Demuxer in those regards as good as Arcsoft and Mainconcepts) http://forum.doom9.org/showpost.php?...postcount=3309 <- so without further testing just from the first player test seems fixed.
Also only 1 stream so far couldn't be played (though it was nicely falling back to MPCs internal Splitter and played) but im still into testing around 50 others of those 158

Being able now to use LavSplitter for Transcoding/Playback is a big usability step (also makes a combined framework with as less as possible dshow code bloat much easier)

Results (Play and Go test First Playback results File open play Video/Audio no switch test no seek test):

out of those 158 streams following new issues (their are a lot of laatm issues in combination with audio decoding but most are known, separated those streams now )

1 stream no parsing @ all switches to MPCs Internal Splitter (old issue, though not critical as this fallback works fine, and changing code because of only this 1 stream seems crazy risking to much)
1 new stream (Mpeg-2, Mainconcept Mpeg-2 Decoder) unsync issues (need to check Decoder side first before looking @ splitter and audio (lav audio sync functions (ac3), easier to avoid cross codec issues that way also testing only the Mpeg-2 streams for differences saves a lot of time )
1 old H264 recording gets unsync (no possibility on the decoder side (Cyberlink Decoder) to change sync options) have to check how the HD PVR fix enabled changes the other streams behavior (as the HD PVR recordings actually work without issues since some time now without the HD PVR fix) <- No issues with DXVA

except those 3 issues and all the laatm related things everything else works 100% for .ts (including VC-1 (Lav Cuvid))
I hope the 2 last issues are just a easy settings fix (decoder and splitter side) without impacting everything else, this would then reduce it to only 1 (Play & Go) issue that isn't really critical @ all

All of the streams Played back with VMR-9 Renderless and Vsync correction (MPC-HC) no issues

Testing is done on Nvidias Framework (so stability and performance is VP2 and Nvidia Driver based Forceware 275.65 WHQL (DSP decoding part (DXVA)) with disabled Nvidia IVTC)

Originally Posted by CruNcher

Arghh just realized DXVA is totally lost (with 275.65 moded Quadro WHQL driver)

Yep it switches to YUY2 (H.264 Cyberlink) and YV12 (Mpeg-2 Mainconcept) the issue on XP for this is to search in the Driver (or decoder needs to be updated to the new Driver) i will redo the test once i get hardware playback working again (Lav Cuvid works even with this new Driver that seems not working with DXVA,testing the 1080p 60 fps playback issues with VMR9 first (maybe i finally can leave @ least DXVA to get rid of these work/not work driver (3rd party decoder DXVA issues) once and for all WipeOut 1080p 60 fps BF3 1080p 60 Fps VMR9 test.

Sorry I totally forgot to check @ the DXVA status and or CPU behavior when testing
Until i tried .m2ts and came to hard DSP and non DXVA complaint streams that suddenly showed no issues i realized something is wrong (6Cat stream,Samsung stream,4 Girls stream) and then i saw all of them where Decoded by the Cyberlink Software part (YUY2)

So above test results are Software Decoding only for both and mostly in Software Decoding you have the least issues currently with anything Hardware Decoding is where most problems arise with the Splitter except the Transcoding issue (which is entirely on the Software Decoding level, though i will double check that too now from the transcoding layer not only fast forward in player to be sure this issue with the 30 fps lock is history when transcoding).

Maybe it's also a MPC-HC issue used the newest build i first have to find out why DXVA is currently failing with VP2 and the mentioned Decoders (i suspect the Driver which isn't even for the Geforce series but Lav Cuvid (Nvcuvid Api) works fine with it)

First though i will check the Splitter level it can cause and has caused DXVA issues with Decoders often in the past, especially when not made by the same vendor (also it's the easiest to test before trying to reinstall a Driver)

Update:

1st try Splitter = Negative MPC-HC splitter behaves the same with Cyberlinks Decoder all 1080p streams lost DXVA 720p works (so Driver or Decoder issue with the Driver is the most probable cause)
2nd try Driver = Gone back to 275.50 beta no good still DXVA doesn't work as it should going back some driver revisions before 275 i know that worked now.

PS: This is serious my whole DXVA subsystem seems to go crazy not sure what code change initiated this but now i understand why Flash Player is also doing strange stuff and this doesn't even seem Driver related maybe some Directx issue Intel Board driver, actually i dunno CoreAVCs DXVA also stoped working and that can be reliable checked because of it's Red DXVA Icon.
Maybe something wants to tell me it's the right time moving to NT 6 now

Originally Posted by CruNcher

Did anyone ever lost the DXVA subsystem under XP completely or @ least it was damaged so heavily that it behaved extremely crazy ?, its my first time ever i looked for every acceleration knob i could find actually their are 3 locations accessible via a GUI i know myself Dxdiag,DirectX Controll Panel, and via the Advanced GFX Panel, everyone of them is active also the DirectX Installation seems ok still i don't get 1080p DXVA acceleration working @ all anymore
Nvcuvid isn't affected 720p,1080p no issues except the 1080p 60 fps problem because of that i actually preferred DXVA and automatic 4:2:2 Studio Profile Hardware/Software switching.

Tried to reinstall the GFX driver (several different revisions) no go i guess only the Panic Solution might be able to help a complete Internet Explorer and Windows Media Player re Installation hopefully it magically comes back after

Actually i found out you can use MPC-HC and it's internal DXVA very nicely @ least to test if it's working @ all
MPC-HC always tries to Decode with DXVA (it doesn't seem to ever fall back to Software Decoding when DXVA fails) if it's selected as internal decoder, result is a full black Screen on 1080p H.264 Videos currently with 720p Videos it works same behavior like Flash Player currently also CoreAVCs DXVA has a nice Indicator (the ATI RED CoreAVC icon that currently with 1080p videos switches to blue Software).

My Current Dilemma





its like 1080p acceleration never existed (and most here know VP2 is capable of it and i didn't imagined using it over all the years )

So after fixing my DXVA issues ( for those who want to have a insight view what was going on and how i fixed it http://forum.doom9.org/showthread.php?t=162021) , and retesting the result doesn't changed much except the 2 streams that showed sync issues also work in DXVA now without any issues, the Latm stuff stays problematic depending on the stream (how it was muxed flaged, does it use Scalable AAC ect).

but all in all it works fantastically stable on the playback side with both Mainconcepts Mpeg-2 Decoder (switching between 4:2:2 Studio Profile Software Decoding and Hardware decoding works without issues) and Cyberlinks H.264 Decoder (no dynamic Hi10, Lossless and 4:4:4 Software switching possible yet, Lav Splitter + LavCuvid in combinatation with LavVideo it would be possible same for MPC-Video Decoder and LavVideo or Ffdshow) for *.ts Or put the whole Logic for this into MPC-HC directly (detecting stream with Mediainfo then decide based on the used Hardware for the most efficient Decoder or even the only working ones).

this was done testing the 0.30 release one guy posted a BBC HD sample of a Beyonce concert here that indeed shows problems (stucks @ the first frame, no issues either with Mplayer though VLC also stucks some seconds but then plays)
If it is damaged maybe after running it throug VIdeoRedo it can be made compatible with LavSplitter (though Lav Splitter should be able to parse this if mplayer, vlc are able too)

[Superb]

A friend posted a problematic trp file. No audio is being heard.
The file: http://www.sendspace.com/file/8v77k3
MediaInfo: http://pastebin.com/nBtREGvX
Filters menu of MPC-HC while playing: http://lulzimg.com/i24/62f526.png (seems like the AAC is identified as mp1 audio)

He used LAV Splitter and LAV Audio v0.30.