MKVToolNix v24.0.0 released

[Mosu]

How am I supposed to check that? It works for me, all my test cases pass, I haven't had a single report similar to yours.

So: what were you doing eaxctly? Command line used? Which OS? Which files? Can I have access to the files?

[vmrsss]

How am I supposed to check that? It works for me, all my test cases pass, I haven't had a single report similar to yours.

So: what were you doing eaxctly? Command line used? Which OS? Which files? Can I have access to the files?

system: MacOSX Lion 7.2, gcc-4.6.2
commandline: everything using mkvmerge and mkvextract appears to give the same error, mkvpropedit and mkvinfo appear to work fine.

For instance:
mkvmerge -o test.mkv test.264
mkvmerge v5.1.0 ('And so it goes') built on Dec 2 2011 19:47:41
'test.264': Using the demultiplexer for the format 'AVC/h.264'.
'test.264' track 0: Using the output module for the format 'AVC/h.264'.
mkvmerge(13325) malloc: *** error for object 0x7fff722e6860: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

And of course you can have the files.

Just tell me what kind of tests you'd like me to run

[Mosu]

I'm sorry, but I don't support Mac OS. Upload the files somewhere (e.g. my FTP server, see signature) and if I can reproduce it on Linux I will take a further look.

[vmrsss]

I'm sorry, but I don't support Mac OS. Upload the files somewhere (e.g. my FTP server, see signature) and if I can reproduce it on Linux I will take a further look.

I will upload, but like a few days ago, I don't think this is a problem with Mac... It says you are deallocating a pointer not allocated. There is must be a subtle bug somewhere, I hoped that by seeing the message, you would immediately see what the problem might be.

I have uploaded vmrssstest.264 to your FTP server.

[vmrsss]

Hi Mosu, Perhaps this stack trace can help. It looks like the crash happens when calling mm_file_io_c::prepare_path from mm_io.cpp


Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
*** error for object 0x7fff722e6860: pointer being freed was not allocated

objc[30845]: garbage collection is OFF

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff84aa582a __kill + 10
1 libsystem_c.dylib 0x00007fff8a32ca9c abort + 177
2 libsystem_c.dylib 0x00007fff8a38b84c free + 389
3 mkvmerge 0x000000010fe132e6 mm_file_io_c::prepare_path(std::string const&) + 310
4 ??? 0x00007fe000000000 0 + 140600049401856

[Mosu]

Not really, no. As you can see in the source code of that function at https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/mm_io.cpp I don't even do any (manual) memory management in that function -- I simply ask Boost to create the directory if it doesn't exist. Maybe it's a bug in Boost.

[Mosu]

Also: your file works fine on both Linux and Windows.

Additionally I've talked a lot with a guy on IRC yesterday evening who was tuning my regression test library to be runnable on Mac OS. With a few adjustments to tests/run.rb he was able to, and they all passed. That shows that mkvtoolnix is fine on Mac, and it really looks like a problem that's solely on your end (compiler, Boost, whatever).

[vmrsss]

it could be boost. or gcc-4.6.2. I am now trying to identify with commit introduced the problem.

[Mosu]

Please don't expect any more help from me. Like I said I don't support mkvtoolnix on Mac.

[vmrsss]

So, the commit where things go wrong is:


commit 4c01e66dd3add13805afb342ce9e545eb6444c57
Author: Moritz Bunkus <moritz@bunkus.org>
Date: Mon Nov 28 22:09:56 2011 +0100

Replace my own directory creation code with boost::filesystem::path


I will try to recompile boost. Though if it was a bug in boost, more people would have this problem...

what do you think?

EDIT: I have boost 1.47: have you tested against this?

[Mosu]

That if it wasn't some bug on your end more people would have noticed this issue in MKVToolNix by now.

[Superb]

http://www.google.com/search?q=boost%3A%3Afilesystem%3A%3Apath+crashes

[vmrsss]

http://www.google.com/search?q=boost%3A%3Afilesystem%3A%3Apath+crashes

Ah, ah.

Mosu, please look at my previous post: Have you tested against Boost 1.47? (or only 1.46)?

[Mosu]

1.46.0 and 1.48.0.

[vmrsss]

unfortunately the problem persists with boost 1.48, just compiled and installed. If anybody is able to advise...

