mkvtoolnix 4.1.1 released

[Mosu]

Not with one of the programs from mkvtoolnix -- at least not without external scripting around mkvinfo's output.

[fingershop]

Thanks. I saved the output of mkvinfo to a file, imported it into Excel, and got the total sizes of each track. Oddly, it may be just as quick to use mkvextract to see those track sizes directly.

[sneaker_ger]

You could also use AVIMUX Gui for that, it will the show the size of each video and audio track in MBytes (one decimal).

[Mosu]

Thanks. I saved the output of mkvinfo to a file, imported it into Excel, and got the total sizes of each track. Oddly, it may be just as quick to use mkvextract to see those track sizes directly.

Both mkvinfo and mkvextract have to parse the whole file (as does AVIMuxGUI btw) in order to get the track sizes as there's no header field for this information in Matroska files.

[[)370|\|470!2]

Just wondering if there's a way to make this crappy app to respect splitting filesize. 4499 MB instead of 4475 huh? If it's not too much to ask.

[Inspector.Gadget]

I'm convinced "[)370|\|470!2" doesn't actually know what the word "crap" means, or else he wouldn't use it to describe the most popular and feature-rich Matroska muxing application in the world.

[nurbs]

He also doesn't seem to know that you can't split (most) video files in arbitrary places.

[Mosu]

He also doesn't know that asking nicely and politely is usually the best way to get good answers.

[[)370|\|470!2]

C'mon, the question was corny, thought it'd be obvious. This bug/feature/whatever that is that sits in there - for how long... forever? Which means that author has no intention to look into it really. Oh, and yet another good reason for me to stay away from this app and quit giving it a try, which would've prevent me from wasting two hours for nothing today, thanks for asking.

Sorry if it was too sincere/not polite enough.

[MatLz]

Instead of continue to troll, you should ask 'why?'. Maybe the discussion would be more constructive...

[Inspector.Gadget]

Oh, and yet another good reason for me to stay away from this app and quit giving it a try, which would've prevent me from wasting two hours for nothing today, thanks for asking.

I think I speak for everyone when I say that software developers' time is so much more valuable than the time of some forum troll that we haven't yet invented the numerical order of magnitude with which to express it. Hope this helps.

[fingershop]

You could also use AVIMUX Gui for that, it will the show the size of each video and audio track in MBytes (one decimal).

Thanks, I just tried that, and it does give you the track sizes in just a few seconds.

However, some of the track sizes are way off, by a factor of 17 in some cases, depending on the file you're checking. At that accuracy level I may as well just make my own guess :-)

[falexak]

Thank you very much for the news, I have been using MkvToolnix for a long time.

[Chumbo]

Just wondering if there's a way to make this crappy app to respect splitting filesize. 4499 MB instead of 4475 huh? If it's not too much to ask.
No one's forcing you to use this tool. You can always write your own to do exactly what you want. Maybe walking an inch in developers shoes would shed some light in that dark space between...[I better stop before I get banned ;)].

Every software has bugs and limitations and developers appreciate help when its done constructively. What exactly have you contributed to make this a better tool and discussion? Please we're all ears...but I guess so are trolls.

[[)370|\|470!2]

That's amazingly funny how fast someone starts hollering "troll" just as they smell a tiny bit of criticism airborne. Oh, and also there's a very nice remark once made by B. Shaw: “Although I cannot lay an egg, I am a very good judge of omelettes”. :rolleyes:

And to conclude, since no one have added nor brought anything constructive conserning subject to shed a light on it, i'd assume there's nothing else remains to discuss.

[nurbs]

I told you the likely cause of why it doesn't split exactly where you want. It probably gave you 4475 MB because the next possible split point would have resulted in a size bigger than 4499 MB. Without telling anything about the file there is no way to know for sure of course.
Also you should try being polite to people sometimes. Maybe then people would be more inclined to spend their spare time helping you with your problems even though they have no obligation to to so.

[liquidskin76]

mkvmerge discards AC3 cores in TrueHD tracks, yes. No, that won't change anytime soon (if at all).

Hi Mosu,

You're sort of right in saying that with ffdshow you can either bitstream truehd or decode it to lpcm, so why would you need the ac3 core.

One thing though... how does that relate if you're using spdif for instance? I didn't think spdif could handle the bandwidth of truehd decoded to lpcm, hence the need for hdmi?

