LAV Filters - DirectShow Media Splitter and Decoders

[madshi]

Ok, good to know, thanks.

[clsid]

These files give a com surrogate error in Explorer:
http://www.mediafire.com/?dgp0q1j73g7rnge

I noticed a blank entry in the formats list.

Some rare formats to add: VP3, CSCD, MJPEG-B, QTRLE, QTRPZA, 8BPS, LOCO, MSZH, ZLIB, ZMVB, CAVS, VCR1, MSRLE, MSVIDEO1, VIXL, QPEG, ULTI, WNV1, Truemotion, AASC, Smacker.

Should VC-1 perhaps be disabled by default until it supports interlaced?

[nevcairiel]

Hi guys,

http://files.1f0.de/lavf/LAVFilters-video2.zip

This is the second "official" test version of LAV Video Decoder.

Changes since the first:

- Multi-Threaded decoding for H264, MPEG2, MPEG4, VP8, VP3/Theora, HuffYUV and DV (thats basically all formats ffmpeg offers multi-threading for)
- Fixed H264 in AVI
- Options to configure Multi-Threading, Stream Aspect Ratio, and which formats are active
- Alot more format support, including: MPEG1, DV, FLV1, VP6, SVQ3, H263, H261, Fraps, Theora, Indeo 3/5, Real Video 1/2/3, Bink Video
- Proper recovery for H264 after seeks, hopefully no artifacts anymore.
- Improved Output Format support for the "odd" renderers
- And a whole lot of other things.

If you're testing, please report any corruptions right after a seek or at the start of a file. Especially with H264!
The other formats are not specifically seek-proof yet, however i've really only ever seen alot of artifacting with H264.

Have fun testing!

[VipZ]

Hi guys,

http://files.1f0.de/lavf/LAVFilters-video2.zip

This is the second "official" test version of LAV Video Decoder.

Have fun testing!

Thanks

[Xaurus]

Thank you Nev.

I have an issue, when using Lav Video on several normal mkv files (not all) mpc-hc will just pause and I can't watch.

Any idea?:thanks:

[nevcairiel]

I tested a whole lot mkv files, and i couldn't reproduce any issues.
I would need a sample file that can reproduce the issue.

[VipZ]

Nev, regarding VC1 interlaced content. ffdshow uses the WM SDK to decode this, is this something you would ever consider?

[nevcairiel]

I have no plans to integrate any other decoder at this time.

[mandarinka]

Hmmmm... I'm a bit confused. Isn't the bitstream AR generally more reliable than the container AR?

Well, when a user encodes a dvd, he/she will usually not use the --sar option in x264 and just enter the AR/display resolution when muxing in mkvmerge later.

I would say that in the case of dgindex -> avs -> x264 -> mkvmerge process, most videos will have undefined or 1:1 SAR (whatever is default in x264) in the stream and more or less properly set display resolution in the mkv header. Video players usually look for the container value AFAIK, and that forces people to set that up properly, while there is nothing pushing them to specify the stream value, meaning that it's likely to be left undefined.

[Dogway]

Well, when a user encodes a dvd, he/she will usually not use the --sar option in x264 and just enter the AR/display resolution when muxing in mkvmerge later.

I always use the --sar option with "esoteric" values, and standard resolutions. It is that, or encode at strange (esoteric) resolutions with 1:1 par for correct geometry. I know TV's and hardware players ignore par but Id rather have something well done, and probably in a future hardware cathes up.

[jmone]

nevcairiel - what is the general thought about the direction of Deinterlacing;
- Add to LAV Video something like YADIF
- LAV Video calls HW (like CUVID can)
- Not part of LAV Video and users will need to add a seperate filter for post processing (but what???)
- Other....

[nevcairiel]

nevcairiel - what is the general thought about the direction of Deinterlacing

http://code.google.com/p/lavfilters/issues/detail?id=17

I thought you read the tracker. :p

[jmone]

I have no plans to integrate any other decoder at this time.

I understand the desire but like with LAV Audio using dtsdecoder.dll if it is there, it would be worth calling something when VC(i) content is encountered (either the std MS filter which is on all PC's anyway or even LAVCUVID if it is compatible with the HW).

[jmone]

http://code.google.com/p/lavfilters/issues/detail?id=17

I thought you read the tracker. :p

I do but with a priority of None - it is always worth a second (or third) go on the discussion :)

[nevcairiel]

The prioritys are not for discussion. :)

[jmone]

Thanks - worth a shot! (pulls head back in and waits patiently)

[clsid]

These files give a com surrogate error in Explorer:
http://www.mediafire.com/?dgp0q1j73g7rngeIt seems to be a build specific problem.

Nev, which mingw toolchain are you currently using?

[nevcairiel]

Nev, which mingw toolchain are you currently using?

The GCC 4.6.1 version of xhmikosr's mingw package.

[clsid]

Debug build shows that the crash occurs in the call
_wcsicmp(extension, L".evo")
inside function
CLAVFDemuxer::InitAVFormat
due to extension being NULL

The code in CLAVSplitter::CompleteInputConnection to get the filename is thus not always successful.

