MKVToolNix 1.6.0 has been released

[Isochroma]

When I mux xvid mp4 natively, media player classic 6.4.8.4 cannot recognize the stream anymore?

[Mosu]

thanks for the clarification, so, what you are saying in a nutshell is that XviD-in-AVI is a "well-established" hack supported by every tool and we don't have to worry about anything, right?

That is 100% correct.

[Mosu]

I created a native xvid mp4 from an xvid avi using mp4box. However, after I've muxed it into MKV using mkvmerge 1.5.0, the properties box shows the Codec ID as:

V_MS/VFW/FOURCC

Why is it being muxed as vfw and not natively?

I've given reasons a couple of posts ago. The quick version is:

a) compatibility (not all splitters/players support it),
b) until 1.5.5 it was very buggy (I've already fixed another bug that's still present in 1.5.5),
c) like Liisachan put it "it's a well-established hack that is supported by every tool out there". Again compatibility.
d) native ASP storage doesn't give a lot of pros compared to VfW mode storage at the moment.

[#2]

Hi guys every time I try to appened my end credits to the main film I get this error. In fact every time I try to append anything it fails.

mkvmerge 1.55
windows xp sp2
rmvb format tracks
useing Auto rv10 7.1 update to encode the rmvb streams

I'm sure this used to work in 1.40 or arround there :?

[Mosu]

Any return code > 2 is a crash. Please upload the files somewhere, e.g. on my FTP server. Thanks.

[Mosu]

Heya guys,

here we go! I consider this release to be a "major bugfix" release. There were a lot of issues that I was finally able to track down or that were simply new bugs I didn't know about before. So I strongly advise to upgrade to this version.

However, AVC aspect ratio info handling has been changed (see the ChangeLog below for details), and it's quite possible that new bugs have introduced in the process.

Here are the typical links...
...to the home page:
https://www.bunkus.org/videotools/mkvtoolnix/
...the source code:
https://www.bunkus.org/videotools/mkvtoolnix/mkvtoolnix-1.5.6.tar.bz2
...the Windows Unicode installer:
https://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-1.5.6-setup.exe

All the other packages are/will be available from the home page.

The ChangeLog since 1.5.5:
-----------------------------------------------------------------
2005-09-06 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: If the user selected an aspect ratio for a video track, then chose "File -> new", added a file, selected another video track and chose the same aspect ratio as before then it wasn't added to the command line. Fixes Anthill bugs 132 and 146.
* mkvmerge: bug fix: Support Qt/MP4 files with 64bit offset tables ('co64' atom instead of 'stco' atom).

2005-09-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: mkvmerge will remove the aspect ratio information from a AVC/h.264 video track bitstream and put it into the display dimensions (until now the AR information was kept on the bitstream level). The reason is that in Matroska the container AR is supposed to take precedence over bitstream AR, but some decoder programmers ignore the container AR in favour of bitstream AR.

2005-08-31 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: The GUI couldn't open files with non-ASCII chars in the file name.

2005-08-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Display dimensions were reported for all tracks, even if they weren't present. In that case they allegedly were "0x0" which caused mmg to add "--display-dimensions ...:0x0" for each track read from a Matroska file, even if the tracks were not video tracks.

2005-08-28 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The extracted timecodes were wrong for blocks with laced frames.

2005-08-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: If a Matroska file with a MPEG-4 part 2 video track was muxed into a Matroska file and the source file did not contain the display width/height elements for that track then the aspect ratio was extracted from the video data itself which clashes with the Matroska specs which say that display width/height default to the pixel width/height if they're not present.

2005-08-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Native MPEG-4 ASP storage was still bugged: timecodes were assigned twice, frames referenced themselves.
* mkvmerge: bug fix: Embedded fonts and pictures in a SSA/ASS file are not discarded any longer. They are converted to Matroska attachments instead. Other sections that were discarded are added to the CodecPrivate data as are "Comment:" lines in the "[Events]" section. Those comment lines still lose their association for which "Dialogue:" line they were meant, but that cannot be changed.

2005-08-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: --delay was not working at all.
* mkvmerge: bug fix: Single digit numbers followed by 's' were not recognized as valid numbers with a unit (e.g. in '--delay 0:9s').
-----------------------------------------------------------------

Have fun :)