I'm on Lion, with the Xcode 4.0 kit, which uses llvm-gcc-4.2.1. Wonder whether I could convince bjam to compile boost using gcc-4.6.2, installed elsewhere on my machine, and whether that would help..

[Mosu]

Why don't you ask that on Boost's mailing lists/in their IRC channel? I'm sure they can tell you how to use bjam/b2 and whether or not mixing libraries compiled with a different compiler version than the main program might pose problems.

[vmrsss]

Why don't you ask that on Boost's mailing lists/in their IRC channel? I'm sure they can tell you how to use bjam/b2 and whether or not mixing libraries compiled with a different compiler version than the main program might pose problems.

done. I found good help (from somebody setting up a macport fro mkvtoolnix). For future refences, that was indeed the problem: to compile boost with llvm-gcc-4.2.1 and mkvtoolnix with gcc-4.6.2 produces horrors!

The small remaining issue is that ./configure leaves BOOST_SYSTEM_LIB unset in build-config, while it should be
BOOST_SYSTEM_LIB = -lboost_system

Perhaps you can check that out. For the moment, fixing that manually, gives a smooth compilation and, most important, a working binary.

[Mosu]

I'm guessing that's the guy going as "konablend" on IRC and github as he and I were talking about that very same thing (mkvtoolnix for Macport, Boost, gcc 4.2 etc) yesterday. Today he submitted patches that supposedly fix Boost on Mac, and I've already merged them. So please try the current git.

[vmrsss]

yes, it's him/her.

As I said, when I compile I get problems with linking


Undefined symbols for architecture x86_64:
"boost::system::generic_category()", referenced from:

etc


because -lboost_system is not added to LDFLAGS by ./configure.


SORRY, it works now. I suppose I had not re-run ./autogen
I then have to edit build-config to add BOOST_SYSTEM_LIB manually.

[Mosu]

And like I said: there are fixes in my git repository for boost on Mac. So please get the current sources from there, be sure to rebuild configure itself with autogen.sh, and run configure with a full rebuild afterwards.

[Paxmilitaris]

mkvalidator keeps telling me my mkv files have errors or warnings but that they are valid.
Is there a way to fix those errors?

[Mosu]

Warnings are warnings, and most of them are completely harmless.

Errors with files produced by mkvmerge are more serious. What kind of errors do you encounter?

[Carpo]

i get the same as Paxmilitaris, mainly its just

WRN0C0: First Block for video track #1 in Cluster at 1460262888 is not a keyfram
e
WRN0C0: First Block for video track #1 in Cluster at 1462581420 is not a keyfram
e
WRN0C0: First Block for video track #1 in Cluster at 1464090820 is not a keyfram
e
WRN0C0: First Block for video track #1 in Cluster at 1465592736 is not a keyfram
e
WRN0C0: First Block for video track #1 in Cluster at 1466883095 is not a keyfram
e
WRN0D0: There are 5149 bytes of void data......

mkvalidator 0.3.7: the file appears to be valid
file created with libebml v1.2.3 + libmatroska v1.3.0 / mkvmerge v5.1.0
('And so it goes') built on Nov 28 2011 23:58:28

seems to go like like from beginning to end

[Mosu]

That is a particularly useless bug report, sorry :)

[Carpo]

i have edited the above post, you impatient little thing :)

[Mosu]

Ah :) Well, like I said: those warnings are completely harmless and can be safely ignored. No, you cannot "tune" mkvmerge to write files that don't show those warnings. Remux with mkvclean if you're that paranoid. I could get technical at this point and explain why mkvmerge does what it does the way it does it, what those warnings exactly refer to, what would improve if those warnings weren't there etc, but the rundown is that optimizing files that way is simply not worth it.

[Carpo]

i have ran them through mvclean, some times it comes up with the same errors, so not overly concerned just curious :) all i care about is that it plays and seeks, which they all do ;)

[Mosu]

mkclean needs some kind of parameter for actual remuxing if I'm not mistaken -- though I never use it myself.

[Carpo]

--optimize , i think, which should add clean. to the beginning of the file name, will test it again and see, could have sworn it gave same issues as before i used it, it just changed the built by line at the bottom is all

[Paxmilitaris]

Warnings are warnings, and most of them are completely harmless.

Errors with files produced by mkvmerge are more serious. What kind of errors do you encounter?