Funny thing is also that I have set the splitter to a lower merit than the MS AVI splitter. So it is weird that is it being used in Explorer to extract metadata.

[roytam1]

The b-frame timestamps are useless, they are basically the same as the last P/I frame befoer that. What VLC does is the same, drop the timestamps of all frames that are not references, which are b-frames in Real Video. I don't know why it works with VLC, but looking at the timestamps of the video, its not like there are gaps somewhere to compensate, i just get the frames like this. Its not dropping any frames when its stuttering, they just come in with time-gaps in them, like there are frames missing.

Maybe its the ffmpeg rmvb demuxer which actually has this problem, and not the decoder. VLC has its own demuxer for Real files - maybe that makes the difference.

MPlayer (plain win32 build) play that file quite well too.
http://sourceforge.net/projects/mplayer-win32/files/MPlayer%20and%20MEncoder/revision%2033883/

Log:
MPlayer Sherpya-SVN-r33883-4.2.5 (C) 2000-2011 MPlayer Team
163 audio & 369 video codecs
Scanning dir C:/WINDOWS/fonts
Scanning file C:/WINDOWS/fonts/8514fix.fon...done
(...)
Scanning file C:/WINDOWS/fonts/wst_swed.fon...done

Playing j:\[KTXP&DYMY][Kamisama Dolls][03][GB][RV10].rmvb.
REAL file format detected.
Stream description: Audio Stream
Stream mimetype: audio/x-pn-realaudio
[real] Audio stream found, -aid 0
Stream description: Video Stream
Stream mimetype: video/x-pn-realvideo
[real] Video stream found, -vid 1
Stream mimetype: logical-fileinfo
VIDEO: [RV40] 848x480 24bpp 23.000 fps 0.0 kbps ( 0.0 kbyte/s)
Clip info:
author: 憤荌趼躉郪
copyright: bbs.ktxp.com
comment:
Load subtitles in j:\
==========================================================================
Opening video decoder: [realvid] RealVideo decoder
Error loading dll
ERROR: Could not open required DirectShow codec drvc.dll.
Read the RealVideo section of the DOCS!
VDecoder init failed :(
Opening video decoder: [realvid] RealVideo decoder
Error loading dll
ERROR: Could not open required DirectShow codec drv43260.dll.
Read the RealVideo section of the DOCS!
VDecoder init failed :(
Opening video decoder: [realvid] RealVideo decoder
Error loading dll
ERROR: Could not open required DirectShow codec drvc.bundle/Contents/MacOS/drvc.
Read the RealVideo section of the DOCS!
VDecoder init failed :(
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffrv40] vfm: ffmpeg (FFmpeg RV40)
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, s16le, 96.0 kbit/6.80% (ratio: 12000->176400)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
==========================================================================
AO: [dsound] 44100Hz 2ch s16le (2 bytes per sample)
Starting playback...
Movie-Aspect is undefined - no prescaling applied.
VO: [directx] 848x480 => 848x480 Planar YV12

[Tsukihime]

Hi guys,

http://files.1f0.de/lavf/LAVFilters-video2.zip

This is the second "official" test version of LAV Video Decoder.



:thanks:
Is there an x64 build?

[betaking]

Hi guys,

http://files.1f0.de/lavf/LAVFilters-video2.zip

This is the second "official" test version of LAV Video Decoder.

Changes since the first:

- Multi-Threaded decoding for H264, MPEG2, MPEG4, VP8, VP3/Theora, HuffYUV and DV (thats basically all formats ffmpeg offers multi-threading for)
- Fixed H264 in AVI
- Options to configure Multi-Threading, Stream Aspect Ratio, and which formats are active
- Alot more format support, including: MPEG1, DV, FLV1, VP6, SVQ3, H263, H261, Fraps, Theora, Indeo 3/5, Real Video 1/2/3, Bink Video
- Proper recovery for H264 after seeks, hopefully no artifacts anymore.
- Improved Output Format support for the "odd" renderers
- And a whole lot of other things.

If you're testing, please report any corruptions right after a seek or at the start of a file. Especially with H264!
The other formats are not specifically seek-proof yet, however i've really only ever seen alot of artifacting with H264.

Have fun testing!

thanks , and i have bug repot use lavvideo decoder some wmv1 wmv2 wmv3 and avi by encoder divx3-divx5 or xvid mpc-hc give a carsh but not haapen a mkv by encoder divx or xvid!vc1 and h.264 play is ok!

[CruNcher]

I found the issue for my DXVA problems it was the NT 5 /3GB Kernel switch :(

[nevcairiel]

Debug build shows that the crash occurs in the call
_wcsicmp(extension, L".evo") inside function CLAVFDemuxer::InitAVFormat due to extension being NULL.

Thansk, added a NULL check around it.

MPlayer (plain win32 build) play that file quite well too.

MPlayer also has its own demuxer, afaik.

thanks , and i have bug repot use lavvideo decoder some wmv1 wmv2 wmv3 and avi by encoder divx3-divx5 or xvid mpc-hc give a carsh but not haapen a mkv by encoder divx or xvid!vc1 and h.264 play is ok!

Like always, i do need a sample for a crash. Otherwise its impossible to debug.

[Mercury_22]

LAVSplitter freezing with some avi files (non-interleaved)

Sample (http://www.megaupload.com/?d=5IN79PM9) (wait till 00:40)

[VipZ]

Nev, got an issue with this sample, http://www.mediafire.com/?8jq2e4857a3udcz

When using LAV Splitter which this, video just stalls and only audio plays, if MPC splitter used with LAV Video/Audio it plays fine.



Here is latest build inc x64 for anyone who wants, http://www.mediafire.com/?2wjbhfo69jjfdzx

[betaking]

to:nevcairiel,check your pm!

[nevcairiel]

to:nevcairiel,check your pm!

The file you send me plays just fine for me.

[betaking]

The file you send me plays just fine for me.

Faulting application mpc-hc.exe, version 1.5.3.3466, time stamp 0x4e2ba357, faulting module quartz.dll, version 6.6.6002.18158, time stamp 0x4b195520, exception code 0xc0000094, fault offset 0x000b9c29, process id 0xf88, application start time 0x01cc49ffa871eb60.

[nevcairiel]

Ah it only happens with VMR-9, should be fixed.

[betaking]

Ah it only happens with VMR-9, should be fixed.

YES some wmv1 wmv2 wmv3 and avi by encoder divx3-divx5 or xvid mpc-hc give a carsh only happens with VMR-9 too! and use SYSTEM DEFAULT video render wmv1 wmv2 wmv3 and avi by encoder divx3-divx5 or xvid mpc-hc give black screen! use evr evr cp evr sync all is ok!

[nevcairiel]

Here is a new test build with mostly crash fixes and small cleanups

http://files.1f0.de/lavf/LAVFilters-video3.zip

[betaking]

Here is a new test build with mostly crash fixes and small cleanups

http://files.1f0.de/lavf/LAVFilters-video3.zip

thanks all my problem is fix now!:)

[ForceX]

Lavvideo has some memory release issues. I took a 720p Hi10P video and opened it 3 times from MPC-HC; first using madVR decoding, then lavvideo. (from File> Open File..). Following is Task Manager's Physical memory usage graph:

http://i.imgur.com/DV6Oi.png

As you can see, madvr properly frees up the memory before opening another file. But instead of releasing the memory, lavideo just keeps allocating more for the new video. Pressing Stop doesn't free any memory either, unlike madVR.

This is especially bad when decoding a 4:4:4 10 bit 1080p video like the Big Buck Bunny video, which eats huge amount of RAM for decoding, and doing it a couple times with lavvideo made my PC freeze due to RAM shortage. Below is the BBB444p10 file being opened twice:

http://i.imgur.com/tS4YD.png

Setup: Win7 64 bit, MPC-HC 1.5.3.3462 32 bit, madVR .69, LAVFilters-video3

[nevcairiel]

Thanks for the report, i found the issue, and now memory returns to nothing when the file is closed.

[Reino]

I have two samples where the audio part is badly processed by the LAV Splitter;
- Tomsk_512x384_490kbit (v320).mpg (http://www.zshare.net/video/929484053a484192/)
- tomsk_sky_512x384_600kbit(v430kbit).mpg (http://www.zshare.net/video/92948599a3b3adeb/)
Both files contain AAC audio, albeit in a non-standard form.
The MPC-HC MPEG Splitter correctly passes it through to whatever AAC audio decoder (FFDshow in my case), but the LAV Splitter incorrectly detects it as MP2 at the beginning and later on MP1, MP2 or MP3 alternately. The video part of the first sample plays normal, but the second sample freezes immediately.

Furthermore, a question for nevcairiel;
I was wondering if you could release a splitter-only package.
Obviously for he who wishes to use FFDshow or any other decoder instead of the LAV Decoder.

[nevcairiel]

I was wondering if you could release a splitter-only package.
Obviously for he who wishes to use FFDshow or any other decoder instead of the LAV Decoder.

No. The actual decoder files (the .ax files) are pretty small, the big parts are the ffmpeg libraries - which are also required for the splitter.

There is no downside in downloading the full package - just only install the parts you want to use.

[madshi]

Yep, please don't split the downloads. I like to have everything in one package.

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.

[nevcairiel]

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.

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.

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.

I may enable it in a future version, just 'cause.

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

[madshi]

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.

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!

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? :D
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]

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]

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 (http://msdn.microsoft.com/en-us/library/dd408052%28v=vs.85%29.aspx) 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.

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? :D

Typically, the first loaded wins.

[SamuriHL]

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]

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]

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]

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 (http://msdn.microsoft.com/en-us/library/ms684175%28v=vs.85%29.aspx):

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]

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]

I have two samples where the audio part is badly processed by the LAV Splitter;
- Tomsk_512x384_490kbit (v320).mpg (http://www.zshare.net/video/929484053a484192/)
- tomsk_sky_512x384_600kbit(v430kbit).mpg (http://www.zshare.net/video/92948599a3b3adeb/)
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..