[Pirks]

* mkvmerge: bug fix: Support Qt/MP4 files with 64bit offset tables ('co64' atom instead of 'stco' atom).
Have fun :)

Where is my portion of fun, Mosu? :-) I thought that 'co64' bug was mine but it was not. So where is my big fat ugly 'oops.mov' bug? :)

[Liisachan]

Other sections that were discarded are added
to the CodecPrivate data as are "Comment:" lines in the "[Events]"
section. Those comment lines still lose their association for
which "Dialogue:" line they were meant, but that cannot be
changed.


The Actor field is all empty in the demuxed ASS. Is this a known limitation, by desing, or a bug? If this can't be fixed, maybe we should include every single SSA/ASS muxed into MKV redundantly as attachments.

[Mosu]

The Actor field is all empty in the demuxed ASS. Is this a known limitation, by desing, or a bug? If this can't be fixed, maybe we should include every single SSA/ASS muxed into MKV redundantly as attachments.

Quoting the Matroska codec specs for SSA/ASS:

Events are stored in the Block in this order: ReadOrder, Layer, Style, Name, MarginL, MarginR, MarginV, Effect, Text (Layer comes from ASS specs ... it's empty for SSA.) "ReadOrder field is needed for the decoder to be able to reorder the streamed samples as they were placed originally in the file.

So yes, it is a limitation. You can of course attach the ssa/ass file in each case. It was never my intention that you could first mux and then demux ssa/ass into Matroska and out again without any losses because that is simply not possible (and not wanted either).

[Mosu]

Where is my portion of fun, Mosu? :-) I thought that 'co64' bug was mine but it was not. So where is my big fat ugly 'oops.mov' bug? :)

That one's still broken, yes :(

[Liisachan]

Quoting the Matroska codec specs for SSA/ASS:
Events are stored in the Block in this order: ReadOrder, Layer, Style, Name, MarginL, MarginR, MarginV, Effect, Text (Layer comes from ASS specs ... it's empty for SSA.) Ah, then probably it's a kind of bug...or rather, the specs are not clear enough. Name in SSA is sometimes called Actor in ASS, but they are totally the same thing. You can (and should) store ASS's Actor just like SSA's Name. The only difference is the name of the filed. It may be called Name or Actor but anyway it's the 6th Field, essentially the same thing.

Edit: Examples

Dialogue: Marked=0,0:00:00.00,0:00:00.00,Style1,Alice,0000,0000,0000,,This is SSA.
Dialogue: Marked=0,0:00:00.00,0:00:00.00,Style1,Bob,0000,0000,0000,,"Alice" and "Bob" = "Name"

Dialogue: 0,0:00:00.00,0:00:00.00,Style1,Alice,0000,0000,0000,,This is ASS.
Dialogue: 0,0:00:00.00,0:00:00.00,Style1,Bob,0000,0000,0000,,"Alice" and "Bob" = "Name" or "Actor"

[Mosu]

You can (and should) store ASS's Actor just like SSA's Name.

Ah ok, that's easy. I'll be away until Sunday, though, so no fix before the end of the weekend.

[Mosu]

Where is my portion of fun, Mosu? :-) I thought that 'co64' bug was mine but it was not. So where is my big fat ugly 'oops.mov' bug? :)

Now at least I know what's wrong. Your file uses edit lists which are not supported by mkvmerge. Edit lists can tell the player ('demuxer' would be more accurate) which frames to use. I'll add a check so that mkvmerge will abort if edit lists are in use because correct muxing is not guaranteed in such cases.

I might add support for edit lists at some point, but not right now.

[Liisachan]

str += _T("[Events]\n");
str += (et == EXTSSA)
? _T("Format: Marked, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text\n")
: _T("Format: Layer, Start, End, Style, Actor, MarginL, MarginR, MarginV, Effect, Text\n");
f.WriteString(str);
From: http://cvs.sourceforge.net/viewcvs.py/guliverkli/guliverkli/src/subtitles/STS.cpp?view=markup

