[Matroska-users] --sync with Matroska input files

Adam Nielsen a.nielsen at optushome.com.au
Thu Nov 13 10:10:20 CET 2003

> First you should probably not open the same source file twice and use
> proper track IDs for --sync instead.

Ah, that's what I should've done - I completely forgot about track IDs, and 
the only reason why I was opening the file twice was because otherwise it 
wasn't adjusting the sync (i.e. the audio and video were being offset by the 
same amount.)

Well, I tried this:

mkvmerge -o new.mkv --sync 2:10000 old.mkv

and it had the same effect as before - there's a huge 10 second delay at the 
start of the file, but as soon as I seek it's gone back to the original sync 
(even if I quickly seek forward then back again, I can watch the same video 
frames but with different audio.)

I think it's definitely related to using an mkv file as input, because it 
works perfectly using a divx avi+vorbis ogg as input.

In case it makes a difference, the input file was created with an older 
version of everything (I created it before you advised me to upgrade) but the 
mkvmerge I'm using now is the newer version.

> Have a look at the output of 'mkvmerge -i old.mkv'. It'll report the track
> IDs. I further assume that track ID 1 is a video track and track ID 2 is the
> audio track you want to have delayed.

Yes, the track IDs are correct:

$ mkvmerge -i old.mkv

File 'old.mkv': container: Matroska
Track ID 1: video (V_MS/VFW/FOURCC, DIVX)
Track ID 2: audio (A_VORBIS)

> Interesting. Actually this is pretty unlikely because the sync process
> inserts or drops frames, so it'll add three seconds of silence in front
> of your audio track. So I don't see why mplayer should revert to the
> non-synced behaviour upon seeking.

That's what I thought - is it possible that timecodes or something aren't 
being rewritten between the two files?  When I mkvmerge the AVI/Ogg I get a 
frame count, but mkvmerging an .mkv gives me a time count (in seconds.)

> Can you give me some more detail on the file used?

$ mkvinfo old.mkv

+ EBML head
+ Segment
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 61)
|+ Segment information
| + Muxing application: libebml v0.6.0 + libmatroska v0.5.2
| + Writing application: mkvmerge v0.7.1
| + Duration: 1468.960s
| + Date: Fri Oct 31 04:51:16 2003 UTC
| + Segment UID: 0xa0 0x97 0xae 0xe4 0x4f 0xf9 0x69 0xe8 0xbe 0xf3 0xdb 0x20 
0x42 0x88 0x12 0x75
|+ Segment tracks
| + A track
|  + Track number: 1
|  + Track UID: 1378031395
|  + Track type: video
|  + MinCache: 1
|  + Codec ID: V_MS/VFW/FOURCC
|  + CodecPrivate, length 40 (FourCC: DIVX, 0x58564944)
|  + MaxCache: 1
|  + Default duration: 40.000ms (25.000 fps for a video track)
|  + Video track
|   + Pixel width: 516
|   + Pixel height: 570
|   + Display width: 760
|   + Display height: 570
|  + Lacing flag: 0
| + A track
|  + Track number: 2
|  + Track UID: 3715179801
|  + Track type: audio
|  + Codec ID: A_VORBIS
|  + CodecPrivate, length 4218
|  + Audio track
|   + Sampling frequency: 48000.000000
|   + Channels: 2
|+ Cluster

> > Is this a known issue?  I'm using mplayer for playback.
> No, I use mplayer, too, and so far sync worked fine for me including
> seeking.

Yes, it's worked fine for me too, that's why I was surprised at this.


More information about the Matroska-users mailing list