I'd love the ability to include the ac3 core as an automatic fallback (without having to select another audio track).

Thanks!

[Mosu]

No, sorry.

[rica]

mkvmerge discards AC3 cores in TrueHD tracks, yes. No, that won't change anytime soon (if at all).


The command line which i gave before creates a thd+ac3 file.
And i can watch the mkv (created by mkvmerge gui 3.2.0) with ac3 or with thd.
Disabling thd passthrough and enabling ac3 SPDIF encode mode in ffdshow must fix your issue. (you'll get ac3 in this case)
Enabling thd passthrough will bring thd bitstreaming back.


Dunno mossu how i get ac3 or THD separately???


_ _ _ _ _ _

[Mosu]

Dunno mossu how i get ac3 or THD separately???

Not with mkvmerge. mkvmerge will always discard the AC3 core of a THD+AC3 file/track.

However, often a disc containing a THD+AC3 as a single track also contains another AC3 track, and you can use that as input as well.

[turbojet]

I see demuxing pgs is supported now, thanks, any news on muxing pgs?

[Mosu]

I see demuxing pgs is supported now, thanks, any news on muxing pgs?

Partially. You can re-mux PGS tracks from one Matroska file to another (mkvmerge will use its general purpose "pass-through" packetizer), but you cannot mux it from PGS elementary streams. It's also not on the agenda just yet.

[Mosu]

This is a mkvtoolnix support thread, not a MakeMKV or "playback on hardware players" support thread. Please create a new one for such a question.

One thing to look into: indexes (called "cues" in Matroska terms). mkvmerge always writes them, maybe makemkv doesn't or doesn't reference them from metaseek elements.

[sheck]

Mosu, in this release I noticed you added --parse-fully switch to mkvextract.exe. What does it add to the functionality ? I tried using it, but results seem to be the same as when not using it.

[Mosu]

Quoting the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvpropedit.html) (both mkvextract and mkvpropedit know this parameter under different names but it seems I've only added it to mkvextract's man page):

-p, --parse-mode mode
Sets the parse mode. The parameter 'mode' can either be 'fast' (which is also the default) or 'full'. The 'fast' mode does not parse the whole file but uses the meta seek elements for locating the required elements of a source file. In 99% of all cases this is enough. But for files that do not contain meta seek elements or which are damaged the user might have to se the 'full' parse mode. A full scan of a file can take a couple of minutes while a fast scan only takes seconds.

Getting a bit more technical:

The 'full' parse mode starts at the beginning of the file and finds all level 1 Matroska elements. These are e.g. 'meta seek', 'cues', 'chapters', 'track headers' and most important 'clusters'. For each level 1 element it reads the ID and the size but not necessarily its content -- only if it has to (for the track headers, the rest depends on the extraction mode/editing mode). However, reading all cluster IDs and sizes takes quite a lot of time as there are a lot of clusters over the whole file.

BTW: The programs will fall back to 'full' if no index is found and 'fast' mode is selected.

[Foofaraw]

At the risk of upsetting someone, mkvtoolnix does not function in isolation - it produces data from or for other products and as such one has to mention other things than mkvtoolnix... (if English is not your first langauge, let me underline this is not an attack or critique of mkvtoolnix)

So my question is in relation to mkvtoolnix.... (so please read it twice)

ProgramA outputs an mkv - we'll call it mkvA

If I now play mkvA in deviceB it has certain defects.

I now take mkvA and 'add' it to Mkvmerge Gui - uncheck a few items in MkvMerge Gui and output mkvB

If I now play mkvB it takes a while to play, but then it plays fine.

BUT

If I take Mkvcleave and extract all items from mkvA

And I then only add the items required to Mkvmerge GUI and output mkvC

Then mkvC starts playing fine right away.


So the question about Mkvmerge gui/mkvtoolnix is:

why is there a difference between mkvB and mkvC - they both contain the same(3) items - we just arrived at the content differently.

Does mkvmerge gui reuse the parts of the container (but not the contents) when you start out by using an existing mkv??? I would have thought it authored from scratch so there shouldn't be a difference? (But there is)

[73ChargerFan]

Ah... output files mkvB & mkvC are different just enough, so that they behave differently when played.

I've encountered something similar. I can have three non-identical copies of a video track (demuxed from .TS, or demuxed from .M2TS using eac3to, or extracted from .M2TS into .MKV using eac3to) and mkvmerge will accept all three tracks. But the output .MKV files don't play back identically in mpc-hc.

