View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
nevcairiel
28th July 2013, 09:57
Well its not like there is a list of all weirdo FourCCs somewhere. :p
Pat357
28th July 2013, 23:42
Well its not like there is a list of all weirdo FourCCs somewhere. :p
It seems that ffmpeg/ffplay can handle this file without problems ; does this mean that the FourCC "Divx" is already known by FFplay ? Or does it use another trick to properly detect the codec ?
Wouldn't it be possible to use the same method in LAV for correct detection ? (ie use the same FourCC list and/or the same probing trick ?)
Output ffplay (verbose) :
[avi @ 044a1260] Format avi probed with size=2048 and score=100
[avi @ 04482fe0] use odml:1
[avi @ 044a1260] File position before avformat_find_stream_info() is 8204
[avi @ 044a1260] All info found
[avi @ 044a1260] File position after avformat_find_stream_info() is 35133
Input #0, avi, from 'K:\downloads\Divx failed.avi':
Metadata:
title : IFDVA_038_title2
encoder : Lavf52.13.0
Duration: 00:00:08.02, start: 0.000000, bitrate: 1997 kb/s
Stream #0:0, 1, 100/2997: Video: mpeg4 (Simple Profile) (Divx / 0x78766944), yuv420p, 720x480 [SAR 1:1 DAR 3:2], 100/2997, 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0:1, 21, 3/125: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16p, 160 kb/s
detected 12 logical cores
[AVIOContext @ 0448b680] Statistics: 182332 bytes read, 7 seeks
cyberbeing
29th July 2013, 05:15
It seems that ffmpeg/ffplay can handle this file without problems ; does this mean that the FourCC "Divx" is already known by FFplay ? Or does it use another trick to properly detect the codec?
It looks like ffmpeg mpegvideo.c may convert "Divx" to uppercase:
/* convert fourcc to upper case */
s->codec_tag = avpriv_toupper4(s->avctx->codec_tag);
s->stream_codec_tag = avpriv_toupper4(s->avctx->stream_codec_tag);
sdancer75
29th July 2013, 19:07
Hi,
Trying to complile LAVSplitter I get the following errors....
1>------ Build started: Project: DSUtilLite, Configuration: Debug Win32 ------
1> ByteParser.cpp
1> DSUtilLite.vcxproj -> C:\MyProjects\LAVFilters-master\bin_Win32d\lib\dsutild.lib
2>------ Build started: Project: LAVSplitter, Configuration: Debug Win32 ------
2> LAVSplitter.cpp
2>c:\myprojects\lavfilters-master\demuxer\demuxers\bddemuxer.h(79): error C2143: syntax error : missing ';' before '*'
2>c:\myprojects\lavfilters-master\demuxer\demuxers\bddemuxer.h(79): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
2>c:\myprojects\lavfilters-master\demuxer\demuxers\bddemuxer.h(85): error C2143: syntax error : missing ';' before '*'
2>c:\myprojects\lavfilters-master\demuxer\demuxers\bddemuxer.h(85): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
2>c:\program files (x86)\microsoft visual studio 11.0\vc\include\regex(1670): fatal error C1903: unable to recover from previous error(s); stopping compilation
2> Generating Code...
2> Compiling...
2> StreamParser.cpp
2> Generating Code...
========== Build: 1 succeeded, 1 failed, 3 up-to-date, 0 skipped ==========
Any help ?
nevcairiel
30th July 2013, 07:08
Works just fine here under both VS2010 and VS2012.
Are you maybe missing the libbluray checkout in the correct position?
Building LAV really isn't all that hard.
1) Checkout LAV Git repository (git clone <url>)
2) Checkout Submodules in the Git Repository (git submodule update --init)
3) Build FFmpeg (included build script, "sh build_ffmpeg.sh")
4) Build LAV itself in VS2010/2012
Or use "build.bat" which combines steps 3 and 4.
Of course this assumes you have VS2010 or VS2012 properly setup and a mingw-w64 GCC properly setup - but i provide the GCC i use for download if required. :)
pOpY
30th July 2013, 09:00
LAV Filters 0.58.2
LAV Splitter
- Fixed demuxing of WavPack from MKV
LAV Video
- Fixed a crash when YADIF was being used on a single- or dual-core CPU
LAV Audio
- Fixed decoding of DTS streams with a frame size change mid-stream
Download: Installer (both x86/x64) (http://files.1f0.de/lavf/LAVFilters-0.58.2.exe) -- Zips: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.58.2.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.58.2-x64.zip)
Just a bug fix/crash fix release, primarily for the YADIF crash, and i decided to pull in two other safe changes.
This release is not based on todays git master, but a stable branch i specifically created to push these changes (of course master also contains the fixes), just as a FYI for anyone that builds their own or bundles it.
Anyway, not much to say about this one otherwise!
Have fun!
thx for the fix :)
will try this and report back.
cu
pOpY
sdancer75
30th July 2013, 12:04
Works just fine here under both VS2010 and VS2012.
Are you maybe missing the libbluray checkout in the correct position?
Building LAV really isn't all that hard.
1) Checkout LAV Git repository (git clone <url>)
2) Checkout Submodules in the Git Repository (git submodule update --init)
3) Build FFmpeg (included build script, "sh build_ffmpeg.sh")
4) Build LAV itself in VS2010/2012
Or use "build.bat" which combines steps 3 and 4.
Of course this assumes you have VS2010 or VS2012 properly setup and a mingw-w64 GCC properly setup - but i provide the GCC i use for download if required. :)
Hi,
I dont think that I am missing libbluray since the Demuxers that uses libbluray compiles just fine.
Anyway, I solved this situation by adding the
#include "libbluray/bluray.h"
in the stdafx.h of the LAVSplitter project.
Regards,
nevcairiel
30th July 2013, 12:48
Anyway, I solved this situation by adding the
#include "libbluray/bluray.h"
You mean this line, which has been there for ever?
https://github.com/Nevcairiel/LAVFilters/blob/master/demuxer/LAVSplitter/stdafx.h#L42
clsid
30th July 2013, 16:46
MPC-HC randomly crashes when destroying the graph if the tray icon is enabled for the internal LAV Splitter.
nevcairiel
30th July 2013, 16:48
Thats something for them to work out, it works in a standalone config.
ƒreeman
1st August 2013, 14:06
hi.. i'm using MPC-BE with LAVFilters and madVR..
here is my configuration:
Windows 7 Professional x64
Intel Pentium Dual Core CPU 997 @ 1.60GHz 1.6GHz
RAM 4GB DDR3 @ 1333MHz
Intel HD Graphics 128 MB dedicated and 1632MB shared..
http://i40.tinypic.com/23rkcph.png
here is my question:
should I use intel quicksync decoding method or software decoding method in LAV Video Filter..?
i'm using madVR too nothing changed except smooth video on..
thanks..
SamKook
1st August 2013, 14:30
should I use intel quicksync decoding method or software decoding method in LAV Video Filter..?
i'm using madVR too nothing changed except smooth video on..
thanks..
Unless you want to save power or you notice dropped frames(this may or may not happen in your case depending on your madvr settings), always use software decoding.
sneaker_ger
1st August 2013, 14:41
Intel Pentium 997 does not support QuickSync in the first place, so it will fall back to software even if you select it.
nevcairiel
1st August 2013, 14:53
Intel Pentium 997 does not support QuickSync in the first place, so it will fall back to software even if you select it.
Thats not true.
What Intel calls "QuickSync" is the encoder support, however all CPUs of the SNB/IVY/Haswell generation with an iGPU support the decoder.
sneaker_ger
1st August 2013, 15:10
I stand corrected - only looked at the Intel chart where it just says not supported without specifying further.
ƒreeman
1st August 2013, 15:57
I stand corrected - only looked at the Intel chart where it just says not supported without specifying further.
it says available in LAV Video decoder.. what it that mean then..??
http://i43.tinypic.com/2cf8wzo.png
SamKook
1st August 2013, 16:04
it says available in LAV Video decoder.. what it that mean then..??
I suggest you read nevcairiel post again, he already explained why.
ƒreeman
1st August 2013, 16:09
Oh yeah.. I got it.. so, as of now software decoding is best on this cpu..??
Edit: one more thing, can this cpu handle madVR..? shall I use madVR or EVR Custom..??
SamKook
1st August 2013, 16:17
Oh yeah.. I got it.. so, as of now software decoding is best on this cpu..??
Software decoding is best for all CPU since, as far as I know, there's no hardware acceleration which doesn't degrade the picture quality vs software decoding.
The reasons one would use hardware decoding are the two I mentioned earlier.
detmek
1st August 2013, 16:43
Hardware acceleration does not degrade picutre quality.
DragonQ
1st August 2013, 16:47
Yeah, this is demonstrable by comparing frames. He may be referring to all of the "enhancements" sometimes added by the GPU during decoding but these can all be turned off. Same with audio - you need to tick "Disable all enhancements" in your sound card's properties to ensure it isn't doing anything funny (like my laptop which liked to apply DRC for no reason until I ticked this option). :o
SamKook
1st August 2013, 17:11
It might be because of the "enhencements", all I know is that out of all the comparison I've seen, those with hardware decoding always looked worse so I never bothered doing extensive testing with it.
The quicksync encoder(not decoder) produced especially terrible results when I was looking if it was worth getting a MB that supported it a year and a half ago.
sneaker_ger
1st August 2013, 17:22
Yes, the hardware and software decoding of LAV are bit-identical (at least for H.264). You can prove it via AviSynth. Differences can only be from the mentioned "enhancements" or deinterlacing. Any "terrible results" could also simply be driver errors.
it says available in LAV Video decoder.. what it that mean then..??
http://i43.tinypic.com/2cf8wzo.png
"Available" means that your system does indeed offer QuickSync decoding (as nevcairiel pointed out). It will turn to "Active" and appear under "Active Decoder" if it actually used which does not seem to be the case for you currently. This could for example be because the video you are playing is not compatible with the hardware decoder - not all formats are. Successful hardware decoding can depend on several factors including OS, drivers, resolution, level/DPB, format, renderer (only DXVA2 native). That's why software is used by default - it is the least error prone decoding method.
DragonQ
1st August 2013, 19:35
It might be because of the "enhencements", all I know is that out of all the comparison I've seen, those with hardware decoding always looked worse so I never bothered doing extensive testing with it.
The quicksync encoder(not decoder) produced especially terrible results when I was looking if it was worth getting a MB that supported it a year and a half ago.
If you're talking about encoding, you're right, hardware options are usually inferior (but much faster). Decoding is totally different though and can (and should) produce identical output.
detmek
1st August 2013, 23:14
I compared output of CoreAVC, LAV Video decoder and FFDShow last year, hardware and software decoding and all output streams ended up bit-identical. You can see test here (http://translate.google.com/translate?sl=sr&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Falexxandar.wordpress.com%2F2012%2F09%2F08%2Fda-li-h-264-dekoderi-daju-identican-output%2F&act=url) (P.S. Google Translate is not perfect but you can fill some blanks).
jkauff
2nd August 2013, 00:33
Nev said in an earlier post that the main reason software decoding is better is that if you have a fast CPU, it will decode many more frames per second than either CUVID or QuickSync (between the two, though, QuickSync is faster). I only use hw decoding if I'm doing a Handbrake encode that grabs 100% of my CPU most of the time.
mindbomb
2nd August 2013, 00:53
I would use quicksync. His cpu might choke on high bitrate h264.
The driver enhancements happen at the renderer level afaik, so it shouldn't impact whether you use hardware accelerated video decoding or not.
sdancer75
2nd August 2013, 07:45
You mean this line, which has been there for ever?
https://github.com/Nevcairiel/LAVFilters/blob/master/demuxer/LAVSplitter/stdafx.h#L42
Yeap you have right, but for a strange reason that I dont remember, I commented sometime the specific line, and I didn't even see it, when I added my own libbluray include.
Thanks :-)
It seems, I am getting old and I can not see things any more or maybe my laptop's screen its to small for my eyes !
pOpY
2nd August 2013, 16:33
thx for the fix :)
will try this and report back.
cu
pOpY
0.58.2 with yadif on my Core 2 Duo works :):)
thx for the fix!
nevcairiel
2nd August 2013, 16:39
Thanks for confirming!
SeeMoreDigital
2nd August 2013, 16:51
Nev,
Out of interest. When you configure 'LAV Audio' to bit-stream Dolby Digital, Dolby Digital Plus, Dolby TrueHD, DTS and DTS-HD audio via HDMI, does it use 'WASAPI' or 'DirectSound'?
Cheers
nevcairiel
2nd August 2013, 16:52
Thats not up to LAV Audio, your audio renderer decides that. Although for bit-streaming its really not important which you use, its not like the mixer can change the bitstream.
sebas_led
2nd August 2013, 20:17
Hi!
First, thanks for the great job with LAV Filters.
Second, can an application uses two instances of LAV filters? I want to have two (or more) independent graphs with LAV Splitter+audio+video+Windows default render.
Sebas
Reino
2nd August 2013, 21:11
"Available" means that your system does indeed offer QuickSync decoding (as nevcairiel pointed out).
http://www.ld-host.de/uploads/images/3791d627cda93616423962a8a78967d1.png
Oops?
nevcairiel
2nd August 2013, 21:25
I blacklisted that on XP before, but some people said it worked for them under certain circumstances, so i enabled it again. It may work on a limited number of systems and codecs.
nevcairiel
3rd August 2013, 09:38
@ nevcairiel:
Any chance you could add auto-update functionality to LAV Filters?
No. Not going to happen.
wanezhiling
3rd August 2013, 14:20
http://aleksoid.voserver.net/Sample/Subtitle/MKV/dvb-subtitle_heb.mkv
Lav splitter can't handle the dvb sub?
nevcairiel
3rd August 2013, 15:41
http://aleksoid.voserver.net/Sample/Subtitle/MKV/dvb-subtitle_heb.mkv
Lav splitter can't handle the dvb sub?
You could also say that whatever subtitle renderer was used could not handle dvb in mkv, but i fixed it anyway.
Sparktank
4th August 2013, 06:01
nevcairiel, please look at this issue (http://forum.doom9.org/showthread.php?p=1639178#post1639178) when you have time.
(Didn't want to cross-post).
frosh
6th August 2013, 11:21
Lav video decoder 0.58.2 doesn't activate neither copy-back nor native DXVA during playback of mkv with 12 reframes.
Tested with PotPlayer and MPC-BE on ATI HD 3200 videocard and 13.1 Catalyst. 0.57 works fine.
Lav splitter hangs PotPlayer up at start of playing of mkv via http.
wanezhiling
6th August 2013, 11:54
Lav video decoder 0.58.2 doesn't activate neither copy-back nor native DXVA during playback of mkv with 12 reframes.
Tested with PotPlayer and MPC-BE on AMD HD4000 videocard. 0.57 works fine.
ref16: http://i.imgur.com/czpF3e8.png
works fine here: http://i.imgur.com/Wd4hDdv.png
roytam1
8th August 2013, 01:01
@nev: is 1f0.de not available right now?
lavfsplitter$ git pull && git submodule update
fatal: unable to connect to git.1f0.de:
git.1f0.de[0: 144.76.108.235]: errno=No such file or directory
CoKing
8th August 2013, 14:12
Hi nev, some questions, namely about an odd h.264 format that I haven't been able to connect the LAV Video Decoder to.
I've seen it called a couple things, H264_bis and H264_MainConcept, and the GUID is { 0x8D2D71CB, 0x243F, 0x45E3, { 0xB2, 0xD8, 0x5F, 0xD7, 0x96, 0x7E, 0xC0, 0x9B } }
Should this be having a problem? I did some digging and it seems to be supported by ffdshow, but I also see references stating not to use it at all for video streaming. I'm trying to pick up an MPEG2 transport stream over udp (multicast) using a mainconcept demuxer that doesn't want to output one of the more common H264 formats.
I also tried using the LAV Splitter but it doesn't want to connect to the source (elecard nwsource-plus). Sadly the splitter source isn't an option since I need to be able to dump the stream to a file before it is demuxed.
SeeMoreDigital
8th August 2013, 15:08
Hi nev, some questions, namely about an odd h.264 format that I haven't been able to connect the LAV Video Decoder to.
Hi and welcome to the forum,
Please provide detailed information about your 'problem' file by using an application called MediaInfo (http://mediainfo.sourceforge.net/en) (set to text mode). And post what it reports, IN FULL as a text (.txt) file.
CoKing
8th August 2013, 15:47
Hi and welcome to the forum,
Please provide detailed information about your 'problem' file by using an application called MediaInfo (http://mediainfo.sourceforge.net/en) (set to text mode). And post what it reports, IN FULL as a text (.txt) file.
Thanks, it's been an interesting site so far! Also, thanks for pointing me to that application, I expect it will be extremely useful in the future!
I've attached the file generated from one of my sample videos. Ideally I'm dealing with live video from camera streamed by a hardware encoder that I then pick up with a directshow graph. This sample video was recorded from the source prior to demuxing so it should match what I see normally. I restream this video for testing when I am without a live source using VLC and the following script:
cd\
cd C:\Program Files (x86)\VideoLAN\VLC
VLC.exe "C:\Users\Public\Videos\EOW_110140Z_001.ts" :sout="#standard{access=udp,mux=ts,dst=224.168.99.99:1239}" -L
If there is any more information I can provide please ask; any help is very much appreciated!
SeeMoreDigital
8th August 2013, 18:14
Given the size of your .TS contained file is only 111MB, try re-muxing it into the .MKV container using the newest version of MKVmerge GUI (http://forum.doom9.org/showthread.php?p=1634657#post1634657).
If MKVmerge rejects it, there may be a problem with the .TS file...
nevcairiel
8th August 2013, 18:28
I think you didn't read his post thoroughly. :)
@CoKing:
Here is a test build with that mediatype added, let me know if it works:
http://files.1f0.de/lavf/LAVFilters-0.58.2-h264bis.zip
Keep in mind that you need to run the install_video.bat script to make it recognize the new type.
CoKing
8th August 2013, 21:01
@SeeMoreDigital:
The file should be fine; it is small because it's just a sample I use for testing and works with other decoders. I'm investigating decoders to try to find a replacement for the one I've used in the past which while it provided some of the lowest latency, it is quite old and support has been non existent the last year or so.
@nevcairiel:
Thanks for taking the time to help with this, I really appreciate it!
I tried the new build and while it was able to connect through to a renderer, I only see a grey output with very occasional artifacts (same result in either graphstudio and my app).
The output itself seems to be ok as it will render correctly using another decoder. I am able to get LAV to decode the video when using a rather specific version of the elecard mpeg push demuxer that outputs both a standard version of H264 and bis, but I really want to avoid painting myself into a corner with a specific version if possible. I'm investigating demuxers as well, which is why I was curious if you have any idea why the splitter wasn't able to connect to the source stream.
For reference, some pin spec's from graph studio:
Output pin from the Elecard NWSource-Plus:
Allocator Properties:
cBuffers: 5; cbBuffer 204800; cbAlign: 1; cbPrefix: 0;
MediaType:
major type: MEDIATYPE_Stream; subtype: MEDIASUBTYPE_MPEG2_TRANSPORT; format type: GUID_NULL;
bFixedSizeSamples: true; bTemporalCompression: false; lSampleSize: 1; cbFormat: 0;
Output pin from the Elecard MPEG Push Demultiplexer:
Allocator Properties:
cBuffers: 200; cbBuffer 655360; cbAlign: 1; cbPrefix: 0;
MediaType:
major type: MEDIATYPE_Video; subtype: {8D2D71CB-243F-45E3-B2D8-5FD7967EC09B}; format type: FORMAT_MPEG2_VIDEO;
bFixedSizeSamples: true; bTemporalCompression: false; lSampleSize: 1; cbFormat: 173;
nevcairiel
8th August 2013, 21:45
LAV doesn't support push sources, only pull sources, which is most likely why it doesn't work.
Anyway, here is another version, i forgot to add the new type in a second place:
http://files.1f0.de/lavf/LAVFilters-0.58.2-h264bis2.zip
A new H264 type doesn't need adding every day, easy to forget places. .)
CoKing
8th August 2013, 22:22
That's got it working, much thanks!
And I imagine they don't come up too often, though there does seem to be far more types than strictly necessary ...
This solves the splitter issue. I do deal occasionally with pull sources and will try LAV there as well.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.