mkvtoolnix 1.0 is out :)

[Mosu]

Hey,

I have a new release of mkvtoolnix -- 1.0.2. This is not the long-awaited release with the tons of new features like support for AVC, MPEG-1/-2 etc. Neither does it contain all the bug fixes that the current development version contains. It is merely a release that works with today's releases of libebml and libmatroska. Nevertheless a few bug fixes are present as well.

For those who want to build it (like the packages): please be aware that you need libebml 0.7.3 and libmatroska 0.7.5 which were released not an hour ago. You can grab their sources at http://dl.matroska.org/downloads/

The usual links to...
...the homepage:
http://www.bunkus.org/videotools/mkvtoolnix/
...the sources:
http://www.bunkus.org/videotools/mkv...-1.0.2.tar.bz2
...the Windows installer:
http://www.bunkus.org/videotools/mkv....0.2-setup.exe

Binary packages for other systems/distributions are available from the home page.

Here's the ChangeLog since 1.0.1:
----------------------------------------------------------
2005-02-06 Moritz Bunkus <moritz@bunkus.org>
* Released v1.0.2.
* all: bug fix: Fixed compilation with the upcoming new versions of libebml and libmatroska.

2005-01-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge did not accept XML chapter files created with older mkvtoolnix versions due to deprecated chapter elements. Such elements are now skipped.

2004-12-18 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Again the window handling. Hopefully this is better than the other attempts.

2004-12-15 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: One was able to crash mmg by pressing 'ok' in the muxing dialog right after muxing finished, especially if the 'abort' button was hit before. This mostly happened on Linux.
* mkvmerge: bug fix: Fixed negative audio displacement for a couple of formats.
----------------------------------------------------------

Have fun

[Yong]

Many thanks, Mosu

[ermannob]

[bond]

Originally posted by Mosu
If you all want a technical explanation of what's going on:

MP4 files can contain an atom named CTTS. Especially for AVC/h.264 video tracks. This atom maps the timecodes usually found in a MP4 file to display timecodes. Normally, the timecodes are 0ms, 40ms, 80ms, 120ms... etc. for a 25 FPS file. With a CTTS atom these can become e.g. 0ms, 120ms, 40ms, 80ms... This is also the case for B frames in "normal" MPEG-4.
...
Therefore the Matroska team (more like Haali and me) decided to do it the "right" way and to store display timecodes. This is "right" because Matroska does indeed store display timecodes. This is also true for what I call "native MPEG-4 storage" or "native B frames"

beaware that ctts is also needed without b-frames, when the encoder does some frame reordering (eg p-frames), which is possible in avc and already done in mainconcept (have a look here) via the "reordering delay" option (isnt enabled if b-vops are enabled no matter what is set in the gui)

[Mosu]

Originally posted by bond
beaware that ctts is also needed without b-frames, when the encoder does some frame reordering (eg p-frames), which is possible in avc and already done in mainconcept

I know, and mkvmerge will always print the following warning if no CTTS atom is found:

The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.

Unfortunately I have two MP4 files without CTTS atoms that are perfectly fine. In such cases this warning will be a "false positive".

[bond]

Originally posted by Mosu
Unfortunately I have two MP4 files without CTTS atoms that are perfectly fine. In such cases this warning will be a "false positive"

with avc? propably muxed with an old version of mp4creator (it should set the ctts right now for avc with b-frames)

note that mp4creator (and therefore mp4ui too) with asp will not set a ctts when you mux from .avi to .mp4 (what most people will do), if you mux from raw to .mp4 they do it

yeah, thats mpeg4ip...

[Mosu]

Originally posted by bond
with avc? propably muxed with an old version of mp4creator

Dunno. Someone provided those samples, I just downloaded them But playback is fine for those. At least on Linux with mplayer and ffmpeg. But I guess that ffmpeg is not as bitchy about the timecodes on Linux as Nero's decoder is, so those files might not play on Windows. Anyway, having the warning is a good thing, especially in light of...

note that mp4creator (and therefore mp4ui too) with asp will not set a ctts when you mux from .avi to .mp4 (what most people will do), if you mux from raw to .mp4 they do it

mkvmerge will have the same problem. Muxing from AVI will be a bitch. I'll have to parse the bitstream in order to find out frame types/references. That's so much work...

[bond]

Originally posted by Mosu
Dunno. Someone provided those samples, I just downloaded them

lol, well if you run mp4info from mpeg4ip you will see the used streams (or open it in mp4ui, if they say "invalid" as description, its avc )
but beaware to only open a copy of your files in mp4ui, as mp4ui has the "nice" feature to optimize (aka rewrite) the files whenever you open them automatically, i dont trust it

But playback is fine for those. At least on Linux with mplayer and ffmpeg. But I guess that ffmpeg is not as bitchy about the timecodes on Linux as Nero's decoder is, so those files might not play on Windows.

yep might be, still what counts are the avc specs, not what players do, cause i think that the players surely do some assumptions about what the ctts says and so ignore it, a method that might not work on all streams