There is a sample SSA generated by Subresync in [matroska-devel] proposed storage of ssa/ass (http://lists.matroska.org/pipermail/matroska-devel/2003-May/000571.html). If the same file is saved as ASS with the same Subresync, you'd see "Actor"

[Mosu]

You can (and should) store ASS's Actor just like SSA's Name.

Try
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.6-build20050909-1.rar

I'm off for the weekend now :)

[Liisachan]

Ah ok, that's easy. I'll be away until Sunday, though, so no fix before the end of the weekend. Thank you. There are a few things that are not well-documented, or not compatible with the written specs (ass-specs.doc): of course it's not your fault :)

[Liisachan]

Try
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.6-build20050909-1.rar

I'm off for the weekend now :) Have fun :)
Tested your quick build, and it worked fine except one tiny unimportant cosmetic problem.


G:\>mkvmerge -o test.mks test.ass
mkvmerge v1.5.6 ('Breathe me') built on Sep 7 2005 18:18:02
...
G:\>mkvextract tracks test.mks 1:demuxed.ass
...
G:\>diff -U 1 test.ass demuxed.ass
--- test.ass 2005-09-09 18:05:00.755625000 +0900
+++ demuxed.ass 2005-09-09 18:05:53.708750000 +0900
@@ -22,2 +22,3 @@
Format: Layer, Start, End, Style, Actor, MarginL, MarginR, MarginV, Effect, Text
+
Dialogue: ...
One empty line is added between the "Format" header and the first "Dialogue" line. No real problem.

OT: imo it's important that you can demux and reuse the data once stored in the container. That's what flexibility/usability means, isn't it? I don't like a "one-way" container where you can put things into but you can't get things out of. Demuxing doesn't necessarily have to be bit-identical, but a significant part like Name/Actor shouldn't be lost.

Being reusable is important in creation. My dream is a GPL-like "open-sub" development. Reusing (retranslation from English to French for instance) would be easier with Names, than without them.

[_E_]

Hi there.

I've been trying to produce a vfr matroska. First of all, I produced the timecodes, chapter file and audio needed. Then I encoded the video using MeGUI into a mp4 file. I've checked it out and it works absolutly fine. However, when I add it in mkvmerge ( along with the audio/timecodes/chapter files), the resultant mkv file doesnt play. I tried encoding the same file again using MeGUI to mkv then add it to mkvmerge...the result is still the same.

At the end, I had to restore to vfw avi x264 output and force mkvmerge to accept it ( I've used the command line --engage allow_avc_in_vfw_mode ) and the resultant mkv file did work. However, I am not aiming to use vfw AVC due to it's limitations/current bugs. Is there any way I can add native AVC mkv/mp4 files on mkvmerge , or are these still not supported for some reason?

I appologize if this was a redundant question.

[jellysandwich]

At the end, I had to restore to vfw avi x264 output and force mkvmerge to accept it ( I've used the command line --engage allow_avc_in_vfw_mode ) and the resultant mkv file did work. However, I am not aiming to use vfw AVC due to it's limitations/current bugs. Is there any way I can add native AVC mkv/mp4 files on mkvmerge , or are these still not supported for some reason?

I appologize if this was a redundant question.

What version are you using? I have no problems handling native AVC with Mkvtoolnix 1.5.6.

js

[LeMoi]

Could you make that we dit the output filename and press enter, the muxing process start ?

[_E_]

What version are you using? I have no problems handling native AVC with Mkvtoolnix 1.5.6.

js

I am using MkvToolsNix 1.5.6

[stephanV]

Are you using the correct timecode file format? (you must use v2 i believe)

[_E_]

I am using v1 timecode ( always worked for me before). But even when I don't use a timecode file nor an audio file, the resultant mkv file still doesn't play. :(

[Liisachan]

Are you using the correct timecode file format? (you must use v2 i believe)

How about the v3 thing? (I don't know what exactly it is though)

I am using v1 timecode ( always worked for me before). There was a major change related to Timecode in 1.5.x. Maybe that's why.
http://forum.doom9.org/showpost.php?p=694472&postcount=69

[iapir]

Timecode files v3 are the easiest ones when dealing with VFR, because it's human readable :D

[_E_]

I dunno, v1 is pretty readable for me....or maybe that's because I am getting blind ;) j/k

Anyways, it turned out to be a splitter problem, updating it with the build available on Jarod's page made the video play again.

[Mosu]

Have fun :)
Tested your quick build, and it worked fine except one tiny unimportant cosmetic problem.

Great :) I can live with an extra empty line, and so should everybody else ;)

OT: imo it's important that you can demux and reuse the data once stored in the container. That's what flexibility/usability means, isn't it?

True, and you can demux a SSA file. But for a lot of formats you will never be able to demux to a bit-identical file. Just think of putting VFR content from Matroska into AVI. Bit identical? No way.

Same for SSA. Bit identical? Nope, there may be empty lines. For SSA it's even worse: comment lines are still stored in CodecPrivate, but they lose their position among the dialogue lines during muxing. Will that be fixed? No. Why? Because Matroska is not meant as a lossless container for everything (including data that's not needed for playback). The only "container formats" that keep source files 100% intact are archivers like ZIP, RAR etc.

I don't like a "one-way" container where you can put things into but you can't get things out of. Demuxing doesn't necessarily have to be bit-identical, but a significant part like Name/Actor shouldn't be lost.

True, and Name/Actor was clearly a bug in mkvmerge.

[Mosu]

Could you make that we dit the output filename and press enter, the muxing process start ?

Sure, I just hope I don't forget about it ;)

[Doom9]

I took the liberty of changing the thread title to reflect the latest version.. mkvtoolnix 1.5.0 is rather old by now.

[jellysandwich]

Mosu, would it be possible for you to add a "remove all" button for the input files?

js

[Liisachan]

Isn't Ctrl+N enough?

[foxyshadis]

I was thinking how it seems mmg would be the perfect place to add a mkv demuxer. Right click on the track, or have a button below "down" for demux.

Obviously for mp4, rm, and some other video formats a translation to AVI isn't always feasible, but for the most part video frames can be pulled right out of mkv and inserted into avi, and I believe most audio formats could be simply demuxed or written into a wave container as well. For the goofy formats, a raw bitstream fallback would be used.

Maybe just an idea for a future version of mkvtoolnix, but it'd sure be nice to not have to hit up the command-line every time I need to rip the audio track or transfer video to another container to edit.

[LeMoi]

So maybe MKVExtractGui is for you ;)
http://corecodec.org/projects/mkvextractgui/