Ok, i provided you with an exemple, but some times i get the same kinds of comments, but with error instead of warning. Even this one with just warnings doesn't work with mkclean.

[Mosu]

If it's just a text file then please send it by email to moritz@bunkus.org ; I don't like waiting for attachment approval...

[Snowknight26]

Error: Found B frame without second reference in a non closed GOP. Fix the MPEG2 video stream before attempting to multiplex it.

Got that error when trying to mux from a certain MPEG-2 TS. Strangely, eac3to was able to demux its AC3 stream without issuing any (discontinuity) warnings or what have you.

http://stfcc.org/misc/mkvmerge.mpeg2.ts

[Mosu]

Sorry, but I don't support MPEG-1/2 video anymore. The functionality will stay as it is unless someone else fixes bugs and provides patches.

[Mosu]

Hey,

I've released mkvtoolnix v5.2.0. It fixes a lot of smaller issues across the board among with restoring the MIME type detection behavior of MKVToolNix v5.0.1 regarding TrueType fonts. There were performance enhancements as well.

There were no changes that concern package maintainers.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-5.2.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.2.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.2.0.7z

All of the Linux binaries that I provide have already been built and are available.

Here's the full ChangeLog since release 5.1.0:


2011-12-18 Moritz Bunkus <moritz@bunkus.org>
* Released v5.2.0.
* mkvmerge, mmg: bug fix: Automatic MIME type recognition for TrueType fonts will result in "application/x-truetype-font" again instead of "application/x-font-ttf". Fix for bug 682 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=682).

2011-12-14 Andriy Bilous'ko <arestarh@ukr.net>
* documentation: enhancement: Added a Ukrainian translation for mkvextract's man page.

2011-12-13 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: Various elements used to have a space between their names and their value's hex dump. In v5.1.0 that space was accentally removed. It has been added again. Fix for bug 583 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=583).

2011-12-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Turn off input file buffering for badly interleaved MP4 files.

2011-12-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Changed how mkvmerge assigns IDs to tracks in source files for Matroska and MP4 files. That way files whose headers contain the same ID for multiple tracks will work correctly. Fix for bug 681 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=681).

2011-12-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: The VP8 output module will always re-derive frame types (key frame vs. non-key frame).
* mkvmerge: bug fix: VP8 read from AVI could not be put into WebM compatible files.
* mkvmerge: bug fix: Fixed a rare audio type mis-detection of MP2/MP3 audio tracks in MPEG program streams causing mkvmerge to abort with an error message.

2011-12-04 Nils Maier <maierman@web.de>
* mkvmerge, mkvextract: enhancement: Implemented input file buffering in mkvmerge and improved/implemented output file buffering in other tools.

2011-12-03 Moritz Bunkus <moritz@bunkus.org>
* mmg, mkvinfo's GUI: enhancement: Added new icons based on the work of Alexandr Grigorcea (see AUTHORS).
* mmg: bug fix: Fixed a memory leak in mmg's header editor that caused the "open file" function to stop working after opening a few files. Fix for bug 679 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=679).

Have fun.

[b66pak]

thanks a lot...
_

[cyberbeing]

* mkvmerge, mmg: bug fix: Automatic MIME type recognition for TrueType fonts will result in "application/x-truetype-font" again instead of "application/x-font-ttf". Fix for bug 682 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=682).

Unless you revert OTF fonts to being detected as application/x-truetype-font as in MKVToolNix 5.0.1 and prior versions, bug 682 is still an issue. Haali Media Splitter doesn't support application/x-font-ttf OR application/vnd.ms-opentype MIME types which were changed in 5.1.0, so there will still be embedded fonts problems with 5.2.0 until Haali gets around to fixing it.

[Midzuki]

...
so there will still be embedded fonts problems with 5.2.0 until Haali gets around to fixing it.

Maybe it's time to http://forum.videohelp.com/attachments/2671-1279232225/uglylol.gif BetaBoy (again) :)

[cyberbeing]

If Haali is still very busy at his job, there is not much anybody can do. It's been over 3 months, and he still hasn't updated his personal website with the latest 1.11.288 splitter build, so his time to make code changes to the splitter anytime soon is probably none. That's just life.

