On Mon, 21 May 2007 15:29:45 +0200 Stefan <[EMAIL PROTECTED]> wrote: > Hi, > > I have experimented a time now with transcode and mkvmerge, but I did > not find out, what exactly the output > > > [transcode] (probe) suggested AV correction -D 2 (80 ms) | AV 87 ms | 7 ms > > (or similar values) is trying to tell me. > I guess, the audiostream begins 80ms too early (or too late?) and the > videostream 7ms,
Yes, the main concept is this one. This capture the time difference between two streams. First and foremost, let me apologize since I haven't fully understood yet the correct terminology and all the gore details here (and that's the main reason because 1) import layer work goes ahead so slowly and because I'm so reluctant to work on demuxer layer). Corrections welcome. Anyway, I'll try to explain at my best. > leading to a difference of 80ms. Total difference of 87 ms. -D value represent the difference in frames: -D 2 -> 80 ms since (I guess we're dealing with 25fps PAL stream) 1 second / 25 frames per second -> 40ms for each frame so 2frames * 40ms_per_frame = 80ms 7 ms is remaining difference due to difference (IIRC) in frame timestamps for first frame in each (audio and video) stream. > Does this mean, I have > to add an offset of 80ms (or -80ms? or ±7ms?) when merging these > streams? Or does the output mean, that transcode corrects the streams > automatically and I do not have to bother anymore? transcode should do this correction automatically, yes. > I recognized, sometimes (why not every time when an async is detected?) async detection depends first on source material. Some source material isn't supported. > transcode seems to correct these shifts, when something like > > > [transcode] A: AV shift | -1891 ms [ -47 (A) | -11 ms ] > > appears (I did not use any -D or -M argument then). With one file I > could not merge the resulting ac3-file with mkvmerge, because it did not > find the ac3-header. This can be a bug on our side. > So I had to disable this with the '-D 0' argument, > but then again, sometimes there still is (with -D 0) a (different) shift > made by transcode. What is the difference between -D and --av_fine_ms ? -D corrects async using frame unit, while --av_fine_ms use microseconds directly. Considering again PAL 25fps streams (Hey, I don't like at all sick NTSC not-integer framerates :P), we have again 40ms for frame. So, say, -D 4 means an AV correction of 4frames * 40ms_per_frame = 160ms total and so on. HTH, -- Francesco Romani - Ikitt ['people always complain, no matther what you do'] IM contact : (email first, Antispam default deny!) icq://27-83-87-867 tiny homepage : http://fromani.exit1.org (see IDEAS if you want send code!) known bugs : http://tcfoundry.hostme.it/mantis (EXPERIMENTAL)