[foxyshadis]

Interesting. I'd still like to have an all-in-one, but that's a nice alternative, with a few minor nitpicks.

[jellysandwich]

Isn't Ctrl+N enough?

Not really. I'd like to keep the Output filename and File/segment title so that I could simply change the number in them instead of having to type/paste them for every single episode.

js

[#2]

In fact every time I try to append anything it fails.

1.56 dosen't work, 1.41 dose, 1.42 dosen't. Hope that helps.

[Pirks]

Your file uses edit lists which are not supported by mkvmerge. I'll add a check so that mkvmerge will abort if edit lists are in use because correct muxing is not guaranteed in such cases.

I have uploaded another small sample to your ftp, named oops_remux.mov. It's the same fragment as oops.mov, except I have remuxed it in QuickTime. The video and the audio streams are the same as in oops.mov as well. And, quite important, I think it also has edit list atom. If you check both oops.mov and oops_remux.mov you'll see that they both contain atom "elst" which is QuickTime's edit list atom. Just do string search, elst is there in both files, and even with the same offset, 0x11C.

Now, if you try to remux oops_remux.mov in mmg you will see that mkv you get on output contains BOTH video and audio. Haali sees both streams, plays them smoothly, everything works great. Unlike oops.mov, which was losing video track after remuxing by mkvmerge.

The question is: why mkvmerge loses video track in oops.mov and does not lose video track in oops_remux.mov? Is this because of edit list or the edit list by itself is not enough?

If presence of edit list by itself is enough to force mkvmerge lose the video track, why then oops_remux.mov contains elst (i.e. edit list) atom AND gets remuxed into mkv with BOTH tracks, without a hitch? Isn't that a contradiction?

[Mosu]

If presence of edit list by itself is enough to force mkvmerge lose the video track, why then oops_remux.mov contains elst (i.e. edit list) atom AND gets remuxed into mkv with BOTH tracks, without a hitch? Isn't that a contradiction?

It's not a contradiction. The thing is that mkvmerge does not lose the video track at all! Even remuxing oops.mov resultings in a file containing both video and audio. But for oops.mov the video track contains one garbage frame at the beginning which the edit list says to skip. mkvmerge simply ignores edit lists and does not skip that first "frame".

Upon playback the codec/player/whatever tries to decode that garbage, failes, and won't display anything. Hence your thought that there's no video track in the MKV to begin with.

Now your remuxed file might still contain an edit list but in this case the first frame that mkvmerge muxes is actually the first "real" frame of the video, so playback works.

Edit list atoms are simply ignored and sometimes not necessary for playback.

[Mosu]

Mosu, would it be possible for you to add a "remove all" button for the input files?

No. Technically it is possible, of course, but I won't implement that, sorry. Ctrl-n should be enough. mmg has too many features as it is already.

[Mosu]

I was thinking how it seems mmg would be the perfect place to add a mkv demuxer. Right click on the track, or have a button below "down" for demux.

Won't happen, sorry. Too many features in mmg already.

[foxyshadis]

Won't happen, sorry. Too many features in mmg already.
That's fine. In that case I'll work with the creators of mkvextract to fix a few things instead.

[Mosu]

Hi guys every time I try to appened my end credits to the main film I get this error. In fact every time I try to append anything it fails.

This should be fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.5.6-build20050915-1.rar

[#2]

Thanks Mosu :)

[lrms]

I've found a small bug in mkvmerge GUI v1.5.6 in the chapter editor.
If you add double quotes (") in chapter titles (like: The Mission is a "Go") after you save and reload the XML file, mmg crashes. The workaround I've found is simple: I've just used single quotes instead (').

[Mosu]

I've found a small bug in mkvmerge GUI v1.5.6 in the chapter editor.
If you add double quotes (") in chapter titles (like: The Mission is a "Go") after you save and reload the XML file, mmg crashes. The workaround I've found is simple: I've just used single quotes instead (').

You've indeed found a bug, but it wasn't " vs '. mmg crashes if you do this:

Create new chapters, add a subchapter, chose a name + start time.
Save those chapters in XML format.
Chose "Chapter Editor -> New".
Reload the saved chapters. mmg will now crash.

However, if you restart mmg and load the XML file save earlier it works OK. So it's not the file.

Unfortunately I haven't found out what the problem is yet... I'll keep working on it.

[LeMoi]

When i extract idx/sub from an mkv file, most of the time, i have at least 5 subs which are not extracted correctly : their timestamps are not extracted correctly, they disappear before they appear :s

[Mosu]

When i extract idx/sub from an mkv file, most of the time, i have at least 5 subs which are not extracted correctly : their timestamps are not extracted correctly, they disappear before they appear :s

Are those entries OK when they're inside the MKV?

[LeMoi]

Yes, they are OK inside the original mkv, and after extraction and remux in another mkv, these entries are no more

[Mosu]

Yes, they are OK inside the original mkv, and after extraction and remux in another mkv, these entries are no more

Ok, definitely a bug in mkvextract then. Could you please upload that file to my FTP server into the subdirectory "bug-152" that I've already created along with a text file containing the timecodes that are wrong? I don't need all the timecodes that are wrong, three or so should suffice.

Thanks.

[LeMoi]

Hmm, it's a 700MB file... i'll try and split the moment where they are wrong