mkvtoolnix 1.0 is out :)

[thana]

vobsubs in mkv are stripped of the mpeg-ps and compressed with zlib (default in mkvmerge). so it's possible that they are infact smaller than the rar-ed .sub and .idx files, or they should at least not be much bigger.

if you mux the mkv once with vobsubs and once without, you can see for yourself if the mkv-with-vobsubs is bigger than mkv-without-vobsubs + rar-ed vobsubs.

[Mosu]

Originally posted by pest
but i wonder if it's possible to mux rared idx/subs?

No. There are two aspects here:

1. The subs are, as thana has pointed out correctly, stripped of their MPEG PS headers and then zlib compressed. This results in quite a gain in size, but not as much as if the .sub itself would have been RARed. A small comparison:

-rwxr--r-- 1 mbunkus mbunkus 61822 Feb 25 08:39 vobby.idx
-rw-rw-r-- 1 mbunkus mbunkus 1811692 Feb 25 08:40 vobby.mks
-rw-rw-r-- 1 mbunkus mbunkus 1147823 Feb 25 08:40 vobby.rar
-rwxr--r-- 1 mbunkus mbunkus 5838848 Feb 25 08:39 vobby.sub
-rw-rw-r-- 1 mbunkus mbunkus 1515472 Feb 25 08:43 vobby.gz


The .sub is the original, the .rar the RARed .sub, the .mks is the mkvmerged version. The .gz is the .sub compressed with gzip (it's the same algorithm used by mkvmerge). The difference between the sizes of the .mks and the .gz can be explained by the fact that each subtitle entry in the .mks MUST be uncompressable on its own. This means restarting the compressor for each block. Each block is usually 500 - 3000 bytes long. Therefore the compression is not as effective as it is for the whole file.

2. Reading RARed subs by mkvmerge will not be implemented either because there's no open source implementation of the RAR v3 algorithm. RARlabs only license the algorithm for a lot of cash. This also impedes playback -- e.g. no open source video player would be able to decompress those subs. (mplayer can only read RAR v2 compressed external VobSubs, for example.)

[Mosu]

Originally posted by karl_lillevold
I did and it works -- Thanks! After using mmg to construct command line and then adding --default-duration 0:41708us in front of the RMVB filename argument, I ended up with (almost) 23.976 fps as default framerate. I remuxed with 41708375ns and got exactly 23.976 ;) Hope you can find a way to add it to the GUI.

Looks like I should allow "--default-duration 0:23.967fps" as an argument, too :) That feature won't make it into the next release of mmg which is due this weekend, but I'll work on it after that.

[Mosu]

Originally posted by Bluedan
Mosu, what's the current state of the head section aka pre1.2.0?

It's pregnant and expecting twins in about three months ;)

Seriously: I'm planning on releasing the next version (from the 1.2.0 tree, not from the 1.0.x tree) this weekend.

Once in the past I knew where to look for a change log. :rolleyes:

https://svn.bunkus.org/mosu/trunk/prog/video/mkvtoolnix/ChangeLog

How far are you away from <higher aims> (i.e.DVD menue transitions??).

Well, mkvmerge can read everything that robux' menu extraction tool can produce, but it will be nothing that Joe User will be able to handle manually. Everything's done via XML files. mkvtoolnix will never contain a "DVD menu editor" -- it's way too complex. If I or someone else from the Matroska team ever writes such an editor it will be a separate application.

So muxing is possible, creation of the necessary files is difficult (or needs robux' tool which still has some bugs). It's all still under heavy development.

Is AVC implementation considered as _quite_ ready?

AVC is considered stable. But only from MP4. From AVI (e.g. x264) it will use the AVI compatibility mode. I don't support this officially -- if it does work then be happy. If not, then don't tell me :)

The last news (http://www.bunkus.org/videotools/mkvtoolnix/avc-status.html) written here are nearly 2 weeks old and there has been a new build nearly every day....

No news are good new ;) Most builds fix a bug or another and are not about AVC at all (at least not the later ones). I don't necessarily mention all those bug fixes in the ChangeLog, btw. Especially not if they haven't been present in the 1.0.x line (e.g. bugs introduced in the 1.2.0 line and fixed later. No need to tell people about that.).

[pest]

@mosu and thana

Yes, Winrar v3 licenced the PPM-algorithm by Dmitry Shkarin

Thanks for the explanation...
its zlib-compressed? :rolleyes:
this is better than nothing :)

pest

[rawr]

zlib (http://www.gzip.org/zlib/) or rather gzip (http://www.gzip.org/) - basically the same thing but Mosu mentioned both. Same compression, different format.

Good to here you're still considering speex, I noticed they have some annotated code (http://www.speex.org/API/refman/annotated.html) for their data structures online, this might not be bit-specific enough for you though.

rawr.

[Mosu]

You might want to look at http://forum.doom9.org/showthread.php?s=&threadid=90628

[Yong]

Anyone has success mux Quicktime MOV to MKV using MKVToolnix1.0.2? The MOV i use contain Sorenson Video V3(SVQ3)(decode with ffdshow) and QDM2(decode with Nero Quicktime DS decoder),
but MKVToolnix only mux the video stream only,
and unable to decode correctly with ffdshow using Haali matroska splitter.
MPlayer(latest CVS version)also unable decoding it...

[Dreassica]

Originally posted by Mosu
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?).


Sorry for the late response. You are right, after extracting, the comma's were still present in SSA file, so I guess it;s somebug in vsfilter provided with matroska pack.

[Hiro2k]

Time for this thread to rest in peace.