In my mind, Audio+Video->MKV should work no matter where I get the source files, but that isn't always the case. I don't have any samples handy now, however.

[Foofaraw]

In my mind, Audio+Video->MKV should work no matter where I get the source files, but that isn't always the case. I don't have any samples handy now, however.

Yeah, in my mind i agree with you. But perhaps there is something we don't know :-/

[Mosu]

Summarizing Foofaraw's question:

A.mkv -> (mkvmerge) -> B.mkv is different from A.mkv -> (mkvcleaver) -> elemental_streams.h264/.ac3/.mp3 -> (mkvmerge) -> B.mkv

mkvmerge has different paths for the same content depending on where they come from. You guessed as much from the evidence. There are several reasons for this, amongst them are:

1. It tries to re-use as much information as possible as can be retrieved from the source container. If you have a h.264 track inside a Matroska file then you have a lot more meta-information about it that you do when it is stored outside of a container as an elementary stream. Information that is reused includes but is not limited to the timestamps, track parameters like display width/height, track name, language etc etc.

2. What is not so obvious is that mkvmerge also reuses the framing. If you have a raw track type like MP3, AC3, AAC or h.264 elementary streams then mkvmerge has to determine how many bytes of the track to put into each Matroska block (also called 'frame' sometimes even though a Matroska block does not necessarily contain exactly one 'frame' in the way people think of frames). This process is usually called framing and has to be done by any raw -> container converter. If a track is stored inside a Matroska file then mkvmerge sometimes skips this process and takes the input file's framing -- one Matroska block in, one Matroska block out.

3. Another important thing to remember is that raw tracks outside of a Matroska file are not simply the concatenation of all the contents of all Matroska blocks. This is the case for some very simple track types (e.g. MP3, AC3, AAC, DTS) but for most others it isn't, especially for video track types like h.264. Elementary streams often contain special framing markers (think of '00 00 01' prefixes for MPEG-1/2 or '00 00 00 01' for h.264). Also some parts of the stream are not put into Matroska blocks but into the CodecPrivate element (e.g. SPS/PPS NALUs in h.264 tracks). The CodecPrivate almost always has some special kind of storage format that is always different than how that information is stored in an elementary stream. mkvextract and mkvmerge convert this data from one form into the other and back again. In the case of direct mkv -> mkv conversion the CodecPrivate element is kept as-is.

4. There are muxers out there that create invalid Matroska files. For example there are files with the CodecID V_MPEG4/ISO/AVC (h.264 video) that contain the elementary stream 1:1 including the '00 00 00 01' prefixes in each Matroska block. They also don't have a CodecPrivate element but store the SPS/PPS NALUs inside the first Matroska block. This not only violates the specs it is also incompatible with most playback software out there. So mkvmerge has yet another processing path for such tracks.

There are more cases, but I guess you get the drift. It is not possible to switch this behavior in mkvmerge -- it is hard coded for each and every combination of track type and source file format (and even for the same tuple "container & track format" there may be different paths as 4. illustrates).

[Foofaraw]

Thank you for the explanation Mosu.

I'm still fairly new to the mkv format (coming rather late to the party!)

Would you say its a good format for streaming video? (Via media players, not the internet)

Reason I'm wondering is because someone said we can't see how long tracks are but you have to scan the entire file to figure it out (i would have thought there was a header somewhere).

[Foofaraw]

Two questions about frames.

Is there an easy way to convert celltimes.txt (a list of frames) to a format mmg understands?

and; you explain about OGM style chapter files

"Due to its limitations mmg cannot output chapters in this format."

What does that mean? mmg won't put them in a mkv file but converts it to xml first?

[Mosu]

Two questions about frames.

Is there an easy way to convert celltimes.txt (a list of frames) to a format mmg understands?

Not with mkvtoolnix per se, but if it's a plain text format then it should be easy to write scripts in whatever scripting language you like (Perl, Python, Ruby, awk...) to convert such files.

and; you explain about OGM style chapter files

"Due to its limitations mmg cannot output chapters in this format."

What does that mean? mmg won't put them in a mkv file but converts it to xml first?

There are two text chapter formats, OGM style and XML files. OGM style files can only store the start timestamp and the name of each chapter, and chapters cannot be nested. The XML file format can contain many more attributes (end timestamp, editions etc) and chapters can be nested.

