LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

Originally Posted by asasadad_1

@nev
could you add support for .amv video files？sample

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]

x64 ffmpeg issue fixed.

Unpatched builds (x86 and x64) :

Non-installer: LAVFilters-git-r1374(4ce224f).7z
Installer: LAVFilters-git-r1374(4ce224f)-Installer.7z

[mindbomb]

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]

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]

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 engff *:*|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 engff *:*|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;engff;*:*|f;*:eng

It looks great so far! Thanks for getting to it.

[nevcairiel]

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]

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]

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]

Originally Posted by magic144

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]

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]

atomic parsley is sometimes useful for that.

[magic144]

@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/m...ap2/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]

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]

@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]

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. easy enough to revert if thats the case.

[magic144]

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]

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]

Originally Posted by nevcairiel

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]

Originally Posted by nevcairiel

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]

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-g41ed098.zip