mkvmerge will have the same problem. Muxing from AVI will be a bitch. I'll have to parse the bitstream in order to find out frame types/references. That's so much work...

[filewalker]

A little cosmetic bug...

During muxing the progress bar doesn't show the "green bar" anymore(mkvmerge GUI v.1.0.2).

Cu filewalker

[Dick Buttkiss]

I'm using mkvtoolnix 1.0.2 and I'm having a problem with chapters not showing up at all.


I load a chapter file in a *.txt format. mkvtoolnix opens and parses the chapters correctly, but when I mux everything together mediaplayer classic 6.4.8.2 (latest ver) doesn't see any chapters in my *.mkv file.

When I mux chapters in VDub-mod everything works fine. However, I like your chapter editor more. I didn't seem to see anything in the last few pages that helped me.

[thana]

the chaptereditor in mmg has nothing to do with the other settings for muxing. you have to save the chapters to a file first and then add them in the 'global'-tab as 'chapter file' and then mux normally. or you can first mux your file without chapters, and then add the chapters in the chaptereditor with "save to matroska file".

[Dick Buttkiss]

Originally posted by thana
the chaptereditor in mmg has nothing to do with the other settings for muxing. you have to save the chapters to a file first and then add them in the 'global'-tab as 'chapter file' and then mux normally. or you can first mux your file without chapters, and then add the chapters in the chaptereditor with "save to matroska file".

That was it, thanks man.

[Dreassica]

Stumbled across a weird problem with ssa subtitles muxed in with mkvtoolnix 1.0.2 Whenever a line ends with a comma it wont show up at playback when muxed in via MKVtoolnix. They do show when I play them back via softsub thoough. Maybe a small bug?

[rawr]

Bump for the speex support request a while back. Though you're obviously busy with other bits at the moment, I have a definate usage for this atm (director's comments track... not worth bloating a file over, but reasonable quality very low bitrate would make it worth backing up), and can see other usage (audio books -> mka etc).

rawr.

[Mosu]

Originally posted by Dreassica
Stumbled across a weird problem with ssa subtitles muxed in with mkvtoolnix 1.0.2 Whenever a line ends with a comma it wont show up at playback when muxed in via MKVtoolnix. They do show when I play them back via softsub thoough. Maybe a small bug?

Probably. I haven't forgotten about this, but I haven't looked at it yet either. It should be easy enough to fix. I'll get to it this weekend.

[Mosu]

Originally posted by rawr
Bump for the speex support request a while back.

Ok, I've talked a bit to a guy on IRC (illi) about Speex. I think I can get it working although there are no specs for Speex (at least not about what I need to know -- the bitstream format. There are specs about the algorithms/methods used, but those don't help me ) But I won't work on it before the next release (due hopefully end of next week).

[Mosu]

Originally posted by thana
the chaptereditor in mmg has nothing to do with the other settings for muxing. you have to save the chapters to a file first and then add them in the 'global'-tab as 'chapter file' and then mux normally.

Very true, and often a source for confusion. I think I'll have to add a warning if there are chapters loaded when muxing is about to start although no chapter file has been selected on the "global" tab (and only then. No need for too many warnings). The chapter editor should have been in its own dialog and not yet another tab, but it's always easy to say that with hindsight.

[Mosu]

Originally posted by Dreassica
Stumbled across a weird problem with ssa subtitles muxed in with mkvtoolnix 1.0.2 Whenever a line ends with a comma it wont show up at playback when muxed in via MKVtoolnix. They do show when I play them back via softsub thoough. Maybe a small bug?

I've tested mkvtoolnix 1.0.2 and current SVN, and neither one drops such a comma. Please have a look at your file in a hex editor (or use mkvextract to extract that SSA track again and look at the resulting file) and make sure that the comma is really not present in the file. If it is then it's a problem with some part of the playback software (VSfilter?).

[karl_lillevold]

I just tried the latest Guliverkli Matroska Splitter and discovered a little problem playing back my trans-muxed RealVideo files. They all have the framerate set to 30.00 fps (RM is inherently VFR, and this might be the max FPS as read by mkvmerge in the RM header I presume).

However, the actual framerate is 23.976. With the previous version of Matroska Splitter, reclock does not detect the framerate and I can manually set it to 23.976. The "problem" with the newer splitter is that now Reclock gets 30.00 as the framerate, and it is not possible to change it back to 23.976 fps. The only solution I have found is to go back to the older splitter version.

Could it perhaps be possible to allow changing the framerate in the MKV file with something like Matroska Properties, in the same way it can now change the display size...? Is it possible to "brute force" hex edit the MKV files?

Alternatively, there does not seem to be an option in mkvmerge to set the framerate, if I were to re-mux all the files and set the framerate correctly..

[b166er]

MKV being VFR I doubt it would work. Maybe the pb is in MatroskaSplitter ? Have you tried Haali's splitter ?