Therefore mmg will not save to OGM style chapter files -- too much information is lost. It can either save a XML text file for further processing or it can save directly into an existing Matroska file. In both cases no information is lost.

[Mosu]

Would you say its a good format for streaming video? (Via media players, not the internet)

Depends on your definition of "streaming" and the type of media player in question. I'm using an Asus O!Play myself and play my files back from a network share. Some people call that streaming. Works flawlessly.

Reason I'm wondering is because someone said we can't see how long tracks are but you have to scan the entire file to figure it out (i would have thought there was a header somewhere).

True, but no player should have to know the length of any track in order to play back a file. MP4 is no better in this regard than Matroska: Either it's "true" streaming (meaning the player cannot seek in the file it reads -- in that case neither format usually has information about total length available) or it's a seekable file (in which cases a player can get the total length from both file types, the methods are just different).

[Foofaraw]

Not with mkvtoolnix per se, but if it's a plain text format then it should be easy to write scripts in whatever scripting language you like (Perl, Python, Ruby, awk...) to convert such files.


Its a text files with a frame number pr line like:
7620
15175
22495
29996
37502
45019
52520

Made by PgcDemux

[liquidator87]

If I may ask... when will you make a repository for Lucid available?

[Mosu]

Certainly not before it's released. I'm busy enough without chasing after betas. "In April" is probably accurate :)

[Mosu]

Additionally you can easily compile the packages yourself; see http://www.bunkus.org/videotools/mkvtoolnix/source.html#debian_ubuntu_package

[liquidator87]

Wow... It took me... like... 10 seconds to build the package... eheh thanks

[Mosu]

Hey,

I've released mkvtoolnix v3.3.0. This release contains contains several important bug fixes and a few new features. Behind the scenes huge parts of the code have seen adjustments, especially the order and amount of included header files. I've gone to great lengths to ensure everything compiles as usual on several platforms and versions but be prepared for compiler errors if you compile the package yourself.

There are no changes that package maintainers have to look out for.

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-3.3.0.tar.bz2

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

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 3.2.0:

------------------------------------------------------------
2010-03-24 Moritz Bunkus <moritz@bunkus.org>
* Released v3.3.0.
* Build system: Sped up builds by using pre-compiled headers. Patches by Steve Lhomme (see AUTHORS) and myself.

2010-03-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the default duration for interlaced MPEG-1/2 video tracks. Also added the 'interlaced' flag for such tracks. Patches by Xavier Duret (see AUTHORS). Fix for bug 479.

2010-03-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Specifying a FourCC with spaces at the end will not result in an error anymore. Fix for bug 480.

2010-03-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Timecodes for MPEG-1/2 tracks are calculated properly, especially for B frames. Patch by Xavier Duret (see AUTHORS). Fix for bug 475.

2010-03-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Added a message in verbosity level 2 to the splitting code. It reports before which timecode and after what file size a new file is started.
* All: A lot of changes preparing mkvtoolnix for use with the upcoming libebml2/libmatroska2 versions were applied. Patches by Steve Lhomme (see AUTHORS).

2010-03-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a crash when reading Matroska files that contain Vorbis audio with in MS compatibility mode (CodecID A_MS/ACM). Fix for bug 477.
* All: enhancement: Added support for old Mac-style line endings (only '\r' without '\n') in text files.

2010-03-11 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Added the values "4483M" and "8142M" to the "split after this size" drop down box.

2010-03-06 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed compilation if gettext is not available.

2010-03-03 Moritz Bunkus <moritz@bunkus.org>
* Build system: Added project files and fixes for compilation with Microsoft Visual Studio 8. Patches by David Player (see AUTHORS).
* Installer: bug fix: A couple of start menu links to pieces of the documentation were broken. Added missing start menu links to translations of the documentation.
* mkvmerge: bug fix: The SRT reader skips empty lines at the beginning of the file.

2010-03-02 Moritz Bunkus <moritz@bunkus.org>
* Build system: bug fix: Fixed the configure script and compilation on OpenSolaris.

2010-02-26 Moritz Bunkus <moritz@bunkus.org>
* Installer: bug fix: The "jobs" directory in the application data folder is removed during uninstallation if the user requests it. Fix for bug 474.
* mkvextract: bug fix: Fixed granulepos calculation when extracting Vorbis tracks into Ogg files. Fix for bug 473.