The only reason I'm bringing this up to Mosu now, is because I see MKVToolNix 5.2.0 containing only a partial-revert like this as worst that leaving it completely broken. Now instead of all embedded fonts being broken by default with Haali, only some will be, making this problem even harder to identify for users... This is one of these things where either MKVToolNix should leave it completely broken (to encourage support) or completely working (until support is added), not some half-working state like it is now which will trick users into thinking the problem is completely resolved, when it really isn't.

[Mosu]

I'm sorry, but I don't really care anymore about compatibility with Haali's splitter. Just like back in the day when Haali's was the hot new stuff and Gabest's was the old and slow-moving one there comes a time when you just have to move on. There are two actively developed splitters that I know of (Solveign's and LAV Filters).

I'm eternally grateful for the work Haali has done, and I'm completely aware of what a boon his splitter was to Matroska. Neither do I blame him for having lost the interest to spend more time on his product (I've been there before myself).

Now a more technical reason why I'm hesitant to map OpenType fonts to "application/whatevertheoldmimetypewas". OpenType fonts are not the same as TrueType fonts. Yes, they're built on them, yes, they share most of the structure, but they're not backwards compatible (a TrueType decoder not supporting OpenType is most likely not able to display an OpenType font) and should therefore not have the same MIME type.

[Mosu]

Oh and just to clear this up here. I actually didn't change any code in v5.1.0 regarding MIME types. I simply linked to a newer version of libmagic (and its MIME type definition file). Updating libraries was intentional, yes, but having TrueType's MIME type changed wasn't.

[cyberbeing]

I'm sorry, but I don't really care anymore about compatibility with Haali's splitter.

Then why when it appears Haali's splitter is the only splitter which doesn't support "application/x-font-ttf" did you change your mind and not leave it with that MIME type, which is the most common MIME type for truetype fonts? If you don't care about Haali compatibility I'm suggesting you leave it completely broken by default, since going forward it would make more sense to use "application/x-font-ttf" and "application/vnd.ms-opentype" instead of "application/x-truetype-font". I had no complaints about this change being made in MKVToolNix 5.1.0. I only have a problem with 5.2.0 since it could lead to non-obvious muxing mistakes by common users.

[LeMoi]

Recently muxed files with mmg (5.1.0) with an ASS sub using attached .ttf file is not correctly displayed, the font is used neither with MPC-HC (using Haali) nor with VLC

[Mosu]

LeMoi: This thread; http://www.bunkus.org/videotools/mkvtoolnix/faq.html#font_mime_types ; https://www.bunkus.org/bugzilla/show_bug.cgi?id=682

[sneaker_ger]

I tend to agree with cyberbeing, might as well break it completely while you're at it. Though the real problem is that there is no "official" MIME type.

[Mosu]

Precisely. If there were I would probably not have changed it back. However, TrueType is still not the same as OpenType.

I'd like to hear some more feedback (both here and privately) before I decide how to proceed.

[LeMoi]

I remuxed the file with mmg 5.2.0, same problem, font is not used neither with MPC nor with VLC :s

[Mosu]

Existing MIME types are kept as they are. This will not change. mkvmerge always tries to preserve as much information from a source file as possible.

The bug fix only applies to MIME type autodetection done when adding new attachments.

[cyberbeing]

Mosu, would it be possible to just enhance mkvmerge to be able to change the MIME type without needing to demux and re-add the attachments? If something like this could be done with the MKV Merge header editor and not even require a re-mux, it would be even better, but I assume because of how attachments are stored that may not be possible?

Another idea would be to just group all the common font MIME types together, so you don't need to scroll through a massive list to find the one you want.

If the default MIME type was a user preference which could be changed/saved and remembered through multiple sessions, that would also be good.

[Mosu]

Technically it's rather easy. I have all the infrastructure in place for such operations already as it is used in the chapter editor, mmg's header editor and mkvpropedit. However, doing the GUI part is an entirely different affair. GUI programming is the work I dislike the most about programming MKVToolNix, and therefore I'm only saying "maybe".

[cyberbeing]

Well if you are able to implement something like that, I'd see it as a good compromise solution for resolving any MIME compatibility woes which occur by mistake.

The easiest thing you could do is just add a checkbox to mmg and a switch to mkvmerge which would force a particular MIME for all attachments (including currently attached) during re-mux, but that probably isn't the best long-term solution.