PDA

View Full Version : changes in mkvmerge's timecode file handling


Mosu
12th August 2005, 12:04
Heya guys,

as I do not know which programs out there create timecode files for mkvmerge I'll post this here in the hope that the authors either read this or some of you will point the authors to this post.

The situation

Until today it was necessary for timecode file authors (persons as well as programs) to know which frame type was which and to sort the timecodes accordingly. In a v2 timecode file, and assuming you have the usual picture sequence IPBBP... with 40 fps, the timecode file would have to look like this:

# timcode format v2
0
120
40
80
...

This is both cumbersome and error-prone.

The change

The upcoming mkvmerge 1.5.1 has been fixed to accept sorted timecodes in the timecode files and to re-order them itself as it is necessary. This means that for the same picture sequence IPBBP... the timecode file will now have to look like this:

# timecode format v2
0
40
80
120
...

This should make it a lot easier for folks to write their timecode files, especially with advanced video codecs like AVC which can even have timecode sequences like 0, 120, 80, 40, ... In fact, if mkvmerge encounters a timecode v2 file with timecodes that are not sorted then it will error out. A new format will be introduced, v4, that is identical to v2 but allows unsorted timecodes. This format should never EVER be used because if you think you know better than mkvmerge how to timecode the frames then you're most likely mistaken. But anyway, I don't want to prevent the user from shooting himself in the foot ;)

I'd appreciate it if you guys could forward this to whoever wrote the tools out there creating timecode files. Thanks.

Liisachan
17th August 2005, 06:48
I have this problem with VLC 0.8.4-svn-win32 on my Windows 2000 SP4:
my MKV file (the video is Xvid with b-vops) 'quivers' in the temporal direction, as if the frames were rendered in the coding order, not in the display order, ie: frames 1234=IBBP, coded as 1423 is rendered as 1->4->2->3 not 1->2->3->4 (that's my guess)

VLC 0.8.2 and 0.8.3-svn don't have this problem.
If the same XviD is in AVI, it plays normally on VLC 0.8.4-svn too.
The problem is when the video is MKV'ed.

Do you think this is somehow related to that change about timecode format?
Or would that be just a bug in the alpha build of VLC?
VLCs I'm testing are here.
http://vthr.via.ecp.fr/~videolan/build/win32/

Mosu
17th August 2005, 09:09
Dunno, could be either program. Does the same file work with 0.8.2/3 but not with 0.8.4? Then blame VLC. Does remuxing the AVI with 1.5.0 (plain) play correctly in 0.8.4 but breaks if you use a pre-build for muxing?

Liisachan
17th August 2005, 09:32
Does remuxing the AVI with 1.5.0 (plain) play correctly in 0.8.4 but breaks if you use a pre-build for muxing? No, 0.8.4 acts weirdly for the both files (the one muxed with the official 1.5.0 and one muxed with the 1.5.0 in /pre/). The pre-build is acutually already 1.5.1, even tho the version info is 1.5.0?

If so, obviously this problem has nothing to do with the diffrence between 1.5.0 and 1.5.1. What i thought might happen was, the muxer is still using 1.5.0 system while the newest decoder is already using the new algo, and that causes the problem.

Mosu
17th August 2005, 09:51
No, 0.8.4 acts weirdly for the both files (the one muxed with the official 1.5.0 and one muxed with the 1.5.0 in /pre/). The pre-build is acutually already 1.5.1, even tho the version info is 1.5.0?

Not really ;) I still have to fix at least two bugs that I know of before 1.5.1 or 1.5.5 or whatever I'll call it will be released. But yes, the version in /pre/ is pretty close to the next release already.

If so, obviously this problem has nothing to do with the diffrence between 1.5.0 and 1.5.1. What i thought might happen was, the muxer is still using 1.5.0 system while the newest decoder is already using the new algo, and that causes the problem.

Dunno. You said you were muxing XviD from AVI, right? Actually this hasn't really changed unless you use both --engage native_mpeg4 and --timecodes for the video tracks... What has changed is AVC muxing even without --timecodes. So in this case I'd really blame vlc.