2010-02-24 Moritz Bunkus <moritz@bunkus.org>
* All: bug fix: The programs will no longer abort with an error message if a selected interface translation is not available. The "C" locale is used instead. Fix for bug 472.

2010-02-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract: enhancement: Improved the error resilience when dealing with damaged Matroska files. When a damaged part is encountered reading will continue at the next cluster.

2010-02-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the handling of UTF-16 encoded chapter names in MP4/MOV files.

2010-02-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Some Matroska files contain h.264/AVC tracks lacking their CodecPrivate element (e.g. files created by gstreamer's muxer). For such tracks the CodecPrivate element (the AVCC) is re-created from the bitstream. Fix for bug 470.
* mkvmerge: bug fix: MP4 files that do contain edit lists but whose edit lists do not span the entire file are processed properly. Such files are created by current x264 builds. Fix for bug 469.

2010-02-13 Moritz Bunkus <moritz@bunkus.org>
* Build system: Fixed configure for systems on which 'echo' does not support the '-n' parameter (e.g. Mac OS).
------------------------------------------------------------

Have fun.

[b66pak]

thanks...
_

[Liisachan]

@Mosu
A minor thing: sha1sums.txt in http://www.bunkus.org/videotools/mkvtoolnix/win32/ is too old
and not helpful. Ty :)

[lych_necross]

I love mkvtoolnix! Thanks Mosu et al. for the update! :D

[kurt]

after installation v3.3.0 windows 7 (prof) complains that the program was probably not properly installed. anybody had the same issue?

[73ChargerFan]

Confirmed. Windows 7x64 doesn't like the new installer; I got a UAC shield on the install app immediately after download. Gui app is fine.

[asc28]

Remuxing telecined material (Tried NTSC telecined MPEG2 from DVD) doesn't seem to work anymore with 3.3.0... video speed is not in sync. Tried specifying fps (24/1.001 and 30/1.001) but doesn't work.

Perhaps, it's mistaking it for pure interlaced? Any ideas?

FYI Remuxing an older mkv file with the newer version is fine, as it doesn't re-create the timecodes.

[Mosu]

@Mosu
A minor thing: sha1sums.txt in http://www.bunkus.org/videotools/mkvtoolnix/win32/ is too old
and not helpful. Ty :)

Dang. Thanks for noticing. I've updated the file.

[Mosu]

after installation v3.3.0 windows 7 (prof) complains that the program was probably not properly installed. anybody had the same issue?

Can't reproduce. I'm using Win7 Professional 64bit myself. My user doesn't have admin privileges.

So what I'm seeing is:

1. Download finishes.
2. I start the setup.exe, UAC kicks in and asks me for the administrator's password.
3. Setup starts. I answer all questions with the default answer.
4. The installer finishes, closes normally, everything's done.

So please give me more details about your system, the user you're running the setup under, any options you chose differently than I did etc etc etc.

[Mosu]

Remuxing telecined material (Tried NTSC telecined MPEG2 from DVD) doesn't seem to work anymore with 3.3.0... video speed is not in sync. Tried specifying fps (24/1.001 and 30/1.001) but doesn't work.

I've forwarded the problem to the person who contributed the new MPEG timecode calculation method. I hope he can shed some light on this problem.

[Mosu]

Confirmed. Windows 7x64 doesn't like the new installer; I got a UAC shield on the install app immediately after download. Gui app is fine.

??? I don't understand your problem. The installer requires admin privileges, so I don't see why the UAC coming up should be considered "does not work".

[Mosu]

Remuxing telecined material (Tried NTSC telecined MPEG2 from DVD) doesn't seem to work anymore with 3.3.0... video speed is not in sync. Tried specifying fps (24/1.001 and 30/1.001) but doesn't work.

Can you please upload a source file for me for testing purposes? It doesn't have to be the whole file, but it should be long enough that the speed problem becomes obvious. You can upload to my FTP server (see my signature).

Also I need some more information:

1. Which program did you use for extracting the MPEG2 from the DVD? Do you mux the .VOB file directly with mkvmerge or has the video been extracted to separate MPEG2 elementary or program streams?

2. Which program do you use for playback? We know that older versions of ffmpeg (and therefore ffdshow) contain a bug that causes it to play video too slow or too fast.

3. "Video speed is not in sync" -- do you mean that the video plays slower/faster than the accompanying audio track?