View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
06_taro
21st October 2011, 01:45
I wonder if you've change anything?
If so it is nice to give out a diff file for the changes. (git diff > changes.diff is handy)
The only patch I used is your rv seek on keyframe patch.
Are you saying there is somewhere unofficial build with ordered chapters support or something like that?
You can find one in this thread like here (http://forum.doom9.org/showthread.php?p=1485416#post1485416).
nevcairiel
21st October 2011, 05:53
Are you saying there is somewhere unofficial build with ordered chapters support or something like that?
There are some experimental patches for ffmpeg, but they dont really work all that well. It may however be a basis for future developments - who knows.
kypec
21st October 2011, 14:57
I enter this: jpn:eng jpn: pol pol: off (without spaces after : )
Did you know that one can Disable smilies in text before submitting reply? Look under Miscellaneous Options
;) :p :o :)
Andy o
21st October 2011, 15:30
Hmm, i just tryed to play some .WAV with DTS inside and it doesnot work any longer - only noice.
Was not that working before?
That's usually an indication that you're not doing bit-perfect playback. What are your settings, filters, player, audio device, and OS?
watchman
21st October 2011, 15:35
If it's clipped in the original, there's nothing it can do. The algorithm should also be smart enough not to clip itself, so you wouldn't have the problem with Death Magnetic.
Problem with Death Magnetic is that it's so poorly mastered. There are songs which have dynamic range under 3db. Also, no plugin is involved in this. I'd never use DRC or some other "enchancement" effect for listing to music. It's a pity that so lots of new songs suffer from poor mastering just to sound louder, especially metal.
An EQ in itself doesn't distort the sound. It can, however, clip the output (depending on the input), which results in distortion. You should try with a lower input volume.
Second, you're just boosting some frequency range. It had been a known problem with iPods that when using EQ you could get clipping fairly easily. Apple JUST fixed it with the iPod Touch 4 and probably others. Fix was simple, boost frequency, then dial back overall gain.
I did few listening tests with different VST equalizer (Linear Phase Graphical Equalizer 2.1) and I didn't notice anything similar to electri-q. It definitely boosted bass range I chose, but without noticeable distortion with same samples, even with bigger values. So there must be something wrong with electri-q, maybe not preventing from clipping like both ouf you said, or some algo errors in free version.
Anyway, thanks for making things clear. So I'll use reclock's DRC for movies, since you guys claim it's working just fine.
ney2x
21st October 2011, 19:12
off-topic
Shark007 just posted a tool/application for our *mkv thumbnailing (alternative to divx media foundation - which is buggy), called Icaros (http://shark007.net/forum/Thread-about-Icaros?pid=22402#pid22402)
06_taro
21st October 2011, 19:41
Unpatched nightly builds (x86 and x64) :
Non-installer: LAVFilters-git-r1368(85d0d90).7z (http://j.mp/LAVFilters-r1368)
Installer: LAVFilters-git-r1368(85d0d90)-Installer.7z (http://j.mp/LAVFiltersI-r1368)
Happy to see that both libav and ffmpeg has supported both intra and inter/lossless H.264 4:2:2 decoding. Hope for the update of ffmpeg in lav's repo.
Shark007
21st October 2011, 21:08
off-topic
Shark007 just posted a tool/application for our *mkv thumbnailing (alternative to divx media foundation - which is buggy), called Icaros (http://shark007.net/forum/Thread-about-Icaros?pid=22402#pid22402)
Not totally off topic... from the Icaros README file,
the requirements are the following:
1. LAV Filters
2. .NET Framework 4
AmshTemp
21st October 2011, 22:59
Thanks Shark & co.
Now that we have a single filter that can split and decode almost anything and a true thumbnailing capability without the need for Media Foundation, suddenly, MF importance have just dropped dramatically.
The only wish I have is an option to choose the method of thumb extraction point: percentage based, which is implmented now or fixedtime based.
CruNcher
22nd October 2011, 03:59
Though Microsoft did this for a big reason and that's the stability of Explorer and ehmm not to sound rude but lav splitter isn't stable as it would be needed to make Microsoft happy to replace one of their core functions in the OS. And getting dshow back for the Thumbnail creation seems a risky thing (unless you turn of the dynamic graph creation and only allow manual connections) as well in terms of crashing caused by interferences of other filter or vfw components that could get loaded as well, not to forget to think about the Security aspect as well.
kirakami
22nd October 2011, 11:11
Frequently asked Question
Q: DirectVobSub will not load with LAVFSplitter
A: Make sure to use the "DirectVobSub" filter when adding it to the preferred filters list, and NOT "DirectVobSub (auto-loading version)". The latter will NOT work.
What does latter mean ???
Mercury_22
22nd October 2011, 11:14
After last (2 or 4 rev) updates LAVAudio x64 it's "gone" = with ac3 no sound, with DTS it's crashing...:confused:
x86 it's working OK
VipZ
22nd October 2011, 11:30
After last (2 or 4 rev) updates LAVAudio x64 it's "gone" = with ac3 no sound, with DTS it's crashing...:confused:
x86 it's working OK
I don't get this issue with my builds, x64 plays AC3/DTS fine in both decoding and bitsteaming.
nevcairiel
22nd October 2011, 11:30
Make sure to do a clean rebuild, especially of ffmpeg. Alot changed.
Mercury_22
22nd October 2011, 11:37
Make sure to do a clean rebuild, especially of ffmpeg. Alot changed.
I've re-downloaded everything (I'm using TortoiseGit)!
I'm using VS2010 SP1 + MSYS_MinGW_GCC_461_x86-x64_Full (http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=)
betaking
22nd October 2011, 11:38
Make sure to do a clean rebuild, especially of ffmpeg. Alot changed.
to nev.last lav Splitter can not Splitter/decoder standlone wavpack audio file!and lav Splitter can not Splitter/decoder wavpack audio in mkv files!
VipZ
22nd October 2011, 11:41
I've re-downloaded everything (I'm using TortoiseGit)!
I'm using VS2010 SP1 + MSYS_MinGW_GCC_461_x86-x64_Full (http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=)
I use the same base, VS with all the updates, and I updated MinGW with this, http://www.xvidvideo.ru/component/docman/cat_view/28-cross-mingwgcc-x86x64/183-cross-mingw-with-gcc-46-x86x64/193-stable.html. I use TortoiseGit 1.6.5, latest version gave me issues.
06_taro
22nd October 2011, 11:43
Now support H.264 4:2:2 decoding
Unpatched builds (x86 and x64) :
Non-installer: LAVFilters-git-r1370(3c21339).7z (http://j.mp/LAVFilters-r1370)
Installer: LAVFilters-git-r1370(3c21339)-Installer.7z (http://j.mp/LAVFiltersI-r1370)
nevcairiel
22nd October 2011, 11:46
to nev.last lav Splitter can not Splitter/decoder standlone wavpack audio file!and lav Splitter can not Splitter/decoder wavpack audio in mkv files!
wavpack in .mkv works just fine here, i don't have any standalone wavpack files.
Mercury_22
22nd October 2011, 11:47
I use the same base, VS with all the updates, and I updated MinGW with this, http://www.xvidvideo.ru/component/docman/cat_view/28-cross-mingwgcc-x86x64/183-cross-mingw-with-gcc-46-x86x64/193-stable.html. I use TortoiseGit 1.6.5, latest version gave me issues.
Your MinGW it's already in MSYS_MinGW_GCC_461_x86-x64_Full (http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=) AFAIK
I'll try TortoiseGit 1.6.5 since I'm using TortoiseGit 1.7.4.0 64bit
roytam1
22nd October 2011, 11:58
don't know if you those ffmpeg subdirectory have correctly updated by "git submodule update" command.
Instead of TortoiseGIT, using git command line is the safest method updating working copy and submodules.
betaking
22nd October 2011, 12:00
wavpack in .mkv works just fine here, i don't have any standalone wavpack files.
standalone wavpack files
http://www.mediafire.com/?5j3ft515rxvimbl
VipZ
22nd October 2011, 12:17
Your MinGW it's already in MSYS_MinGW_GCC_461_x86-x64_Full (http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=) AFAIK
I'll try TortoiseGit 1.6.5 since I'm using TortoiseGit 1.7.4.0 64bit
Ok, you right the latest version from xhmikosr does have v2. I am still using the version that had v1, then used v2 from xvidvideo.ru to update.
Mercury_22
22nd October 2011, 13:53
Now support H.264 4:2:2 decoding
Unpatched builds (x86 and x64) :
Non-installer: LAVFilters-git-r1370(3c21339).7z (http://j.mp/LAVFilters-r1370)
Installer: LAVFilters-git-r1370(3c21339)-Installer.7z (http://j.mp/LAVFiltersI-r1370)
Your LAVAudio x64 it's not working either for me ! :confused:
So it's not my builds
(http://www.multiupload.com/Q499YPQSVL) (please someone check my lavaudio x64)
But older builds mine and taro's
Thx for supporting vobsub in mp4 files. Hope for officially supporting ordered chapters.
Custom build ( 32 and 64 bit )
LAVFilters-git-r1365(2dc15e5).7z: MediaFire (http://j.mp/LAVFilters-r1365), NMM-Mirror (http://nmm.me/2c)
PS. Could you please add an option to prefer text formats subtitles or image formats when they are in the same language?
OR
Unpatched nightly builds (x86 and x64) :
Non-installer: LAVFilters-git-r1368(85d0d90).7z (http://j.mp/LAVFilters-r1368)
Installer: LAVFilters-git-r1368(85d0d90)-Installer.7z (http://j.mp/LAVFiltersI-r1368)
Happy to see that both libav and ffmpeg has supported both intra and inter/lossless H.264 4:2:2 decoding. Hope for the update of ffmpeg in lav's repo.
are working
Again its only the LAVaudio x64 which is NOT working LAVAudio x86 or MPC-HC's decoder x64 and x86 are working
SamuriHL
22nd October 2011, 14:00
don't know if you those ffmpeg subdirectory have correctly updated by "git submodule update" command.
Instead of TortoiseGIT, using git command line is the safest method updating working copy and submodules.
That's what I do... Command line git added to my build batch file. Haven't had a problem since.
Sent from my Xoom using Tapatalk
nevcairiel
22nd October 2011, 14:40
I found the x64 issue and fixed it, someone broke some code in ffmpeg.
VipZ
22nd October 2011, 14:40
Again its only the LAVaudio x64 which is NOT working LAVAudio x86 or MPC-HC's decoder x64 and x86 are working
Yep before it was my bad, forgot my script only updated x86 files. I can confirm x64 LAV Audio with AC3 or DTS gives the issues, bitsteaming is fine.
upyzl
22nd October 2011, 14:41
Frequently asked Question
Q: DirectVobSub will not load with LAVFSplitter
A: Make sure to use the "DirectVobSub" filter when adding it to the preferred filters list, and NOT "DirectVobSub (auto-loading version)". The latter will NOT work.
What does latter mean ???
latter --> "DirectVobSub (auto-loading version)"
You should use DirectVobSub, without that suffix
CruNcher
22nd October 2011, 14:47
be aware its gonna change your colorspace
asasadad_1
22nd October 2011, 14:51
@nev
could you add support for .amv video files?sample (http://uploading.com/files/8e83bce6/hellgate_e32005_med.amv/)
nevcairiel
22nd October 2011, 14:56
@nev
could you add support for .amv video files?sample (http://uploading.com/files/8e83bce6/hellgate_e32005_med.amv/)
The file itself works just fine, the only thing that doesn't is decoding with LAV Video. I can add that to the formats, i suppose.
06_taro
22nd October 2011, 16:48
x64 ffmpeg issue fixed.
Unpatched builds (x86 and x64) :
Non-installer: LAVFilters-git-r1374(4ce224f).7z (http://j.mp/LAVFilters-r1374)
Installer: LAVFilters-git-r1374(4ce224f)-Installer.7z (http://j.mp/LAVFiltersI-r1374)
mindbomb
22nd October 2011, 17:53
Check out this mkv made from importing an m2ts with vc-1 video into mkvmerge 5.0.1:
http://www.mediafire.com/?3gshc717zk26udg
By default, it plays badly. With vc-1 timestamp correction forced on, it's better, but i don't think it's perfect.
And you don't have to use my sample, as it appears to happen with any vc-1 m2ts thats been made into an mkv through mkvmerge 5.0.1.
nevcairiel
22nd October 2011, 18:37
Since mpegts import is rather new in mkvmerge, i would call it a bug in there, and the files are not muxed the same as from raw vc1 streams.
It looks like it muxed them with only PTS timestamps, but no DTS timestamps - but all other VC-1 when muxed from a raw stream for example are muxed with DTS only, which is the de-facto standard today.
I cannot detect from what source a MKV file is, and if this does not get fixed in mkvmerge, i'm afraid the files will remain broken.
You should report it to the mkvmerge author.
PS:
FWIW, those files are equally broken with all splitters. (Tried Haali and MPC-HC, as well as LAV of course)
glorp
22nd October 2011, 19:02
nev,
I have a question about the advanced audio,subs selection string after reading through the new readme. Will it be possible to use the foced/default flags as selection criteria on audio tracks as well as subs? The reason I ask is that I came on to a situation recently where a blu-ray had an audio track in Italian PCM but also an English DD 2.0 commentary track. My normal advanced selection string would be:
eng:eng|f eng:off *:*|f *:eng
but it won't work for this case because I get the English commentary and no subs instead of the Italian audio and English subs. I can't think of any way to deal with it except "mis-label" the commentary as something like "und" and include that in the string or,
if I could do:
*|f:eng eng:eng|f eng:off *:*|f *:eng
then mux the Italian track as forced. That would do it but the advanced mode would have to deal with forced flags on audio tracks as well. Maybe I've overlooked something?
Also just a suggestion that you might want to use a required delimiter other than a space between audio/sub pairs so it's easier to write and spot errors. Maybe ";" like Haali's:
eng:eng|f;eng:off;*:*|f;*:eng
It looks great so far! Thanks for getting to it.
nevcairiel
22nd October 2011, 19:11
It actually supports different delimiters, space is only one of them. "eng:eng;eng:off" is perfectly valid syntax (It supports semicolon, comma and space)
I do not have plans to allow "advanced" audio selection at this time, though. Maybe that wasn't particularly clear, the advanced selection is *only* for subtitles.
"eng:eng" means "Use english subtitles when english audio is active", it does NOT mean "Use english audio and english subtitles". Audio is still selected as in the previous version, from the separate audio language box.
I realize this is different to how Haalis thing works, but i do believe it makes more sense.
glorp
22nd October 2011, 19:59
OK. It wasn't clear that it only applied to subs and had no effect an audio selection but it won't really matter if you only have one language preference configured anyway like I do.
The only answer I can see to my specific case then is to mis-tag the commentary track as "und".
magic144
22nd October 2011, 21:23
Hi,
just been looking at some BBC iPlayer downloads (MP4 via get_iplayer)
I noticed that when playing back the .mp4 originals (Zoom Player Max v8 latest RC), LAV Splitter (0.37) seems to produce a slight A/V sync discrepency, which I do not get if, e.g., I play the same file in VLC 1.1.11 (or in fact the same file in Zoom with Haali 1.11.96.14 as the splitter)
Here is a sample:-
http://www.mediafire.com/?icr4bnnfqt0a1qd
IF I remux the file into an mkv using mkvmerge GUI (5.0.1), the mkv plays back with LAV Splitter perfectly fine (in sync terms).
One thing I do notice is that after the remux, mediainfo (0.7.50) reports -80ms for "Delay relative to video" under the audio AAC track inside the new (Matroska/mkv) container.
Hope you can find the cause of this!
cheers for a superb tool,
m
nevcairiel
22nd October 2011, 22:28
I noticed that when playing back the .mp4 originals (Zoom Player Max v8 latest RC), LAV Splitter (0.37) seems to produce a slight A/V sync discrepency, which I do not get if, e.g., I play the same file in VLC 1.1.11 (or in fact the same file in Zoom with Haali 1.11.96.14 as the splitter)
It looks like ffmpeg fails to regard the edit list (elst atom) which defines a time-stamp offset.
I found a pretty trivial fix, I'm not sure however if my fix is universally right, but it does appear to "fix" the timestamps to be exactly the same Haali delivers.
I'll have to double check some other sources to see if i this is the real solution, though.
magic144
22nd October 2011, 22:35
wow that was fast! - I knew an expert would be able to zoom in on something like the atoms
(I'm afraid MP4 is a total mystery to me - is there a simple tool out there to decode these atoms - e.g. if I point the .mp4 file at the tool, it will highlight, for instance, this time-stamp offset?)
I wonder why in the post-mux .mkv, it lists the audio track as -80ms for "Delay relative to video" (i.e. NEGATIVE)
if you play back the original .mp4 file under LAV Splitter, you need to POSITIVELY delay the audio by 80ms to make it correct...
in any case, HUGE thanks again, hope you can confirm your fix!
SamuriHL
22nd October 2011, 22:37
atomic parsley is sometimes useful for that.
magic144
22nd October 2011, 23:02
@SamuriHL - thanks, will investigate...
just found something called mp4dump from mpeg4iptools that seems to at least allow me to see all of these header structures (including this Edit List/elst atom)
here is the beastie...
type edts
type elst
version = 0 (0x00)
flags = 0 (0x000000)
entryCount = 2 (0x00000002)
segmentDuration = 80 (0x00000050)
mediaTime = 4294967295 (0xffffffff)
mediaRate = 1 (0x0001)
reserved = 0 (0x0000)
segmentDuration[1] = 3540000 (0x00360420)
mediaTime[1] = 2 (0x00000002)
mediaRate[1] = 1 (0x0001)
reserved[1] = 0 (0x0000)
which, in conjunction with reading this very interesting doc:
http://developer.apple.com/library/mac/#documentation/QuickTime/QTFF/QTFFChap2/qtff2.html
suggests to me that the "video" track (in which header this atom seems to dwell) comprises a) an 80ms segment of "empty edit" and b) "the real video clip" segment of 3540s
is that about right?
what about the reason for mediainfo's reported -80ms delay on the audio track in the .mkv though?? (and how does that relate to having to apply a +80ms delay to the audio in ZP with LAV Splitter for the .mp4 file?)
nevcairiel
22nd October 2011, 23:18
I'm not sure why, but it appears the first edit list entry defines a negative offset (at least if its mediaTime is -1, or 0xffffffff). Must be defined like that in the spec, the code works like that in other parts too. I didn't find a spec to confirm it, though.
The whole concept is called an "empty edit" apparently, but i couldn't find any specific technical details. I sadly do not have the MP4 spec at hand.
So the file is actually set up like this:
First audio at 0, first video at 160ms. The edit list is defined to offset that to 80 for video, which then results in the -80ms for audio, or +80 for video. ;)
magic144
23rd October 2011, 00:08
@nev - that document I referenced describes the empty edit
"Media time: A 32-bit integer containing the starting time within the media of this edit segment (in media timescale units). If this field is set to –1, it is an empty edit."
and
"In the absence of an edit list, the presentation of a track starts immediately. An empty edit is used to offset the start time of a track."
mostly this stuff is still just confusing me
did you get "first audio at 0, first video at 160ms" from timestamps in the actual stream data? (I don't know how to look at that)...
if I end up with a valid file, I will be happy... if I end up with a load of files that one day don't work, not so happy ;-)
so far, remuxing to mkv has always worked for me - I hope I can keep trusting that process :-)
nevcairiel
23rd October 2011, 00:17
So far it seems to do what it should do on the mp4s i have tested, but i don't have all that many tbh.
I'll keep testing some files, i doubt it has the potential to really break stuff, in the worst case you end up with more desync. :p easy enough to revert if thats the case.
magic144
23rd October 2011, 00:27
and do you think that
a) the original source file (mp4) is intact and semantically valid? (probably I expect)
and
b) remuxing it through mkvmerge (into an mkv container) is also valid? (I have always done this for years)
as long as the files are safe and sound, I can happily wait for software to catch up - plus I already have seen (and heard!) that the mkv repackaged version plays A-OK
I assume the only "error" right now is in the way the file is interpreted in LAV Splitter (using some ffmpeg library I assume from your post) which is something you have clearly already solved and are just testing :-)
...so is the fix in ffmpeg itself, or the way you use it?
thanks again for the hard work... (and for the stuff you did before to help Blight resolve those issues with the LAV Audio graph teardown issues)
nevcairiel
23rd October 2011, 00:31
I assume the file itself is just fine, and remuxing is probably fine as well, as the result is ok, apparently.
And yes, i use ffmpeg for reading the file, and it just did not account for the edit list in this case. The fix is in ffmpeg itself,.
betaking
23rd October 2011, 05:24
I assume the file itself is just fine, and remuxing is probably fine as well, as the result is ok, apparently.
And yes, i use ffmpeg for reading the file, and it just did not account for the edit list in this case. The fix is in ffmpeg itself,.
TO NEV:
if use last lav Splitter to Splitter mkv .use wavpack for lavaudio or last wavpack-directshow
http://code.google.com/p/wavpack-directshow/
mediaplayer give me not good sound!
test file
http://www.mediafire.com/?62l18m72ztxbmdo
CruNcher
23rd October 2011, 09:10
It looks like ffmpeg fails to regard the edit list (elst atom) which defines a time-stamp offset.
I found a pretty trivial fix, I'm not sure however if my fix is universally right, but it does appear to "fix" the timestamps to be exactly the same Haali delivers.
I'll have to double check some other sources to see if i this is the real solution, though.
i wonder if this fixes a freeze i got in one of my *.mov test samples finally (thats not happening with MPC-HC and neither Hallis splitter) ;)
nevcairiel
23rd October 2011, 13:00
Hi,
here is a test build which, among other things, trys to fix the MP4 A/V sync problem reported.
If you people that watch MP4 files on a regular basis could test this, and report if it improved, or possibly got worse on other files, that would be great.
http://files.1f0.de/lavf/LAVFilters-0.37-50-g41ed098.zip
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.