MKVToolNix v24.0.0 released

[nautilus7]

I've uploaded a sample (m2ts file) where mkvmerge can't detect the video stream inside.

[Mosu]

Hey,

I've released mkvtoolnix v5.0.0. It's a release with a lot of small bug fixes, but it also features support for MPEG transport streams.

Change for package maintainers: Building against external versions of libEBML and libMatroska is possible again. libEBML 1.2.2 (http://dl.matroska.org/downloads/libebml/) and libMatroska 1.3.0 (http://dl.matroska.org/downloads/libmatroska/) are required. If they're not found or too old then the internal versions will be used and linked statically.

Here are the usual links: the home page (http://www.bunkus.org/videotools/mkvtoolnix/), the source code (http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-5.0.0.tar.bz2) and the Windows installer (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.0.0-setup.exe) and 7zip archive (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.0.0.7z).

All of the binaries (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html) that I provide myself are already available.

Here's the full ChangeLog (http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since release 4.9.1:

2011-09-24 Moritz Bunkus <moritz@bunkus.org>
* Released v5.0.0.
* build system: libEBML 1.2.2 and libMatroska 1.3.0 are required for building. If external versions are not found or if they're too old then the included versions will be used as a fallback.

2011-09-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The "writing application" element will not be localized but always be written in English.

2011-09-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: MPEG TS: mkvmerge will extract the track languages from a corresponding clpi (clip info) file. That file is searched for in the same directory and in ../CLIPINF and must have the same base name but with the ".clpi" extension.
* mkvmerge: enhancement: Added new stereo mode options to match the current specs. The new options are "anaglyph_green_magenta" (12), "both_eyes_laced_left_first" (13) and "both_eyes_laced_right_first" (14).
* mkvmerge: The --stereo-mode named option "anaglyph" was renamed to "anaglyph_cyan_red" to match the specs. The numerical value (10) remains unchanged.

2011-09-18 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Fixed attachment number displayed during extraction. Fix for bug 663 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=663).
* mkvmerge: enhancement: MPEG TS: Added support for HDMV PGS subtitles.
* mkvmerge: enhancement: MPEG TS: Added support for DTS HD Master Audio tracks.

2011-09-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: MPEG TS: Streams that are mentioned in the PMT but do not actually contain data are neither reported during identification nor muxed.

2011-09-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: MPEG TS: Added support for reading the language code.

2011-09-13 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Added MPEG transport streams to the "add file" dialog file selector.
* mkvmerge: new feature: MPEG TS: Added support for normal DTS tracks.
* mkvmerge: Tons of fixes and additions to the MPEG transport stream demuxer.

2011-09-10 Moritz Bunkus <moritz@bunkus.org>
* build system: configure will accept external versions of libEBML and libMatroska again. Minimum required versions are libEBML 1.2.1 and libMatroska 1.1.0.

2011-09-07 DenB <denb10@free.fr>
* All: Updated the French translation with a complete set by DenB (see AUTHORS).

2011-09-05 Cosme Domínguez <cosme.ddiaz@gmail.com>
* mmg: mmg respects the XDG Base Directory Specification regarding its configuration files (environment variable $XDG_CONFIG_HOME/mkvtoolnix if set, otherwise ~/.config/mkvtoolnix).

2011-08-24 Moritz Bunkus <moritz@bunkus.org>
* all: Added an Lithuanian translation by Mindaugas Baranauskas (see AUTHORS).

2011-08-14 Massimo Callegari <massimocallegari@yahoo.it>
* mkvmerge: new feature: Implemented a MPEG transport stream demuxer.

2011-08-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: When looking for MPEG files with the same base name as a source file mkvmerge will be stricter what it accepts. The file name must consist of at least one char followed by "-" or "_" followed by a number. That will match VTS_01_1.VOB but not e.g. "some_series_s03e10.mpg".

2011-07-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Opening MPEG files with numbers in their name from folders with e.g. Cyrillic names failed on Windows.
* mkvmerge: bug fix: Several elements are not written when creating WebM compliant files. In the segment headers: SegmentUID, SegmentFamily, ChapterTranslate, PreviousSegmentUID, NextSegmentUID. In the track headers: MinCache, MaxCache and MaxBlockAdditionID.

2011-07-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Sped up file identification by caching read operations.
* mkvmerge: bug fix: Fixed identifying QuickTime/MP4 files that start with a 'skip' atom.

2011-07-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a crash when reading AVI files with DTS audio tracks that do not contain valid headers in the first couple of packets. Fix for bug 646 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=646).

Have fun.

[Inspector.Gadget]

I've released mkvtoolnix v5.0.0.

:thanks::thanks::thanks:

[b66pak]

thanks a lot...
_

[Lincoln Burrows]

People,
I have a Matroska file, extracted from my DVD. It has a spanish subtitle (the only available), and it's some american production. However, I understand english (not my native language), but I don't want this subtitle to be loaded when I open the file with MPC-HC. I mean, I want the subtitle track to be there, but I want it to be disabled by default, so we have to select in MPC to be displayed.

Can you tell me which option should I choose?

Default track flag:

1) Default
2) Yes
3) NoAnd what about "Forced track flag - yes or no?" what is this thing?

[Mosu]

Set "default track" to "no" for all subtitle tracks. Leave "forced track" at "default" (resulting in no track having "forced" set by default).

"Default" tells the player that a track should be displayed.

"Forced" means that it must be displayed (e.g. for an English film this could be used for English subtitles tracks that only show a translation if one of the character is speaking a non-English sentence, e.g. Legolas speaking Elfish in "The Lord of the Rings").

[Lincoln Burrows]

Set "default track" to "no" for all subtitle tracks. Leave "forced track" at "default" (resulting in no track having "forced" set by default).And what if this is the only subtitle track? Should I set "Forced track flag" to no as well?

In this case, I want the player to not display the subtitle track, unless I tell otherwise, so it should be disabled by default.

[Mosu]

Like I said, leave the "forced" flag at anything but "yes".

[Chetwood]

I'm sorry but I also still don't get the difference. You say that "Default" tells the player that a track should be displayed. Now if I set the forced flag to default, would it display the sub or not. And if only yes will set the forced flag, what's the use of having the setting default? Maybe I'm confused by the way it works on DVDs where one can set a track to default but off which won't display any sub initially. but will start cycling at this particular track, once they get enabled via remote.

Also, if I mux an mkv with 2 audio and subtitle streams (de/en) and don't want any sub to be displayed upon playback, what flags do I set? Default track to default? Would it make a difference to set it to no?

And what if I do have Elvish? Do I need to set both default track and forced to "yes". Or does the forced flag override the default flag? :confused:

[Mosu]

Leaving a flag (no matter which flag) on the "default" settings means the decision whether or not it should be set is up to mkvmerge. mkvmerge usually takes the information provided by the source container into account. For some flag types (especially the "default track" flag) there are other considerations as well.

Setting a flag to "no" will force mkvmerge not to set that flag, no matter what those other considerations would have done and no matter what the source container provided for that flag.

For the "default track" flag: The special consideration is that mkvmerge will automatically set this flag to "yes" for exactly one track of each track type (audio, video, subtitles). You can only prevent this by explicitly setting the "default track" flag to "no" manually for all tracks of a kind (e.g. for all subtitle tracks).

The "default track" flag tells the player that this track should be played unless the user overrides that decision somehow. You usually mark the original audio track with "default track" and leave it off for the rest of them, e.g. for the director's commentary or some translations you don't want (e.g. Lord of the Rings, mark "English" as "default track" but not "German" and "Director's comments (English)").

As a lot of users don't want subtitles shown by default they tell mkvmerge not to set the "default track" flag for any subtitle track.

Now on to the "forced display" flag, in short "forced". If this is set to "on" then this track must be played/shown no matter what the user selected for his preferences or what the player would normally chose to show/play. This is used seldom, e.g. only for a subtitle track that only contains the English translation whenever Legolas is talking Elbish.

"Forced" has nothing to do with "default track". If "forced" is set the player must play that track no matter what "default track" is set to. In fact normally a track that has "forced" set does not have "default track" set, though it is neither invalid nor undefined behavior.

[Chetwood]

Leaving a flag (no matter which flag) on the "default" settings means the decision whether or not it should be set is up to mkvmerge. mkvmerge usually takes the information provided by the source container into account.
Ok, but since I'm using demuxed streams as source there is no container and thus no information provided. How will mmg decide then?

For the "default track" flag: The special consideration is that mkvmerge will automatically set this flag to "yes" for exactly one track of each track type (audio, video, subtitles).
Always for the first audio and the first subtitle stream or how does mmg decide?

You can only prevent this by explicitly setting the "default track" flag to "no" manually for all tracks of a kind (e.g. for all subtitle tracks).
Right, so if I have subs but don't want them to be displayed automatically, I'd set the "default track" flag not to "default" but to "no".

The "default track" flag tells the player that this track should be played unless the user overrides that decision somehow.
Which can also be overwritten by the player's setting.

You usually mark the original audio track with "default track" and leave it off for the rest of them, e.g. for the director's commentary or some translations you don't want (e.g. Lord of the Rings, mark "English" as "default track" but not "German" and "Director's comments (English)").
So the "default track" flag is set to "yes" for the original audio track and set to "no" for the director's commentary? Sorry, this double "default" is strangely confusing to me :o

"Forced" has nothing to do with "default track". If "forced" is set the player must play that track no matter what "default track" is set to. In fact normally a track that has "forced" set does not have "default track" set, though it is neither invalid nor undefined behavior.
I always thought setting the "default track" flag to yes would only be reinforced by the "forced" flag. But if one track is default and another is forced, the latter will be displayed.

[Mosu]

Ok, but since I'm using demuxed streams as source there is no container and thus no information provided. How will mmg decide then?

First, it's not mmg that decides but mkvmerge.

Second, if the source container does not provide that information then it is ignored.

Always for the first audio and the first subtitle stream or how does mmg decide?

Video as well. The algorithm is a bit more complex. For each track the decision is made somewhat like this:

1. Is "no" set on the command line? Set flag to "no".
2. Is "yes" set on the command line? If so and if no previous track of this kind has been set to "yes" from the command line then set flag to "yes". Otherwise continue in the evaluation process.
3. Does source container provide "no"? Set flag to "no".
4. Does source container provide "yes"? If so and if no previous track of this kind has been set to "yes" either from the command line or from its source container then set flag to "yes". Otherwise continue in the evaluation process.
5. Has the flag NOT been set to "yes" for any other track of this kind encountered so far? Set flag to "yes".
6. Set flag to "no".

Right, so if I have subs but don't want them to be displayed automatically, I'd set the "default track" flag not to "default" but to "no".
...
Which can also be overwritten by the player's setting.
...
So the "default track" flag is set to "yes" for the original audio track and set to "no" for the director's commentary? Sorry, this double "default" is strangely confusing to me :o

Correct.

I always thought setting the "default track" flag to yes would only be reinforced by the "forced" flag. But if one track is default and another is forced, the latter will be displayed.

Not really. You're assuming that only one track can be displayed for each track type. This is not the case in general. Therefore the Matroska specs don't say "if one track has 'forced' set then only display this track". They only say that this track must be displayed; they don't prohibit another track of its kind of being displayed at the same time.

[Chetwood]

Thanks for clearing that up. Another question: how can I determine whether an MKV was muxed with header compression set to on? I've muxed two test files, one with this setting on, the other off. Both have the same size. I'm trying to determin, why some muxed files playback on DVBViewer and others have no sound.

[Mosu]

This question has been asked and answered in this thread numerous times already, e.g. in http://forum.doom9.org/showthread.php?p=1514173&highlight=compression#post1514173

[Chetwood]

Right. So if Muxing mode : Header stripping means, header compression is on, I'm out of luck because this setting is not set in my new muxings and yet I don't get sound on playback with DVBViewer.

BTW, the mouseover translation of the "Wegen potenziell..." checkbox in mmg 5.0 is missing a "t" in "warnt".

[TechnoPhil]

Hi Guys,
i would like to ask if it is possible to find a .dmg version for MacOs of the new MKVToolnix version (ver.5).
I need the newer version on my Mac because it supports MPEG transport streams (.ts or .m2ts files)!

Actually this is the last version form Mac: http://jonthn.free.fr/MKVtoolnix/Mkvtoolnix-4.9.1_2011-07-22-67c1-intel-ppc.dmg

Anyone can help me? Maybe the author "j0nthn" ?

Best regards.

Filippo

[Mosu]

Speaking only for myself: I don't support Mac OS. I just link to others providing images/build scripts/whatever. Which translates into "I don't know".

The Macports project (http://www.macports.org/ports.php?by=name&substr=mkvtoolnix) seems to have updated already.

[TechnoPhil]

Thank you for your answer!
I am waiting for "j0nthn" answer, maybe he's going to publish an update for the Mac version.

I know that MacPorts is up to date, but would prefer the .dmg version!

[TechnoPhil]

Speaking only for myself: I don't support Mac OS. I just link to others providing images/build scripts/whatever. Which translates into "I don't know".

The Macports project (http://www.macports.org/ports.php?by=name&substr=mkvtoolnix) seems to have updated already.

Hi!
Can you suggest me how to contact "j0nthn"?
I tried by email and here in this forum, but i did not received an answer yet :(

[Mosu]

No, sorry.

[Lincoln Burrows]

Mosu,
is there a way to create a Matroska file with multi video streams/angles? I am sorry, but I can't find anywhere a way to do that using MKVMerge, but I am quite sure I knew.

And if there is, can we do in one sequence and then join this with the rest?

This is a case of multi-angle - the initial credits from Star Wars. A unique M2TS file with 2 minutes (the first 2 minutes) from the movie. There are other 5 or 6 files with the same content, but translated in other languages as you can see:

http://i.imgur.com/SjiTL.jpg

http://i.imgur.com/7dib6.jpg

Star Trek: TOS also have multi angle scenes in all episodes, if I recall.

One question I was going to ask is this one: will MKVMerge be able to join, for example:

- The file with multi-angle feature + the other one without multi-angle with no issues? Or they both need to be multi-angle?

[Mosu]

I have no idea; never played around with such things; never bothered reading up on multi-angle stuff.

[Lincoln Burrows]

I have no idea; never played around with such things; never bothered reading up on multi-angle stuff.Well, I tried doing the exact following here:

tsMuxerGUI to demux a m2ts file from some extra feature with no audio tracks. tsMuxerGUI to demux a m2ts from some extra feature with a single audio track.

MKVToonix > Add the first file (MPEG-4 AVC), and Add the 2nd file (also MPEG-4 AVC).

That was the result (and you can see for yourself) using Media Player Classic Home-Cinema. Please note there's a second video angle here, you can select by going to "Video Stream" in MPC options.

http://www.embedupload.com/?d=7YZEDKGSQ1

Assuming both angles have the same audio track, it won't matter if the 2nd is playing this audio track while the first is mute.

However, if I use the "Append" option to make the whole thing like that:

1st video angle ===========||||||||||||||||||||||
2nd video angle ===========|||||||||||||||||||||

||||||||||||||||| = REST OF THE MOVIE (and a single file demuxed from another m2ts)

Will be rejected, even if it's MPEG-4 AVC as well, with the following reason:

00720.track_4113.264' cannot be appended to the track number 1 from the file 'C:\Users\Q9450\Desktop\00720.track_4113.mkv'. The formats do not match.

[somms]

However, if I use the "Append" option to make the whole thing like that:

1st video angle ===========||||||||||||||||||||||
2nd video angle ===========|||||||||||||||||||||

||||||||||||||||| = REST OF THE MOVIE (and a single file demuxed from another m2ts)

Will be rejected, even if it's MPEG-4 AVC as well, with the following reason:

From my limited experience using the append function, the resolutions i.e. 1920x1080, for both files have to match exactly...one cannot be 1912x1080 while the other is 1920x1080 or you will get a similar error message...

[Lincoln Burrows]

From my limited experience using the append function, the resolutions i.e. 1920x1080, for both files have to match exactly...one cannot be 1912x1080 while the other is 1920x1080 or you will get a similar error message...But in this case both files are exactly the same. I made a copy from the demuxed file and tried to append using MKVmerge. Couldn't do that because the first MKV file had this multi-angle thing, and it seems you can't append if the 2nd file has no multi-angle in it.

Which means, you can't do this multi-angle (multiple video stream) thing with one MKV file and then try to append with another.

So in this case I have no choice? Do I need to watch, instead of a 2 hour movie, the first 2 minutes and then the next 118 in another file?

I was going to do this trick in Star Trek: TOS episodes and Star Wars, but I guess I can't do that...

[robpdotcom]

This will do what you want:

http://forum.doom9.org/showthread.php?t=160027

[Lincoln Burrows]

This will do what you want:

http://forum.doom9.org/showthread.php?t=160027Do you know for sure if this method will give me a MKV file with the entire movie but with the audio/video/subtitle streams untouched? I mean, I use MAKEMKV and MKVTOOLNIX to convert my Blu-rays (and even DVDs) into Matroska, but I don't want anything but a lossless compression:

http://en.wikipedia.org/wiki/Lossless_data_compression

So if I am not getting that from this method, it can't help me either.

(Anyway, I posted in that thread, take a look what I said).

[Chetwood]

There is no need for sperate angles cause only the crawl is separate and the rest of the movie is the same. Since you can't sort streams in MakeMKV (yet?), you can use Clown BD which in a first step will demux all files but also merge the angles. Then you can mux with MKVmerge as usual.

[TechnoPhil]

Hi,
can you suggest me a free blue-ray ripper for Mac?

[Mosu]

Hey,

I've released mkvtoolnix v5.0.1. It's a release with a few improvements/bug fixes and one important fix for a regression introduced in v5.0.0 regarding PGS subtitles.

There were no changes that concern package maintainers.

Here are the usual links: the home page (http://www.bunkus.org/videotools/mkvtoolnix/), the source code (http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-5.0.1.tar.bz2) and the Windows installer (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.0.1-setup.exe) and 7zip archive (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.0.1.7z).

All of the binaries (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html) that I provide myself are already available.

Here's the full ChangeLog (http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since release 5.0.0:

2011-10-09 Moritz Bunkus <moritz@bunkus.org>
* Released v5.0.1.

2011-10-08 Moritz Bunkus <moritz@bunkus.org>
* build system: Updated the Debian/Ubuntu files to debhelper v7/quilt 3.0 format.
* mkvmerge: enhancement: Implemented support for yet another way of storing EAC3 and DTS in MPEG transport streams.

2011-10-05 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: Track information was not reset when opening more than one file in the GUI.

2011-10-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The PGS subtitle output module was not outputting any packet in certain cases due to uninitialized variables.

2011-09-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed mkvmerge not finding any track in TS streams whose first PMT packet could not be parsed (e.g. invalid CRC).
* mkvmerge: bug fix: Fixed detection of TS streams that only contain one PAT or PMT packet within the first few KB but no others within the first 10 MB.


Have fun.

[b66pak]

thanks a lot...
_

[tebasuna51]

Thanks for you new version.

Please, can you replace the spanish translation for:
"Disable header removal compression for audio and video tracks by default"
to:
"Deshabilitar la compresión de cabeceras para audio y video por defecto"?

The actual one:
"Deshabilitar eliminador de la compresión del encabezado para audio y video predeterminadamente"
isn't clear at all.
"Deshabilitar eliminador de la compresión" can be understand like "Enable compression"

Thanks.

[Mosu]

Sure, will do.

[Chetwood]

Can you explain the bug concerning PGS subs. I had some issues with these on my WDTV Live and according to the latest firmware log they should work.

"The PGS subtitle output module was not outputting any packet in certain cases due to uninitialized variables."

Does this mean, there simply would be no PGS sub stream or that the stream would be empty or something?

[Mosu]

"The PGS subtitle output module was not outputting any packet in certain cases due to uninitialized variables."

Does this mean, there simply would be no PGS sub stream or that the stream would be empty or something?

The latter. The track headers contained an entry for the track, but there was not a single packet for it.

[mbcd]

Oh God, I`m happy with that, because I used exactly that version for remuxing all my files and it would be lots of days hard work to remux the original PGS again.

Question:
Is it possible to fix this issue by remuxing the files with further versions? Will there be a internal check to fix that? As I understood there is nothing damaged or lost, only some additional entries where no data (paket) is behind. So there are now for example 500 entries in Header, but only 200 real subtitles inside those track.

I`m asking because I mentioned those problem, because I watched a movie, activated a subtitletrack, but nothing was shown on screen. Now I am not shure if those track was only a forced subtitletrack (with very less "messages" = entries?), or a "damaged" one.

[sneaker_ger]

As far as I understand Mosu, you could be in deep trouble. Players will indicate that there is a track, but no actual "lines" (actually bitmaps for PGS) were written to the file. This would imply unrecoverable data loss, simple remuxing (or anything else for that matter) can not repair those files.

/edit:
Didn't saw any trouble muxing from mkv, m2ts and raw. Maybe Mosu can elaborate on "in certain cases"?

[Mosu]

As far as I understand Mosu, you could be in deep trouble. Players will indicate that there is a track, but no actual "lines" (actually bitmaps for PGS) were written to the file. This would imply unrecoverable data loss, simple remuxing (or anything else for that matter) can not repair those files.

This is correct. Ok here goes a longer explanation:

Prior to v5.0.0 everything was A-OK.

v5.0.0 introduced a nasty bug that only occurred if mkvmerge itself was compiled with compiler optimization turned on. As most people on this planet use pre-built binary packages this does apply to all of them as binary packages, especially the ones I provide, are almost always compiled with optimization. The reason I'm making this distinction right now is because my development builds are always compiled with optimization turned off (otherwise it makes stepping through it with a debugger really difficult). Therefore I just didn't notice that bug during development. Neither did my automated test suite fail because I usually run it from a development build, too, simply because re-compiling with optimization turned on takes a couple of minutes (and as I run the test suite quite often these minutes can add up quickly).

The bug itself resulted in the track headers being OK (they're exactly the same as they were before v5.0.0) but no pictures written at all. Yes, all the data was lost. No, there's no way to recover the data from such a file. You can only re-mux the original source file(s) with v5.0.1.

/edit:
Didn't saw any trouble muxing from mkv, m2ts and raw. Maybe Mosu can elaborate on "in certain cases"?

The "certain cases" refer to the compiler optimization being turned on or off. At the time of the release of v5.0.1 I still thought it might only have occurred when PGS subs were read from a Matroska file but not from a PGS subtitle file, but I was wrong in that. It always happens if compiler optimization was turned on.

[sneaker_ger]

It doesn't seem do happen with your win32 binary, 5.0.0, Sep 25 2011 20:33:49. Lucky that the most used binary was unaffected or am I looking at the wrong place?

[Mosu]

It is possible, though I haven't confirmed it myself, that the mingw cross-compiler (which is a gcc running on Linux compiling into Windows executables) treats this differently than my gcc on Linux.

More likely, however, is that it is more or less random. The bug itself is that a certain variable was not initialized. Without optimization gcc still initializes memory to 0 whenever memory is allocated. With optimization gcc re-uses the memory, so the variables initial value depends on what was present in the memory before the object the variable belongs to was constructed. Therefore I still believe that the Windows executable for v5.0.0 is affected.

[sneaker_ger]

"Random" lines, or always all or no lines affected?

[Mosu]

As the variable in question is only created once per track I'd say you either get all lines or none at all.

[sneaker_ger]

I see, thx.

[mbcd]

Therefore I still believe that the Windows executable for v5.0.0 is affected.

Yes :( I still have to confirm this.

I remuxed all my files with 5.0.0 by cli-batch-processing. So a new instance was created for each remux.

Now I demuxed lots of files and some are damaged.
The bug ends in empty subtitletracks. The Track is still there, but there is not a single line in it, its completely empty.
So you get a demuxed filesize of 0 Bytes for those tracks.

Fixing is happily very easy because the damaged tracks can be identified by filesize. What I figured out (until now) is, that if filesize is bigger than 0, track is Ok and bitidentical to the original one.

So the bug did not damaged single lines inside a subtitletrack but the whole track, thats "good".

Here its about 10% until now.
I can remux those damaged track (mostly only one from 3 inside one mkv) and everything is fine again.

I think those version should not have named "Die wahre Liebe", because after this at all, this version is not any more my "true love" ... :sly:

Love is a lie ... Love lies ... and my love to this version dies/died ;)

[Mosu]

Well, you got MPEG transport stream support, which counted for a lot of love all around ;)

[bernd_b]

Indeed, the mpeg-ts support is a great joy comming unearned and surprisingly - something which sounds like love to me...

:thanks::thanks::thanks:

[Lincoln Burrows]

Wait... what's going on, I am using MKVExtractGUI2 to extract one AC3 stream from a Matroska file and the resulting AC3 file has:

Duration : 8003184
Duration : 2h 13mn
Duration : 2h 13mn 23s 184ms
Duration : 2h 13mn
Duration : 02:13:23.184While inside the MKV container, MediaInfo says it's longer (with the same length from the video stream/movie):

Duration : 8045072
Duration : 2h 14mn
Duration : 2h 14mn 5s 72ms
Duration : 2h 14mn
Duration : 02:14:05.072Any idea what happened?

Edit: What the hell is this?

http://i.imgur.com/M1j0w.png

Several "Warning - This AC3 track contains X bytes of non AC3-data which were skipped. The audio/video synchronization may have been lost" messages. Why are these programs doing that? They are ruining what I was trying to do!

[Mosu]

Oh no, the programs are out to get you!

[Lincoln Burrows]

Oh no, the programs are out to get you!And it's all of them, not just yours. :p

Even converting the MKV with the AC3 into AVI/MP3 couldn't change the final length, which is always shorter.

There's no way to fix this? I also found someone indicating
http://www.videohelp.com/tools/AC3fix_GUI

But that didn't helped me either.

As long as this problem isn't solved I am going to use this solution: use Sound Forge to record the entire stream while playing in my computer.

[Mosu]

How do you expect it to be resolved? If the track contains some bytes that simply do not adhere to the AC3 specifications then that is simply garbage.

Also the track "length" inside a Matroska file is not a precise measurement. MediaInfo can only take the difference between the last and the first timecode for that track. However, it cannot take into account if there are gaps, nor does it take into account if there are packets with timecodes but with garbage as their payload.

I'm pretty sure there simply is not more (good) data available.

You may still succeed with your method, though, if the player you're using adheres to the timecodes in the file and fills gaps (caused by e.g. missing packets/gaps or garbage data) with silence (or random noise). That way you might actually end up with a track that's exactly as long as you expect it to be; just don't expect it to sound perfect 100% of the time.

[Lincoln Burrows]

You may still succeed with your method, though, if the player you're using adheres to the timecodes in the file and fills gaps (caused by e.g. missing packets/gaps or garbage data) with silence (or random noise). That way you might actually end up with a track that's exactly as long as you expect it to be; just don't expect it to sound perfect 100% of the time.The issue here is that you can watch the entire movie with 2h14m06s with no "garbage" as you say, but when you attempt to extract the audio/data it's always shorter.

So, if there's no way to extract the audio with the same length from the video, the only alternative is to record the entire stream again (wasting 2h14m with SF recording that).

Even if the audio stream is damaged I was expecting that all tools would extract as I see it, and not give me excuses to mess with the whole thing.

I don't know if this can be quoted as an example, but think about it:

* When you try to convert a Blu-ray decripted to your Hard Drive with MakeMKV, sometimes the program warns that AnyDVD is running. If you do it anyway, the program will not complete the task and it will freeze.

The developer instructed me to decrypt the original disc with MakeMKV.

But if AnyDVD was not running when I tried to convert, what happened with the files?

I don't know, but from the looks of it, it seems they were not decrypted properly or there's something wrong with the data (although if there is something wrong, it can't be seen while you are watching the movie). And it only happens with the movie, not the extra features.

But what if you lost the original disc? There's no way to convert to Matroska, right?

Wrong. You can still do this way:

1) Open tsMuxerGUI
2) Select the m2ts file with the movie.
3) Select "Demux" and what streams you want.
4) After they were all demuxed, select them with MKVMerge and save to Matroska.You see? MakeMKV was simply refusing to convert the files for some strange reason.

I don't know what happened with this audio stream but whatever happened, I assure you it's not noticeable when you are watching the video stream it was originally attached.

[Mosu]

Still, you're missing the point about gaps in the timecodes. It's quite possible and maybe even likely that your player simply compensates for a situation when the available number of samples (after decoding the AC3 frame) are not enough to fill the time period until the next packet's timecode. Usually players do that by speeding up the video track ever so slightly for such short gaps (e.g. displaying one or two frames a couple of ms shorter than they otherwise should have).

Now when you extract stuff like AC3 into a raw file then mkvextract does not "mess around with your data"; it simply writes them 1:1 as the data is found in the Matroska file. The big difference is that raw AC3 files have no timecode information whatsoever. Therefore gaps such as those I've mentioned above would "disappear". There's simply nothing mkvextract can do about it.

As to mkvmerge refusing to re-use that garbage: that's completely compliant with the Matroska specs with state (apart from other things) that a track must only contain valid data for exactly one codec.

I can understand that you're frustrated, but there's simply nothing I can or will do about it.

[Lincoln Burrows]

What about stretching or delay ?

If audio or video ist streched / or delayed you could get such differences too, or am I wrong ?

As far as I remember, mkvmerg does not fix delays or stretching directly on filebase.Let me explain what I am trying to do here:

1) I need to extract this audio stream from the video it was originally attached (and it can be watched perfectly) in the exact way it is presented.

The way I am getting the whole thing is this: in the first hour the audio is out of sync 1, 2, 3, 4 seconds and the difference is 8 seconds after 2 hours. It's not the whole thing that is 8 seconds out of sync. So I can't add 8 seconds of "silence" using Sound Forge in the beginning of the file (that was going to do the trick).

2) Even if I managed to fix this whole thing, I need to sync this audio for the same movie, but another source. It's a dubbing. And the other source might have a different length.

In other words, I need the whole thing perfect to make another edition using Sound Forge, perhaps adding a few seconds of "silence" to match the sync. It needs to be 100% corrected from the first second to the last. If it's not, even with other tools to fix the audio, I am going to notice there's something wrong.

[Mosu]

Two thoughts:

1) Just do it like you proposed. You've probably spent way more time now on trying to get it working like you think it should with other tools than it would've taken you to record it in the first place.

2) Just re-create the movie from your source.

Other than that I cannot help you. Or more precise I don't want to spend any more time and thought on your once-in-a-lifetime, unique problem.

[Lincoln Burrows]

Other than that I cannot help you. Or more precise I don't want to spend any more time and thought on your once-in-a-lifetime, unique problem.I was just wondering how this audio stream had this problem in the first place (non-AC3 data).

But it's not just your software that can't give me that stream the way I want, I wasn't able to find another solution and even this ac3fix couldn't help me.

I had these sorts of problems before, but as I see it, some things can't be fixed for a long time, like the 3 PIP streams from "The Sound of Music (1965)" blu-ray, that can't be converted to Matroska (I had to keep the original decrypted files in my Hard Drive (even the 30 GB m2ts from the movie), and I only want converted MKVs to waste disk space), or simply the slideshows from DVDs/BDs (I also had to keep the smaller VIDEO_TS folder files)...

I am having another issue with yellow/transparent subtitles from a DVD as well... (this was the first time MPC couldn't display a subtitle from a MKV file).

Not to mention the multiple angle streams...

All those issues should be fixed by MakeMKV itself (if there's a way to do it), I was only going to use MKVToolnix to a simple task, inserting the audio file and making a direct stream copy.

Two thoughts:

1) Just do it like you proposed. You've probably spent way more time now on trying to get it working like you think it should with other tools than it would've taken you to record it in the first place.

2) Just re-create the movie from your source.

Other than that I cannot help you. Or more precise I don't want to spend any more time and thought on your once-in-a-lifetime, unique problem.Edit: I tried now, same problem. It seems (I noticed for a brief moment) the player is doing exactly what you told here:

Usually players do that by speeding up the video track ever so slightly for such short gaps (e.g. displaying one or two frames a couple of ms shorter than they otherwise should have).Therefore, there's no way to even record this thing...

[mindbomb]

Umm, I think there is a bug.
When importing an m2ts with vc-1 video, the resulting mkv file doesn't play correctly.

According to nevcariel, " It looks like it muxed them with only PTS timestamps, but no DTS timestamps - but all other VC-1 when muxed from a raw stream for example are muxed with DTS only, which is the de-facto standard today."

[Mosu]

Upload a sample, please.

[mindbomb]

certainly, here is the resultant mkv file:
http://www.mediafire.com/?3gshc717zk26udg

And the initial m2ts is here
http://www.mediafire.com/?5wt2ujrwsxcb9fy

[mbcd]

Feature Request:

It would be nice to get an additional Feature with mkvextract.

If you use "ordered-chapters" inside mkv it would be nice to have an additional parameter to choose from which "movie" you want to demux tracks or something else.

ATM you can only demux whole mkv-file, or am I missing something?

[Mosu]

All of my tools are pretty limited to processing a single segment in a single file (apart from mkvmerge which can obviously read more than one input file; however, "only one segment in a file" also applies to it). That will not change in the near future as it would require a major overhaul of pretty much everything.

Also, what you're asking for will also not be implemented any time soon. Again, it'd require major additions/changes, not something that I'm willing to do at the moment. Sorry.

[mindbomb]

mosu, was I supposed to use your ftp instead of mediafire?

did you already download the file, or do you want me to upload it there?

[Mosu]

I've downloaded the file(s) already; sorry for not answering sooner. No need to upload to my FTP server. Thanks.

[Mosu]

Here's a build that uses DTS instead of PTS for VC1 from MPEG TS: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.0.1-build20111024-376-setup.exe

[mindbomb]

thanks mosu!

[vmrsss]

Hi Mosu,

Building 5.0.1 now seems to require gcc-4.6 or more:


The following features of the C++11 standard are not supported by g++:
* initializer lists
* range-based 'for'
* right angle brackets
* 'auto' keyword
* lambda functions
If you are using the GNU C compiler collection (gcc) then you need
at least v4.6.
configure: error: support for required C++11 features incomplete


What a pity, that is not available on Mac. I won't be able to keep my copy of mkvmerge up to date.

Very disappointing. Do you know of a workaround?

Thx

[Abradoks]

What a pity, that is not available on Mac.
What's the problem with 4.6 on Mac? Google tells (http://beardedcodewarrior.net/2011/07/25/building-gcc-4-6-1-on-mac-os-x-lion/) it works fine.

[Mosu]

MKVToolNix will not require gcc in particular, but certain features of the C++11 standard. For gcc v4.6 is the first version that supports all of them, especially range-based "for" loops (see http://gcc.gnu.org/projects/cxx0x.html ).

Unfortunately clang/llvm doesn't support all the required features as of yet, especially lambda expressions (see http://clang.llvm.org/cxx_status.html when it's back up).

There's no workaround, I will not remove the code using these features again. See http://marcmutz.wordpress.com/2011/09/20/c98-support-costs-extra/ why. I like being an early adopter of good stuff :)

What you can do is compile gcc 4.6.1 yourself as Abradoks has pointed out.

[forclip]

Hi Mosu. Please check the "Add to job queue" button in mmg, it seems to be broken in the last few builds.

http://img192.imageshack.us/img192/9654/89068700.th.png (http://imageshack.us/photo/my-images/192/89068700.png/)

[vmrsss]

What's the problem with 4.6 on Mac? Google tells (http://beardedcodewarrior.net/2011/07/25/building-gcc-4-6-1-on-mac-os-x-lion/) it works fine.

ah!, ah!, anecdotal reports say it's a nightmare to build...

[Mosu]

Hi Mosu. Please check the "Add to job queue" button in mmg, it seems to be broken in the last few builds.

Thanks for noticing. Interesting. That particular bug has been present for more than seven years now. It's interesting that that particular code path hasn't been invoked for such a long time.

Anyway, it's been fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.0.1-build20111030-377-setup.exe

[Abs62]

Font files added as attachments by last builds (376, 377) don't loaded by VSFilter when it shows subtitles. With files created by build 369 all works perfectly.
If source file for last mkvmerge already have fonts as attachments added by build 369, it also work OK. Problem is occurred only if fonts was attached by last builds.

PS. Result file with attachments created by last build is 10 bytes shorter then same file created by build 369.

[forclip]

Anyway, it's been fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.0.1-build20111030-377-setup.exe
:thanks:

[Thunderbolt8]

got a problem with a DTS-HD (hi-res) track (5.1 96kHz) I am trying to mux. basically what happens is that it creates a 0 byte file at the beginning and then doesnt continue, CPU load goes up to 50% (= 1 core at 100%) and it doesnt proceed any further from there. muxing other DTS-HD hi res tracks works fine (e.g. no problems with 7.1 96kHz).

uploaded a 100mb sample (test.dtshd) to your ftp server.

[Mosu]

Font files added as attachments by last builds (376, 377) don't loaded by VSFilter when it shows subtitles. With files created by build 369 all works perfectly.
If source file for last mkvmerge already have fonts as attachments added by build 369, it also work OK. Problem is occurred only if fonts was attached by last builds.

PS. Result file with attachments created by last build is 10 bytes shorter then same file created by build 369.

Those two results seem to come from the newer builds using newer versions of libfile, the component used for automatic MIME type recognition for attachments. The old build's libfile library used "application/x-truetype-font", the new one "application/x-font-ttf". That's also the reason why the file is shorter: the old MIME type designation is five bytes longer, and my guess is that you've got exactly two fonts attached.

Now there's no official MIME type for fonts (any font type, not just not for TrueType fonts). See the official list at IANA (http://www.iana.org/assignments/media-types/index.html). However, most sources I've been able to dig up (e.g. Apache's latest list (http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/mime.types?view=markup) or Wikipedia (http://en.wikipedia.org/wiki/Internet_media_type#Type_x)) agree with the new version of libfile and list "application/x-font-ttf". Therefore I will not change MKVToolNix.

You can/should do two things: file a bug report/feature request with the VSFilter developers and manually tell mkvmerge to use the old MIME type until the bug is fixed.

[Mosu]

got a problem with a DTS-HD (hi-res) track (5.1 96kHz) I am trying to mux. basically what happens is that it creates a 0 byte file at the beginning and then doesnt continue, CPU load goes up to 50% (= 1 core at 100%) and it doesnt proceed any further from there. muxing other DTS-HD hi res tracks works fine (e.g. no problems with 7.1 96kHz).

uploaded a 100mb sample (test.dtshd) to your ftp server.

I'm sorry, but I cannot reproduce it with the file you've uploaded and the latest build from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (as well as on Linux). Muxes fine, file has the expected size.

Try upgrading your MKVToolNix installation, please. If it sill doesn't work then post your command line as well.

[Abs62]

You can/should do two things: file a bug report/feature request with the VSFilter developers and manually tell mkvmerge to use the old MIME type until the bug is fixed.
Thanks. Haali Media Splitter and internal MPC-HC matroska splitter don't recognize "application/x-font-ttf", but LAVSplitter has understand it.

[Thunderbolt8]

I'm sorry, but I cannot reproduce it with the file you've uploaded and the latest build from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (as well as on Linux). Muxes fine, file has the expected size.

Try upgrading your MKVToolNix installation, please. If it sill doesn't work then post your command line as well.you are right, its actually the VC-1 video track of a file I want to remux with the DTS-HD track which is causing problems -.-

uploaded another sample of the video (test2.mkv). hoping upload was successful, if not please let me know.

[Mosu]

That VC1 problem should be fixed in build 378: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.0.1-build20111104-378-setup.exe

It's still uploading at the moment, and that will take another hour or so as I'm also uploading something else.

[Thunderbolt8]

any comment on what the problem was? that BD wasnt really a new one so wondering why this problem hasnt occured before.

[Mosu]

The VC1 bitstreams I've seen so far are built similar to MPEG bistreams, meaning they start with start codes (0x00 0x00 0x01 ...). mkvmerge looks for those markers in order to determine frame boundaries. However, this particular file uses a different bitstream syntax. Maybe it's an older version of the VC1 bistream, I don't know. I've chosen the path of leaast resistance and made the Matroska reader simply copy such streams over as they are without any further processing ("pass-through packetizer").

[Fullmetal Encoder]

1. Is there any chance that you will be including the ability for mkvmerge to read the chapter points for blu-ray files and DVD's so they could be extracted into an xml or muxed directly into the final mkv? I'm hoping that that wouldn't be too difficult since mkvmerge already knows about the structure of the DVD from the VOBS and playlist data from the blu-ray files.

2. Is there any way you could include the ability to split a VOB/M2TS, using time values, into certain segments while excluding other segments? Right now, if I try to split a file using 2 different times mkvmerge writes all three segments to disk. What if I only wanted the middle segment between the time values (my time values are always chapter points)? My problem is that my source content is almost always a television show with an OP and ED that I don't want to include. If I'm processing for an encode then, aside from wasting a lot of time, splitting the file forces me to do a tremendous amount of writing/deleting to/from disk of those segments that I don't want (for what will be thousands of episodes). Actually if mkvmerge were aware of the chapter points then it could automatically include those time values into the split function giving us the ability to demux individual chapters from a stream. If there is any way for the split capability to exclude certain segments as it is I haven't been able to find anything about how to do it in the documentation.

3. Is there any chance you will give mkvmerge the ability to pull DVD subtitles? I know that technically I can do it on a chapter basis using VOBlanker and VSRip but that's such a sloppy and time consuming solution compared to the elegant way in which it's handled for m2ts files.

Any of the above would be tremendously helpful.

Also, I had a question about how mkvmerge muxes the components of an m2ts file. When I create an MKV from an m2ts what I get is an MKV that is 502 MB smaller than the m2ts even though I didn't exclude anything from being muxed. What could account for this?

Thank you for adding direct m2ts support. It's very exciting development.

[Mosu]

1. Is there any chance that you will be including the ability for mkvmerge to read the chapter points for blu-ray files and DVD's so they could be extracted into an xml or muxed directly into the final mkv? I'm hoping that that wouldn't be too difficult since mkvmerge already knows about the structure of the DVD from the VOBS and playlist data from the blu-ray files.

For DVDs: no. Chapters are not stored in the VOBs but in the accompanying files. Adding support for reading chapters from DVDs in mmg's chapter editor would not be that difficult (I've written a command line tool for that back in the days of the ogmtools (http://www.bunkus.org/videotools/ogmtools/), dvdxchapt it was called, using libdvdread). However, doing it directly in mkvmerge would require a lot of more infrastructure (track selection, some way to specify the chapter names as only their timecodes are actually present in the DVD structures) than I'm willing to build.

For BluRay: maybe, though I don't know if it's even realistic as I don't know a lot about that format. What I'm concerned about is that the menu system is built on an interpreted language as far as I know, and maybe there simply aren't chapters stored in an easy-to-access way. I may investigate this in the future though. Also: mkvmerge only reads the M2TS files (and it can also extract the track languages from the .clip files); playlist data or whatever is not understood yet.

2. Is there any way you could include the ability to split a VOB/M2TS, using time values, into certain segments while excluding other segments?

See bug/feature request 518 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=518). It boils down to "I agree it would be a cool feature, but don't count on it".

3. Is there any chance you will give mkvmerge the ability to pull DVD subtitles?

No, sorry.

I know that technically I can do it on a chapter basis using VOBlanker and VSRip but that's such a sloppy and time consuming solution compared to the elegant way in which it's handled for m2ts files.

They way they're stored in M2TS and what they actually consist of (e.g. no pesky information in an .idx file derived from the DVD's support files instead of the VOBs) is way easier to read/demux than how subtitles on DVDs are stored.

Also, I had a question about how mkvmerge muxes the components of an m2ts file. When I create an MKV from an m2ts what I get is an MKV that is 502 MB smaller than the m2ts even though I didn't exclude anything from being muxed. What could account for this?

Several things come to mind:

MPEG transport streams have higher overhead than Matroska files.
mkvmerge intentionally discards certain contain (e.g. the AC3 "core" from a combined TrueHD+AC3 track; see this FAQ entry (http://www.bunkus.org/videotools/mkvtoolnix/faq.html#truehd_with_ac3) for details)
mkvmerge discards anything it doesn't support.

[mindbomb]

http://www.mediafire.com/?4ficfdybbti26hc

mkvmerge mistakes mp4 streaming text subtitles for chapters.

[Mosu]

I actually have files in which this very method is used for storing chapters. Users requested mkvmerge recognizes them as such, hence that functionality. Also I know that at least one popular splitter/player uses this method as well, just like at least one authoring/muxing application. Therefore I will not change it.

[Toddler Naruto]

Suggestion: Please add a "Minimize to System Tray" feature, that can be activated by clicking on Minimize or Close buttons.

[Mosu]

No, sorry.

[Toddler Naruto]

No, sorry.

Why not, if you don't mind me asking? I don't like having it stay in the taskbar while it's running.

[Mosu]

I don't like wasting time I don't have. Such a feature would not be critical, has not been requested often, would not fix a bug, would not enhance or extend even semi-important functionality. At best it would be a convenience feature that only a minority of users would actually care for.

If someone were to provide a patch that a) implements support on both Windows and Linux and b) leaves the choice where to minimize to to the user then I certainly wouldn't reject it. But I will just as surely not work on this myself.

[Chetwood]

Please add a "Minimize to System Tray" feature, that can be activated by clicking on Minimize or Close buttons.
Whoever started to have clicking close" minimize to tray instead of actually closing the program should be torn and quartered anyway! And what's the point of having an icon in the taskbar and the tray at the same time? Tray only would be fine by me, though.

BTW, Mosu, just tried the batch feature of mmg.exe and it works like a charm.

[Mosu]

Although he didn't explicitly say it I'm guessing he did mean "minimize to the tray instead of the taskbar" and not "in addition to the taskbar". Still, doesn't change my view of the issue.

[vmrsss]

Trying to compile mkvtoolnix, rake stops at flac_common.h with the following error (never happened before).

Any suggestion please?


rake aborted!
Don't know how to build task 'src/input/flac_common.h'


EDIT: I have solved this by trashing the entire directory and cloning it from scratch. Thanks anyway

[MrVideo]

I've never had this happen before. The demultiplexer failed to initialize. The x264 .264 file was encoded like all of the other 10800p/23.976 files before it. I have a script that does the encoding and the exact same options are used for all of the 1080p/23.976 files that I encode.

Mediainfo has no problem opening and displaying the content of the file and tsMuXer has no issue creating a TS file from the .264 and .ac3 files.

Is there a MKV tool that I can run to find out why it doesn't like the .264 file?

[Mosu]

Trying to compile mkvtoolnix, rake stops at flac_common.h with the following error (never happened before).

gcc tracks dependencies for all compiled files. Yesterday I've moved flac_common.h and flac_common.cpp around a bit, but your dependencies still list the old names & locations. Easy to fix:

rm -rf rake.d/dependency.d
drake clean
drake

[Mosu]

I've never had this happen before. The demultiplexer failed to initialize.

File too short or damaged maybe. Hard to tell without having the actual file to look at (hint!).

[vmrsss]

Hi Mosu,

there appears to be a problem with the latest commit: this


mtx ex: seek in file error (type: N3mtx5mm_io6seek_xE

happens with all attempts to mux/demux (tried h.264 and ac3).

The problem definitely wasn't there yesterday...

[Mosu]

Interesting. It doesn't happen for me. Which OS are you using? Have you made sure that you've rebuilt completely?

[vmrsss]

Interesting. It doesn't happen for me. Which OS are you using? Have you made sure that you've rebuilt completely?

macos x, both snow leopard and lion. Both with gcc-4.6.1 and 4.6.2.

I did rake clean at the beginning. Is there a better a command to try?

[Mosu]

No, "rake clean" is sufficient. BTW you can use "./drake -j N" instead of rake if you have more than one core and replace N with the number of cores + 1 or something like that for faster builds.

I still cannot reproduce it. Can you please show me a command line you're using? As well as the full output? Thanks.

[vmrsss]

No, "rake clean" is sufficient. BTW you can use "./drake -j N" instead of rake if you have more than one core and replace N with the number of cores + 1 or something like that for faster builds.

I still cannot reproduce it. Can you please show me a command line you're using? As well as the full output? Thanks.

eg:

src/mkvmerge -o tmp.mkv The\ Story\ of\ Film/The\ Story\ of\ Film.mkv
mkvmerge v5.0.1 ('Es ist Sommer') built on Nov 15 2011 09:41:26
'The Story of Film/The Story of Film.mkv': Using the demultiplexer for the format 'Matroska'.
'The Story of Film/The Story of Film.mkv' track 1: Using the output module for the format 'AVC/h.264'.
'The Story of Film/The Story of Film.mkv' track 2: Using the output module for the format 'MP3'.
The file 'tmp.mkv' has been opened for writing.
Progress: 0%
mtx ex: seek in file error (type: N3mtx5mm_io6seek_xE)
Progress: 100%
The cue entries (the index) are being written...
Muxing took 0 seconds.

I can confirm that if I rollback to the Nov 13 checkout, things work out just fine.

[Mosu]

Still cannot reproduce it. Can you upload your source file, please?

[Mosu]

Oh... wait before uploading, please...

[Mosu]

How embarrassing. I developed that functionality on my laptop and forgot to pull on my regular development machine on which I ran the tests. Yes, I can reproduce the issue; no need to upload a file.

[vmrsss]

Still cannot reproduce it. Can you upload your source file, please?

done. I am not sure you'll learn much from it, because it does it with all the files I've tried. Possibly, you might learn more from the output file, tmp.mkv, which I have uploaded too.

[Mosu]

Fixed in revision 5766d8e.

[73ChargerFan]

mkvmerge intentionally discards certain contain (e.g. the AC3 "core" from a combined TrueHD+AC3 track; see this FAQ entry (http://www.bunkus.org/videotools/mkvtoolnix/faq.html#truehd_with_ac3) for details)


Suggestion: List the AC3 core as an additional english track, and then I can select it or discard it.

------------------------------------------------

That is disappointing, for two reasons:

First, this behavior is different than for DTSMA. (I know the DTSMA is extras that are added to the core to make it lossless, and that AC3 isn't essential to TrueHD, but both are described as lossless with a lossy core.)

Second, what is this with "silently discarding" stuff? I must have missed the blurb in the changelog.

The discard assumes that the person has a TrueHD decoder, which not everyone does. Media players that will output the AC3 core but will not decode / transcode TrueHD, and apparently movies with TrueHD remuxed using mkvtoolnix won't play on them.

Fortunately, most BDs have the DTSMA tracks, so the problem isn't widespread, but each remux takes a few hours.

[Mosu]

The AC3 core in a TrueHD+AC3 track has always been dropped silently. There was no need for an entry in the ChangeLog because it's never worked any other way. Yes, it is a possibility to present the AC3 core as an addition track, but that would require substantial additions to mkvmerge in order to be able to handle demuxers that contain demuxers. Therefore I don't think I'll work on this any time soon.

[Mosu]

Oh, and yes, that behaviour is different for DTS-MA but you're comparing apples and oranges. DTS-MA needs both the core and the extension in order to be losslessly decodable. For TrueHD+AC3 you only need the TrueHD part in order to be losslessly decodable. The AC3 core is completely redundant.

[Atak_Snajpera]

@Mosu
Why does mkvmerge show this warning for raw .aac

"mkvmerge.exe" -o "C:\Users\Dawid\Desktop\video.mkv" --
compression 0:none --title "video" --default-duration 0:24000/1001fps "C:\Temp\
RipBot264temp\video.264" --compression 0:none --language 0:fre --aac-is-sbr 0:0
"C:\Temp\RipBot264temp\audio.aac"
mkvmerge v5.0.1 ('Es ist Sommer') built on Oct 9 2011 11:55:43
'C:\Temp\RipBot264temp\video.264': Using the AVC/h.264 ES demultiplexer.
'C:\Temp\RipBot264temp\audio.aac': Using the Quicktime/MP4 demultiplexer.
'C:\Temp\RipBot264temp\video.264' track 0: Using the MPEG-4 part 10 ES video out
put module.
'C:\Temp\RipBot264temp\audio.aac' track 1: Using the AAC output module.
Warning: 'C:\Temp\RipBot264temp\audio.aac': A track with the ID 0 was requested
but not found in the file. The corresponding option will be ignored.
The file 'C:\Users\Dawid\Desktop\video.mkv' has been opened for writing.
'C:\Temp\RipBot264temp\video.264' track 0: Extracted the aspect ratio informatio
n from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 19
20/1080.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 1 second.

BTW. File has been muxed correctly with aac audio.

MKVmerge does not complain for other formats like ac3,vorbis ...
"mkvmerge.exe" -o "C:\Users\Dawid\Desktop\video.mkv" --
compression 0:none --title "video" --default-duration 0:24000/1001fps "C:\Temp\
RipBot264temp\video.264" --compression 0:none --language 0:fre "C:\Temp\RipBot2
64temp\audio.ac3"
mkvmerge v5.0.1 ('Es ist Sommer') built on Oct 9 2011 11:55:43
'C:\Temp\RipBot264temp\video.264': Using the AVC/h.264 ES demultiplexer.
'C:\Temp\RipBot264temp\audio.ac3': Using the AC3 demultiplexer.
'C:\Temp\RipBot264temp\video.264' track 0: Using the MPEG-4 part 10 ES video out
put module.
'C:\Temp\RipBot264temp\audio.ac3' track 0: Using the AC3 output module.
The file 'C:\Users\Dawid\Desktop\video.mkv' has been opened for writing.
'C:\Temp\RipBot264temp\video.264' track 0: Extracted the aspect ratio informatio
n from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 19
20/1080.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 1 second.

[Mosu]

As you can see in mkvmerge's earlier message that the file you've named ".aac" is actually a MP4/QuickTime file containing an AAC track. Use mkvmerge's identification mode in order to find out the track ID mkvmerge assigns to that track ("mkvmerge --identify file.aac").

Also read the documentation about mkvmerge's track IDs (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.track_ids).

In short: don't rely on what you think the track ID might be. Ask mkvmerge.

[Thunderbolt8]

The discard assumes that the person has a TrueHD decoder, which not everyone does. Media players that will output the AC3 core but will not decode / transcode TrueHD, and apparently movies with TrueHD remuxed using mkvtoolnix won't play on them.do most hardware receivers decode the truehd track if the ac3 track is not present?

[Mosu]

If hardware can decode TrueHD in the first place then it decodes it even if AC3 is not present. If that doesn't work for a particular hardware set then that piece of hardware is seriously bugged because, let me repeat that, TrueHD is completely independent of any AC3 track/part/content.

[Toddler Naruto]

what's the point of having an icon in the taskbar and the tray at the same time? Tray only would be fine by me, though.

I was asking minimize to the tray instead of the taskbar, thought that was obvious and did not need to be mentioned.

[Chetwood]

I simply observed that some coders do it differently, which is pointless. I thought that was obvious and did not need to be mentioned.

[stax76]

@Mosu

mmg has some minor issues with 144 DPI in Win7 (probably exactly identical in Vista).

http://msdn.microsoft.com/en-us/library/dd464660%28v=VS.85%29.aspx#high_dpi_issues_checklist

[Mosu]

@Mosu

mmg has some minor issues with 144 DPI in Win7 (probably exactly identical in Vista).

http://msdn.microsoft.com/en-us/library/dd464660%28v=VS.85%29.aspx#high_dpi_issues_checklist

Screenshots of the problems, please, I only have access to a Windows laptop running rather low resolution so testing high DPI is not really possible at the moment.

[stax76]

Since it don't has a high DPI manifest it uses DPI virtualization so it's completely blurry with default settings, it's also rather large.

With DPI virtualization disabled (can be set per application) it starts with a too small window height and resulting small and overlapped controls. After increasing the window height manually everything looks more or less OK.

.NET has some scaling and layout support, I test the scaling directly at runtime with a hidden keyboard shortcut and I test it also on XP with VirtualBox.

http://thumbnails50.imagebam.com/16065/3734ec160644360.jpg (http://www.imagebam.com/image/3734ec160644360)

http://thumbnails65.imagebam.com/16065/38c353160644937.jpg (http://www.imagebam.com/image/38c353160644937)

[Mosu]

The DPI awareness and a few other minor things (compared to pre build 382) have been implemented/fixed in pre build 384 (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) which is still uploading at the time of posting.

[stax76]

Looks fine with 144 DPI on Win 7 and XP. Thanks!

[mindbomb]

is this a bug?

when using mkvextract to extract srt subtitles from an mkv, some characters, like musical notes, get changed into question marks.

[Mosu]

No, it's not a bug, you simply don't specify the charset to use. Therefore it'll probably stay encoded in UTF-8, and if your editor or player cannot handle that...

[mindbomb]

alright, now this i think is a real bug then.

http://www.mediafire.com/?4c6n4cyde5jgso7

This ts sample with PAFF interlacing, when imported into mkvmerge and muxed into an mkv, plays back very choppily.

[Mosu]

It's well-known that mkvmerge has several problems with interlaced h264 tracks. It will be fixed sometime in 2012 (that's vague enough an estimation to have a chance of being correct).

[Chumbo]

@Mosu,
I saw this issue a while ago and forgot to report so here you go. Basically, the target/output folder structure is created on the source drive when I run the command line, e.g.,
for /f "delims=" %%i in ('dir /b "%SEARCH%"') do (
"mkvmerge.exe" -o "e:\\media\\work\\%%i" "--default-track" "1:yes" "--forced-track" "1:no"
"--display-dimensions" "1:720x540" "--default-duration" "1:24000/1001fps" "--compression" "1:none"
"--language" "2:eng" "--default-track" "2:yes" "--forced-track" "2:no" "--compression" "2:none" "-a" "2"
"-d" "1" "-S" "-T" "--no-global-tags" "--no-chapters" "%%i" "--track-order" "0:1,0:2"
)
So if I'm running the above from say drive N: then the output path specified above "\\media\\work\\" gets created on drive N:. It happens consistently so you should be able to duplicate it.

I'm currently running the following version: mkvmerge v5.0.1 ('Es ist Sommer') built on Oct 30 2011 21:53:49

I think I noticed this as far back as version 4 so sorry for the late report.

[Mosu]

Double backslashes? What for? cmd.exe doesn't use backslashes for escaping, neither does mkvmerge when it receives arguments directly on the command line. mkvmerge only uses backslashes for escaping when reading arguments from an options file.

Yes, I can reproduce it with double backslashes, but not with single ones. My guess is that boost::path interpretes this as a UNC path. Anyway, I will most likely not fix this.

[Mosu]

...or maybe I will; hmm this code is not using boost::filesystem::path yet... So it's definitely my mistake.

[Mosu]

No, I won't fix it. Boost handles things the same way my own code handled it. Therefore: don't use double backslashes if one suffices.

[Mosu]

....aaaand maybe I shouldn't code this late at night. Boost handles it correctly, it will be fixed in the next release.

[SamuriHL]

....aaaand maybe I shouldn't code this late at night. Boost handles it correctly, it will be fixed in the next release.

ROFLMAO! You're starting to sound like me when I write code after drinking too much rum! :D

[Chumbo]

ROFLMAO! You're starting to sound like me when I write code after drinking too much rum! :D
Ditto...:) I like to water down my rum with some Pepsi. :D

Mosu,
I had tried NOT using the double backslashes but mkvmerge would fail. But that was going all the way back to at least version 3. I have NOT tested the latest version of mkvmerge CLI with single slashes. I basically took what the UI provides as the correct command line which includes the double backslashes.

[Chetwood]

BTW, I've been using your batch functionality a lot lately. How about being able to make mmg play back a sound when finished? Thx.

[Mosu]

BTW, I've been using your batch functionality a lot lately. How about being able to make mmg play back a sound when finished? Thx.

Technically: sure, it's possible, but I will not do it, sorry. Playing sound in a cross-platform way would require yet even more libraries to use, not something I'm willing to do for tiny functionality gains.

I had been looking into notification techniques like growl/snarls a while back but didn't find easy-to-use, cross-platform code there either. Basically each desktop environment has its own notification mechanism (some like Linux even more -- KDE's + gnome's, even though basic access works through a shared interface), and again, that would be a lot of code to write and to test for little gain.

[Mosu]

Ditto...:) I like to water down my rum with some Pepsi. :D

Mosu,
I had tried NOT using the double backslashes but mkvmerge would fail. But that was going all the way back to at least version 3. I have NOT tested the latest version of mkvmerge CLI with single slashes. I basically took what the UI provides as the correct command line which includes the double backslashes.

Hmm, that's mmg escaping the command line wrongly on Windows then. Unfortunately cmd.exe totally sucks when it comes to command line parsing (try entering path names with spaces and quotes in it), so not every command line produced by mmg will be useable in cmd.exe. That's why there are option files. If in doubt use one (mmg always does).

See http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.option_order and search for "option file".

[Mosu]

Hey,

I've released mkvtoolnix v5.1.0. It fixes a lot of smaller issues across the board and greatly improves support for MPEG transport streams.

There are two important issues for package maintainers:

1. MKVToolNix now requires a C++ compiler that supports certain features of the C++11 standard. For gcc this means at least v4.6.0 is required. Unfortunately clang, even in the upcoming release 3.0, doesn't support all of the required features yet. Platforms that don't ship with such a new gcc or with clang only will have to stay at MKVToolNix 5.0.1.

2. MKVToolNix now requires Boost v1.46 or newer.

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

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

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

Here's the full ChangeLog since release v5.0.0:

2011-11-28 Moritz Bunkus <moritz@bunkus.org>
* Released v5.1.0.
* mkvmerge: bug fix: Fixed more timecode handling issues for video tracks in MPEG transport streams whose PES packets sometimes don't have a timecode.
* mkvmerge: bug fix: mkvmerge will no longer create folders on drives it shouldn't create them on on Windows.

2011-11-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed bogus huge timecodes sometimes occurring for AVC/h.264 video tracks read from MPEG transport streams.

2011-11-24 Moritz Bunkus <moritz@bunkus.org>
* all: enhancement: Made all EXEs declare their required access level privileges for Windows' User Access Control.
* mmg: enhancement: Made mmg DPI-aware on Windows (tested up to 144 DPI).

2011-11-09 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: mmg will append ".xml" to the file name entered when saving from the chapter editor if no extension was given.

2011-11-06 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: Improved skipping broken data on all operating systems.
* mkvmerge, mkvextract: bug fix: Skipping broken data in Matroska file often caused the program to abort on Windows. This has been fixed so that processing continues after the broken part. Fix for bug 668 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=668).

2011-11-04 Moritz Bunkus <moritz@bunkus.org>
* examples: Added XSLT 2.0 stylesheets in the "examples/stylesheets" directory for turning Matroska chapters into cue sheet and split points for "shntool" (useful for situations in which you have e.g. a live recording from a concert including chapters and want to create one audio file per song).
* mkvmerge: bug fix: Fixed reading VC1 video tracks from Matroska files that don't use VC1 start markers (0x00 0x00 0x01 ...).

2011-10-30 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Added "ogv" to the list of known file extensions for "Ogg/OGM audio/video files". Implements bug 667 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=667).
* mmg: bug fix: A utility function for breaking a line into multiple ones was accessing invalid memory in rare situations causing mmg to crash. Could happen e.g. when adding a job to the job queue.

2011-10-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge will use DTS instead of PTS for VC1 video tracks read from MPEG transport streams.

2011-10-23 Moritz Bunkus <moritz@bunkus.org>
* build system: Boost's "Range" library is now required.
* build system: Boost v1.46.0 or newer is now required. As a consequence included copies of some of Boost's libraries have been removed (foreach, property tree).
* build system: The C++ compiler must now support several features of the C++11 standard: initializer lists, range-based 'for' loops, right angle brackets, the 'auto' keyword and lambda functions. configure checks for each of these. For GCC this means at least v4.6.0.

2011-10-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed reading MPEG transport streams on big endian systems.
* mkvmerge: enhancement: Added support for reading AAC tracks from MPEG transport streams.

2011-10-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Relaxed the compatibility checks when concatenating VP8 video tracks.

2011-10-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed PCM audio in WAV sometimes being detected as DTS.
* mkvmerge: enhancement: The verbose identification mode will add the properties "default_duration", "audio_sampling_frequency" and "audio_channels" if appropriate and if the corresponding header elements are present.

2011-10-13 Moritz Bunkus <moritz@bunkus.org>
* Packaging: In v5.0.1 mmg's guide was accidentally moved into the "mkvtoolnix" Debian/Ubuntu package. It has been moved back into "mkvtoolnix-gui" again.

2011-10-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: "Castilan" has been merged with "Spanish" into "Spanish; Castillan" in the ISO 639 language list as both share the same ISO 639-2 code "spa".

Have fun.

Kind regards,
mosu

[b66pak]

thanks a lot...
_

[Chumbo]

Hey,
I've released mkvtoolnix v5.1.0.
...
Thanks Mosu.

[robpdotcom]

Hey,

I've released mkvtoolnix v5.1.0. It fixes a lot of smaller issues across the board and greatly improves support for MPEG transport streams.

Will this help with appending m2ts files?

[Mosu]

Will this help with appending m2ts files?

More or less. The functionality is there in mkvmerge, you just cannot use it with mmg -- yet.

For mkvmerge you can now specify more than one file name in parenthesis and those files will be treated like they were one logical big file. The syntax is pretty simple:

mkvmerge -o out.mkv ( file1.ts file2.ts file3.ts )

However, this cannot be used from mmg yet as mmg's "append" function still only does this:

mkvmerge -o out.mkv file1.ts + file2.ts + file3.ts

Both are valid options for different scenarios. The "( file1 file2 ... )" syntax is meant to be used with files that are just different parts of one huge file, meaning that the single parts, concatenated binarily (think of DOS's "copy /b" or Linux' "cat file1 file2 > hugefile"), would be a valid file.

The "old" method "file1 + file2" is used if each file has its own set of file headers and control structures, e.g. AVIs, MP4 files, Matroska files etc.

I will add the required parts to mmg sometime, but that will most likely not occur before the holidays (maybe not even before end of January judging from my calendar), and I didn't want to delay this release any further.

I also haven't found the time to document it yet. I wanted to before the release, but... well...

[Chumbo]

Hmm, that's mmg escaping the command line wrongly on Windows then. Unfortunately cmd.exe totally sucks when it comes to command line parsing (try entering path names with spaces and quotes in it), so not every command line produced by mmg will be useable in cmd.exe. That's why there are option files. If in doubt use one (mmg always does).

See http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.option_order and search for "option file".
Honestly, I've had no issues other than the one I just reported regarding creating the path. The only issue is inconvenience in that I have to use a separate variable to hold those paths that contain the double slashes. Although, I'm trying to move away from command-line scripting to WSH but just not had the time.

[Chetwood]

Playing sound in a cross-platform way would require yet even more libraries to use, not something I'm willing to do for tiny functionality gains.
I wasn't talking about cross-platform but mmg.exe ;)

Seriously, I guessed as much however I'd hoped that at least having the computer make a beep sound using the internal speaker would be equally doable on all systems.

[Mosu]

Everything about mkvtoolnix has to be cross-platofmr.

Even accessing the speaker in a cross-platform compatible way is not trivial, I guess. Also: the speaker is the most annoying sound-making device in computer history :)

Still no, sorry.

[Superb]

void wxBell()
Ring the system bell.

Include files:
<wx/utils.h>
Wouldn't that work...? or wxSound?

[Mosu]

Sure. Will you also provide the patch that implements a checkbox-backed option in mmg so that users can turn it on&off?

[sneaker_ger]

And make "off" the default, please.
Always falling off my chair after re-installing imgburn or eac3to...

[Chetwood]

Of course you're right about the PC speaker. However, some tool back in the day used it in a way that it only made a short, low 'thud' sound which wasn't annoying. Well, maybe someone else will provide a patch cause I sure as hell ain't a programmer...

[hello_hello]

Suggestion: Please add a "Minimize to System Tray" feature, that can be activated by clicking on Minimize or Close buttons.

Personally I don't mind if software doesn't have that functionality (in fact sometimes it'd be better) as I prefer to control it myself.

For XP there's TrayIt! (http://www.teamcti.com/trayit/trayit.htm) or for more functionality or newer versions of Windows there's something like PMW (http://www.snapfiles.com/get/processmanagerwin.html).

Or try a Google search for system tray managers or something similar.

PS TrayIt has an option labelled "disable quick minimise" which for some inexplicable reason is, I think, checked by default. If you uncheck it you can minimise any application to the tray simply by right clicking on it's close button.

[roozhou]

Hi Mosu,

Two questions:

1) Is it possible to build win32 binary on Windows, using either MSVC or GCC?
2) Why do all .exe files in mkvtoolnix have an export table? They are all exporting ~100 functions of names starting with libssh2, e.g. libssh2_channel_close.

[Mosu]

Hi Mosu,

Two questions:

1) Is it possible to build win32 binary on Windows, using either MSVC or GCC?

Yes, it is possible albeit not easy. One of my translators usually builds with mingw gcc on Windows (not with a cross-compiler on Linux as I do).

A couple of versions ago it was definitely possible to build with MSVC, and other interested users contributed project files to that effect. However, they have neither been updated nor tested in the weeks since. However, as v5.1.0 requires certain C++11 features I'm actually not sure whether or not MSVC supports them already.

So "yes" for gcc, "I don't know but unlikely out of the box" for "MSVC".

2) Why do all .exe files in mkvtoolnix have an export table? They are all exporting ~100 functions of names starting with libssh2, e.g. libssh2_channel_close.

No idea.

[roozhou]

Yes, it is possible albeit not easy. One of my translators usually builds with mingw gcc on Windows (not with a cross-compiler on Linux as I do).

A couple of versions ago it was definitely possible to build with MSVC, and other interested users contributed project files to that effect. However, they have neither been updated nor tested in the weeks since. However, as v5.1.0 requires certain C++11 features I'm actually not sure whether or not MSVC supports them already.

So "yes" for gcc, "I don't know but unlikely out of the box" for "MSVC".

Thanks, I will have a try.


No idea.
The export table should only exists on DLLs. It is likely all EXEs are linking to libssh2 and libssh2 is built as a DLL-like library, which is built as a static library, but with all functions still marked 'export'. So all libssh2 functions, no matter used or not, are linked and exported, making the EXEs very big.

[Mosu]

The export table should only exists on DLLs. It is likely all EXEs are linking to libssh2 and libssh2 is built as a DLL-like library, which is built as a static library, but with all functions still marked 'export'. So all libssh2 functions, no matter used or not, are linked and exported, making the EXEs very big.

Thanks for the insight. I'll dig into this further (meaning I now know where and what to ask).

[vmrsss]

Hi Mosu,

I find the following with 5.1.0: it immediately crashes with this error, whatever the input.

mkvmerge(13149) malloc: *** error for object 0x7fff722e6860: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

Can you please check?

[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.

[LeMoi]

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.

OK, indeed, if I remux the file with the needed font again, it now works. Have to remux all the corrupted files :s

[monohouse]

-----

[sneaker_ger]

PGS subtitles have been supported for quite some time now. Describe your problem more specifically, i.e. what kind of input file are you using and which mkvmerge version? You might want to upload a sample if you think it is a bug.

[monohouse]

-----

[hubblec4]

version 5.2.0, input files are .sup files
http://manoa.flnet.org/00000.track_4608.7z
the mux process completes but when the new file is opened with mmg these .sup tracks are gone

for me works this file perfect :-)

[monohouse]

-----

[hubblec4]

i have only insert the sup-file and generated a mks-file. the mks-file put into a new mmg.
and it works.

i dont understand the file-input. all sup-files shown as video, why is that so?

(you select a fps at the sup-files, but it doesnt goes normaly)

[monohouse]

-----

[Mosu]

A hint for everyone using old .mmg files with 5.2.0 and newer. In 5.2.0 I changed the way several input modules have their track IDs assigned. This was necessary in order to fix a bug (see https://www.bunkus.org/bugzilla/show_bug.cgi?id=681 ). Unfortunately I forgot to change mmg not to load .mmg files created with older versions as they're now incompatible as they contain wrong track IDs.

[mbcd]

Yes, I even have problems merging two mkv-files together.
Merging is here !! NOT !! meant as appending two files together.

Thats because in both there are same IDs, and because of that I get an result with no video (because both mkv have video on track 1 and track 1 is ignored because both mkv have one).

I use CLI for merging!

[Mosu]

That is a problem most likely due to wrong usage. Post your command line here.

[Chumbo]

@mosu,
I don't know if I ever got back to you or not on the double backslashes or not. I did finally get around to testing it with a normal path with just one slash and it works great. :) Note that the UI still copies the command line with the double/escaped backslashes, e.g.,"d:\Program Files (x86)\MKVtoolnix\mkvmerge.exe" -o "E:\\media\\MKV\\EditedSample (1).mkv"
"--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1280x720" "--compression" "0:none"
"--language" "1:eng" "--default-track" "1:yes" "--forced-track" "1:no" "--compression" "1:none" "-a" "1" "-d" "0" "-S" "-T"
"--no-global-tags" "--no-chapters" "E:\\media\\MKV\\EditedSample.mkv"
"--track-order" "0:0,0:1"

I also noticed that if you copy to the clipboard and then exit the UI BEFORE pasting the UI clears the clipboard contents. Would be nice if it didn't do that.

[Mosu]

Note that the UI still copies the command line with the double/escaped backslashes

The "copy to clipboard" function is more useful for Linux users. The problem on Windows is cmd.exe's horrible/almost non-existent escaping rules. Read http://stackoverflow.com/a/623202 for a very nice description of the issue(s).

I also noticed that if you copy to the clipboard and then exit the UI BEFORE pasting the UI clears the clipboard contents. Would be nice if it didn't do that.

That's up to wxWidgets, I guess, and I'm not really keen to look into it. Sorry. If someone else provided a patch I wouldn't refuse it, of course.

[Atak_Snajpera]

There is something I don't understand with 5.2.0
mkvinfo report
File 'E:\_Video_Samples\mkv\[AniYoshi]_Kimi_ga_Aruji_de_Shitsuji_ga_Ore_de_-_01_[859986ED].mkv': container: Matroska [title:Kimiaru\s~They\sAre\sMy\sNoble\sMasters~\s-\s01\s-\sYou're\sthe\sMaster\sand\sI'm\sthe\sButler duration:1468437000000]
Track ID 0: video (V_MPEG4/ISO/AVC) [language:jpn track_name:Video\s(H.264) display_dimensions:704x400 default_track:1 forced_track:0 packetizer:mpeg4_p10_video default_duration:41708375]
Track ID 1: audio (A_VORBIS) [language:jpn track_name:Japanese\sAudio\s(2ch\sVorbis) default_track:1 forced_track:0 audio_sampling_frequency:48000 audio_channels:2]
Track ID 2: subtitles (S_TEXT/ASS) [language:eng track_name:English\sSubtitles\s(ASS) default_track:1 forced_track:0]
Attachment ID 1: type 'application/x-truetype-font', size 97284 bytes, file name 'BRLNSR.TTF'
Chapters: 5 entries


but when I demux with this command
"mkvextract.exe" tracks "E:\_Video_Samples\mkv\[AniYoshi]_Kimi_ga_Aruji_de_Shitsuji_ga_Ore_de_-_01_[859986ED].mkv" 1:"C:\Temp\RipBot264temp\job2\1_audio_Japanese.ogg" 2:"C:\Temp\RipBot264temp\job2\2_subtitles_English.ass"

I get video (AVC) in 1_audio_Japanese.ogg instead of audio file.

[Mosu]

See https://www.bunkus.org/bugzilla/show_bug.cgi?id=689

Yes, this has already been discussed on this very page.

[Atak_Snajpera]

where can i find fixed 5.2.0 version?

[Mosu]

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

[Atak_Snajpera]

thnaks!

[mbcd]

Yes, I even have problems merging two mkv-files together.
Merging is here !! NOT !! meant as appending two files together.

Thats because in both there are same IDs, and because of that I get an result with no video (because both mkv have video on track 1 and track 1 is ignored because both mkv have one).

I use CLI for merging!

"C:\Program Files (x86)\MKVtoolnix\mkvmerge.exe" -o "%path%%filmname%.mkv" "--language" "1:und" "--default-track" "1:yes" "--forced-track" "1:no" "--compression" "1:none" "-d" "1" "-A" "-S" "-T" "--no-global-tags" "--no-chapters" "%path%%filmname%\%filmname%.h264.mkv" "-D" "%path%%filmname%\%filmname%.mkv" "--track-order" "0:1,1:1"

This worked with 5.1.0 over hundreds of times ...

Info:
The first file loaded (...h.264.mkv) has ONLY a Videotrack
The last file hast Video, Audio and Subtitles, but video is not needed from this track (replaced by first file)

[Mosu]

The way track IDs are assigned in Matroska and MP4 files has changed in v5.2.0. Use mkvmerge's identification mode in order to find out the actual track IDs. This has ALSO been discussed on this page and the one before.

[mindbomb]

Small comment, not really an issue.

When importing an mkv muxed with haali's muxer, and muxing that into an mkv with mkvmerge, the resulting line is present in the mediainfo for h264 video:
Muxing mode : Container profile=Unknown@0.0

[Mosu]

I'm really not sure what you're trying to say or why you think it important/remarkable.

[nekrovski]

Mosu, could you take a look at this please

http://forum.doom9.org/showthread.php?t=163687

[Mosu]

I'm not willing to help you, sorry. I don't have time (nor the expertise) for video encoding questions anymore.

mkvmerge can only split on key frame boundaries. That's by design and will not change.

[nekrovski]

Alright.

[Mosu]

Hey,

I've released mkvtoolnix v5.2.1. It corrects a nasty inconsistency regarding track IDs between mkvmerge and mkvextract, improves performance on Linux quite a bit by not caching data twice and fixes a few smaller issues here and there.

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

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

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

Here's the full ChangeLog since release 5.2.0:


2012-01-02 Moritz Bunkus <moritz@bunkus.org>
* Released v5.2.1.

2011-12-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed certain DTS files being mis-detected as AC3. Fix for bug 693 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=693).

2011-12-28 Moritz Bunkus <moritz@bunkus.org>
* build system: Added an option "--without-gettext" that allows for building without support for translations even if gettext itself is installed.
* build system: Added an option "--without-curl" that allows for building without CURL support even if CURL itself is installed.
* all: bug fix: Fixed compilation if gettext/libintl is not available.
* mkvmerge: bug fix: The MPEG program stream reader was reporting wrong progress percentage if multiple files were used since v5.1.0.

2011-12-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Removed the posix_fadvise() code. The application is using its own caching code which caused bad performance if the OS caching provided via posix_fadvise() is used as well.

2011-12-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: If an MP4 file contains chapters encoded in a different charset than UTF-8 and --chapter-charset is not used then the error message shown is a lot clearer why mkvmerge aborts muxing. Before the error message was a generic "mm_text_io_c::read_next_char(): invalid UTF-8 character. The first byte:..."
* mkvmerge: bug fix: MPEG program streams in which a track suddenly ends and others continue or in which a track has huge gaps will no longer cause mkvmerge to try to read the whole file at once. This could lead to excessive swapping and finally mkvmerge crashing if no more memory was available.

2011-12-24 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The track IDs used for extraction are consistent again with the IDs that mkvmerge's identification reports. Fix for bug 689 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=689).

2011-12-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fix compilation if FLAC is not available. Fix for issue #13.

Have fun.

[Snowknight26]

Is the Windows installer supposed to say 2011-12-03 in brackets?

[Mosu]

No, it's not. Thanks for noticing. It was just the installer script that accidentally had a pre-build version number included since the start of December. New builds are uploading.

[b66pak]

thanks a lot...
_

[Boulder]

Hey,

I've released mkvtoolnix v5.2.1. It corrects a nasty inconsistency regarding track IDs between mkvmerge and mkvextract, improves performance on Linux quite a bit by not caching data twice and fixes a few smaller issues here and there
It seems that MKVExtractGUI-2.2.2.5 doesn't show correct tracks with this version so is there any other recommended GUI to use?

[soneca]

I hope MKVExtractGui also be updated to work with this new version.

[Mosu]

Guys, posting here about mkvextragui or mkvcleaver will most likely not help you. I'm the author of neither program, and neither author of those programs reads this thread as far as I know. Contact the authors directly. No, I don't know how.

[Boulder]

No problem..I was only asking if there is some other recommended GUI to use. Nevertheless, I reported the issue at the SF tracker so we'll see if we get an update at some point.

[Selur]

Got a question regarding:
mkvextract: bug fix: The track IDs used for extraction are consistent again with the IDs that mkvmerge's identification reports.
Did you fix this like you wanted?

using: mkvmerge v5.1.0 ('And so it goes') built on Nov 28 2011 23:58:28
mkvmerge.exe -i h:\Banana.mkv
gives:
File 'h:\Banana.mkv': container: Matroska
Track ID 1: video (V_MPEG4/ISO/AVC)
Track ID 2: audio (A_DTS)
Track ID 3: subtitles (S_TEXT/UTF8)
Track ID 4: subtitles (S_TEXT/UTF8)
Track ID 5: subtitles (S_TEXT/UTF8)
Track IDs reported match with the track IDs reported by MPlayer and extraction with mkvextract using this IDs works fine. (the right track is properly extracted)

using: mkvmerge v5.2.0 ('I can't explain') built on Dec 18 2011 18:12:03
mkvmerge.exe -i h:\Banana.mkv
gives:
File 'h:\Banana.mkv': container: Matroska
Track ID 0: video (V_MPEG4/ISO/AVC)
Track ID 1: audio (A_DTS)
Track ID 2: subtitles (S_TEXT/UTF8)
Track ID 3: subtitles (S_TEXT/UTF8)
Track ID 4: subtitles (S_TEXT/UTF8)
Track IDs reported do not match with the track IDs reported by MPlayer but extraction with mkvextract using the IDs reported with MPlayer works fine. (the right track is properly extracted)

using: mkvmerge v5.2.1 ('A Far Off Place') built on Jan 2 2012 23:21:10
mkvmerge.exe -i h:\Banana.mkv
gives:
File 'h:\Banana.mkv': container: Matroska
Track ID 0: video (V_MPEG4/ISO/AVC)
Track ID 1: audio (A_DTS)
Track ID 2: subtitles (S_TEXT/UTF8)
Track ID 3: subtitles (S_TEXT/UTF8)
Track ID 4: subtitles (S_TEXT/UTF8)
Track IDs reported do not match with the track IDs reported by MPlayer and extraction with mkvextract using the IDs reported with MPlayer does not work only using the IDs that are now reported by mkvmerge fine.

here's how the tracks are reported by MPlayer
using: mplayer -v -identify -demuxer mkv -vo null -ao null -frames 0 "H:\Banana.mkv"
[mkv] Found the head...
[mkv] + a segment...
[mkv] /---- [ parsing seek head ] ---------
[mkv] /---- [ parsing cues ] -----------
[mkv] \---- [ parsing cues ] -----------
[mkv] \---- [ parsing seek head ] ---------
[mkv] |+ segment information...
[mkv] | + timecode scale: 1000000
[mkv] | + duration: 225.270s
[mkv] |+ segment tracks...
[mkv] | + a track...
[mkv] | + Track number: 1
[mkv] | + Track type: Video
[mkv] | + Codec ID: V_MPEG4/ISO/AVC
[mkv] | + CodecPrivate, length 42
[mkv] | + Default duration: 41.708ms ( = 23.976 fps)
[mkv] | + Name: Banana
[mkv] | + Video track
[mkv] | + Pixel width: 1280
[mkv] | + Pixel height: 720
[mkv] | + Display width: 1280
[mkv] | + Display height: 720
[mkv] | + a track...
[mkv] | + Track number: 2
[mkv] | + Track type: Audio
[mkv] | + Codec ID: A_DTS
[mkv] | + Name: DTS 5.1 @ 768 kbps
[mkv] | + Audio track
[mkv] | + Sampling frequency: 48000.000000
[mkv] | + Channels: 6
[mkv] | + a track...
[mkv] | + Track number: 3
[mkv] | + Track type: Subtitle
[mkv] | + Default flag: 0
[mkv] | + Codec ID: S_TEXT/UTF8
[mkv] | + a track...
[mkv] | + Track number: 4
[mkv] | + Track type: Subtitle
[mkv] | + Default flag: 0
[mkv] | + Codec ID: S_TEXT/UTF8
[mkv] | + Language: fre
[mkv] | + a track...
[mkv] | + Track number: 5
[mkv] | + Track type: Subtitle
[mkv] | + Default flag: 0
[mkv] | + Codec ID: S_TEXT/UTF8
[mkv] | + Language: spa
[mkv] |+ found cluster, headers are parsed completely :)

=> Watching these changes I wonder if this was fixed as it was intended. (if so I will fix my code to lower the IDs I get with MPlayer by one to adjust the changes,... + some I'll have to add additional code to check which mkvmerge&extract versions are used,...)

Cu Selur

[Mosu]

The Matroska files do not contain track IDs. They contain track numbers and track UIDs. The latter are supposed to be random. The former are the once that used to coincide to how mkvmerge assigns its own track IDs. However, neither of those two header elements are the ones that mkvmerge and mkvextract use.

My bug fix restored the intended behavior that the IDs reported by "mkvmerge -i in.mkv" are the same that both "mkvmerge -o out.mkv in.mkv" and "mkvextract ... in.mkv" use. That was always my promise: mkvmerge reports IDs that can be used by other tools (e.g. my own mmg or external GUIs like MKVcleaver).

I don't care what other third party reports as the ID. No, mkvinfo's output is not a good source for those IDs either.

The idea has always been "spawn mkvmerge once and query the track IDs" followed by "use those track IDs with mkvmerge or mkvextract". I'm kind of curious why you don't do that and try to use mplayer's output instead.

[Selur]

I'm kind of curious why you don't do that and try to use mplayer's output instead.
Simple, I do a MPlayer analysis because:
1. I use the VIDs, AIDs, SIDs to preview different stream combinations (with mplayer)
2. it's output is more informative than the one from -i using mkvmerge
3. the IDs MPlayer shows (and mkvmerge showed including 5.1.0) match the IDs that mediaInfo uses, which allows me to get even more info about the streams

btw. why did you change the IDs in the first place?

Cu Selur

[Mosu]

"mkvmerge --identify-verbose" outputs more than simply "mkvmerge -i". And I don't guarantee that mkvmerge will not change how it assigns track IDs in the future. I only guarantee that I will always (do my best to) keep "mkvmerge -i" in sync with itself and mkvextract. Just as a fair warning.

[Selur]

"mkvmerge --identify-verbose" outputs more than simply "mkvmerge -i".
But since I still need the IDs MPlayer uses for preview I will still need the mplayer pass,...
+ is there a complete list of the cli switches mkvmerge supports somewhere? (didn't know of "--identify-verbose" since it's not listed in the -h output)

I only guarantee that I will always (do my best to) keep "mkvmerge -i" in sync with itself and mkvextract. Just as a fair warning.
if it gets to wild I'll probably start a mkvmergeMod and a mkvextractMod to keep the IDs in synch with other tools,... ;)

Cu Selur

[Mosu]

I don't expect them to change again soon, but... well... you never know what bugs still lurk inside my code ;)

[Chumbo]

No problem..I was only asking if there is some other recommended GUI to use. Nevertheless, I reported the issue at the SF tracker so we'll see if we get an update at some point.
In the meanwhile, you can use tsmuxer to demux any supported tracks/streams you need.

[kassiesa]

In the meanwhile, you can use tsmuxer to demux any supported tracks/streams you need.

tsmuxer: Unsupported format. Some tracks not recognized. This tracks was ignored.

Error appears for DTS tracks.

[Mosu]

You could also learn to use mkvextract from the command line. It's not that hard.

[Boulder]

It's not hard, I'm used to command lines at home and work, but it's a pain in the butt as I have a lot of files to process. I'm going through my video archive to re-encode the AC3/DTS/etc. tracks to put them on my networked media tank using a different audio format (AAC).

[DragonQ]

End users having to do anything in the command line in 2012 bewilders me. Should be totally unnecessary. I know this is a "power user" program (and a great one at that) but still, GUIs are so much easier to use.

In theory, this'd be fixed pretty quickly. However, AFAIK, none of the three main GUIs (MKVExtract GUI, MKVExtractGUI-2, MKV Cleaver) have been updated in ages (years even)!

[sneaker_ger]

It's not hard, I'm used to command lines at home and work, but it's a pain in the butt as I have a lot of files to process. I'm going through my video archive to re-encode the AC3/DTS/etc. tracks to put them on my networked media tank using a different audio format (AAC).

As a tip: eac3to makes it unnecessary to demux the audio tracks, as it can work directly on mkv files.

[Chumbo]

@Boulder,
You can process many files by using a for loop. Just open a command window and type "for /?" to get the syntax. You can also Google for more clarification and examples. Once you set up your batch/command file to do what you want, it just requires minimal after that. If you're more comfortable with a language like Visual Basic, you can always use Windows Host Scripting. Whatever tool you decide to use, if it has a CLI then you're good to go. :)

Here's an example for you that uses the MediaInfo CLI to display and log some basic info about, in this case, TS files found in the folder where this file is executed:@echo off
setlocal EnableDelayedExpansion
set SEARCH=*.ts
set LOGFILE=MEDIAINFO.LOG.TXT
set vformat=
set vscantype=
set vscanorder=
set vfps=
if exist "%logfile%" del "%logfile%"
for /f "delims=" %%i in ('dir /b "%SEARCH%"') do (
set vformat=
set vscantype=
set vscanorder=
set vfps=
echo PROCESSING %%i
echo PROCESSING %%i >> %LOGFILE%
rem GET video format
for /f "delims=" %%f in ('mediainfo --Inform^=Video^;%%Format%% "%%i"') do (
set vformat=%%f
)
for /f "delims=" %%s in ('mediainfo --Inform^=Video^;%%ScanType%% "%%i"') do (
set vscantype=%%s
)
for /f "delims=" %%s in ('mediainfo --Inform^=Video^;%%ScanOrder%% "%%i"') do (
set vscanorder=%%s
)
for /f "delims=" %%f in ('mediainfo --Inform^=Video^;%%FrameRate%% "%%i"') do (
set vfps=%%f
)
echo Format: !vformat!, Scan Type: !vscantype!, Scan Order: !vscanorder!, FPS: !vfps!
echo Format: !vformat!, Scan Type: !vscantype!, Scan Order: !vscanorder!, FPS: !vfps! >> %LOGFILE%
)
:end
endlocal

[Boulder]

Thanks, I may not need it for this particular job but I got something else that such approach would benefit :)

[Mosu]

Good news, everyone! The author of MKVExtractGUI2 has just posted on my bug tracker that he's updated his GUI:

Hi, folks.

Fixed my GUI, download newest from
http://sourceforge.net/projects/mkvextractgui-2/

Sorry for the overdue update, i still use mkvtoolnix 3.4 :)

[Boulder]

Hey, that's very nice indeed :)

[DragonQ]

Good news, everyone! The author of MKVExtractGUI2 has just posted on my bug tracker that he's updated his GUI:
Doesn't work for me. Extracting the second track (audio) works fine but extracting the first one (video) gives me this when using mkvtoolnix 5.2.1:

http://i43.tinypic.com/s6onle.png

(Note that my renaming of the exe isn't the issue; it happens with its default name too.)

[Sparktank]

Good news, everyone! The author of MKVExtractGUI2 has just posted on my bug tracker that he's updated his GUI:

That's wonderful news! :D
I was holding off on doing anything until there was news of anything updating.

I figured it would be a week or so lol.

Thanks for the info.

[Mosu]

Doesn't work for me. Extracting the second track (audio) works fine but extracting the first one (video) gives me this when using mkvtoolnix 5.2.1:

http://i43.tinypic.com/s6onle.png

(Note that my renaming of the exe isn't the issue; it happens with its default name too.)

Don't post this HERE. The author doesn't read the thread. And I don't support any of the mkvextract GUIs as they're not my products.

[Selur]

Got a small (?) feature request for mkvmerge&mkvextract: add the possibility to cut 'from-to' where from and to can be times or chapters.

It's a bit like the splitting by timecodes option.
When using mkvmerge to split by timecodes and feeding it with something like 01:20:10.000,01:23:12.400 I would end up with 3 files (middle one is the one I want) since mkvmerge would create one from 00:00:00.000 to 00:20:10.000, one from 00:20:10.000 to 01:23:12.400 (start chapter 11) and one that goes from 01:23:12.400 (start chapter 12) to the end of the clip.
I know I could abort mkvmerge after the file I want is created (to avoid the last file to be created), but the first file will still be created, which is a pain if the source file is long&large,...

Cu Selur

[Mosu]

Yeah yeah, has often been requested, will be implemented sometime this decade. Implementing stuff like that is a pain, too.

[Selur]

No hurry, I just stumbled over this scenario a few times in the last few days.
(will probably request it again, when enough time has elapsed and I run into the scenario again :))

Cu Selur

[Mosu]

:)

There's also a bug report for such a feature request already: https://www.bunkus.org/bugzilla/show_bug.cgi?id=518

[Selur]

Oh, didn't know that. I didn't look in the bugzilla since it's not really a bug but more a missing feature in my eyes. ;)

[Mosu]

Oh it certainly is, but I also use Bugzilla for tracking feature requests.

[Selur]

Ah, okay, good to know for the future. :)

Cu Selur

[Selur]

Just wondering,.. If I have a bunch of mkv files with multiple audio and video streams in them, and I want to check if one or more of these streams was 'streched' to be synch, how do I do that? (ideally get the strech factor)
Is there some indication, about the streching in a mediainfo, mkvmerge, mkvinfo output I overlook atm., or is the only may to extract, remux and see which streams are asynch after the remux?
(another way maybe to extract the time codes for each track and compare them,..)

Cu Selur

[HeartWare2]

The Matroska files do not contain track IDs. They contain track numbers and track UIDs.

Would it be possible to update both MkvMerge and MkvInfo so that they both display this UID for each track, thus making it possible for external programs to synchronize the output from these two programs?

[Mosu]

Just wondering,.. If I have a bunch of mkv files with multiple audio and video streams in them, and I want to check if one or more of these streams was 'streched' to be synch, how do I do that? (ideally get the strech factor)

A stretch factor is applied directly to the timecodes before they're output. It is not stored separately somewhere. As stretching could really be applied to any track (a lot of people try to apply it to audio tracks even though this often does not render good results upon playback) it would be rather difficult to guess that factor automatically somehow.

[Mosu]

Would it be possible to update both MkvMerge and MkvInfo so that they both display this UID for each track, thus making it possible for external programs to synchronize the output from these two programs?

mkvinfo already does that. I'll update mkvmerge accordingly for its verbose identification mode.

Which piece(s) of information from mkvinfo do you need that mkvmerge's verbose identification mode doesn't provide? I'll most likely add those to mkvmerge as well so that people will not have to parse two program's outputs and correlate them.

[Selur]

A stretch factor is applied directly to the timecodes before they're output. It is not stored separately somewhere. As stretching could really be applied to any track (a lot of people try to apply it to audio tracks even though this often does not render good results upon playback) it would be rather difficult to guess that factor automatically somehow.
Okay, so if I for example have a video stream that is 25fps.
and two audio streams with timecodes like:
for the first track:
# timecode format v2
0
40
80
120
160
200
240
280
and for the second track:
# timecode format v2
5
37
69
101
133
165
197
229
261
293
since the first time codes match my frame rate (25fps -> 40ms per Frame) and the second stream timecodes do not I conclude that the second stream is 'stretched'.

But you are right, guessing the stretch factor is problematic,... :/

Okay, so the best thing I can to is automatically detect if a stream is stretched.
(Which should be when ever the timecodes of the audiostreams to not match the timecodes of the videostream and do not use steps that match 1000/(average video frame rate).)

-> reencoding or remuxing such clips is a real pain :/

Cu Selur

Ps: I suspect it might be possible to 'guess' an approximate stretch factor by comparing the original file length with the length of the extracted audio stream,..

[sneaker_ger]

Timecodes of different tracks don't match each other, audio tracks have their own frame sizes (like 32 ms for ac3 for example). You could just read the last timecode (and any delay) and guess if it has been stretched for formats with constant frame sizes. But if the audio has gaps even that wouldn't always work, though probably mostly it will.

[Mosu]

What sneaker_ger said. Audio timecodes depend on the number of samples per audio packet (which in turn has nothing to do with video frames). For AC3 and AAC it's simple as there are always 1536 (AC3) and 1024 (AAC) samples per packet. For other formats it's way more complicated: ranging from "it depends on the layer, the version and the sampling frequency" (MP3) to "it depends on the headers and actually changes in every packet" (Vorbis with its sliding window approach).

Add to that that timecodes are usually rounded to ms precision in a Matroska file (they can have way higher precision but for mixed audio/video content no one actually bothers to use higher precision) and you end up with a task that is at best difficult and imprecise and completely garbage at worst.

[Selur]

Okay, so extracting all audio streams and comparing the original files playtime with the extracted audio stream file size is the only kind of working way,.. :/

[sneaker_ger]

File size? For CBR maybe, but looking at the last (and first for delay) timecode seems more straight forward.

[HeartWare2]

mkvinfo already does that. I'll update mkvmerge accordingly for its verbose identification mode.

Thank you...

Which piece(s) of information from mkvinfo do you need that mkvmerge's verbose identification mode doesn't provide?

Display Resolution (or if it already provides that, then Physical Resolution) so that a Display Aspect Ratio can be calculated.

Duration (runtime) of file (not tracks) in hh:mm:ss.nnn format.

FPS of video track.

SBR/LC of audio tracks (may be encoded in the CODEC value, if you use same CODEC values as MKV Info).

The amount of time (if any) of delay of the track (isn't provided by MKV Info at the moment, but if you are updating MKV Merge to display more info, this one would be appreciated).

The resolution of PBS/VOBSUB subtitles (again, an addition that would be nice to have).

Offset of attachments within the file.

Chapter information (chapter position, language and name at least).

Those are what springs to mind right off the top of my head.:D

[Mosu]

Display Resolution (or if it already provides that, then Physical Resolution) so that a Display Aspect Ratio can be calculated.

Pixel width/height has been added a few days ago already.

Duration (runtime) of file (not tracks) in hh:mm:ss.nnn format.

Will do, but all numbers will be unformatted.

FPS of video track.

Track headers don't have FPS information as Matroska doesn't store that. There's only the "default duration" and that is already output.

SBR/LC of audio tracks (may be encoded in the CODEC value, if you use same CODEC values as MKV Info).

What do you mean with "CODEC value"? Codec ID, Codec Private? "SBR/LC" is not stored in the headers. Codec Private content will not be included in the output either.

The amount of time (if any) of delay of the track (isn't provided by MKV Info at the moment, but if you are updating MKV Merge to display more info, this one would be appreciated).

The resolution of PBS/VOBSUB subtitles (again, an addition that would be nice to have).

Such information is not stored in Matroska's headers and cannot be output.

Offset of attachments within the file.

Chapter information (chapter position, language and name at least).

Attachment position is possible, though I honestly don't know why you'd need it.

Chapter information will not be included in mkvmerge's output as they can be nested etc. For that you'll still need mkvextract/mkvinfo.

[HeartWare2]

What do you mean with "CODEC value"? Codec ID, Codec Private?

Codec ID (I think). The one with "A_AAC/SBR". At the moment, MkvInfo outputs the above value (or something very much like it - I don't have a sample file at hand right now), and my PopCorn MKV AudioConverter (http://www.networkedmediatank.com/showthread.php?tid=20887) needs this information in order to know if the audio track needs to be converted (normal, stereo AAC audio tracks needn't be converted, but SBR or LC audio tracks may need to).

[Mosu]

A_AAC/SBR is an old format for AAC. Newer files use A_AAC whether the AAC data is SBR or not. You cannot base a decision on it.

I'll add the CodecID to the output though.

[HeartWare2]

Such information (delay) is not stored in Matroska's headers and cannot be output.

How about outputting the time stamp for the first sample of a given track? Wouldn't that amount to the delay value you get when you execute MkvInfo(?) with v2_timecodes (or whatever it's called)? At the moment, I need to use the aforementioned option, even though I only need the time stamp for the very first line, and it may take a very long time to process a 13 Gb file over a 100 Mbit network, so if a quick way to get the delay for a track would be appreciated.

I need it to be able to apply the same delay as the original track has, when I ReMux the converted audio track back into the .MKV file.

[HeartWare2]

A_AAC/SBR is an old format for AAC. Newer files use A_AAC whether the AAC data is SBR or not. You cannot base a decision on it.

Rats!:sly:

Any other way to detect if an AAC audio track is SBR or not, then?

[Mosu]

Oh and here's the ChangeLog entry from back when that change was implemented (and for good reason!):

2006-11-10 Moritz Bunkus <moritz@bunkus.org>

* Released v1.8.0.

* mkvmerge: Changed the CodecID for AAC audio tracks to "A_AAC" by
default. The CodecPrivate contains the same initialization data
that are stored in the ESDS in MP4 files for AAC tracks. The old
CodecIDs (e.g. "A_AAC/MPEG4/SBR") can be turned on again with
"--engage old_aac_codecid".

[Mosu]

If CodecPrivate is 5 bytes long or longer then it uses SBR. If it's only 2 bytes then it doesn't.

[Mosu]

How about outputting the time stamp for the first sample of a given track?

No, sorry. That would in general require way more time to process the file than I want mkvmerge to take (think of e.g. subtitle tracks with very, very few entries in between). Your case is special, and you will most likely still have to run mkvinfo on the source file for that.

I don't want to make mkvmerge slow for 100% of all users when only 1% or fewer would actually need such an option.

[Mosu]

Here's a build with three more fields in file identification mode: UID, CodecID (even though that's now duplicate information in the line), codec private data size and content (the latter as a hex dump).

As for the other stuff you've requested:

File duration has already been present in the container line.

I will not add attachment offsets within the file. This leads to reading/writing directly in the file and I don't want to make this easy. Use mkvextract if you need access to the attachments (or continue parsing mkvinfo's output if you insist on fiddling around in the internals of a Matroska file).

The codec private data can be used for AAC in order to find out what kind of AAC it is. For code how to parse such data look at e.g. the "parse_aac_data()" function in https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/aac.cpp

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.2.1-build20120107-397-setup.exe

[Selur]

File duration has already been present in the container line.
Would it be possible to include the stream duration (due to the 'stretch' option, the extracted stream duration can differ from the file duration)?
And/Or is there a way to calculate the raw/demuxed length of an audio stream inside a mkv container without extracting the stream?

Cu Selur

[Mosu]

A track's duration is not stored in the track headers, hence mkvmerge cannot display it.

And I assume that by "without extracting the stream" you also mean "without running mkvinfo on the whole file and parse its output".

[Selur]

I'm willed to run mkvinfo with:
mkvinfo -v "Path to file" (or what ever is necessary)
if you can point me in the direction how to calculate the raw stream length from that. :)

[Mosu]

How about "Track duration = last timecode + duration of last packet - first timecode"?

[Lincoln Burrows]

I am having a problem with MKVExtractGUI here. I have downloaded the last version, 2.2.2.7, and tried to extract a subtitle from a Matroska file converted from a DVD. It failed, since ended right after started, generating no file. The same issue is happening with other MKV files from the bonus material.

I should add that all (yellow) subtitles can be displayed with no issues in Media Player Classic.

When I use MKVToolnix to save the MKV file, by removing all streams and only letting the subtitle, it saves using .mks extension. If I add this file into another MKV, it will report this error:
* Warning: matroska_reader: Could not keep the track UID 3 because it is already allocated for the new file.

The subtitle format is S_VOBSUB. And I never had this problem before. Maybe there's something special about this one?

P.S. I checked the new MKV, and despite this warning *, the subtitle from the mks file was inserted. However, if we need to edit the subtitle, it would be necessary to extract into idx/sub. SubResync is one example of software that can easily do this task.

And I was able to extract this subtitle from the new MKV, but only one IDX file was generated, not IDX/SUB. SubResync is not working with this IDX. So I guess the subtitle is different in a way that is being rejected by MKVExtractGUI from the start.

[Mosu]

Pleae, please read the page(s) leading up to this. It has been discussed in depth.

Hint: it's a bug in mkvextract GUI. It uses the wrong track IDs.

Also: If mkvmerge says "Warning:" then it is not an error. I thought that was obvious.

[Lincoln Burrows]

Pleae, please read the page(s) leading up to this. It has been discussed in depth.

Hint: it's a bug in mkvextract GUI. It uses the wrong track IDs.

Also: If mkvmerge says "Warning:" then it is not an error. I thought that was obvious.Well, let's see. I tried another title (in the previous case I solved by inserting the "mks" files, they already had all subtitles I needed for) that has nothing to do with this one. And this is a DVD.

http://i.imgur.com/Nc56j.png

As you can see, two tracks, DD 2.0 ENG and PT, two subtitles, PT/ENG + chapters.

When attempting to extract:

1) Video = extracts a MPG file. OK
2) ENG track = extracts AC3 file. OK
3) PT audio track = extracks SUB file. FAIL.
4) PT subtile track = extracks SUB file. OK
5) EN subtile track = FAIL. Nothing happens.
6) Chapters = extracts file, OK.

And when attempting to extract all 6 combined = FAIL, nothing happens.

And I need to extract exactly 3), the PT audio track.

Any ideas?

Edit: I managed to extract this portuguese AC3 track with tsMuxerGUI. The title I have tested was The Adventures of Baron Munchausen (1988), Region 4-Brazil. Maybe this disc was decrypted by me in a different way or it was authored in a different way that prevented from working with your software. I also remember it was decrypted about 2-3 years ago.

[Selur]

@mosu: Will you also adjust mkvinfo to the TrackIDs mkvmerge&mkvextract use since 5.2.1+?

mkvinfo v5.2.1 ('A Far Off Place') built on Jan 7 2012 21:56:27
+ Segment tracks
+ A track
+ Track number: 1
+ Track UID: 3986723374
+ Track type: video
+ Forced flag: 1
+ Lacing flag: 0
+ MinCache: 1
+ Codec ID: V_MPEG4/ISO/AVC
+ CodecPrivate, length 39 (h.264 profile: High @L3.1)
+ Default duration: 40.000ms (25.000 fps for a video track)
+ Language: ger
+ Name: tvp-farscape-s01e01-720p
+ Video track
+ Pixel width: 960
+ Pixel height: 720
+ Display width: 960
+ Display height: 720
+ A track
+ Track number: 2
+ Track UID: 1274075454
+ Track type: audio
+ Forced flag: 1
+ Codec ID: A_AC3
+ Default duration: 32.000ms (31.250 fps for a video track)
+ Language: ger
+ Audio track
+ Sampling frequency: 48000
+ Channels: 6
+ A track
+ Track number: 3
+ Track UID: 2195572176
+ Track type: audio
+ Default flag: 0
+ Codec ID: A_DTS
+ Default duration: 10.667ms (93.750 fps for a video track)
+ Audio track
+ Sampling frequency: 48000
+ Channels: 6
mkvmerge v5.2.1 ('A Far Off Place') built on Jan 7 2012 21:56:27
Track ID 0: video (V_MPEG4/ISO/AVC)
Track ID 1: audio (A_AC3)
Track ID 2: audio (A_DTS)

-------------------------------------------


How about "Track duration = last timecode + duration of last packet - first timecode"?
Wouldn't that just give me the length of the stream inside the container?

1st entry for Track 3: SimpleBlock (key, track number 3, 8 frame(s), timecode 0.000s = 00:00:00.000)
-> first timecode = 0
last entry for Track 3: SimpleBlock (key, track number 3, 8 frame(s), timecode 2885.846s = 00:48:05.846)
-> last timecode = 2885.846

"duration of last packet"
is this:
a. distance between the last entry for Track 3 and the next entry in the container?
b. distance between the last entry for Track 3 and the length of the clip as a whole?
c. none of the above,.. (what?)
if I extract track 3 I get a length of 00:50:07.700. (3007.7)

Cu Selur

Ps.: Here's (http://forum.gleitz.info/attachment.php?attachmentid=97102&d=1326070663) the mkvinfo -v output for the file,..

[sneaker_ger]

@mosu: Will you also adjust mkvinfo to the TrackIDs mkvmerge&mkvextract use since 5.2.1+?

He won't. The TrackNumber (http://matroska.org/technical/specs/index.html#TrackNumber) is hard-coded into the file. This is not the same as the "TrackID"s mkvmerge and mkvextract use, those are made up and can thus be subject to change. Maybe he could also generate the "TrackID" into the mkvinfo output, in the same way that mkvmerge and mkvextract do it, if that is wanted.

How about "Track duration = last timecode + duration of last packet - first timecode"?
Wouldn't that just give me the length of the stream inside the container?

Correct.

1st entry for Track 3: SimpleBlock (key, track number 3, 8 frame(s), timecode 0.000s = 00:00:00.000)
-> first timecode = 0
last entry for Track 3: SimpleBlock (key, track number 3, 8 frame(s), timecode 2885.846s = 00:48:05.846)
-> last timecode = 2885.846

"duration of last packet"
is this:
a. distance between the last entry for Track 3 and the next entry in the container?
b. distance between the last entry for Track 3 and the length of the clip as a whole?
c. none of the above,.. (what?)

I'm also wondering about this. It's not b, I'd say. Maybe one is supposed to calculate it from the frame size, which would be format depended? For this DTS frame it would be 10.67 ms (one third of the 32ms ac3 length), but I have no idea if this info can be derived otherwise (and for sources with e.g. Vorbis).

if I extract track 3 I get a length of 00:50:07.700. (3007.7)

The "extracted length" would be [number of frames] * [frame duration] (or more precisely sum of [frame duration]s). Again, no idea how to read that for e.g. Vorbis. Maybe calculate from frame size (and bitrate, which mkvinfo does not show)?

Ps.: Here's (http://forum.gleitz.info/attachment.php?attachmentid=97102&d=1326070663) the mkvinfo -v output for the file,..

Please use "-r output.txt" instead of "> output.txt". The latter results in "[CR][CR][LF]" somehow, don't know if this is a bug in mkvinfo or not. Mosu?

It's not quite clear what exactly you want to know:
a.) Length of stream within the container(Mosu: "Track duration = last timecode + duration of last packet")(1*) or
b.) "extracted length" of the audio track (the sum of all frame durations, for streams with constant duration [number of frames]*[frame duration])

For this example:
a.) duration = 2885.928s + (0.032/3)s ~= 2885.939s = 48min5s939ms
b.) duration = 282112(2*) * (0.032/3)s ~= 3009.195 = 50min9s195ms

(1*) I left out the delay (first timecode) to simplify.
(2*) Parsed the mkvinfo output. (Hopefully correct)

Also, since only the timecodes of the frames are stretched, and not the length of the packets, there is an additional small error in calculation a. In theory you would have to calculate the stretching factor from all but the last frame. (Maybe nitpicking...)

I hope this is correct.

[Chetwood]

I am having a problem with MKVExtractGUI here. I have downloaded the last version, 2.2.2.7, and tried to extract a subtitle from a Matroska file converted from a DVD. It failed, since ended right after started, generating no file.
Same here, only it happens when extracting from MKVs ripped from Bluray with MakeMKV and when done with MKVCleaver. However, doing it manually with mkvextract works so yes, it's a GUI bug.

[Selur]

b.) "extracted length" of the audio track (the sum of all frame durations, for streams with constant duration [number of frames]*[frame duration])
this is what I want :)

I nearly all of the Frames are in SimpleBlocks, but there's also a single Blockgroup with a 'Block (track number 3' which also has a Block Duration entry, should the frames from the 'Block (track number 3' also be counted or just the frames from the SimpleBlocks ?

Cu Selur

[Mosu]

@mosu: Will you also adjust mkvinfo to the TrackIDs mkvmerge&mkvextract use since 5.2.1+?

No. sneaker_ger has answered as to why not. I will also not add additional information to mkvinfo's output. Finding out the track IDs is what mkvmerge's "--identify" options are for. I won't duplicate that feature into another program, especially as mkvinfo's output does not take default values into account while mkvmerge's does (e.g. track language, "default" flag status etc).

Wouldn't that just give me the length of the stream inside the container?

Correct.

"duration of last packet"
is this:
a. distance between the last entry for Track 3 and the next entry in the container?
b. distance between the last entry for Track 3 and the length of the clip as a whole?
c. none of the above,.. (what?)

The timecode + the packet's duration. If an explicit duration is given in a BlockGroup element, then it is that duration. Otherwise it's the default duration.

It's definitely not the difference between the timecode and the end of the stream/file.

[Mosu]

this is what I want :)

I nearly all of the Frames are in SimpleBlocks, but there's also a single Blockgroup with a 'Block (track number 3' which also has a Block Duration entry, should the frames from the 'Block (track number 3' also be counted or just the frames from the SimpleBlocks ?

Cu Selur

All frames, of course. How they're stored (SimpleBlock vs BlockGroup) is simply a matter of taste/information that has to be stored. SimpleBlocks have less overhead, a BlockGroup can contain an explicit duration for that frame.

[Selur]

btw.: Thanks to Mosu&sneaker_ger, I got a stretch detection working for all streams that have a duration specified, without extracting the streams!! :)

[Abradoks]

btw.: Thanks to Mosu&sneaker_ger, I got a stretch detection working for all streams that have a duration specified, without extracting the streams!! :)
Can you please share corresponding code? Such tool is often asked on the forums.

[Selur]

atm. it's not a stand alone tool but a new part of Hybrid.
I already got the Track IDs, length indicated by the container (needed for length comparisons) and the frame count of the video stream (needed for progress indication) there, so the code is probably not really useful to others in the state it is now.
If people are interested I could probably come up with a small stand alone tool (without progress indication, since total frame count of any stream isn't indicated by mkinfo.

Cu Selur

[Abradoks]

It would be enough if you can tell, how do you get real (extracted) frame duration.

[Selur]

Like I wrote before it only works for streams where the frame duration is known, i.e. dts, ac3, it's basically a simple scan the input,.. count&multiply that could be done by a shell script. :)

Cu Selur

Ps.: source code for a small shell application using mkvinfo: http://www.multiupload.com/BO3IFKAVWP and a win64 static binary (http://www.multiupload.com/OGON5W22G8)

[Simon88]

I'm using MKVmerge v5.2.1 converting an RV40/cook file from a RMVB container to a MKV container, afterwards the file will no longer play. Nothing changed, only the container. MPC-HC, VLC 1.30 git, & SMPlayer 0.6.10, all did not work. Once I removed the audio & remuxed to a new MKV file w/ only the RV40 video, everything worked.

Does Matroska v5.2.1's mkvmerge have trouble dealing w/ "cook" audio?

[wbee]

I encountered a problem

muxing or spliting video files with aac 24khz Audio track, will cause the audio track's samping rate changed to 48khz.
Because some playback device cant play video with 48khz audio track.
is it possible to leave the sampling rate unchanged? how?

[Mosu]

Does Matroska v5.2.1's mkvmerge have trouble dealing w/ "cook" audio?

I don't know. And honestly, Cook/RealAudio is so old and unused today that I don't really care.

[Mosu]

I encountered a problem

muxing or spliting video files with aac 24khz Audio track, will cause the audio track's samping rate changed to 48khz.
Because some playback device cant play video with 48khz audio track.
is it possible to leave the sampling rate unchanged? how?

Are you the one who's posted a similar bug in my bug tracker (https://www.bunkus.org/bugzilla/show_bug.cgi?id=699)? Even if not, the answer is still the same. If your source file uses a sampling rate of 24kHz then it uses spectral band replication (SBR). For such cases Matroska contains two header fields, the sampling frequency (unchanged at 24kHz) and the output sampling frequency (48kHz). That is perfectly normal. If your player cannot play such files then it's more likely that it either cannot play SBR at all or that its Matroska support is so abysmal that it's so confused by the additional header field that it just gives up. Either way, this is not a problem in mkvmerge, it's the correct and spec-compliant behavior. There's no way to change it.

[wbee]

Are you the one who's posted a similar bug...
yes

Thank you very much for your detailed explanation!
it's more likely my player cant play SBR

[Simon88]

I don't know. And honestly, Cook/RealAudio is so old and unused today that I don't really care.
RMVB/RM seems to be REALLY popular in Asia. They have cheap devices that produces excellent video at low bitrates w/o having to pay royalties I guess.

Bit-rate below ~100Kbps defaults to cook and LC-AAC for anything above. Real is moving to HE-AAC for the lower bit-rates, though.

Anyhow, I was hoping to preserve the original RV40/cook onto a MKV container & also add a re-encode of the video as H264/LC-AAC inside the MKV container, and show the original if hardware permits as recencodes degrade video quality.

I didn't know that apparently just by having a "cook" track inside the MKV, playback is negatively affected even on the H264/LC-AAC tracks.

[Mosu]

Back when I implemented support for RealMedia re-muxing cook used to work. That was... oh... hmm... in 2004, it seems. The last time someone actually had contacted my about some RealAudio issue (not AAC) was in 2007, if I'm not mistaken. Also: players refusing to play a whole file just because one kind of track is present are seriously broken -- unless mkvinfo and mkvmerge cannot read such a file either. In which case I would actually investigate the issue.

So please check: "rmvb-with-cook -> mkvmerge -> mkv-with-cook -> mkvinfo" and "rmvb-with-cook -> mkvmerge -> mkv-with-cook -> mkvmerge -> mkv-remuxed-without-cook". If the last step of those actions fail (not if playback fails!) then it might be interesting to look at.

[Simon88]

Back when I implemented support for RealMedia re-muxing cook used to work. That was... oh... hmm... in 2004, it seems. The last time someone actually had contacted my about some RealAudio issue (not AAC) was in 2007, if I'm not mistaken. Also: players refusing to play a whole file just because one kind of track is present are seriously broken -- unless mkvinfo and mkvmerge cannot read such a file either. In which case I would actually investigate the issue.

So please check: "rmvb-with-cook -> mkvmerge -> mkv-with-cook -> mkvinfo" and "rmvb-with-cook -> mkvmerge -> mkv-with-cook -> mkvmerge -> mkv-remuxed-without-cook". If the last step of those actions fail (not if playback fails!) then it might be interesting to look at.
I re-muxed according to your instructions and MPC-HC played it, the RV40 video, fine except there was a slight video studder during playback using VLC and MPC-HC. Changed the splitter to LAV from Haali and video playback works OK without stutter, with cook audio in the MKV container, not OK, no matter using Haali or LAV.

mkvinfo read all the MKVs info without issue.

Finally tried playing RV40/cook using ffplay.exe (ffmpeg) and audio stuttering also occured inside the MKV container. Without cook audio, ffplay.exe played the video ok as well. I believe audio/video may not be interleaved/aligned correctly by mkvmerge. Perhaps, just a one line, code change of some sorts.

I believe the RealMedia container has undergone various changes thru the years, perhaps. Like you, I also think it is a dead/dying format, so I checked wikipedia: http://en.wikipedia.org/wiki/RealNetworks
Surprisingly with the lousy economy, after laying off alot of their employees, they still have more than 1,600 employees left...

If you visit Asian video sites, it is the preferred online format in Asia, they almost exclusively still use RM/RMVB for streaming and downloading, with MKV's used for d/l's of multi-lingual videos, AVI's used less often.

Because of the low-bit rate required, cook is still quite popular and just recently ffmpeg reliably supports RM/RMVB, it is now easily played on ALL platforms without the need of using hacked RealNet dll's.

[Mosu]

Upload a sample file to my FTP server. Maybe I'll take a look at it over the next couple of weeks.

[Simon88]

Upload a sample file to my FTP server. Maybe I'll take a look at it over the next couple of weeks.

Hi Mosu,

I just uploaded two low resolution very recent broadcast/over the air TV captures to your ftp server. I've included MD5 checksums because your ftp server choked a few times during the upload & retransmission/recovery was used. Both use RV40 for video & one has cook, the other has LC-AAC for audio.

HD 1280 x 720p, 3Mbps, RV40 video, 128Kbps LC-AAC audio are the most popular resolutions, though (1GB/45min) too big, I sent you the low resolution varieties.

After a few months, only archived version are available/saved at usually 720x408p, 700Kbps, RV40, video, 64Kbps, cook, audio.

If you convert even the one using LC-AAC to the MKV container, the MKV video has a slight stuttering/not smooth compared with the original RMVB. However, RMVB w/ LC-AAC converted fine using the following command:
ffmpeg -i RMVB_with_LC-AAC_audio.rmvb -vcodec copy -acodec copy RMVB_with_LC-AAC_audio.mkv

However, even ffmpeg does not convert RMVB_with_cook_audio.rmvb to mkv properly.

I've only uploaded the two most popular & current types of RMVB encoded by RealVideo v10/11.

Most development work & source cvs codes, command-line utilities, etc is located at: https://helixcommunity.org/
and only sell their stuff at: http://www.realnetworks.com/

So, HelixCommunity is where everything is at for OpenSource info regarding there SDK, tool, and complete source codes for those tools. The site is hard to navigate, you'd have to poke around to find the good stuff :-)

[redfordxx]

Hi,
I have question about appending in mkvmerge:
When I join two files in mkvmerge, is the junction smooth like there was never a break, or there will be some anomally.

Example:
*.avs with trim(0,10000) --> x264.exe --> *.mkv
will have same result as
*.1.avs with trim(0,4999) --> x264.exe --> *.1.mkv
*.2.avs with trim(5000,10000) --> x264.exe --> *.2.mkv
*.1.mkv append *.2.mkv --> mkvmerge.exe --> *.mkv

Thank you.R.

[Mosu]

It will have almost the same effect, but not really. The difference should not be noticeable though.

[vdcrim]

there will be some anomally?

If the x264 input is VFR, yes. I have noticed that x264 writes the duration of the last frame as '0' if a timecode is supplied. So if you append several VFR videos the timecodes of the final video will be like this:
0
40
80
80 <- start of the second file
120
160
200
200 <- start of the third file
240

A thing to be considered is that mkvextract doesn't include the duration of the last frame when outputing a timecode file (it's often not included in the mkv anyway), so to check this x264 bug you have to append another video and check the timecode as in the example above. Btw I filed a bug (https://www.bunkus.org/bugzilla/show_bug.cgi?id=691) for mkvextract.

[sneaker_ger]

What do you mean with "0"?
The timecodes are starting times, not ending times. So yes, we can't know (only guess) how long the last frame is supposed to be shown from them, but it hardly qualifies as a bug IMHO. :confused:

[Simon88]

Does anyone know if/howto make mkvtoolnix support the saving of iso 639-3 language codes for future use?

The language codes which supports language "dialects". thanx..

[sneaker_ger]

That is probably a limitation of the Matroska format, not of mkvtoolnix.

@vdcrim

Ok, I read bug 233 which implies it may be possible, so ignore my last post.
So what you are saying is that x264 doesn't do it correctly, and what you want from mkvextract is basically a feature request?

[Atak_Snajpera]

@Mosu
Is it possible to get key frame positions from mkv?
Something like this

0
24
48
67
71
95
119
143
167
191
215
239
263
287
311
335
359
383
407
431

[Mosu]

If the x264 input is VFR, yes. I have noticed that x264 writes the duration of the last frame as '0' if a timecode is supplied.

Does x264 explicitely write a BlockGroup with a Duration element set to 0 in such cases? If so then you're correct regarding how mkvmerge will calculate the timecodes.

If, on the other hand, x264 writes no duration for the last frame then mkvmerge will use the track's default duration header field.

[Mosu]

Does anyone know if/howto make mkvtoolnix support the saving of iso 639-3 language codes for future use?

The Matroska format has no header field for that piece of information. Therefore mkvmerge doesn't support it. You could only store in one of the elements suited for free-form text entry, e.g. track titles, tags or even in a text file that is then used as an attachment.

The drawback is that the information will still not be used for track selection in players (apart from the track's title which might be shown by a player).

[Mosu]

@Mosu
Is it possible to get key frame positions from mkv?

Not without parsing the whole file. If you don't have a Matroska parser then parsing mkvinfo's output is always a possibility.

Matroska files may have an index, and most do, but that index is neither mandatory nor does it have to include all key frames of all tracks.

[Mosu]

A thing to be considered is that mkvextract doesn't include the duration of the last frame when outputing a timecode file (it's often not included in the mkv anyway), so to check this x264 bug you have to append another video and check the timecode as in the example above. Btw I filed a bug (https://www.bunkus.org/bugzilla/show_bug.cgi?id=691) for mkvextract.

When appending Matroska files mkvextract is not used, and judging from the original poster's question he didn't plan to extract the tracks before appending.

However, I've just fixed that bug.

[Selur]

Not without parsing the whole file. If you don't have a Matroska parser then parsing mkvinfo's output is always a possibility.
does/can mkvinfo differentiate between I and IDR frames for avc content ?

[Mosu]

Matroska itself doesn't differentiate, and mkvinfo only uses information on the container level. So... no.

[vdcrim]

The timecodes are starting times, not ending times.
Well, they are just timestamps associated to frames. IMHO a timecode of a n frames video should always contain n+1 timestamps. But I don't really need it to be that way, I just wanted to point something that in my opinion is incorrect.

Does x264 explicitely write a BlockGroup with a Duration element set to 0 in such cases?

If, on the other hand, x264 writes no duration for the last frame then mkvmerge will use the track's default duration header field.


It seems the later case is more likely, sorry. I just skipped through the x264 code and the default duration for vfr matroska is indeed 0. I don't know how to check the BlockGroup though.

Edit:
Wouldn't be more appropriate to discard the default duration if it happens to be '0', and use an average FPS or the duration of the previous frame?


When appending Matroska files mkvextract is not used, and judging from the original poster's question he didn't plan to extract the tracks before appending.

I meant that checking the timecode of the file to see if I was right would be worthless as mkvextract doesn't (didn't) include the last timestamp, and that a way to circumvent this would be append another file and check its timecode instead.

[sneaker_ger]

Well, they are just timestamps associated to frames. IMHO a timecode of a n frames video should always contain n+1 timestamps. But I don't really need it to be that way, I just wanted to point something that in my opinion is incorrect.

I hear you, but I didn't think Matroska had this information in the first place. Turns out I was wrong.

[Simon88]

Hi Mosu,

I was testing some MKVs on the recently released ASUS O'Play Media Player ( http://www.asus.com/Multimedia/Digital_Media_Player/ ), which just recently supports HD 720p RMVBs. I had some HD 720p RMVBs that I converted to MKVs which will only play correctly if I used the LAV splitter on my PC.

On this device it also has issues with RMVBs muxed into MKVs (RV40/AAC-LC). I also had to run it thru ffmpeg (not re-encode) first, before the ASUS Media player would play it correctly.

It's not a big issue for me as I can remux to MKV using ffmpeg first, and afterwards use mkvtoolsnix, but I just want to let you know this particular issue and hope it can be fixed one day. thanx..

[Mosu]

Like I've written one or two pages ago RealAudio/RealMedia doesn't really have any priority for me at the moment. Maybe I'll get around to it one day, maybe I won't.

[Lincoln Burrows]

I received this message while creating a Matroska file from one MPV/AC3 and two SUP files demuxed using TSMuxer from the m2ts file decrypted from the original Blu-ray disc:

Warning: Video ended with a shortened group of pictures. Some frames have been dropped. You may want to fix the MPEG2 video stream before attempting to multiplex it.Does it mean the m2ts file is somehow corrupted?

Note: I had to use TSMuxer instead of MakeMKV for the reasons stated here:
http://www.makemkv.com/forum2/viewtopic.php?f=1&t=4353

BTW, despite this warning I mentioned above, I am watching the video with no apparent problems, so I guess it's fine.

[Atak_Snajpera]

@Mosu
I have a feeling that MKVMerge incorrectly splits mkv with VC-1 inside.

http://i.imgur.com/E6DbS.png

sample -> http://www.mediafire.com/?wg81zwe1cu1pv7u

http://i.imgur.com/Gv1Uc.jpg

BTW. The same happens in FFmpegSource (http://forum.doom9.org/showthread.php?p=1551279#post1551279)
For FFMS2 I found workaround. Trim(detected keyframe-1,...)

[Liisachan]

Mosu:

I have this specific (but quite normal) AVC (x264 r2120) video in MP4 container, which causes "Assertion failed: TimecodeDelay >= int16(0x8000) && TimecodeDelay <= int16(0x7FFF), file lib/libmatroska/src/KaxCluster.cpp, line 280" if muxed with a normal-looking, stereo 48000 Hz Vorbis.ogg (aoTuV), using --timecode-scale -1.
Like:
mkvmerge -o out.mkv x264.mp4 vorbis.ogg --timecode-scale -1

The same command line works just fine if --timecode-scale 20832 is used explicitly (apparently that's what mkvmerge is trying to do for -1, though 1/48000 is 20833 ns).

The problem occurs only with a specific .mp4 file; other .mp4 files creaetd with the same version of x264 so far mux just fine with --timecode-scale -1. Also, if I transmux this.mp4 into tmp.mkv first, tmp.mkv and vorbis.ogg mux just fine as well. On the other hand, this specific AVC.mp4 doesn't mux with other vorbis files either, with --timecode-scale -1.

I'm on Windows (still XP), and the above happens with the current version (5.2.1) of mkvmerge, and also with older versions (tested v2.9.9, 3.0.0, 3.4.0, 4.0.0). With -v -r debug.log, the last message when this happens is:
Vorbis: samples_here at 246276000000 (orig -1 expected 246276000000): 128 (m_previous_samples_sum: 11821376)

The next line would have been:
Vorbis: samples_here at 246278666666 (orig -1 expected 246278666666): 128 (m_previous_samples_sum: 11821504)

I'm not normally using --timecode-scale -1 at all. This happened while I was testing that option out of curiosity.
Do you want me to upload these files in question to somewhere, maybe to your server? It's about 180 MiB.

[Mosu]

Mosu:

I have this specific (but quite normal) AVC (x264 r2120) video in MP4 container, which causes "Assertion failed: TimecodeDelay >= int16(0x8000) && TimecodeDelay <= int16(0x7FFF), file lib/libmatroska/src/KaxCluster.cpp, line 280" if muxed with a normal-looking, stereo 48000 Hz Vorbis.ogg (aoTuV), using --timecode-scale -1.
Like:
mkvmerge -o out.mkv x264.mp4 vorbis.ogg --timecode-scale -1

Yes, please upload at least the MP4 file (my server would be fine). I guess it has something to do with the distance between key frames. Normally mkvmerge can only write a cluster when all frame references are resolved, meaning that for a sequence IBBPBBI... mkvmerge will only start the new cluster after it has seen the second I frame. It will also put everything before that second I frame into the cluster (IBBPBB), even though that is not really necessary.

These are two different things: The decision which frames are ready to be written to a cluster in general, and the decision which of the frames to put into which cluster. The first one cannot be changed, but it is also not the reason for the issue at hand if I guess correctly. However, changing the second reason is kind of a lot of changes. I might decide not to fix the issues.

Anyway, I'd appreciate the upload in order to verify whether or not my assumption is correct.

The same command line works just fine if --timecode-scale 20832 is used explicitly (apparently that's what mkvmerge is trying to do for -1, though 1/48000 is 20833 ns).

Ok, this is strange. Maybe my guess is completely wrong.

BTW, 1/48000 is 20833.333333333, and in order to achieve sample-precision timestamps I decided to err on the side of caution and not only truncate that value to the nearest integer but to subtract 1 from that as well.

[Liisachan]

OK, upping td.mp4 & td.ogg; the actual command-line and output are in TimecodeDelay-assert.txt. ETA a few minutes.

I guess it has something to do with the distance between key frames.
Though my x264 settings are quite conservative in this case (--fps 24000/1001 --keyint 240 --bframes 5 --ref 6). It's 8-bit and CFR too.

Ok, this is strange. Maybe my guess is completely wrong.
mkvmerge is happy with --timecode-scale 1000 or 100 or 10 or even 1 (Docs say the min valid value is 1000, but it accepts and actually handles lower values too). Doesn't look like a simple arithmetic overflow. There might be a glitch in handling -1, something un-auto-magical. Like, the variable size becomes 32- or even 64-bit when you do --timecode-scale with a small value explicitly, but always 16-bit if -1 is given, maybe?

BTW, 1/48000 is 20833.333333333, and in order to achieve sample-precision timestamps I decided to err on the side of caution and not only truncate that value to the nearest integer but to subtract 1 from that as well.
Thought so. That's fine with me :)

[Mosu]

@Liisachan: Thanks for the files. As my time is really limited at the moment I've decided to open a bug report (https://www.bunkus.org/bugzilla/show_bug.cgi?id=707) for it so I don't forget about it.

[Mosu]

@Mosu
I have a feeling that MKVMerge incorrectly splits mkv with VC-1 inside.

Thanks for the test file. At the moment I only have access to my laptop which is not able to play HD video. Therefore I cannot test this properly. I'll try to take a look at it over the weekend.

[Mosu]

Hi Mosu,

I just uploaded two low resolution very recent broadcast/over the air TV captures to your ftp server.

Thanks for the files. As you can probably see in some of the other answers I don't really have the time to look into this. But in order not to forget about it I've created a bug report (https://www.bunkus.org/bugzilla/show_bug.cgi?id=708) for this issue.

[Simon88]

Thanks for the files. As you can probably see in some of the other answers I don't really have the time to look into this. But in order not to forget about it I've created a bug report (https://www.bunkus.org/bugzilla/show_bug.cgi?id=708) for this issue.

Thanks for looking into the RV/cook issues inside MKVs.

btw, earlier today, RealNetworks just sold and licensed most of there "precious" audio/video/streaming patents to Intel for $120 mil... hope Intel will open up / make the format less restrictive.. as Intel intend to use it for streaming on phones, tablets, media players...

[Liisachan]

Thanks, Mosu.

Now I have another question. I'm still doing this x264+vorbis business, and now mkvalidator emits "ERR0C2: The timecode of the Cluster at ... is not incrementing". I didn't get this error before. Is this something I can safely ignore?
The actual internal is like this.

—Cluster (4+3+240028 0x114aa01)
——Timecode (1+1+ 3 0x0114aa08): 85002 <--scale is default
——SimpleBlock (1+2+ 1462 0x0114aa0d): #2A 0:01:25.164000000 ( 162) Xiph lacing
——SimpleBlock (1+2+ 6719 0x0114afc6): #1V [0:01:25.168000000] ( 166) P Frame2042
——SimpleBlock (1+2+ 6319 0x0114ca08): #1V [0:01:25.085000000] ( 83) B 2040D
——SimpleBlock (1+2+ 770 0x0114e2ba): #1V [0:01:25.002000000] ( 0) b 2038D
——SimpleBlock (1+2+ 1569 0x0114e5bf): #1V [0:01:25.043000000] ( 41) b 2039
...
——SimpleBlock (1+1+ 90 0x01185099): #1V [0:01:30.007000000] ( 5005) B 2158D
——SimpleBlock (1+1+ 92 0x011850f5): #1V [0:01:29.923000000] ( 4921) b 2156D
——SimpleBlock (1+1+ 64 0x01185153): #1V [0:01:29.965000000] ( 4963) b 2157
——SimpleBlock (1+1+ 46 0x01185195): #1V [0:01:30.048000000] ( 5046) b 2159
——SimpleBlock (1+2+ 250 0x011851c5): #1V [0:01:30.132000000] ( 5130) P 2161
——SimpleBlock (1+2+ 223 0x011852c2): #2A 0:01:30.152000000 ( 5150) no lacing

—Cluster (4+2+215 0x11853a4)
——Timecode (1+1+ 3 0x011853aa): 90173
——SimpleBlock (1+2+ 207 0x011853af): #2A 0:01:30.173000000 ( 0) no lacing

—Cluster (4+3+61497 0x1185481)
——Timecode (1+1+ 3 0x01185488): 90173 <-- This?!
——SimpleBlock (1+3+ 18860 0x0118548d): #1V [0:01:30.173000000] ( 0) I 2162K
——SimpleBlock (1+2+ 1625 0x01189e3d): #2A 0:01:30.195000000 ( 22) Xiph lacing
——SimpleBlock (1+2+ 1631 0x0118a499): #2A 0:01:30.365000000 ( 192) Xiph lacing
——SimpleBlock (1+2+ 160 0x0118aafb): #1V [0:01:30.424000000] ( 251) P 2168
——SimpleBlock (1+1+ 53 0x0118ab9e): #1V [0:01:30.299000000] ( 126) B 2165D
——SimpleBlock (1+1+ 67 0x0118abd5): #1V [0:01:30.215000000] ( 42) b 2163D
——SimpleBlock (1+1+ 26 0x0118ac1a): #1V [0:01:30.257000000] ( 84) b 2164
——SimpleBlock (1+1+ 22 0x0118ac36): #1V [0:01:30.340000000] ( 167) b 2166
——SimpleBlock (1+1+ 28 0x0118ac4e): #1V [0:01:30.382000000] ( 209) b 2167
——SimpleBlock (1+2+ 1627 0x0118ac6c): #2A 0:01:30.536000000 ( 363) Xiph lacing

Format: <id> (<size of id>+<size of size>+<size of data> 0x<pos>)
#1V = track 1 x264 video; #2A = track 2 vorbis audio; K = Keyframe flag; D = Discardable flag

[Mosu]

Thanks, Mosu.

Now I have another question. I'm still doing this x264+vorbis business, and now mkvalidator emits "ERR0C2: The timecode of the Cluster at ... is not incrementing". I didn't get this error before. Is this something I can safely ignore?

Short answer: yes.

Long answer: Matroska's timecodes are stored as 16bit signed integer numbers in the SimpleBlock and BlockGroup elements. These are relative to the ClusterTimecode element. Their scale is the global TimecodeScale. Now if you're using sample precision then TimecodeScale is pretty low which, in turn, means that those 16 bit signed integer values only account for a limited range of timecodes. For example, at a sampling frequency of 48000 Hz TimecodeScale is probably 20835 (meaning that the value "1" stored in ClusterTimcode would be "20 ns 835 usecs"). 16 bit signed integers = max 32767 (mkvmerge does not use negative relative timecodes) which corresponds to a maximum cluster length of 32767 * 20835 usec = roughly 682.6 msecs.

Now combined with video B frames it's clear that the timecode of cluster n+1 might not always be higher than that of cluster n.

mkvvalidator probably doesn't account for this.

[Liisachan]

Thanks for quick reply. I'll just ignore this error then. Also, mkvalidator emits the same error for some of my old mkv files too; so this was nothing new at all.

The TimecodeScale in above sample is default (1 ms; that's what I meant by "scale is default"), so your long answer may not be applicable in this case, though. I gave up tweaking the timecode scale already, because if I do VLC can't handle subtitle tracks (their bug--nothing to do with mkvtoolinx).
I wanted to use slightly finer scale (0.1 ms), because for example if video is 30-fps, some frames are 33 ms and other frames are 34 ms in MKV, implying about 3% fluctuation or un-smoothness, at least in theory. This 3%-ish may be unnoticeable in reality, but I've been always unsure about it. Using 0.1 ms time-scale "just in case" only increases the file size by a few KiB, so I figured it was a good trade-off even for placebo happiness by thinking "now this is more accurate"... until I tested it on VLC.

[Snowknight26]

mkvmerge outputs an mkv with mangled timestamps when remuxing this (http://stfcc.org/misc/ffmpegsource.mangled.timestamps.ts) sample; eac3to, on the other hand, does not.

[Selur]

startingt with a test.avi file (xvid+mp3)
I created a (xvid+pcm) mkv file by:
1. extract audio as pcm:
mplayer -aid 1 -msglevel statusline=5:all=0 -mc 0 -hardframedrop -vc dummy -nocorrect-pts -aid 1 "G:\Hybrid\test.avi" -vo null -ao pcm:fast:waveheader:file=""""D:\Encoding Temp\test__aid_1__11_22_56_221_01.wav""""
2. mux audio&video to mkv:
mkvmerge --ui-language en -o "D:\Encoding Output\test.mkv" -d 0 --default-track 0:yes --default-duration 0:25fps --aspect-ratio-factor 0:1 --no-chapters --forced-track 0:yes --no-audio --no-subtitles "G:\Hybrid\test.avi" --default-track 0:yes --forced-track 0:no -a 0 --no-video --no-subtitles --no-chapters "D:\Encoding Temp\test__aid_1__11_22_56_221_01.wav"

looking at the file with:
mkvinfo "D:\Encoding Output\test.mkv"
everything looks fine:
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 8147739
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4045)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libebml v1.2.3 + libmatroska v1.3.0
| + Writing application: mkvmerge v5.2.1 ('A Far Off Place') built on Jan 7 201
2 21:56:27
| + Duration: 17.160s (00:00:17.160)
| + Date: Sat Feb 04 10:23:01 2012 UTC
| + Segment UID: 0x98 0xf0 0x5c 0x48 0x26 0x7a 0x36 0x4a 0x96 0x9f 0xce 0x9e 0x2
7 0x24 0x89 0x32
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 3165394818
| + Track type: video
| + Forced flag: 1
| + Lacing flag: 0
| + MinCache: 1
| + Codec ID: V_MS/VFW/FOURCC
| + CodecPrivate, length 40 (FourCC: XVID, 0x44495658)
| + Default duration: 40.000ms (25.000 fps for a video track)
| + Language: und
| + Video track
| + Pixel width: 640
| + Pixel height: 352
| + Display width: 640
| + Display height: 352
| + A track
| + Track number: 2
| + Track UID: 2416414350
| + Track type: audio
| + Codec ID: A_PCM/FLOAT/IEEE
| + Default duration: 31.250ms (32.000 fps for a video track)
| + Language: und
| + Audio track
| + Sampling frequency: 48000
| + Channels: 2
| + Bit depth: 32
|+ EbmlVoid (size: 1081)
|+ Cluster
and playback is fine also.
Now I wanted to extract the audio again with:
mkvextract tracks "D:\Encoding Output\test.mkv" 1:"D:\Encoding Temp\test2__aid_0__11_23_20_911_01.wav"
but ended up with:
Error: Extraction of track number 1 with the CodecID 'A_PCM/FLOAT/IEEE' is not supported.

-> bug? missing feature? or stupid user?

Cu Selur

[Mosu]

Missing feature.

[Selur]

Okay, thanks for the info. (save me the hassle of looking for a problem on my end :))

[73ChargerFan]

7 0x24 0x89 0x32
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 3165394818
| + Track type: video
.....
.....
| + A track
| + Track number: 2
| + Track UID: 2416414350
| + Track type: audio

??? You're asking to extract the video track as a wav file ???

[Selur]

No th auidio track, since the content is pcm audio, raw pcm or wav seem like a normal choice.

[sneaker_ger]

??? You're asking to extract the video track as a wav file ???

http://www.bunkus.org/videotools/mkvtoolnix/faq.html#mkvmerge_mkvextract_mkvinfo_track_ids

[Mosu]

Hey,

I've released mkvtoolnix v5.3.0. It contains bug fixes all over the board: DTS handling, (E)AC3 detection, invalid memory access with certain broken files and more. mkvmerge's verbose identification mode has been extended with a couple more fields. mkvmerge can treat several separate input files as if they were concatenated into a single large file (e.g. VOBs or MPEG transport streams). The documentation has been updated accordingly.

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

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.3.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.3.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.2.1:


2012-02-09 Moritz Bunkus <moritz@bunkus.org>
* Released v5.3.0.

2012-02-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: mkvmerge will parse and apply the audio encoder delay in MP4 files that contain said information in the format that iTunes writes it. Fix for bug 715 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=715).

2012-02-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Implemented support for treating several input files as if they they had been concatenated binarily into a single big input file. Snytax is "mkvmerge -o out.mkv ( in1.ts in2.ts in3.ts )". This feature has already been present since version 5.1.0 but never been mentioned in the ChangeLog. Support for this feature in mmg is still missing.

2012-01-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Blocks with "BlockAdditions" will no longer be muxed as "SimpleBlock" elements discarding the additions but instead as "BlockGroup" elements. This applies to e.g. WAVPACK4 tracks with correction files as the correction data is stored in "BlockAdditions". Fix for bug 713 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=713).
* mkvmerge: bug fix: Fixed some more issues with (E)AC3 being misdtected as AVC elementary streams.

2012-01-27 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The header editor was sometimes creating two instances of an element if an element was added to the second or one of the later tracks. Fix for bug 711 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=711).
* mkvpropedit, mmg: bug fix: Trying to modify a file located in a path mounted with GVFS SFTP will no longer crash the programs. Instead an error message is output if an error occurs. Fix for bug 710 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=710).

2012-01-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed integer underflows in the read caching code resulting in invalid memory access. Happened in broken or incomplete files only. Fix for bug 709 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=709).

2012-01-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Appending AVI, Matroska or MPEG program stream files with DTS audio tracks will not result in a warning that the appended DTS tracks might not be compatible. Fix for bug 705 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=705).

2012-01-13 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix for the "timecodes_v2" mode: mkvextract will write one more timecode than there are frames in the file. The last timecode written will be the the sum of the last frame's timecode and duration with the "last frame" being the one with the highest timecode. Fix for bug 691 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=691).

2012-01-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed writing into paths on which a drive is mounted on Windows. Fix for bug 701 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=701).
* mkvmerge: enhancement: Identification output for Matroska files: Added the track number header field as "number" to the verbose identification mode.

2012-01-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Identification output for Matroska files: Added a field "content_encoding_algorithms" that contains a comma-separated list of encoding algorithm IDs used for that track. For example, "content_encoding_algorithms:3" would indicate that header removal compression is used.

2012-01-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Identification output for Matroska files: Added several fields to mkvmerge's verbose identification mode for tracks: UID, CodecID, length and content (as a hex dump) of the codec private data.
* mkvmerge: bug fix: Fixed a segmentation fault in the DTS detection code. Fix for bug 698 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=698).

2012-01-05 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The track IDs used in the "timecodes_v2" extraction mode are consistent again with the IDs that mkvmerge's identification reports and that mkvextract's "tracks" extraction mode uses. Fix for bugs 689 and 694.

2012-01-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Added video pixel dimensions to the output of "--identify-verbose" for Matroska files.

Have fun.

[Selur]

Nice! Thanks!

[b66pak]

thanks a lot...
_

[Chumbo]

Nice big update. :) Thanks a lot.

[Sparktank]

Wonderful! Thanks for the update :D

[73ChargerFan]

http://www.bunkus.org/videotools/mkvtoolnix/faq.html#mkvmerge_mkvextract_mkvinfo_track_ids
I sort of follow that, and have read this thread for years. The documentation does say that track numbers will correspond between mkvinfo & mkvextract for the same release.

In the post I commented on, above mkvinfo has a string "track number: 1" which is labeled video, and later in the same message mkvextract states "cannot extract track number 1 as audio".
So I think his command to mkvextract is incorrect.

I am even more grateful now to sheck for mkvcleaver.

[73ChargerFan]

Thank you Mosu for the update!

[sneaker_ger]

I sort of follow that, and have read this thread for years. The documentation does say that track numbers will correspond between mkvinfo & mkvextract for the same release.

In the post I commented on, above mkvinfo has a string "track number: 1" which is labeled video, and later in the same message mkvextract states "cannot extract track number 1 as audio".
So I think his command to mkvextract is incorrect.

No. In mkvinfo you only see the "TrackNumber", while mkvextract is using the "Track ID". The former is hard-coded into the file, the latter is made up by mkvmerge and mkvextract. They do not necessarily correspond, but for older mkvtoolnix versions they did.

"cannot extract track number 1 as audio" actually means "cannot extract track with TrackID 1 as audio". Maybe that should be changed to avoid confusion.

[smok3]

mkvmerge will parse and apply the audio encoder delay in MP4 files that contain said information in the format that iTunes writes it. Fix for bug 715.
Anyone knows if afconvert would behave the same? (I did't notice so far)

[sneaker_ger]

Probably not.
See if it contains the "iTunSMPB" tag or upload a sample if you don't feel confident enough to look for it yourself.

[Mosu]

I sort of follow that, and have read this thread for years. The documentation does say that track numbers will correspond between mkvinfo & mkvextract for the same release.

No, it says that they correspond between mkvMERGE and mkvextract. Not mkvinfo. It also says that in earlier versions some of mkvinfo's reported fields accidentally matched the track IDs reported by mkvmerge, and that users were therefore wrongly assuming mkvinfo's output could be used for building mkvmerge's/mkvextract's command lines as well.

In the post I commented on, above mkvinfo has a string "track number: 1" which is labeled video, and later in the same message mkvextract states "cannot extract track number 1 as audio".

A "track number" is a header field in a Matroska file. As is a "track UID" ("unique identification number"). However, a "track ID" as used by mkvmerge's and mkvextract's command lines is something else and has nothing to do with any header field (regardless of input file type!).

[Mosu]

"cannot extract track number 1 as audio" actually means "cannot extract track with TrackID 1 as audio". Maybe that should be changed to avoid confusion.

Good point. I'll see to it.

[Vol666]

Hello

i'm looking for some help about muxing video + audio which delay.

The movie which I'm trying to contain has LPCM 5.1 audio which i don't want cause its too big. So I've download the same movie but another release and it has DTS 1536kbps audio.

They start at the same time but at the end the video delay with 2,47sec. I preview the video but didn't found any extra scene. The delay its growing anytime with a few frames so at the end the result is: video end at 02:21:04.748 but the audio 02:21:07.218.

So how I can synchronize them?

btw the frame rate is the same too!

[Inspector.Gadget]

The movie which I'm trying to contain has LPCM 5.1 audio which i don't want cause its too big. So I've download the same movie but another release and it has DTS 1536kbps audio.

Read Rule 6.

[[ReX]]

Is there any way to remove chapters with mkvpropedit using an option file?
I tried to pass --chapters with just a new line but it asks for a file name, quotes and double-quotes also don't work.

[Mosu]

;1557513']Is there any way to remove chapters with mkvpropedit using an option file?
I tried to pass --chapters with just a new line but it asks for a file name, quotes and double-quotes also don't work.

Hmm. I always assumed it would work, but actually it doesn't -- meaning I can confirm your observation. I'll fix this tomorrow.

[Mosu]

I'm considering a re-write of mmg and would like your opinion. Please do not discuss this here but in the separate thread I've created for it. Thanks.

[Mosu]

;1557513']Is there any way to remove chapters with mkvpropedit using an option file?
I tried to pass --chapters with just a new line but it asks for a file name, quotes and double-quotes also don't work.

Oh, I actually forgot about how I had implemented that feature. An empty argument must be represented by the line "#EMPTY#" as empty lines are skipped. Now this is unfortunately undocumented. The simple reason why I chose to do this is so that the very last character in a file can still be a newline without the resulting empty line at the end of the line being interpreted as an additional argument. I'll add this to the documentation.

[Mosu]

I've updated the documentation for option files (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.option_files).

[[ReX]]

Thanks for the info, Mosu!

Edit:
Another thing I noticed, the tag parameter (the one to remove all tags, specifically) only seem to work if it's the first parameter (even when not using an option file). I don't know if it's intended or not.

[Brother John]

Speaking of the documentation: I noticed that “10. Subtitles” http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.subtitles does not mention Blu-ray PGS as a supported format though they work perfectly fine. Also the second sentence
At the moment mkvmerge(1) supports only text, VobSub and Kate subtitle formats.
seems redundant since it says the same as the bullet list directly below.

[Mosu]

Thanks for the hint. I've updated that section.

[Selur]

Is there a way to set the 'Track enabled' flag for a track using mkvmerge through the command line? I would like to set it to 'true' for all the tracks I'm muxing into a mkv file,... (I also was surprised to see that this flag is as a default set to false,.. ;))

[Mosu]

Is there a way to set the 'Track enabled' flag for a track using mkvmerge through the command line? I would like to set it to 'true' for all the tracks I'm muxing into a mkv file,... (I also was surprised to see that this flag is as a default set to false,.. ;))

mkvmerge doesn't have a flag for this at the moment, no. But your assumption is wrong. The standard says that enabled is "1" by default (see http://www.matroska.org/technical/specs/index.html ). mkvmerge does not write the element by default either, meaning all tracks produced by mkvmerge are set to "enabled".

[Selur]

Okay, thanks for clearing that up, would be nice if there was an option to add the element (via command line would be enough for me :)), since some hardware player seem to assume the element as false if it is not present. :)

[Selur]

Small feature request if it's not hard or time consuming to implement:
- additionally to '--split timecodes:' it would be nice to have a '--split frames:' which would tell mkvtoolnix to split at the specified frame (okay the next key-frame after the specified frame) instead of splitting after a specific time code. This is usefull when handling vfr files.

Small question regarding '--split timecodes:' do these have to be the cfr timecodes (= frame number / average bitrate) or the vfr timecodes (= playback time codes) ?

Cu Selur

[Mosu]

Matroska doesn't have a concept of VFR vs. CFR. Neither does mkvmerge. Each frame has exactly one timecode, the one assigned to it for display purposes, and that's the one mkvmerge uses during splitting.

About splitting by frames: maybe. Technically not that challenging.

[Selur]

Thanks for clearing that up, hope you find the time and motivation to add the split by frames option. ;)

[vrpatilisl]

where is that croping black borders function (hidden).

[Mosu]

I don't understand that question.

[vrpatilisl]

sorry i mean how to crop black border in film without rencoding. Please read
http://forum.doom9.org/showthread.php?t=163897

[Selur]

Select the video track, go to it's 'Format specific options' read the toolTip for the 'Cropping' input field and act accordingly.

[Mosu]

That question has been discussed in the very thread you've linked, and is better answered there than here.

[aufkrawall]

Can anyone tell me how to muxe subtitles that are demuxed from DVD by PGCDemux?
Here's a sample:
http://www.mediafire.com/?fh73p4e2a53afvv

Do I have to convert it in some way?

[Mosu]

Those are HD-DVD subs. They are unsupported by mkvmerge, but you can convert them to PSG subtitles which are with BDSup2Sub (http://forum.doom9.org/showthread.php?t=145277)

[aufkrawall]

That program can't open my testsample. :(

[Mosu]

Then contact its author.

[aufkrawall]

No program could ever work for me with demuxed DVD subtitles of PGCDemux.
It happens with every DVD...

A bit OT: Do you know any other solution to demux DVD subtitles?
Shouldn't be too complicated. :)

[Mosu]

No, and please keep anything else related to HD subs/demuxing subtitles from DVDs etc out of this thread. It's completely offtopic. Thanks.

[Mosu]

I usually provide support by email and here on doom9. However, often enough the issues brought up by users are generally interesting for a wider audience. And, just as often, I have to answer the same question over and over again.

Therefore I decided to open a forum for MKVToolNix (https://www.bunkus.org/answers/) in particular and Matroska in general. Everything about my programs and Matroska is ontopic there. It’s a StackExchange like forum that uses the excellent Questions2Answer (http://www.question2answer.org/) software.

Feel free to come around. I’ve added all of my earlier FAQ entries as posts, and a couple of other questions have been asked by new members as well.

This does not mean that I won't hang around in here anymore. Said new forum is more of an additional offer.

https://www.bunkus.org/answers/

[Selur]

like the idea of a forum, but the layout of the current one is a real pain, hope it will change in the future,.. (the font sizes, of the titles, are just too large to get some kind of overview + a back button would be nice, once you click on a question,..)

[Mosu]

The browser already provides you with a "back" button, you know ;)

I can certainly tune the style sheets. I kind of agree -- the fonts are a bit on the large side.

[Selur]

The browser already provides you with a "back" button, you know
Damn, I never realized that. ;)

[mbcd]

Maybee on TODO-List but still missing since """long times""" (dont take personally !!)

Adding automatic Framerate-Extraction from h264-RAW-Streams.

ATM mkvmerge is not able to read out framerate from this streamformat. Eac3to can do this, so I think its saved in a field somewhere inside. Other formats work very well, but h264 is one of the less where this does not function automaticly.

Would be nice to have this feature completed for "all" formats :)

:thanks:

[Mosu]

Maybee on TODO-List but still missing since """long times""" (dont take personally !!)

Adding automatic Framerate-Extraction from h264-RAW-Streams.

I'm actually working on that at the moment. However, I'll be away for most of next week, therefore I don't have an ETA. But yes, this is the next thing that I'm trying to fix.

[Chetwood]

I agree with Selur, cool idea but Simple Machines Forum or something would prolly made for better software ;)

[Mosu]

Over the last three days I've completely re-written mkvmerge's timecode handling code. This means that mkvmerge now handles all pathological files that I have including but not limited to:

interlaced content
TS files that only contain timecodes for some of the slice (e.g. every second slice)
files with multiple SPS and differing timing information
files in which the SPS change even though their ID is the same


This also means that the user doesn't have to specify the default duration (FPS) for h264 tracks anymore. The corresponding warnings in mmg have been removed.

All of this applies to h264 read from raw h264 elementary streams, AVIs, MPEG-2 program streams (VOB, EVO) and MPEG-2 transport streams.

I'd appreciate some testing :) The Windows builds including said code are 414 and higher available from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

[Snowknight26]

Any chance of being able to use the mouse scroll wheel in the 'Tracks, chapters and tags' CheckedListBox (or whatever wxWidgets calls it)?

[Mosu]

I don't really want to spend time on mmg, so it's a definite "maybe one day when I've got nothing better to do".

[sneaker_ger]

A question about the new h.264 timecode handling:
This is only intended to work correctly for CFR ES files, right?

[Mosu]

mkvmerge doesn't parse h264's picture timing SEIs, if that is what you're asking. Mostly because I don't have any such file, nor has anyone requested it so far.

Using timecode files should still work, though. If it doesn't then that's definitely a bug. I have to admit that I haven't tested it, though.

[sneaker_ger]

Timecode files still work, but mkvmerge pre will always set the standard duration element according to the info in the ES.

This file was created by x264 with a timecode file (hybrid 23.976/29.97):
http://www.mediafire.com/?d3t1pn44nu6bm5a
Not sure if it has this info, or if I would have had to use --pic-struct.

[Mosu]

Can you please also upload the timecode file? Thanks.

[sneaker_ger]

http://pastebin.com/Lzpqhsn6

[rack04]

Out of habit I set the FPS of a raw h264 video with the new version (416). Mediainfo reports the file is 24000/1001 which is the setting I selected in mkvmerge gui but for some reason when I play the file the video plays very slow and the length is reported as 4:00:59 instead of 2:00:30 if I don't set the FPS.

[sneaker_ger]

Yes, I have the same problem. Framerate is half of what it should be.

[Mosu]

For h264 you have to enter the field rate which is double the frame rate. Unfortunately the field in mmg is labeled "FPS". That's a decision I made back in the day, and I will likely change it to "default duration" -- just as mkvmerge's option for this has always been called "--default-duration".

The new tool tip already mentions h264 needing the field rate and not the frame rate.

[Mosu]

Oh, and Mediainfo only reports the "default duration" as well. If Mediainfo calls that the "number of frames per second" (I cannot check at the moment) then this is a bug/misrepresentation in Mediainfo. The Matroska specs do NOT have a sense of "numer of frames per second". There's only the "duration a Matroska block has by default". A "Matroska block" usually contains either a full frame or a field.

[Selur]

getting a bit confused now ;)
When using --default-duration with H.264 raw, can we still use i.e. --default-duration 1:25fps for a 25i stream of do we have to use 50fps?

[Mosu]

You have to use "--default-duration 1:50fps" if you know that the stuff that ends up in a Matroska block is only a field. I'm not certain what all those descriptions like "50i" refer to, therefore I cannot answer this directly.

[Selur]

to clarify: with 25i I ment 25 interlaced frames = 50 fields

[Mosu]

Then the answer is probably 1:50fps.

[sneaker_ger]

Well, I'm talking about progressive material. This is totally incoherent with older versions. And why would you offer "24", "25", "30", "30000/1001" and "24000/1001", when these field rates are totally uncommon? Also the "standard duration" is now different between 24/1.001 files muxed without manually entering the fps and files where I am now supposed to enter "48000/1001".
Please just return to the old behavior instead of defending accidental changes so stubbornly.

[Mosu]

No, I won't. In fact the new code doesn't require you to enter the default duration at all. Also the "old" way was totally broken for mixed content, for streams in which the SPS changed midstream or where different SPS with different timing information were present, and for files in which the source container provided timecodes for only some of the fields/frames (e.g. a TS file that only provided a timecode for every second field).

As for mmg: I can easily add double the values that are already present.

[Mosu]

I understand that you want an option that "just works" for the user. This option is supposed to be NOT to specify the default duration at all.

[sneaker_ger]

That would still leave the problem of incoherent behavior between manually specifying "48000/1001" (resulting in standard duration = "20854166") and automatically letting mkvmerge detect it (resulting in standard duration = "41708333").

[Mosu]

Look. It's like this. In Matroska the "default duration" is the duration that applies to a "Matroska block" if that "Matroska block" doesn't specify another duration. For h264 progressive content this is one frame. For interlaced content this can be a frame or a field.

The h264 bitstream always contains the field rate even for progressive content -- if it contains timing information at all. mkvmerge uses this field rate as the default duration. Meaning that the duration of a single h264 output unit (field or frame) can be twice the field rate (for a frame) or simply equal the field rate (for a field).

However, mkvmerge is trying to be smart as well. If it detects that the stream only contains frames and not fields then it will use twice the field rate as the default duration. This is done by calculating the most often used duration between the first two key frames. That one is used as the "default duration".

Now to mmg and specifying the default duration manually. There are two possibilities here:

1. The current method. The user has to specify the field rate as the default duration for h264 content. This can result in what you've describe: an inconsistency between what you enter and what you see in the final file if e.g. the content is progressive.

2. I could make the "FPS" in "--default-duration" be interpreted as the number of frames. Meaning mkvmerge would internally use double its value for fields. However, this could lead again to two undesirable situations:

2.1. I use what the user provides as "--default-duration" literally. This means that if the user says "25 FPS" and the content is interlaced with one field in a Matroska block then each Matroska block would have a duration that's different than the default duration. This requires that, on the file level, each Matroska block needs an explicit "duration" element. This also means that "SimpleBlock" elements cannot be used. This results in higher overhead.

2.1. I still detect whether or not fields or frames are usually output and adjust the header value for "default duration" accordingly. This can again lead to the same discrepancy as shown in "1." above: the user specifieds "25FPS" (which corresponds to a default duration of 40000000) but mkvmerge detects fields and writes "20000000" into the track headers.

I don't see any way to make this a) use the least amount of overhead possible while b) not being prone to discrepancies. Unless you do not specify the default duration at all and let mkvmerge decide itself.

[Selur]

Another question regarding --default-duration is the interpretation of fps as fields per second only for H.264 raw content or also for other i.e. MPEG-2 raw content ?

[Mosu]

Another question regarding --default-duration is the interpretation of fps as fields per second only for H.264 raw content or also for other i.e. MPEG-2 raw content ?

At the moment only the handling for h264 has changed. For MPEG-2 it is still "frames per second", more or less, but there are known issues with interlaced MPEG-2 content (e.g. https://www.bunkus.org/bugzilla/show_bug.cgi?id=672 ). However, MPEG-2 doesn't have a high priority for me anymore.

[sneaker_ger]

Look. It's like this. In Matroska the "default duration" is the duration that applies to a "Matroska block" if that "Matroska block" doesn't specify another duration. For h264 progressive content this is one frame. For interlaced content this can be a frame or a field.

The h264 bitstream always contains the field rate even for progressive content -- if it contains timing information at all. mkvmerge uses this field rate as the default duration. Meaning that the duration of a single h264 output unit (field or frame) can be twice the field rate (for a frame) or simply equal the field rate (for a field).

However, mkvmerge is trying to be smart as well. If it detects that the stream only contains frames and not fields then it will use twice the field rate as the default duration. This is done by calculating the most often used duration between the first two key frames. That one is used as the "default duration".

Now to mmg and specifying the default duration manually. There are two possibilities here:

1. The current method. The user has to specify the field rate as the default duration for h264 content. This can result in what you've describe: an inconsistency between what you enter and what you see in the final file if e.g. the content is progressive.

2. I could make the "FPS" in "--default-duration" be interpreted as the number of frames. Meaning mkvmerge would internally use double its value for fields. However, this could lead again to two undesirable situations:

2.1. I use what the user provides as "--default-duration" literally. This means that if the user says "25 FPS" and the content is interlaced with one field in a Matroska block then each Matroska block would have a duration that's different than the default duration. This requires that, on the file level, each Matroska block needs an explicit "duration" element. This also means that "SimpleBlock" elements cannot be used. This results in higher overhead.

2.1. I still detect whether or not fields or frames are usually output and adjust the header value for "default duration" accordingly. This can again lead to the same discrepancy as shown in "1." above: the user specifieds "25FPS" (which corresponds to a default duration of 40000000) but mkvmerge detects fields and writes "20000000" into the track headers.

I don't see any way to make this a) use the least amount of overhead possible while b) not being prone to discrepancies. Unless you do not specify the default duration at all and let mkvmerge decide itself.

Sorry, that still doesn't make any sense to me, but let me get this straight:
1. What mkvmerge calls "--default-duration" and what you're intending to label as "default duration" in mmg, actually means "field rate" for h.264.
2. With mkvmerge, there will be no way to get a correctly set DefaultDuration (http://matroska.org/technical/specs/index.html#DefaultDuration) Track element for progressive H.264 content when manually choosing framerate/field rate/default duration.

[Mosu]

For h264: The "default duration" header element should contain either the field rate IF there are fields present or double the field rate = the rame rate if only frames are present.

Like I said, Matroska itself does not know anything about a "field rate" or "frame rate". It only knows about how long that content stored in a single Matroska block should be.

If the user insists on specifying this value then he must know exactly what his source file contains. Otherwise the value he enters as the default duration may not be the one that mkvmerge writes to the file (as it is now), or mkvmerge would have to be changed in this regard and then it would cause higher overhead in the file as each Matroska block would have a different duration that the default duration indicates.

Like I said, the correct solution is not to specify the default duration at all.

[sneaker_ger]

Like I said, Matroska itself does not know anything about a "field rate" or "frame rate". It only knows about how long that content stored in a single Matroska block should be.

If the user insists on specifying this value then he must know exactly what his source file contains. Otherwise the value he enters as the default duration may not be the one that mkvmerge writes to the file (as it is now)

No. Wrong.
Currently (416 pre) there is no way at all to use "--default-duration" on progressive content correctly. Try it!

I don't understand why you arbitrarily chose "--default-duration" to expect the field rate (and only for h.264 at that). Might as well let it expect the ... eh ... default duration (or the respective "fps" value).

[Mosu]

OK, let's assume I'll change how --default-duration works. What would you as a user want it to do?

Remember: the "default duration" header value should, in the end, contain the default duration of a single Matroska block. Otherwise the experience upon playback may not be what the user expects it to be! (E.g. if the user thinks "hey, I'll enter 25FPS even for interlaced content" and players use that value for each Matroska block -- even though each Matroska block only contains a field but not a frame. I've seen that happen.)

[sneaker_ger]

Well, let's just be consequent and let it expect the default duration in the Matroska sense:
For a 25p file: user chooses "25"s^(-1) in mmg or "40ms"
For a 25i file: user chooses "50"s^(-1) in mmg or "20ms"

Result: each block has the correct length and the "DefaultDuration" Track element is set correctly.
I would also be fine with either frames per second or fields per seconds, it's just that I consider pre 416's progressive muxing wrong.

[Mosu]

Well, let's just be consequent and let it expect the default duration in the Matroska sense:
For a 25p file: user chooses "25"s^(-1) in mmg or "40ms"
For a 25i file: user chooses "50"s^(-1) in mmg or "20ms"

After having thought about this I don't like a lot anymore. This would require that mkvmerge analyses what kind of a bitstream is present and converting the number from "frames per second" to "fields per second". At the moment mkvmerge's timestamping formula is pretty simple:

multiplier = current_block_is_a_field ? 2 : 1
timecode = previous_timecode + default_duration * multiplier

I have another suggestion. If the user specifies the --default-duration then mkvmerge always assumes that the user meant "frames per second". What the h264 code does internally doesn't matter: it would simply use the user-supplied value and use half of it for its default_duration internally.

However, this would mean that the default_duration written to the file may be different than the value the user supplied. On the other hand it would make it easier for the user: no matter whether or not the input is 25p or 25i the user only has to enter "25fps". And I could leave mmg's "FPS" field as it is, meaning it wouldn't be renamed to "default duration".

Thoughts?

[mbcd]

Muxing a progressive 23,976 fps h264-file: It seems to work fine here.

Duration is shown with 41708333 ms, thats correct.
VLC shows: Bildwiederholrate: 47.952047, but plays at correct speed.

You should implement all Framerates, as they are usualy given by frames. 25i is 50P, everywhere this is that way and it has ever been, at mmg it is 25, thats really confusing. Every program uses fullframes for definition, nor fields. If user defines manualy he has to know if source is progressive or interlaced.

If frame is progressive or interlaced is work of decoder / muxer.

25p is 25p.

So i would suggest for manual input:
23,976, 24/1001 = 41,708375041708375041708375041708
24,000, 24/1000 = 41,666666666666666666666666666667
25,000, 25/1000 = 40 -> 25P
29,970, 30/1001 = 33,366700033366700033366700033367
30,000, 30/1000 = 33,3
50,000, 50/1000 = 20 -> 50p / (25i) --> is 20ms per field = 40ms as block (frame)

so I think Im mostly dealing with sneaker_ger in that point of user-Input.
MMG still misses 50fps (25i) /60fps (30i) as userinput.

I you could find out if stream is interlaced or progressive there should not be a problem dealing with 50p(=40ms) on interlaced material:

multiplier = current_block_is_a_field ? 40/2 : 40/1

But it is still confusing:
You say that the duration is for every block, and a block can consist even fields or frames, so mmg splits "frames" if they are interlaced, so:
1 Progressive Frame = 1 block
1 Interlaved Frame = 2 blocks

am I right?

So "kick of" default-duration, say generally that the progressive (deinterlaced) Framerate is mandantory, otherwise you get in hell with progressive and interlaced.

[sneaker_ger]

After having thought about this I don't like a lot anymore. This would require that mkvmerge analyses what kind of a bitstream is present and converting the number from "frames per second" to "fields per second". At the moment mkvmerge's timestamping formula is pretty simple:

multiplier = current_block_is_a_field ? 2 : 1
timecode = previous_timecode + default_duration * multiplier

I have another suggestion. If the user specifies the --default-duration then mkvmerge always assumes that the user meant "frames per second". What the h264 code does internally doesn't matter: it would simply use the user-supplied value and use half of it for its default_duration internally.

However, this would mean that the default_duration written to the file may be different than the value the user supplied. On the other hand it would make it easier for the user: no matter whether or not the input is 25p or 25i the user only has to enter "25fps". And I could leave mmg's "FPS" field as it is, meaning it wouldn't be renamed to "default duration".

Thoughts?



Yes, that is fine, I guess. Better to make it work the same as the older versions than to arbitrarily switch to a different way, unless it offers any significant improvement. And it does indeed not matter what H.264 does internally.

[Mosu]

@mbcd: No, you suggested something else than sneaker_ger. sneaker_ger said that for 25i the user should have to enter "50fps". I don't like that. Like I said in my post after sneaker_ger's, I would suggest that the user enters "25fps" for both 25p and 25i content and 50fps for both 50p and 50i (and so on). mkvmerge would do the "right thing" with that information.

The only downside would be that for 25i content the "default duration" element would contain "20000000" meaning a default duration of 20ms which is only half the value the user supplied. However, there's always one downside. The advantage is that the user only deals with "frames per second" and not with the question whether or not the content is progressive or interlaced.

Muxing progressive content without the --default-duration given is working just fine, that's right.

[sneaker_ger]

Yeah, I think the "frames per second" is more user friendly. Or one would differ between durations (ms, ns...) and rates (fps). The former getting used exactly as specified and the latter being divided by 2 for interlaced tracks.

But my main complain never really was about in which format the user has to supply these values, but the fact that for progressive content mkvmerge writes the wrong "DefaultDuration" value. I still wonder if Mosu really understands what I'm complaining about: a bug!

[Mosu]

But my main complain never really was about in which format the user has to supply these values, but the fact that for progressive content mkvmerge writes the wrong "DefaultDuration" value. I still wonder if Mosu really understands what I'm complaining about: a bug!

This does not happen if you do NOT specify a --default-duration:

[0 mosu@tionne /ftp/.rip/mkv/h264] mkvmerge -o IcePrincess-nodefault.mkv IcePrincess.h264
mkvmerge v5.3.0 ('I could have danced') built on Mar 4 2012 17:24:24
'IcePrincess.h264': Using the demultiplexer for the format 'AVC/h.264'.
'IcePrincess.h264' track 0: Using the output module for the format 'AVC/h.264'.
The file 'IcePrincess-nodefault.mkv' has been opened for writing.
'IcePrincess.h264' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1920/1088.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 3 seconds.
[0 mosu@tionne /ftp/.rip/mkv/h264] mkvinfo -s IcePrincess-nodefault.mkv|head -n 4
Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: High @L4.0), language: und, pixel width: 1920, pixel height: 1088, display width: 1920, display height: 1088, default duration: 40.000ms (25.000 fps for a video track)
I frame, track 1, timecode 80 (00:00:00.080), size 82504, adler 0xbc38e88e
B frame, track 1, timecode 0 (00:00:00.000), size 25210, adler 0xf56842b0
P frame, track 1, timecode 40 (00:00:00.040), size 28907, adler 0xeca776a4

However, you are right that if you do specify a --default-duration then it is wrong:

Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: High @L4.0), default duration: 40.000ms (25.000 fps for a video track), language: und, pixel width: 1920, pixel height: 1088, display width: 1920, display height: 1088
I frame, track 1, timecode 160 (00:00:00.160), duration 80.000, size 82504, adler 0xbc38e88e
P frame, track 1, timecode 0 (00:00:00.000), duration 80.000, size 25210, adler 0xf56842b0
P frame, track 1, timecode 80 (00:00:00.080), duration 80.000, size 28907, adler 0xeca776a4

I will fix that, of course, along with the changes we've discussed.

I think I'll stay with "--default-duration always applied to a full frame and the packetizer will have to use half its value if its calculations are field-based". Treating the --default-duration units "fps" and "ms" differently seems error prone from a usage standpoint.

[sneaker_ger]

Good, I agree, so we can end this discussion.
Anyways, mkvmerge automatically reading the fps of h.264 ES is a very good change. Those popup windows in mmg were annoying, setting the fps was tedious and now we will have less newbies asking about these problems. Batching also got easier as a small bonus.

[Mosu]

That was the intention :)

[sneaker_ger]

One small thing I forgot:
mkvmerge pre 416 writes the "DefaultDuration" Track element even when a timecode file is supplied, while it probably shouldn't write any value in that case.

[Mosu]

Even with a timecode file the default duration should still be set. This should be done by calculating the most-often used duration in the timecode file. I'll take a look at the current state.

[sneaker_ger]

You can use the file I posted yesterday:
https://forum.doom9.org/showthread.php?p=1563354#post1563354

For the hybrid file x264 used 120/1.001 Hz as the timebase and that is what pre 416 takes for the DefaultDuration value at the moment.

[mbcd]

@mbcd: No, you suggested something else than sneaker_ger. sneaker_ger said that for 25i the user should have to enter "50fps". I don't like that. Like I said in my post after sneaker_ger's, I would suggest that the user enters "25fps" for both 25p and 25i content and 50fps for both 50p and 50i (and so on). mkvmerge would do the "right thing" with that information.

Damn, is this shit complicated :sly: :cool:

Yes, thats what I meant ... Dealing with fullframes, so 25i IS 50(p)
If User has video of 25i he has to enter 50, thats usual
If User has video of 25p he has to enter 25, thats logic

Video is alway counted in Frames, not in Fields, so I wouldnt change that for mmg.


The only downside would be that for 25i content the "default duration" element would contain "20000000" meaning a default duration of 20ms which is only half the value the user supplied. However, there's always one downside. The advantage is that the user only deals with "frames per second" and not with the question whether or not the content is progressive or interlaced.

Muxing progressive content without the --default-duration given is working just fine, that's right.

But that it, If you have 25 interlaced Frames, you dont have 25 Frames per second, but 50 Frames. So you are not dealing with "Real-Frames", but interlaced Frames. And a Frame is never a mix of both frames, like they are packed as interlaced together in one "Frame".

I think that this is confusing the stuff a little bit. I woudnt do it that way, but its your decision, I think its a wrong interpretion as usual used.

But not to forget:
Thanks for the new features and your work on it !!!!! :thanks::thanks::thanks:

[Mosu]

Here's a new build with these changes (only listing the ones relevant to our current discussion):

2012-03-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: When using an external timecode file with AVC/h.264 video the default duration will be set to the most-often used duration in the timecode fi\
le.
* mmg: enhancement: Added the values "50", "60" and "48000/1001" to the list of commonly used values for the "FPS" input field.
* mkvmerge: bug fix: AVC/h.264 packetizer: The value given with "--default-duration" is now again interpreted as the number of "frames per second". The conversion\
to "fields per second" is done internally; the user doesn't have to think about it, though.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ build 417 and newer

[Mosu]

Damn, is this shit complicated :sly: :cool:

Yes, thats what I meant ... Dealing with fullframes, so 25i IS 50(p)
If User has video of 25i he has to enter 50, thats usual

Wrong. The "i" behind the value means interlaced. With "interlaced" the number before the "i" refers to the number of fields per second. Therefore this would actually mean "12.5 frames per second".

Also there isn't something like "25i". Yes, I used this wrong above.

See http://www.hdtvprimer.com/ISSUES/what_is_ATSC.html

Now to mmg. With build 417 the value entered is always interpreted as the number of frames per second. Therefore here are a couple of examples that should work correctly:

source is 25p: enter "25"
source is 50i: still enter "25"
source is 50p: enter "50"


I could also add more parsing code that would accept "number followed by either p or i", e.g. "25p" or "50i" and convert it accordingly.

[Midzuki]

I could also add more parsing code that would accept "number followed by either p or i", e.g. "25p" or "50i" and convert it accordingly.

Another possibility: just add a checkbox which says "the source is interlaced" or something :)

[Mosu]

I think that terms like "25p", "50i" are more common and would actually be of help.

[Mosu]

Here's a new build with these changes (only listing the ones relevant to our current discussion):

...

build 417 and newer

Actually, build 417 is working fine with progressive content (both with --default-duration, --timecodes and with mkvmerge's auto-detection). Unfortunately it was its problems with interlaced content if --default-duration is used (similar to how it had those problems with progressive content). Will investigate and fix.

[Mosu]

A new build is up, 418. It fixes the issue with --default-duration on interlaced content. It also introduces a new feature: being able to use "number postfixed with 'i' or 'p'" for --default-duration, e.g. "--default-duration 0:50i". mmg's corresponding "FPS" drop down box contains a lot of new default values as well: everything from "24p" down to "60000/1001i".

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

I'd highly appreciate some testing.

[sneaker_ger]

Seems to work.
Though the drop down box is really long now. I'd remove all "48000/1001" values, as that is no common value. Same goes for all values without any letter at the end, because "no letter"=="p", I guess. Having both in there is too confusing for users.

The "DefaulDuration" for my VFR sample was set to "32999999"(~=30.3 fps) with timecode v2 file input, which can't be right for a VFR with a maximum of 29.97 fps. :confused:
Seems to work as expected when using timecode v1, though.

[Mosu]

Not quite right. Here's how mkvmerge calculates the default duration for a timecode v2 file:

First, it reads all the timecodes in the file and sorts them.
Second, it calculates each timecode's duration as the difference between the following one and itself.
Third, it records each duration's absolute probability.
The default duration is the one with the highest absolute probability.

For your file these are the absolute probabilities:

Debug> src/merge/timecode_factory.cpp:243: Absolute probablities with maximum in separate line:
Debug> src/merge/timecode_factory.cpp:244: Duration | Absolute probability
Debug> src/merge/timecode_factory.cpp:245: ----------+---------------------
Debug> src/merge/timecode_factory.cpp:253: 33000000 | 2052
Debug> src/merge/timecode_factory.cpp:253: 34000000 | 1187
Debug> src/merge/timecode_factory.cpp:253: 41000000 | 292
Debug> src/merge/timecode_factory.cpp:253: 42000000 | 709
Debug> src/merge/timecode_factory.cpp:256: Max-------+---------------------
Debug> src/merge/timecode_factory.cpp:257: 33000000 | 2052

Therefore 33000000 is the winner. Don't blame mkvmerge, blame your file :)

[sneaker_ger]

Eh...correct (except for "33000000" becoming "32999999"). Damn.

[Mosu]

I cannot reproduce the issue with 33000000 becoming 32999999. Anyway, I've removed a conversion from int64_t to double and back again in the v2 timecode factory. Pre-build 421 from www.bunkus.org/videotools/mkvtoolnix/win32/pre/ will contain that fix. mmg from the same pre-build will also only contain the "p" and "i" postfixed FPS values. The 48000/1001 ones have been removed as well.

Pre-build 421 should be available in shortly.

[sneaker_ger]

The rounding's working now with 421.

[Mosu]

Then I guess the Windows build was converting int -> double -> int differently than the Linux build. Happens. Anyway, no conversion, no problem :)

[Selur]

mkvmerge: bug fix: AVC/h.264 packetizer: The value given with "--default-duration" is now again interpreted as the number of "frames per second".
Okay, so the 'i'/'p' thing is dropped,... -> this does mean the 'fps' postfix is back, correct?

[Mosu]

OK, that changelog message was indeed confusing.

Now for "--default-duration": 'i' and 'p' are there to stay. 'fps' is also not going anywhere. If no unit is given then "ms" is assumed. mkvmerge always converts the value to "ns" internally as this is the resolution that Matroska works at (before applying timecode scale).

For mmg's "FPS" input field: If you enter a value without a unit then "fps" or "p" is assumed as both evaluate to the same. You can still enter "i" or "p" as a unit.

What the changelog message actually meant was: Before the change the h264 packetizer would interprete the value that was ultimately calculated for "--default-duration" as the duration of a field and not of a frame. That was the "arbitrary change" that several people here complained about, including speaker_ger.

After this change the value is again interpreted as the duration of a single frame. If the unit that the h264 packetizer outputs is a field then it will simply use half the duration.

For the user it means that he doesn't have to care about whether or not some part of mkvmerge thinks in fields or frames.

[Selur]

okay,.. to get this clear

for 50i (25 interlaced frames = 50 fields) would I use:
--default-duration 1:25ifps
or
--default-duration 1:25i ? (I guess the second)
and for 60p:
--default-duration 1:60pfps
or
--default-duration 1:60p
or
--default-duration 1:60fps
(I guess the later two are possible)

Cu Selur

[Mosu]

Normally you don't have to enter anything there anymore! mkvmerge will simply do the right thing itself. That was the whole point of the rewrite.

There is nothing like 25i. 25i would mean 12.5 frames per second. If your material is 50 interlaced frames/fields then you use 50i.

All values with 'p' as a unit are equivalent to the unit 'fps'. Therefore '25p' would be the same as '25fps' or '40ms'.

There are no units called 'ifps' or 'pfps'. There are only the units 'i', 'p' or 'fps' along with the time-based units 's', 'ms', 'us' or 'ns'.

See http://www.hdtvprimer.com/ISSUES/what_is_ATSC.html

[Selur]

That was the whole point of the rewrite.
I prefer to write it out to know what value was used when I log at my log files. ;)

Thanks for clearing the rest up. :)
(so for 50i I would use --default-duration 1:50i and be happy, right?)

[Mosu]

Suit yourself. Just don't complain if you use the wrong values then :)

[szabi]

Hi

I added global, video and audio tag info to matroska.
I do not know why, but audio tag is displayed in global area, by mediainfo (http://mediainfo.sourceforge.net)
Could anyone try it, for re-checking?

bye
szabi

[Selur]

probably a 'bug' in MediaInfo,..

[Liisachan]

It's not a problem of mkvmerge. I've experienced a similar problem for example when both video and audio tags have ENCODER_SETTINGS (it looks like the value of the audio one "overwrites" and hides the video's one). I've seen that both in MPC-HC and VLC but it's so minor it didn't bother me.

[Mosu]

I've released mkvtoolnix v5.4.0. It's a release that contains one huge improvement: the AVC/h.264 timecode assignment code has been completely rewritten. Users do not have to specify the default duration/FPS for such tracks anymore safe for the rarest cases. Apart from that there were tons of bug fixes, improvements regarding file type recognition, and a complete re-write of the (E)AC3 parsing code.

A note for package maintainers: Boost's rational library is now required.

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

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.4.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.4.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.3.0:

2012-03-10 Moritz Bunkus <moritz@bunkus.org>
* Released v5.4.0.

2012-03-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed wrong calculation of the maximum number of ns per cluster in certain fringe cases if timecode scale was set to "auto" mode ("--timecode-scale -1"). Fix for bug 707 (https://www.bunkus.org/trac/ticket/707).

2012-03-07 Moritz Bunkus <moritz@bunkus.org>
* build system: The C++ compiler must now support the C++11 keyword 'nullptr'. configure checks for it. For GCC this means at least v4.6.0.
* mkvinfo: new feature: mkvinfo will output the track ID that mkvmerge and mkvextract would use for a track. This information is shown alongside the "track number" element in verbose mode and in the track summary in summary mode.
* mkvmerge, mmg: enhancement: The "--default-duration" in mkvmerge and the "FPS" drop down box in mmg now accept "p" or "i" as a unit -- as in e.g. "25p" or "50i". Several commonly used values have been added to mmg's "FPS" drop down box and others removed.
* mkvmerge: bug fix: When using an external timecode file with AVC/h.264 video the default duration will be set to the most-often used duration in the timecode file.
* mmg: enhancement: Added the values "50", "60" and "48000/1001" to the list of commonly used values for the "FPS" input field.
* mkvmerge: bug fix: AVC/h.264 packetizer: The value given with "--default-duration" (after internal conversion from the unit given by the user to duration in nanoseconds) is now again interpreted as the duration of a frame and not of a field.
* mkvmerge: bug fix: SRT subtitles: timecodes can contain the minus sign before any digit, not just before the first one.

2012-03-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Sometimes non-AC3 files were mistakenly for AC3 after the re-write of the AC3 handling code on 2012-02-26. This has been rectified. Fix for bug 723 (https://www.bunkus.org/trac/ticket/723).

2012-03-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge will keep the "enabled" track header flag when muxing. mkvmerge will also output its value in verbose identification mode as "enabled_track".
* mkvmerge: enhancement: MicroDVD text subtitles are recognized as an unsupported format instead of an unknown format.
* mmg: The warning that no default duration/FPS has been given for AVC/h.264 tracks has been removed.
* mkvmerge: bug fix: Complete re-write of the timecode handling code for AVC/h.264 tracks. Now handles several cases correctly: interlaced video, video with multiple or changing SPS with different timing information. The timing information is extracted from the bitstream. Therefore the user doesn't have to specify the default duration/FPS himself anymore. Fix for bugs 434 and 688.

2012-02-26 Moritz Bunkus <moritz@bunkus.org>
* build system: Boost's "rational" library is now required.
* mkvmerge: bug fix: Complete re-write of the (E)AC3 parsing and handling code. Dependent EAC3 frames are now handled correctly. Fix for bug 704 (https://www.bunkus.org/trac/ticket/704).

2012-02-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The width and height of h.264 video tracks with a pixel format other than 4:2:0 are now calculated correctly. Fix for bug 649 (https://www.bunkus.org/trac/ticket/649). Patch by Nicholai Main (see AUTHORS).
* mkvmerge: bug fix: Fixed file type recognition and frame drops for VC1 elementary streams that do not start with a sequence header but with frame or field packets instead.
* mkvmerge: bug fix: Fixed mis-detection as unsupported DV files (happened for e.g. PGS subtitle files).

2012-02-12 Moritz Bunkus <moritz@bunkus.org>
* doc: enhancement: Updates for option file usage and supported subtitle formats.

Have fun.

Kind regards,
mosu

[Selur]

thanks for the new release :)

[sneaker_ger]

http://www.mediafire.com/?lidxnvnc3997dzd

VFR H.264 file with pic-struct, automatic FPS detection results in all timecodes = zero

[Mosu]

Pic struct are not supported yet. You'll have to keep using --default-duration for such files.

However, pic struct parsing is more or less on my TODO list.

[szabi]

probably a 'bug' in MediaInfo,..

It's not a problem of mkvmerge. I've experienced a similar problem for example when both video and audio tags have ENCODER_SETTINGS (it looks like the value of the audio one "overwrites" and hides the video's one). I've seen that both in MPC-HC and VLC but it's so minor it didn't bother me.

Which splitter do you use with mpc-hc?
My experiment only haali splitter reading metadata more or less.
In this case ARTIST is mixed with AUTHOR.
Inbuild of mpc-hc and LAV splitter NOT reading any tag info. :rolleyes:

Anyway it means there is a bug in MediaInfo, mpc-hc and vlc as well!?

bye
szabi

[Mosu]

Well, all these talk about tags is definitely off-topic in this thread. Please move it over to a more appropriate one (MediaInfo support or whatever) or create a new one. Thanks.

[DragonQ]

There is nothing like 25i. 25i would mean 12.5 frames per second. If your material is 50 interlaced frames/fields then you use 50i.
Actually, the European Broadcasting Union notation uses the frame rate rather than field rate. So in this notation, a video with 50 interlaced fields per second is "25i". A 1920x1080 video of the same type is "1080i/25".

[Mosu]

Quoting http://en.wikipedia.org/wiki/1080i :

The frame rate can be implied by the context, while the field rate is generally specified after the letter i, such as "1080i60". In this case 1080i60 refers to 60 fields per second. The European Broadcasting Union (EBU) prefers to use the resolution and frame rate (not field rate) separated by a slash, as in 1080i/30 and 1080i/25, likewise 480i/30 and 576i/25.[1] Resolutions of 1080i60 or 1080i50 often refers to 1080i/30 or 1080i/25 in EBU notation.

You'll note that in neither case is the 'i' postfixed to the frame/field rate, but to the resolution. "25i" vs "1234i25". See the difference?

OK, there's also nothing like a pure "50i" in high def broadcasting... however, for mkvmerge the resolution doesn't matter in this case. Therefore I only needed a way to describe the number of frames per second.

Maybe I shouldn't have introduced those values after all ~~ Too much damn confusion.

[DragonQ]

Hmm true, I guess "50i" by itself is acceptable notation (and certainly used very often). I wasn't talking about the new options in MKV Merge, just your comment from this thread. The new options for frame rate are definitely useful, IMO.

[mbcd]

http://forum.doom9.org/showthread.php?p=1563669#post1563669 ;)

:confused:
:confused:

Welcome into the world of crazy framerates Mosu ... ;)

Thats why I suggested to deal only with FULLFRAMES, to get a right definition --> How much fullframes you have per second ?

Thats because the future is in progressive material, so I think its better to handle with progressive values.

Its hard to deal with. Problem is, that in future even 50p/60p or 100p might get around, so dealing with assigned values could give some problems in future. Some Camcoder are able to deal with 50p, so ...

If you only take care of DVD or BD (PAL/NTSC) you wont get problems there, so only a hint of mine ... if you want change it in future again, then there must be a clear way for definition now.

[sneaker_ger]

Its hard to deal with. Problem is, that in future even 50p/60p or 100p might get around, so dealing with assigned values could give some problems in future

I suppose that's why there's also "50p" and "60p" to choose from...
(And you don't have to wait for the future, 50p is already used for broadcasting and Blu-Ray.)

[DragonQ]

BD only supports 50p or 60p at 1280x720 resolution, unfortunately. Although ATSC and DVB both support 1080p/50 and 1080p/60, I don't think these are currently used anywhere. Fortunately, DVB's "Scalable Video Coding" support means that older hardware that pre-dates 1080p/50 should just use the 1080i/25 "part" of the stream rather than crash or whatever. So, in theory, the switch to 1080p/50 can be made at any point in the future without affecting current consumer hardware.

I guess the timescale of the switch depends on what existing infrastructure broadcasters have in place - if they've shelled out on suites that only support up to 1080i/25 (or 30) then they're not gonna switch to 1080p/50 (or 60) any time soon, even though it shouldn't require any more bandwidth to broadcast. This is why they should've just ditched interlaced broadcasting from the beginning when HD standards were devised. >_>

[sneaker_ger]

No one was talking about 1080, right?
There are 720p50 Blu-Rays and DVB broadcasting channels. Also, users may want to deinterlace 1080i content to 50p/60p and store it in a Matroska file.

Anyhow, I didn't really want to start a discussion about it, just point out that these rates are not that uncommon and that mmg already has these values in the drop down box.

[hello_hello]

Just an "out of curiosity" question.....

I have two identical PCs. Well almost identical. They have exactly the same hardware aside from the CPU. One is a Q9450 and the other an E6750. Both CPUs usually run at the same clock speed, although currently the quad is slightly overclocked (3.2GHz) while the dual core is running at stock speed (2.67GHz). The Windows (XP) and programs installations are also identical. I installed everything on one PC, imaged the setup, then "restored" that image to the second PC.

So my question is, why does MKVMergeGUI take two or three times longer to open on the PC with the quad core CPU than it does when opening it on the PC with the dual core CPU? I just opened MKVMergeGUI on each PC, shut it down, then opened it again and timed how long it took (to ensure I wasn't opening it for the first time on one PC but not the other). 2 to 3 seconds to open using the dual core, 6 to 7 seconds using the quad core. The time it takes to open has always been slower using the quad core regardless of which version of MKVToolNix has been installed, yet for any other software, I can't say I've ever noticed a difference.

It's no big deal at all, but I've always wondered "why?"

[Snowknight26]

Process Monitor should tell you.

[Mosu]

It's no big deal at all, but I've always wondered "why?"

I have no idea :) However, I'm curious, too. So here's a special debug build for your: http://www.bunkus.org/videotools/mkvtoolnix/win32/debug/ (build 424)

Install it, run mmg, quit mmg. mmg will write a small text log file to your temporary files folder called "mmg-startup-time-debug.log". Please send me that file to moritz@bunkus.org -- and let's continue the rest of the debugging session via email, please.

If you don't know how to find your temporary files folder: for me it's something like C:\Users\mosu\AppData\Local\Temp. You can also use Windows' search functionality for the file name mentioned above.

[hello_hello]

Please send me that file to moritz@bunkus.org -- and let's continue the rest of the debugging session via email, please.

Email sent.

Cheers.

[Lincoln Burrows]

I noticed MKVToolnix is not warning us the fps will be set to 25 when opening .264 files (original source is MPEG-4 AVC). This one was extracted from a Blu-ray (I used TSMuxer GUI on a m2ts file), released in US. I usually informed this setting in the MKVToolnix fps tab:

http://i.imgur.com/iziy7.png

Can you confirm if we need to keep doing that or if it's not necessary anymore?

[Selur]

should not be necessary due to the h.264 parsing rewrite,... ;)

[DragonQ]

Yeah I think it reads the timecodes (or maybe the stream header, or both) from the file to determine the frame rate now. There was a big rewrite in between 5.3.0 and 5.4.0 and I for one am very grateful since it fixed the muxing of UK TV streams. :)

[Mosu]

Can you confirm if we need to keep doing that or if it's not necessary anymore?

http://forum.doom9.org/showthread.php?p=1564296#post1564296

[Chumbo]

@hello_hello,
In addition to what Mosu provided for debugging, there are great tools available in the Sysinternals Suite available here (http://technet.microsoft.com/en-us/sysinternals/bb842062). In your case, Process Monitor would be very handy as you can set it to monitor the specific executable for MKVToolnix and monitor all activity to see where the bottleneck is occurring.

[sneaker_ger]

Some parts of your homepage are no longer visible in the browser, but appear as downloads. The changelog for example.

[Mosu]

I've switched from Apache to nginx last week. Looks like nginx uses application/octet-stream for files without extension. Will fix; should only concern ChangeLog and README so far.

[Mosu]

Fixed. Thanks for noticing. If you still get the download on at least those two files then it's your browser that's caching.

[Mosu]

http://www.mediafire.com/?lidxnvnc3997dzd

VFR H.264 file with pic-struct, automatic FPS detection results in all timecodes = zero

That particular file will always require user intervention. Yes, it does contain picture timing SEIs, but those do not contain a clock timestamp. Furthermore the timing parameters in the SPS are as follows: num_units_in_tick = 1, time_scale = 2000000000 -- meaning that each frame is supposed to have a duration of 1 nanosecond. No wonder all timecodes are 0.

The bitstream itself simply doesn't provide useful/enough information for mkvmerge to work with.

[MasterNobody]

Furthermore the timing parameters in the SPS are as follows: num_units_in_tick = 1, time_scale = 2000000000 -- meaning that each frame is supposed to have a duration of 1 nanosecond.
No, as it is VFR so it only means that minimum tick interval between frames is 1 ns (precision of timebase). It doesn't say anything about average frame duration (it is of course higher than minimum). And yes, there is no ways to get real frame durations here from elementary stream (bad idea to encode VFR without container with timestamp support).

P.S. If you output VFR to raw elementary stream it better to consider using --tcfile-out option.

[kieranrk]

Yes, it does contain picture timing SEIs, but those do not contain a clock timestamp.

Whilst I appreciate MKV incorrectly uses timecode and timestamp interchangeably, you should not be using any of the timecodes present in the picture timing SEIs since timecodes != timestamps.

[Mosu]

At the moment mkvmerge doesn't use them at all. However, I don't see the harm in using them in one specific way and in one specific situation. The situation: if and only if the source file is a raw h.264, the user hasn't specified an external timecode file for that track. The way: use them as they are but zero-base them -- meaning subtract the smallest of them from all of them.

BTW: The h.264 specs talk about "clock timestamps" for the stuff in the picture timing SEIs, not about "timecodes present in the picture timing SEIs" as you do. Simple error on your part? And why should I not use them at all?

[tormento]

Mosu: could you please make MMG recognize the stream language from the first three characters of the filename? Let's say iso_filename... Sometimes I have to mux lot of files and one step less should make me faster.

[Mosu]

No, sorry. That would be catering to a very small minority of users. It would also mean way too many false positives as there are tons of ISO language codes that are prefixes of perfectly normal words.

[kieranrk]

BTW: The h.264 specs talk about "clock timestamps" for the stuff in the picture timing SEIs, not about "timecodes present in the picture timing SEIs" as you do. Simple error on your part? And why should I not use them at all?

It's probably because it has been abstracted away by JVT from the original definition of timecode because not all applications are the same. However, it's clear this field is meant to be the same as the MPEG-2 timecode field.

[szabi]

Since the new update to version 540, runtime error-application closing occurs when i click on video tag button.

bye
szabi

[Mosu]

Thanks for noticing, I can reproduce it. Will investigate.

[Mosu]

Fixed in builds 429 and higher: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

[szabi]

Thnx, checking. :thanks:
I tought it was only for me, because the offtopic tagging discussion (http://forum.doom9.org/showthread.php?p=1564434#post1564434). :D

bye
szabi

[Mosu]

Well, that particular bug had been present for a couple of years, and only pure luck prevented the app from crashing at that point until now.

[tormento]

No, sorry. That would be catering to a very small minority of users. It would also mean way too many false positives as there are tons of ISO language codes that are prefixes of perfectly normal words.
There could be a special char between the iso and the filename, such as _ or # or some other ASCII...

[Selur]

Sorry, but for me the whole get parameters from a 'user created&named'-file just sounds like a bad idea. If the whole thing is done by a program that looks over the whole naming, it's not a problem, but as things are this would still lead to tons of false positives, for people that are not aware that they are not allowed to use this char in their filenames.

Cu Selur

[mbcd]

Of course you cant catch all variants, but what about pattern:

(DE) (EN)
, german, , english,

, de, , en,


As I said before, there are some main programs out there which might be the most popular tools for handling audio and video.

Build in some pattern for handling those filenames should not be that bad, and whats negative if there is a false ?

If you dont have any recognizion, you have to set e.g. language-field from "und" to "eng".
If you have a false recognizion, you have to set language-fiels from "rus" to "eng".
If you have correct recognizion, you have to set : nothing.
So you dont have more work, even if recognizion is false, its not more work, but on the other hand: it could be less work.

I think only few people do not set languages, so I dont see any problems to implement a few patterns. Normaly you check settings bevore muxing, so I you use a pattern which is not known correctly by mmg you have to check, if you know the pattern is known, you dont have ...

[Selur]

If you dont have any recognizion, you have to set e.g. language-field from "und" to "eng".
which doesn't change a thing, since 'und' and 'eng' are the same. ;)

If you have a false recognizion, you have to set language-fiels from "rus" to "eng".
only if you recheck, the fields, if you don't the auto-detection might set a false value.

@Mosu: if you implement something like this, please only implement it for mmg, not for mkvmerge. (I normally don't use mmg, so I can live with 'strange things happening when one uses mmg'. ;))

[sneaker_ger]

which doesn't change a thing, since 'und' and 'eng' are the same. ;)

They are not.
"und" is not the same as an empty language field.

[Selur]

"und" is not the same as an empty language field.
which is the same as 'eng' (since eng is the default value if there is no track language :) and iirc no matter if you set 'und' or 'eng' mkvmerge does not write a language flag in both cases ;))

[sneaker_ger]

If you don't specify a language (and the source container does not have that info) mkvmerge will explicitly write "und". Otherwise there would be no way to distinguish between English and undefined. "eng" is the standard value of the matroska spec, not what mkvmerge writes by default.

[Selur]

let's wait what Mosu has to say, but afaik you can't distinguish between English and undefined (and this has probably been discussed in this thread before,.. ;))

[sneaker_ger]

Well, you could easily confirm it with the header editor:
Mux two tracks, for one you set "eng" and for the other you let it at "und". Then open the file with the header editor and look at the language value of each track. The first track will have no language element and the second track will have "und". Also note that "und", "eng" and "remove element" are three separate options in the header editor.
Also MediaInfo, LAV Splitter, MPC-HC's Splitter etc. will differ between those.

[Mosu]

which doesn't change a thing, since 'und' and 'eng' are the same. ;)

No, they aren't. "und" stands for "undefined" which means that the language is either not known or that the concept of "language" isn't applicable to a track.

[Selur]

Okay, so 'eng' <> 'no track set'. :)

[Mosu]

To elaborate.

The Matroska specs say that "eng" is the default value of the "TrackLanguage" attribute. This means that if the track headers do NOT contain a copy of the "TrackLanguage" element then an application reading the file must treat that track as if the "TrackLanguage" was actually present and was set to "eng". That's the meaning of "default value" regarding the Matroska specs. Nothing more.

"eng" and "und" are two different and distinct possible values for the "TrackLanguage" element. The former says the obvious: the track is in English. Simple.

The latter says that the person creating the file did not know about the language, did not care about it or that the concept of "language" is not applicable to this track (e.g. a video track without any text showing up).

Now to mkvmerge. If the user does NOT specify the track's language then mkvmerge will assume that the person creating the file did not know about the language, did not care about it or that the concept of "language" is not applicable to this track (e.g. a video track without any text showing up). Therefore it sets "TrackLanguage" to "und" (undefined).

This is one of the few cases in which mkvmerge's default value for one of mkvmerge's options does not equal the default value of the corresponding Matroska item from the Matroska specs.

[Thunderbolt8]

I always use 'und' for silent movies and then use the language identifier for the video track (which usually gets 'und' for my movies, because usually video track itself doesnt really have any language)

[Chetwood]

I never bothered to set this value for video tracks or chapter files.

[DragonQ]

I always set video tracks to English if that's what's being spoken by the actors. For example, if a film is natively English but you're watching a version with French dubbing then I would say it makes sense to set the video track to English and the audio track to French.

I kinda assumed it made no difference but I'm a completist. :)

[nevcairiel]

Unless the video has burned-in forced subtitles or other image captions, its really more language neutral.... :)

[Mosu]

Well, it might make sense for hearing-impaired people who can read lips. Though I guess that might be a very small minority :)

[hubblec4]

hi Mosu

i have used a chapter.xml with a special command from the mkv specs: <ChapProcessCodecID>

mmg shows this error.

Error: Chapter parser failed for '***\kap 2Editions-test.xml', line 3, column 0: <ChapProcessCodecID> is not a valid child element of <Chapters>.


this is the line from the xml: <ChapProcessCodecID>0</ChapProcessCodecID>
is it worng or is this type not supported by mmg/mkvmerge?

[b66pak]

i have noticed that h264 raw with no fps info is muxed by default to 25fps without any warning...may be reverting to the old "no fps info" warning will be a good ideea for this kind of special case...not everybody is aware of what is muxing and this situation could lead to out of sync av...
_

[Mosu]

hi Mosu

i have used a chapter.xml with a special command from the mkv specs: <ChapProcessCodecID>

The names used by mkvmerge do not always match the specs. Instead, they mostly match libmatroska. For all chapter related elements the names start with "Chapter" and not "Chap", hence <ChapterProcessCodecID>.

[Mosu]

i have noticed that h264 raw with no fps info is muxed by default to 25fps without any warning...may be reverting to the old "no fps info" warning will be a good ideea for this kind of special case...not everybody is aware of what is muxing and this situation could lead to out of sync av...
_

Yeah well, maybe I'll implement such a warning one day. Maybe not.

[hubblec4]

The names used by mkvmerge do not always match the specs. Instead, they mostly match libmatroska. For all chapter related elements the names start with "Chapter" and not "Chap", hence <ChapterProcessCodecID>.

i tested it with "ChapterProcess", but it fails too.

the ChapProcess is a subcommand of the Chapter entry.

my xml-file started with <Chapters>

it looks like so:

<Chapters>
<ChapProcess>
<ChapProcessCodecID>0</ChapProcessCodecID>
<GotoAndPlay>1111100000</GotoAndPlay>
<GotoAndPlay>2222200000</GotoAndPlay>
<EditionEntry>
<EditionUID>1111100000</EditionUID>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>1</EditionFlagDefault>
<EditionFlagOrdered>1</EditionFlagOrdered>
<ChapterAtom><ChapterUID>1111100001</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterTimeEnd>00:02:58.360000000</ChapterTimeEnd>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterDisplay>
<ChapterString>Chapter 1</ChapterString>
<ChapterLanguage>und</ChapterLanguage>
....

i will try to use the Menu function of mkv. (Matroska-Specs (http://matroska.org/technical/specs/index.html)) Below on this side you find information for the Menu entry.
it would be nice if you have a look at this. Perhaps you can implement this in a future version.

[Mosu]

<ChapProcess> mus be <ChapterProcess>. <ChapterProcess> is a level 4 element (look at the specs!), meaning it is a child of <ChapterAtom>.

Please don't post results test cases in which you obviously did NOT change "Chap" to "Chapter". Thanks.

[hubblec4]

thanks for the information. it works with <ChapterProcess>

But GotoandPlay seems to be wrong:
"...
2Editions-test.xml', line 13, column 0: <GotoAndPlay> is not a valid child element of <ChapterProcess>.
..."

Do you have a tip for me.

[Mosu]

GotoAndPlay is not mentioned in the Matroska specs. Where did you find those?

[hubblec4]

GotoAndPlay is not mentioned in the Matroska specs. Where did you find those?

i found this in the matroska-specs
Menu features (http://matroska.org/technical/specs/chapters/index.html#dvd) (scroll a little bit up.

...The one and only command existing for the moment is GotoAndPlay( ChapterUID );. As the same suggests, it means that when this command is encountered, the playback should jump to the Chapter specified by the UID and play it....

[robpdotcom]

Not trying to change this into a chapters thread, but while we're on the subject.... Is ChapterSegmentEditionUID supported by mmg, or am I using it wrong? When I try to drag it into the Chapter Editor, I get the "Does not contain valid chapters" error.

<?xml version="1.0" encoding="UTF-8"?>

<!-- <!DOCTYPE Tags SYSTEM "matroskatags.dtd"> -->

<Chapters>
<EditionEntry>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>1</EditionFlagDefault>
<EditionFlagOrdered>1</EditionFlagOrdered>
<EditionUID>2927856557</EditionUID>
<ChapterAtom>
<ChapterUID>56485314556</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterTimeEnd>02:18:37.412600000</ChapterTimeEnd>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterSegmentUID format="hex">
f7 3d e7 44 df 72 96 6c 58 b9 2b 9f 65 ce f5 76
</ChapterSegmentUID>
<ChapterSegmentEditionUID>1248654321</ChapterSegmentEditionUID>
<ChapterDisplay>
<ChapterString>Part II</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
</EditionEntry>
</Chapters>

[Mosu]

i found this in the matroska-specs
Menu features (http://matroska.org/technical/specs/chapters/index.html#dvd) (scroll a little bit up.

...The one and only command existing for the moment is GotoAndPlay( ChapterUID );. As the same suggests, it means that when this command is encountered, the playback should jump to the Chapter specified by the UID and play it....

Quoting from the specs: "The scripts are stored in ChapProcessData." And not as XML elements, but as binary data (ChapterProcessData is an EBML binary). I have no examples for you how to use this properly as I don't think any software has ever implemented support for this.

[Mosu]

Not trying to change this into a chapters thread, but while we're on the subject.... Is ChapterSegmentEditionUID supported by mmg, or am I using it wrong? When I try to drag it into the Chapter Editor, I get the "Does not contain valid chapters" error.

ChapterEditionSegmentUID is a binary. If you use a tag for a binary element without a "format" attribute then it is assumed to contain Base64 encoded data. For pure ASCII content you can use "<ChapterEditionSegmentUID format="ascii">1234567890...</ChapterEditionSegmentUID>".

[Mosu]

Hmm... I just noticed that libmatroska lists that element as an "unsigned integer" while the specs list it as a "binary". This is a bug in libmatroska that I'll have to fix.

[Mosu]

ChapterEditionSegmentUID is a binary. If you use a tag for a binary element without a "format" attribute then it is assumed to contain Base64 encoded data. For pure ASCII content you can use "<ChapterEditionSegmentUID format="ascii">1234567890...</ChapterEditionSegmentUID>".

I was wrong. Both the specs and libmatroska say that it's an unsigned integer. No bug there. My answer is simply wrong. Also: the XML file you've posted works fine with a mkvmerge build that I haven't released yet. I'm re-writing the complete XML handling code at the moment, and chapters and tags are done. The old code did indeed not recognize ChapterEditionSegmentUID while the new code does. This will be part of the next release, v5.5.0, and I might offer a new Windows build including that code in the next couple of days.

[robpdotcom]

Thanks Mosu. I always hate asking unrelated questions, but now I'm glad I did.;)

[Mosu]

Hey,

I've finally implemented one of the more-often asked for features (https://trac.bunkus.org/ticket/518). mkvmerge can now copy only requested ranges of timecodes. Think of it as splitting by timecodes without writing undesired parts at all. It can even do a bit more: you can tell mkvmerge to write a range to the same file as the previous range.

This is implemented as another syntax for the "--split" option: "--split parts:....". mmg has received the usual update with its own control for that option.

The full documentation for the syntax is available: http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split and I really suggest you read it and its examples before trying it out :)

The usual restrictions to mkvmerge's "--split" option still apply: mkvmerge will only do something on a key frame.

This feature requires some testing though, and that's where you come in :) I've provided a build for Windows at http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (build numbers 433 and higher). Please test and report issues, feedback etc. Thanks.

BTW: Nope, this is not an April fool's joke.

[Selur]

Thanks! Nice!
This feature is really appreciated!
Only missing feature for me regarding splitting is now a --split frame:.. option which works analog to parts:.. but with frame numbers instead of time codes ;)

Cu Selur

[LeMoi]

Is this included in the GUI ?

[Selur]

yes,.. mosu wrote:
mmg has received the usual update with its own control for that option.

[cengizhan]

Hey,

I've finally implemented one of the more-often asked for features (https://trac.bunkus.org/ticket/518). mkvmerge can now copy only requested ranges of timecodes.
....
BTW: Nope, this is not an April fool's joke.

:thanks:

[robpdotcom]

This may be a regression:

I created a chapter file, opened with mmg (the latest version, with the "Split by parts" option), and saved. For the lines <ChapterSegmentUID format="hex">, the segment UID was changed. Opening and saving with older versions of mmg reverses the change.

After saving with old mmg:

<?xml version="1.0" encoding="UTF-8"?>

<!-- <!DOCTYPE Tags SYSTEM "matroskatags.dtd"> -->

<Chapters>
<EditionEntry>
<EditionUID>2606402697</EditionUID>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>0</EditionFlagDefault>
<EditionFlagOrdered>1</EditionFlagOrdered>
<ChapterAtom>
<ChapterUID>90723729</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterTimeEnd>00:00:07.200000000</ChapterTimeEnd>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterSegmentUID format="hex">
b4 1c 1c d0 de c8 84 84 8e a9 b5 c7 7d 5e c6 d3
</ChapterSegmentUID>
<ChapterDisplay>
<ChapterString>1</ChapterString>
<ChapterLanguage>und</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
</EditionEntry>
</Chapters>


After saving with latest mmg:

<?xml version="1.0"?>
<!-- <!DOCTYPE Chapters SYSTEM "matroskachapters.dtd"> -->
<Chapters>
<EditionEntry>
<EditionUID>2606402697</EditionUID>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>0</EditionFlagDefault>
<EditionFlagOrdered>1</EditionFlagOrdered>
<ChapterAtom>
<ChapterUID>90723729</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterTimeEnd>00:00:07.200000000</ChapterTimeEnd>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterSegmentUID format="hex">0xb4 0x1c 0x1c 0xd0 0xde 0xc8 0x84 0x84 0x8e 0xa9 0xb5 0xc7 0x7d 0x5e 0xc6 0xd3 </ChapterSegmentUID>
<ChapterDisplay>
<ChapterString>1</ChapterString>
<ChapterLanguage>und</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
</EditionEntry>
</Chapters>

[Mosu]

That is not a regression. I've completely rewritten the XML handling code. That he XML files don't look he same is OK. Even if elements occur in a different order is OK because Matroska itself does not impose an order (apart from a few places that are not relevant to the current discussion) . As long as the element's content is the same (and it is in this case) everything's fine.

[robpdotcom]

Gotcha. The chapters do still work fine, unless I do this (this is how I discovered something had changed):

Save the file with the new mmg > Open the file in GDS Mux (I use it because it makes adding ordered chapters easy). > Add a new ordered chapter (I copy/paste the segment UID from mmg's Header Editor). > Save, and use mmg to add it to the mkv. > The ordered chapters no longer work.

It happens like this:

I create an ordered chapter file, with a segment UID: b4 1c 1c d0 de c8 84 84 8e a9 b5 c7 7d 5e c6 d3

Open in mmg, save, the UID changes to: 0xb4 0x1c 0x1c 0xd0 0xde 0xc8 0x84 0x84 0x8e 0xa9 0xb5 0xc7 0x7d 0x5e 0xc6 0xd3

Open in GDS Mux, save.

I open the file in the new mmg again, save, and the UID gets changed again, to this: 0x0b 0x40 0x1c 0x01 0xc0 0xd0 0x0d 0xe0 0xc8 0x08 0x40 0x84 0x08 0xe0 0xa9 0x0b 0x50 0xc7 0x07 0xd0 0x5e 0x0c 0x60 0xd3

Apparently, GDS Mux is to blame, but I thought I would pass this along just in case it was useful.

[Mosu]

Let me get this right: GDSMux is not reading the actual XML file, but you're copy & pasting from mmg's XML file into an input control in GDSMux?

Either way, I could be technical and say "I don't care, this is solely mkvmerge's/mmg's format", but adding back the "0x" prefix is so damn trivial that I'll just do it.

[robpdotcom]

Let me get this right: GDSMux is not reading the actual XML file, but you're copy & pasting from mmg's XML file into an input control in GDSMux?

No. Through some experimentation, I found that if I: Load the XML with GDSMux > make no changes > save > open with mmg > save > mmg will try to add the 0x prefix, even though it is already there. But this only happens if I open/save the XML with GDSMux - opening it with notepad, extracting with mkvExtract, etc, all work fine.

[Mosu]

mmg, in its current build, will never add a "0x" prefix when it writes an XML file. The "0x" prefix is purely syntactic sugar for hexadecimal numbers. When mmg reads an XML file it silently discards all "0x" prefixes as if they weren't there.

The "0x" prefixes are ALSO not part of a Matroska file (!). Instead the hexadecimal numbers are converted into binary bytes -- that's the whole reason we're dealing with hex numbers in the first place. You could express the very same _content_ in a Base64 encoding, or, if all of those binary bytes were in the ASCII range, you could even write them out in ASCII.

[Mosu]

I have to apologize. It's exactly the other way around.

Before the XML rewrite the various XML writer routines did not prefix each hex digit pair with "0x". After the XML code rewrite they do.

However, in both cases the "0x" is still syntactic sugar. Neither mkvmerge nor mmg care whether or not a hex digit pair is prefixed with "0x". The hex digit still gets converted to the very same byte in Matroska, e.g. "0x54" would get converted to "T". As a matter of fact with the new code all of the following examples will all result in exactly the same value inside a Matroska file:

<ChapterSegmentUID format="hex">
b4 1c 1c d0 de c8 84 84 8e a9 b5 c7 7d 5e c6 d3
</ChapterSegmentUID>
<ChapterSegmentUID format="hex">0xb4 0x1c 0x1c 0xd0 0xde 0xc8 0x84 0x84 0x8e 0xa9 0xb5 0xc7 0x7d 0x5e 0xc6 0xd3 </ChapterSegmentUID>
<ChapterSegmentUID format="hex">b4 1c 1c d0 de c8 84 84 8e a9 b5 c7 7d 5e c6 d3</ChapterSegmentUID>
<ChapterSegmentUID format="hex">b41c1cd0dec884848ea9b5c77d5ec6d3</ChapterSegmentUID>
<ChapterSegmentUID format="hex">b4 0x1c 1c d0 de 0xc8 84 84 8e a9 0xb5

c7 0x7d 5e c6 d3</ChapterSegmentUID>

Note that earlier versions of mkvmerge/mmg (before the XML rewrite) could just as well deal with all of those examples above. Like I said, having "0x" there or not makes no difference to MKVToolNix.

I'll try to reproduce your issue with GDSMux later.

[Mosu]

What GDSMux does is being lazy. It simply removes everything that is not a valid hex digit (0-9, a-f) and writes the rest into the XML file. This includes spaces and the 'x', but not the '0' of the '0x' prefix. Interestingly it only does this when writing the XML file, not when loading it. I consider this at least a bug.

Even if you only load an XML file that does NOT have the ChapterSegmentUID element in it and then copy & paste to the "Segment ID" control in GDSMux and then save it will still mess it up by only removing 'x' but not '0x'. Still a bug.

But we all know Haali, right? He's going to fix this... never. So I'm changing back to not writing '0x' prefixes because, like I said, MKVToolNix simply doesn't care.

However, don't expect me to pay homage to braindead programs forever, please :)

[Mosu]

And here you go (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) (builds 434 and newer, still building, should be done in five minutes or so).

[robpdotcom]

I really don't expect you to work around other programs bugs, and I don't blame you if you don't. I just noticed that something which used to work no longer did, so I was passing it along.

To be honest, if I were you I probably wouldn't change anything. Hell, it seems like I'm very much alone when it comes to using ordered chapters, and I can always use notepad to write them.;) If Haali weren't the only splitter to support ordered chapters, I probably wouldn't even have it on my system, and I'd be using notepad anyway.

While we're on the subject, will something similar ever be added to mmg's chapter editor? Should I add a request on the "Re-write of mmg" thread?

Anyway, thanks for the explanations, and thanks for all your work.

[Mosu]

Sure, post on the re-write thread. If/when I get around to doing it the chapter editor will definitely be different than it is now :) Please describe what GDSMux does what the current one doesn't regarding ordered chapters -- I never use GDSMux and couldn't tell myself.

[robpdotcom]

lol It seems no one besides me uses GDSMux. All it does is have a checkbox for ordered chapters (to write <EditionFlagOrdered>1</EditionFlagOrdered> to the XML) and provide a box to enter a segment UID. I'll post it on the re-write thread.

Thanks again.

[hubblec4]

i use GDSMux too, because its simple there to generate ordered chapter xml files.
but the files which saved and load in Notepad++ looks not good. all lines written in one and its looks confused.

The best feature in mmg chapter editor is the "Adjust timecodes".

[hubblec4]

...
Hell, it seems like I'm very much alone when it comes to using ordered chapters, and I can always use notepad to write them.;) If Haali weren't the only splitter to support ordered chapters, I probably wouldn't even have it on my system, and I'd be using notepad anyway.


your are not alone with ordered chapters, i use it too.

And i see the same problem with a perfect ordered-chapter-splitter.
Haali works very well, but with the DTS-HD MA or Flac7.1 sound the video plays not good.

The best alternitiv is AVSplitter. It works in ever case!

I hope that Nev will update the LAV Splitter, but it seems it will do not this year :-(

[Mosu]

Hey,

I've released MKVToolNix v5.5.0. It fixes a few issues all across the board. The XML handling has been completely rewritten resulting in the tag, chapter and segment info XML files supporting more of the Matroska specs. A new mode for "--split" has been implemented that let's you keep certain ranges and discard others without the need for temporary files or multiple muxing passes.

A note for package maintainers: Boost's "lexical_cast" and "type traits" libraries is now required. expat is not used anymore.

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

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.5.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.5.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.4.0:

2012-04-06 Moritz Bunkus <moritz@bunkus.org>
* Released v5.5.0.
* Build system: Boost's "lexical_cast" and "type traits" libraries are now required.
* mmg: new feature: Added GUI controls for mkvmerge's "file concatenation" feature as "additional file parts". The user can chose which individual files are treated as if they were a single huge source file.
* mkvmerge: bug fix: The handling of the "do not read other files" options (e.g. "=file.vob" and "( file.vob )") was broken for MPEG program stream files.

2012-04-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a wrong assertion about minimum MPEG 1/2 video start code lengths. Fixes ticket 728 (https://www.bunkus.org/trac/ticket/728).

2012-03-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: new feature: Added support for keeping only certain timecode ranges from the source files with a new format to "--split": "--split parts:...". Implements ticket #518 (https://www.bunkus.org/trac/ticket/518).

2012-03-30 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added an option in the preferences dialog called "clear jobs from the job queue after they've been run". Can be set to "only if run was successfull", "even if there were warnings" and "even if there were errors". Defaults to off.

2012-03-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract, mmg: Re-write of the whole XML handling code. It now uses the "pugixml" C++ library instead of the "expat" library. Therefore "expat" is not required for building MKVToolNix anymore. And neither is Boost's "property tree" library. "pugixml" itself is included and not an external requirement either.
* Build system: removed all files and documentation related to building MKVToolNix with Microsoft's Visual Studio because even the most recent version of Visual C++ does not support the C++11 features required for MKVToolNix.
* mkvmerge, mkvextract: removal: Removed support for the CorePicture file format. It was mostly unused and relied on old code that will be removed soon.
* documentation: enhancement: mkvmerge's man page has been updated with a list of valid XML tags for the chapters, tags and segment info XML file formats.
* all: Updated the DTD files with the newly supported elements.
* mkvmerge: enhancement: Chapter XML files: mkvmerge can handle the "ChapterSegmentEditionUID" element.
* mkvmerge: enhancement: Segment info XML files: mkvmerge can handle the "SegmentFilename", "PreviousSegmentFilename" and "NextSegmentFilename" elements.

2012-03-19 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Added "mts" as yet another file extension for MPEG transport streams.

2012-03-18 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed a crash due to a missing argument for a format string when clicking on the "Browse" button for the track-specific tags.

2012-03-15 Moritz Bunkus <moritz@bunkus.org>
* mmg, mkvinfo's GUI, all .exes: enhancement: Added new icons by Eduard Geier. (see AUTHORS).

2012-03-14 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: mkvextract sometimes wrote undefined values to a single reserved header field when extracting into AVI files. Patch by buguser128k. Fix for ticket 727 (https://www.bunkus.org/trac/ticket/727).
* mkvmerge: bug fix: AVC/h.264 mkvmerge was wrongfully writing a default duration of 60 frames/fields even if the source was signalling 60000/1001 frames/fields. The frame timecodes have been correct already.

2012-03-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed timecode calculation for (E)AC3 tracks if the source container (e.g. MPEG transport streams) only provided timecodes for some of the (E)AC3 packets itself.

Have fun.

[wanezhiling]

Thanks Mosu.:)

[Sparktank]

Awesome stuff!!!

I was just running eac3to through a "test" to see how my codecs are doing with it and saw the notification that MKVToolnix has been updated.
I got all excited about it and just had to jump on it right away.

Excellent work, as always! :)

[b66pak]

thanks a lot...
_

[zn]

thanks for #518

2012-03-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: new feature: Added support for keeping only certain timecode ranges from the source files with a new format to "--split": "--split parts:...". Implements ticket #518 (https://www.bunkus.org/trac/ticket/518).

[hello_hello]

Thanks for the new version (5.5.0). BTW, I like the new yo-yo icon. ;)

[Mosu]

Unfortunately the original implementation of the --split parts:... feature contained quite a few bugs: 737 (https://trac.bunkus.org/ticket/737) 738 (https://trac.bunkus.org/ticket/738) 739 (https://trac.bunkus.org/ticket/739) 740 (https://trac.bunkus.org/ticket/740) 742 (https://trac.bunkus.org/ticket/742).

They’ve all been fixed now. But I suggest you get the latest pre-build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) if you want to use this feature. Build numbers 436 and higher include all the fixes.

[FCBarca]

Been trying to figure out how to mux audio into a video file with mkvtoolnix on my MBP...I have a 1080i russian video of a match that I wanted to mux in english broadcast from another file...There's a gap, a couple really...The video on the russian cap has around 1 min less to the start ahead of the whistle than the english cap does...Any tips on how to get this muxed in well?

First attempt at muxing things initially looked good as I added a negative delay to the audio track which seemed to sync perfectly..Then I realized a bit later that the original russian cap has a 12 second video hiccup which loses 12 seconds of video/audio...and of course puts the newly muxed audio track out of sync once again from that point...Can I do multiple syncs or muxes or is there nothing to be done

[sneaker_ger]

You could do it in two steps:
1. Use the new "--split parts:" (see Mosu's post above for latest pre) to cut out the 12 seconds from the English cap
2. Then merge the new file's audio with your Russian cap

(it is theoretically possible to keep the audio and freeze frame the video for 12 seconds, but you would have to manually edit the timecodes or do a combination of clever splits/cats, which is not for beginners and players may not like it)

[Fullmetal Encoder]

Mosu,

Thanks a lot for your work on recent improvements to add the split functionality. It expands the usefulness of the tool tremendously.

I had a couple questions about how mmg/mkvmerge works with VOB and M2TS files.

Currently, when I drag a VOB into mmg for output into an MKV it grabs all of the VOB's in the current disc. This is extremely useful for me because I deal mostly with television shows where I might want to due a lot of splits with timecodes and I can process a whole disc at once. I would bet that it was easiest for you to implement direct input from VOBs this way too as you don't have to deal with VOB and cell ID numbers. However, if I wanted to do the same with a Blu-ray disc I would have go through the stage of appending each separate M2TS and writing one large M2TS, then importing back into mmg for splits or optionally multiple steps for each individual M2TS. When outputting DVD VOBs to MKV there doesn't appear to be any involved process taking place behind the scenes to append all the tracks together for each VOB.

So I guess my question is, how is mkvmerge/mmg handling these VOBs in the background? And is it possible to have this same effect for whole Blu-ray discs?

Also, a while ago I posted here (http://forum.doom9.org/showthread.php?p=1537956#post1537956) about a few things I'd like mkvmerge to be able to do and you said that it would be too much work. If I could code solutions to these problems in C++ would you consider making them a part of mkvmerge/mmg?

[Mosu]

So I guess my question is, how is mkvmerge/mmg handling these VOBs in the background? And is it possible to have this same effect for whole Blu-ray discs?

First, you have to differentiate between mkvmerge and mmg. mkvmerge's low-level file handling code can treat an arbitrary number of files as a single virtual file so that the upper layers only "see" one big input file. The "upper layers" in this case are all the input file type readers (e.g. the MPEG program stream reader, but just as well the MPEG transport stream reader or even the AVI reader -- though you never see an AVI file split binarily these days).

The difference between the program stream reader and all the other readers is that the program stream reader is the only reader that will actively look for split files even if the user doesn't request it -- e.g. if you execute mkvmerge -o out.mkv VTS_01_1.VOB it will look for VTS_01_2.VOB etc. as well. The reason is that DVD-named VOB files have pretty distinct naming patters while most other cases don't. BluRay simply names the files something like title00001.m2ts etc.

If you want to tell mkvmerge manually to read several (M2)TS files as a single file then the general command line syntax for treating multiple input files as a single file is this:

mkvmerge -o out.mkv ( in-part1.m2ts in-part2.m2ts in-part3.m2ts )

Note the spaces before and after the parenthesis. Also note that most Linux/Unix shells treat parenthesis as special characters, meaning you might have to quote them, e.g. mkvmerge -o out.mkv '(' in-part1.m2ts in-part2.m2ts in-part3.m2ts ')'

Now on to mmg. At the moment mmg only supports knowing which MPEG program stream parts mkvmerge will process and will prevent you from appending them manually. Unfortunately you cannot use the general "treat several files as one" feature with mmg at all currently. The QtMmg re-write that I'm actually working on at the moment will have full support for this feature. But for the time being you're restricted to the command line/option files if you want to use it with mkvmerge.

And here's a fair warning: never use mmg's/mkvmerge's "append" feature for files that have been split binarily. You will use information (packets/frames) at the point where a file ends and the next one starts unless the next file starts with whole packets that are I frames for each track type (even then) -- for VOBs this is never the case, I'm not sure about MPEG TS.

Also, a while ago I posted here (http://forum.doom9.org/showthread.php?p=1537956#post1537956) about a few things I'd like mkvmerge to be able to do and you said that it would be too much work. If I could code solutions to these problems in C++ would you consider making them a part of mkvmerge/mmg?

To 1.: This would be a feature of mmg more than of mkvmerge. Of course you could also try implemented "readers" for DVD idx files / BluRay clip files (or wherever the chapter information is stored for BluRays) that only read chapters from those files but no tracks. I will most likely not accept features for the current mmg anymore due to the re-write. I will accept patches for mkvmerge, but be prepared for a shitload of work -- including updating the documentation for mkvmerge (the man page).

To 2.: Has been implemented.

To 3.: If you want to implement it then go ahead, but you'll have to duplicate the functionality of DVDVobSub (or whatever program is used to create separate VobSubs from DVDs). Again you'll have to parse the DVD idx files in order to create the "text" part of a VobSub.

I also expect any patch to be platform-independent. Meaning you cannot use e.g. a library that's only available on Windows -- and that includes all of DirectX, of course. For DVD reading you can use e.g. libdvdread which is generally the standard way of accessing DVDs in the OpenSource world (e.g. VLC, mplayer etc all use it). I will not accept a dependency on ffmpeg either.

[Selur]

small question: is anyone building mkvmerge&co statically for Mac OS X? (the downloads over at bunkus.org are dynamically linked and don't run on my system out of the box)

Also when there are no static build of mkvmerge&co, is there a way to use mkvmerge&co without having to install/copy a bunch of stuff to the /usr/bin etc folders?
-> okay, never mind. I totally overlooked the Framework folder. :)

[Mosu]

So... There was no problem in the first place, right? If there still is then I suggest you contact Jonathan (http://jonthn.free.fr/MKVtoolnix/CONTACT). He is quite helpful

[Selur]

Not really,.. there was a conflict but it was rooted in my system configuration :)

[Selur]

Okay, there is kind of a problem,.. libmagic, libvorbis are not included in the mac builds, therefore the tools can't handle everything like the windows builds,.. -> I'll write an email to Jonathan,..

[smok3]

small question: is anyone building mkvmerge&co statically for Mac OS X? (the downloads over at bunkus.org are dynamically linked and don't run on my system out of the box)

Can try, but i would need a small (general) guide on what to download/compile first/last, ect?

[Selur]

only thing I know is https://www.bunkus.org/videotools/mkvtoolnix/source.html other than that, it's trial and error ;)
Problem is the configure script doesn't provide a '--enable-static' or similar option, so static might not be possible, but a version with all the libraries included would be fine too. ;)

[smok3]

looks like pain, especially the
sudo apt-get install debhelper \
libogg-dev libvorbis-dev libwxgtk2.8-dev libexpat1-dev zlib1g-dev \
liblzo2-dev libbz2-dev libflac-dev libmagic-dev libboost-dev \
libboost-regex-dev libboost-filesystem-dev libboost-system-dev \
libebml-dev libmatroska-dev libcurl4-gnutls-dev autoconf git-core ruby part (for my noobines).

[Selur]

yup + from what I gathered to war one can't simply add the libraries to the Frameworks folder in the .app :/

[Mosu]

At least on Linux you cannot compile mkvtoolnix statically due to usage of DNS resolving. That's why there's no such option in the first place.

You should REALLY ask Jonathan for his thoughts on compilation. He has done the hard part already, it would probably be easy for him to write it down.

[Selur]

I already wrote an email to Jonathan, got no reply so far.
would be nice if mkvtoolnix could be at least 'stand-alone' on mac; doesn't have to be static a .app file with no extern dependencies would be fine in my view
trying to use the current mac version from Jonathan (without having Xcode and macports installed) is a bad idea since at least these libraries are missing:
libboost_filesystem-mt.dylib
libicuuc.48.dylib
libboost_regex-mt.dylib
libintl.8.dylib
libboost_system-mt.dylib
liblzo2.2.dylib
libiconv.2.dylib
libmagic.1.dylib
libicudata.48.dylib
libogg.0.dylib
libicui18n.48.dylib
libvorbis.0.dylib

-> waiting for a reply from Jonathan, just wanted to list the libraries so others know what to look for,... (btw. here (http://forum.videohelp.com/threads/345428-Batch-extract-srt-from-multiple-Mkv-s) is how I stumbled over the problem,..)

Cu Selur

[J0nThn]

I'm a bit suprised by this behavior of the Mac binaries, in fact they are "static" binaries, and usually when there is a problem of *.dyld missing I receive a lot more e-mails than what I got sofar.

I saw the thread you posted, I can't explain this behavior. I'll make a fresh build that you can try.

Also considering the thread from videohelp, i.e. one of the missing library is /opt/local/lib/libicudata.48.dylib which doesn't exist at all ony my system (I use an alternative path/folder).
It seems to me there is a mixup between binary from another source.

[Selur]

I'll also do a recheck on my mac.

[Selur]

ARGH,.. after deleting half of my system, it seems to work,.. no clue why -> I'm deeply sorry for the commotion

[J0nThn]

No worries. Glad it works that's the most important goal. :)

[hello_hello]

So my question is, why does MKVMergeGUI take two or three times longer to open on the PC with the quad core CPU than it does when opening it on the PC with the dual core CPU?

I have no idea :) However, I'm curious, too. So here's a special debug build for your: http://www.bunkus.org/videotools/mkvtoolnix/win32/debug/ (build 424)

Would it be safe to assume you found the magic tweak? :)
Version 5.5.0 seems to open much quicker using the quad core.

Cheers.

[Mosu]

That assumption would be wrong. I haven't done any work in that direction at all.

[Frankenscript]

Hi folks,

When I update from MKVToolnix 4.4.0 to either 5.3.0 (a while back) or 5.5.0 (today), I notice that my output from ripping BDs with Another EAC3toGUI-Plus doesn't contain video streams. The ripping is fine (and creates the expected work files, including the video stream), but the MKV output file that gets created at the end is missing the video.

Reverting to the 4.4.0 MKVToolnix package fixes this.

I'm using Another EAC3toGUI-Plus 0.9.1.11 on one machine, and .18 on the other, and both show the same problem with the newer versions of toolnix.

Can anyone help me track down the problem and solution?

Thanks!

Marc

[Mosu]

I'm guessing the GUI is fucked and doesn't use mkvmerge to query the track IDs. As the author of that GUI to read https://www.bunkus.org/answers/?qa=15/mkvextract-extracts-mkvinfos-match-mkvextracts-mkvmerges (you should, too, if you don't know what I'm talking about).

[Frankenscript]

I'm guessing the GUI is fucked and doesn't use mkvmerge to query the track IDs. As the author of that GUI to read https://www.bunkus.org/answers/?qa=15/mkvextract-extracts-mkvinfos-match-mkvextracts-mkvmerges (you should, too, if you don't know what I'm talking about).

Interesting! I'm sure this is the root of the problem. It's been a while since the author updated that tool; I will reach out to him and see if he's willing to update it.

Thanks for the quick response
:D

[hello_hello]

That assumption would be wrong. I haven't done any work in that direction at all.

My mistake. Yesterday it seemed much faster to open using the quad core. Well not just seemed.... it was.
Today it's back to being slower to open than when it's running on the dual core. Oh well.....

[Fullmetal Encoder]

First, you have to differentiate between mkvmerge and mmg. mkvmerge's low-level file handling code can treat an arbitrary number of files as a single virtual file so that the upper layers only "see" one big input file. The "upper layers" in this case are all the input file type readers (e.g. the MPEG program stream reader, but just as well the MPEG transport stream reader or even the AVI reader -- though you never see an AVI file split binarily these days).

The difference between the program stream reader and all the other readers is that the program stream reader is the only reader that will actively look for split files even if the user doesn't request it -- e.g. if you execute mkvmerge -o out.mkv VTS_01_1.VOB it will look for VTS_01_2.VOB etc. as well. The reason is that DVD-named VOB files have pretty distinct naming patters while most other cases don't. BluRay simply names the files something like title00001.m2ts etc.

If you want to tell mkvmerge manually to read several (M2)TS files as a single file then the general command line syntax for treating multiple input files as a single file is this:

mkvmerge -o out.mkv ( in-part1.m2ts in-part2.m2ts in-part3.m2ts )

Note the spaces before and after the parenthesis. Also note that most Linux/Unix shells treat parenthesis as special characters, meaning you might have to quote them, e.g. mkvmerge -o out.mkv '(' in-part1.m2ts in-part2.m2ts in-part3.m2ts ')'

Now on to mmg. At the moment mmg only supports knowing which MPEG program stream parts mkvmerge will process and will prevent you from appending them manually. Unfortunately you cannot use the general "treat several files as one" feature with mmg at all currently. The QtMmg re-write that I'm actually working on at the moment will have full support for this feature. But for the time being you're restricted to the command line/option files if you want to use it with mkvmerge.

Ok, this is great news. Yes, I recall reading a while back something about QtMmg but I had forgotten about it. I will definitely not create/propose any changes for mmg then and will wait until you are finished with QtMmg. What is its status at this point? Are you still working on the chapter capabilities of it or do you have most of it hammered out at this point? Let me know and I will post in the QtMmg thread if it hasn't been written in stone yet. I have a number of ideas about how to improve over mmg.

To 1.: This would be a feature of mmg more than of mkvmerge. Of course you could also try implemented "readers" for DVD idx files / BluRay clip files (or wherever the chapter information is stored for BluRays) that only read chapters from those files but no tracks. I will most likely not accept features for the current mmg anymore due to the re-write. I will accept patches for mkvmerge, but be prepared for a shitload of work -- including updating the documentation for mkvmerge (the man page).

As for VOBs I believe I can make use of libdvdread to handle pulling just the necessary chapter start times as in your dvdxchap.c. However libdvdread is very large and complex and a lot of its classes seem to be opaque so I am having difficulty ferreting out exactly what it's doing and the format the info it provides is in so that I can make use of it. Not to mention that a lot of the sources I'm looking at are in C and not C++ which is what I'm more familiar with. I am fighting a learning curve though too as I am new to programming.

From what I've been able to tell pulling Blu-ray chapter points is surprisingly straight-forward. John Stebbins has freely provided the source code for his tool to do it and it's not very complicated at all. When I get around to it I just need to find the best way to do it for the usage scenarios I'd like QtMmg to be capable of satisfying.

To 3.: If you want to implement it then go ahead, but you'll have to duplicate the functionality of DVDVobSub (or whatever program is used to create separate VobSubs from DVDs). Again you'll have to parse the DVD idx files in order to create the "text" part of a VobSub.

Once I can create correct .sub and .idx files I should be good to go though, right? Am I correct in assuming that mkvmerge would first write the relevant infos from those files into the mkv before it does any file splits by timecodes? I am not informed about exactly how the .sub RLE bitmaps are combined with the mkv file but I am hoping I don't have to go that deep into the rabbit hole.

I am currently learning about how to extract the necessary information from the VOB and IFO files to directly create .sub and .idx files as VobSub would. I think there is a better way to do it than in VSRip. I am understanding a lot of the structures but correctly finding and calculating the timestamps is proving pretty complex. Fortunately, there is a lot of good reverse-engineered information about the DVD specs available online.

I also expect any patch to be platform-independent. Meaning you cannot use e.g. a library that's only available on Windows -- and that includes all of DirectX, of course. For DVD reading you can use e.g. libdvdread which is generally the standard way of accessing DVDs in the OpenSource world (e.g. VLC, mplayer etc all use it). I will not accept a dependency on ffmpeg either.

Understandable and there is nothing to be concerned about here. I have no plans to use anything proprietary or locked down.

[Mosu]

Well, mkvtoolnix-gui (that'll be the name for the new GUI 'cause it will evolve into more than just a frontend for mkvmerge) is in very early stages. It's a huge piece of work. I haven't done any work on the chapter editor at all, so suggestions are still very welcome.

As for the rest: I'll answer more tomorrow.

[Chetwood]

I am currently learning about how to extract the necessary information from the VOB and IFO files to directly create .sub and .idx files as VobSub would. I think there is a better way to do it than in VSRip.
While you're at it, feel free to add a batch function so subs can be ripped from all files in a subfolder, VSRip is just too tedious. Thx ;)

[Mosu]

As for VOBs I believe I can make use of libdvdread to handle pulling just the necessary chapter start times as in your dvdxchap.c. However libdvdread is very large and complex and a lot of its classes seem to be opaque so I am having difficulty ferreting out exactly what it's doing and the format the info it provides is in so that I can make use of it. Not to mention that a lot of the sources I'm looking at are in C and not C++ which is what I'm more familiar with. I am fighting a learning curve though too as I am new to programming.

You will have to use libdvdread one way or the other, otherwise you won't be able to handle encrypted DVDs.

Once I can create correct .sub and .idx files I should be good to go though, right? Am I correct in assuming that mkvmerge would first write the relevant infos from those files into the mkv before it does any file splits by timecodes? I am not informed about exactly how the .sub RLE bitmaps are combined with the mkv file but I am hoping I don't have to go that deep into the rabbit hole.

Well. The .sub is really only a MPEG program stream containing only the subtitle packets. The .idx file contains indices into that program stream to where the subtitles start.

What mkvmerge's VobSub reader does is throw away the indices from the .idx, parse the program stream and re-assemble each RLE bitmap. The Matroska file's packets contain one RLE-encoded bitmap each.

So ideally your code would be integrated into my MPEG program stream reader. This would not create temporary .idx/.sub files but instead create the important parts of the .idx file in memory (palette info etc), assemble the RLE-encoded bitmaps from the program stream and pass both to the VobSub packetizer.

[Fullmetal Encoder]

While you're at it, feel free to add a batch function so subs can be ripped from all files in a subfolder, VSRip is just too tedious. Thx ;)

I'm not sure it would be workable to go that far but one of my goals is to render VSRip, along with a number of other standalone applications, unnecessary for single disc operations.

[Fullmetal Encoder]

What mkvmerge's VobSub reader does is throw away the indices from the .idx, parse the program stream and re-assemble each RLE bitmap. The Matroska file's packets contain one RLE-encoded bitmap each.

So ideally your code would be integrated into my MPEG program stream reader. This would not create temporary .idx/.sub files but instead create the important parts of the .idx file in memory (palette info etc), assemble the RLE-encoded bitmaps from the program stream and pass both to the VobSub packetizer.

This is along the lines of what I have wanted to do. VobSub creates a lot of stuff that's not necessary for the mkv. What I wanted to do is create just what was needed for mkvmerge and it seems best to integrate that directly into the tool. After all, I don't want to reinvent the wheel, just make it roll easier plus it's a lot less work :) What puzzles me though is looking at VobSub.c it seems that it literally recreates from scratch the whole PES stream, headers and all, and I don't see why that would be necessary if the end result is the same as a byte exact copy of all the subtitle streams concatenated together into one file. Once you know which VOB and Cell ID's are needed all I should need to do is find/calculate the correct presentation timestamps and copy over the subtitle packs.

[Chetwood]

one of my goals is to render VSRip, along with a number of other standalone applications, unnecessary for single disc operations.
Well, single discs might contain several episodes (up to 7 is the max I have seen so far) and having to extract each manually is a PITA.

[Mosu]

mkvmerge will not gain a batch muxing feature ("read all titles from a DVD"), neither will mmg. If you want to to discuss a separate tool for that job then please do that in a different thread. Thanks.

[Frankenscript]

Hi folks,

This is a question about MKVMerge (used via the GUI), but please direct me if I should put it in a different location.

I use MKVMerge to strip out unwanted tracks (Extra audio or subtitles) from MKV files ripped from my BluRay discs. However, I've just started noticing an annoying artifact:

Any remuxed MKV I create doesn't play properly in TotalMediaTheater 5. The problem is that subtitles remaining in the MKV are not detected by TMT5.

There's something about the remuxed file, even if I don't remove any tracks, that makes the subs unreadable.

Are there any options in MKVMerge that I might have mis-set that would do this?

The resulting files play the subtitles OK in MPC-HC, but I have a problem with MPC-HC (it freezes at random times on me).

I'm working through this with the ARCSoft folks, but perhaps the issue is an easy one I can fix on my end through changes to MKVMergeGUI. Right now, I leave everything default other than source file, output file, and which tracks to include.

The process I go through is:

Bluray disc --> MakeMKV --> MKV File

This file plays subs fine in TMT5, though there are usually several sub tracks present.

I take that MKV file and use mkvmerge GUI and strip out all undesired tracks.

Resulting output doesn't show subs in TMT5 (but does in MPC-HC).

As a test I removed none of the tracks, the output file that should have been identical still didn't play in TMT5.

So, my thought is that TMT5 is sensitive about input format / headers and that it doesn't like something about the way mkvmerge writes the output MKVs.

Any troubleshooting advice would be appreciated. Thanks.

Marc

[Mosu]

See https://www.bunkus.org/answers/?qa=11/improving-playback-players-implement-matroska-specification

[Lincoln Burrows]

I couldn't help but notice that MakeMKV is now generating Matroska files with the video track not marked as default (Default = No), while the audio track, usually english, is set to Default = Yes. Will it make any difference to have the video track this way or do we need to change to Default = Yes?

It's the only video track in each MKV anyway.

[Mosu]

Depends on the player, but in practice it should not really make a difference. The meaning of the "default track flag" is: "player, you should use this track if the user hasn't chosen anything else in his/her preferences for this track type" (quote from the specs: "Set if that track (audio, video or subs) SHOULD be active if no language found matches the user preference. (1 bit)").

It does not mean "do not play this track if the flag is not set".

It is safe to assume that if the user starts a video player and selects a file with a video track in it that he/she wants to actually watch a video, so the player is definitely free to chose that video track.

The only case in which it would make a difference would be if the file contained more than one video track.

Note that players have been bad at following the spec's wording in their interpretation of that flag. So reality might look a whole lot different, though I've always considered such situations to be bugs in the players.

[Atak_Snajpera]

@mosu
is there any magic switch which could limit number of "garbage" reported by --identify-verbose command? for example codec_private_data.

old output
File 'E:\_Video_Samples\mkv\Matrix.mkv': container: Matroska [duration:151458000000]
Track ID 1: video (V_MS/VFW/FOURCC, XVID) [language:eng track_name:Matrix\sReloaded\sTrailer\sXviD\s1.0\sBeta1 display_dimensions:640x346 default_track:0 forced_track:0]
Track ID 2: audio (A_AAC) [language:eng track_name:HE-AAC\s50-70 default_track:0 forced_track:0]
Track ID 3: subtitles (S_TEXT/UTF8) [language:ara track_name:Arabic default_track:0 forced_track:0]
Track ID 4: subtitles (S_TEXT/SSA) [language:cat track_name:Catalan default_track:0 forced_track:0]
Track ID 5: subtitles (S_TEXT/SSA) [language:dut track_name:Dutch default_track:0 forced_track:0]
Track ID 6: subtitles (S_TEXT/SSA) [language:eng track_name:English default_track:0 forced_track:0]
Track ID 7: subtitles (S_TEXT/SSA) [language:fin track_name:Finnish default_track:0 forced_track:0]
Track ID 8: subtitles (S_TEXT/SSA) [language:fre track_name:French default_track:0 forced_track:0]
Track ID 9: subtitles (S_TEXT/SSA) [language:ger track_name:German default_track:0 forced_track:0]
Track ID 10: subtitles (S_TEXT/UTF8) [language:jpn track_name:Japanese default_track:0 forced_track:0]
Track ID 11: subtitles (S_TEXT/SSA) [language:por track_name:Portuguese default_track:0 forced_track:0]
Track ID 12: subtitles (S_TEXT/SSA) [language:slv track_name:Slovenian default_track:0 forced_track:0]
Track ID 13: subtitles (S_TEXT/SSA) [language:spa track_name:Spanish default_track:0 forced_track:0]
Attachment ID 1: type 'image/jpeg', size 50436 bytes, description 'Cover', file name 'reloaded.jpg'


new output
File 'E:\_Video_Samples\mkv\Matrix.mkv': container: Matroska [duration:151458000000]
Track ID 0: video (V_MS/VFW/FOURCC, XVID) [number:1 uid:2738550924 codec_id:V_MS/VFW/FOURCC codec_private_length:40 codec_private_data:28000000800200005a01000001000c00585649440046140000000000000000000000000000000000 language:eng track_name:Matrix\sReloaded\sTrailer\sXviD\s1.0\sBeta1 pixel_dimensions:640x346 display_dimensions:640x346 default_track:0 forced_track:0 enabled_track:1 default_duration:41666663]
Track ID 1: audio (A_AAC) [number:2 uid:1982383230 codec_id:A_AAC codec_private_length:5 codec_private_data:139056e5a0 language:eng track_name:HE-AAC\s50-70 default_track:0 forced_track:0 enabled_track:1 default_duration:46439909 audio_sampling_frequency:22050 audio_channels:2]
Track ID 2: subtitles (S_TEXT/UTF8) [number:3 uid:3270128816 codec_id:S_TEXT/UTF8 codec_private_length:0 language:ara track_name:Arabic default_track:0 forced_track:0 enabled_track:1]
Track ID 3: subtitles (S_TEXT/SSA) [number:4 uid:3563875756 codec_id:S_TEXT/SSA codec_private_length:796 codec_private_data:5b53637269707420496e666f5d0d0a3b20546869732069732061205375622053746174696f6e20416c706861207634207363726970742e0d0a3b20466f72205375622053746174696f6e20416c70686120696e666f20616e6420646f776e6c6f6164732c0d0a3b20676f20746f20687474703a2f2f7777772e65737761742e64656d6f6e2e636f2e756b2f0d0a3b206f7220656d61696c206b6f7475734065737761742e64656d6f6e2e636f2e756b0d0a5469746c653a204d61747269782052656c6f6164656420547261696c65720d0a4f726967696e616c205363726970743a206d6620616e64204372754e636865720d0a4f726967696e616c2054696d696e673a204c69717569645f736b6965730d0a536372697074547970653a2076342e30300d0a436f6c6c6973696f6e733a204e6f726d616c0d0a506c6179526573593a203736380d0a506c617944657074683a20300d0a5761763a20302c2031333435382c433a5c446f63756d656e747320616e642053657474696e67735c4d616b2e50414b4f4e5c4465736b746f705c656e636f64696e675c456c6974652046616e737562735c4e61727565206e6f2053656b61695c6d61747269785f72656c6f616465642d386269742d32326b687a2e7761760d0a4c6173745761763a20310d0a54696d65723a203130302e303030300d0a0d0a5b5634205374796c65735d0d0a466f726d61743a204e616d652c20466f6e746e616d652c20466f6e7473697a652c205072696d617279436f6c6f75722c205365636f6e64617279436f6c6f75722c205465727469617279436f6c6f75722c204261636b436f6c6f75722c20426f6c642c204974616c69632c20426f726465725374796c652c204f75746c696e652c20536861646f772c20416c69676e6d656e742c204d617267696e4c2c204d617267696e522c204d617267696e562c20416c7068614c6576656c2c20456e636f64696e670d0a5374796c653a2044656661756c742c417269616c2c34302c31333433343837372c36353533352c36353533352c2d323134373438333634302c302c2d312c312c322c312c322c33302c33302c33302c302c300d0a language:cat track_name:Catalan default_track:0 forced_track:0 enabled_track:1]
Track ID 4: subtitles (S_TEXT/SSA) [number:5 uid:2003350774 codec_id:S_TEXT/SSA codec_private_length:783 codec_private_data:5b53637269707420496e666f5d0d0a3b20546869732069732061205375622053746174696f6e20416c706861207634207363726970742e0d0a3b20466f72205375622053746174696f6e20416c70686120696e666f20616e6420646f776e6c6f6164732c0d0a3b20676f20746f20687474703a2f2f7777772e65737761742e64656d6f6e2e636f2e756b2f0d0a3b206f7220656d61696c206b6f7475734065737761742e64656d6f6e2e636f2e756b0d0a5469746c653a204d61747269782052656c6f6164656420547261696c65720d0a4f726967696e616c205363726970743a206d660d0a4f726967696e616c2054696d696e673a204c69717569645f736b6965730d0a536372697074547970653a2076342e30300d0a436f6c6c6973696f6e733a204e6f726d616c0d0a506c6179526573593a203736380d0a506c617944657074683a20300d0a5761763a20302c2031333435382c433a5c446f63756d656e747320616e642053657474696e67735c4d616b2e50414b4f4e5c4465736b746f705c656e636f64696e675c456c6974652046616e737562735c4e61727565206e6f2053656b61695c6d61747269785f72656c6f616465642d386269742d32326b687a2e7761760d0a4c6173745761763a20310d0a54696d65723a203130302e303030300d0a0d0a5b5634205374796c65735d0d0a466f726d61743a204e616d652c20466f6e746e616d652c20466f6e7473697a652c205072696d617279436f6c6f75722c205365636f6e64617279436f6c6f75722c205465727469617279436f6c6f75722c204261636b436f6c6f75722c20426f6c642c204974616c69632c20426f726465725374796c652c204f75746c696e652c20536861646f772c20416c69676e6d656e742c204d617267696e4c2c204d617267696e522c204d617267696e562c20416c7068614c6576656c2c20456e636f64696e670d0a5374796c653a2044656661756c742c417269616c2c34302c31333433343837372c36353533352c36353533352c2d323134373438333634302c302c2d312c312c322c312c322c33302c33302c33302c302c300d0a language:dut track_name:Dutch default_track:0 forced_track:0 enabled_track:1]
Track ID 5: subtitles (S_TEXT/SSA) [number:6 uid:2619120828 codec_id:S_TEXT/SSA codec_private_length:783 codec_private_data:5b53637269707420496e666f5d0d0a3b20546869732069732061205375622053746174696f6e20416c706861207634207363726970742e0d0a3b20466f72205375622053746174696f6e20416c70686120696e666f20616e6420646f776e6c6f6164732c0d0a3b20676f20746f20687474703a2f2f7777772e65737761742e64656d6f6e2e636f2e756b2f0d0a3b206f7220656d61696c206b6f7475734065737761742e64656d6f6e2e636f2e756b0d0a5469746c653a204d61747269782052656c6f6164656420547261696c65720d0a4f726967696e616c205363726970743a206d660d0a4f726967696e616c2054696d696e673a204c69717569645f736b6965730d0a536372697074547970653a2076342e30300d0a436f6c6c6973696f6e733a204e6f726d616c0d0a506c6179526573593a203736380d0a506c617944657074683a20300d0a5761763a20302c2031333435382c433a5c446f63756d656e747320616e642053657474696e67735c4d616b2e50414b4f4e5c4465736b746f705c656e636f64696e675c456c6974652046616e737562735c4e61727565206e6f2053656b61695c6d61747269785f72656c6f616465642d386269742d32326b687a2e7761760d0a4c6173745761763a20310d0a54696d65723a203130302e303030300d0a0d0a5b5634205374796c65735d0d0a466f726d61743a204e616d652c20466f6e746e616d652c20466f6e7473697a652c205072696d617279436f6c6f75722c205365636f6e64617279436f6c6f75722c205465727469617279436f6c6f75722c204261636b436f6c6f75722c20426f6c642c204974616c69632c20426f726465725374796c652c204f75746c696e652c20536861646f772c20416c69676e6d656e742c204d617267696e4c2c204d617267696e522c204d617267696e562c20416c7068614c6576656c2c20456e636f64696e670d0a5374796c653a2044656661756c742c417269616c2c34302c31333433343837372c36353533352c36353533352c2d323134373438333634302c302c2d312c312c322c312c322c33302c33302c33302c302c300d0a language:eng track_name:English default_track:0 forced_track:0 enabled_track:1]
Track ID 6: subtitles (S_TEXT/SSA) [number:7 uid:2674700248 codec_id:S_TEXT/SSA codec_private_length:783 codec_private_data:5b53637269707420496e666f5d0d0a3b20546869732069732061205375622053746174696f6e20416c706861207634207363726970742e0d0a3b20466f72205375622053746174696f6e20416c70686120696e666f20616e6420646f776e6c6f6164732c0d0a3b20676f20746f20687474703a2f2f7777772e65737761742e64656d6f6e2e636f2e756b2f0d0a3b206f7220656d61696c206b6f7475734065737761742e64656d6f6e2e636f2e756b0d0a5469746c653a204d61747269782052656c6f6164656420547261696c65720d0a4f726967696e616c205363726970743a206d660d0a4f726967696e616c2054696d696e673a204c69717569645f736b6965730d0a536372697074547970653a2076342e30300d0a436f6c6c6973696f6e733a204e6f726d616c0d0a506c6179526573593a203736380d0a506c617944657074683a20300d0a5761763a20302c2031333435382c433a5c446f63756d656e747320616e642053657474696e67735c4d616b2e50414b4f4e5c4465736b746f705c656e636f64696e675c456c6974652046616e737562735c4e61727565206e6f2053656b61695c6d61747269785f72656c6f616465642d386269742d32326b687a2e7761760d0a4c6173745761763a20310d0a54696d65723a203130302e303030300d0a0d0a5b5634205374796c65735d0d0a466f726d61743a204e616d652c20466f6e746e616d652c20466f6e7473697a652c205072696d617279436f6c6f75722c205365636f6e64617279436f6c6f75722c205465727469617279436f6c6f75722c204261636b436f6c6f75722c20426f6c642c204974616c69632c20426f726465725374796c652c204f75746c696e652c20536861646f772c20416c69676e6d656e742c204d617267696e4c2c204d617267696e522c204d617267696e562c20416c7068614c6576656c2c20456e636f64696e670d0a5374796c653a2044656661756c742c417269616c2c34302c31333433343837372c36353533352c36353533352c2d323134373438333634302c302c2d312c312c322c312c322c33302c33302c33302c302c300d0a language:fin track_name:Finnish default_track:0 forced_track:0 enabled_track:1]
Track ID 7: subtitles (S_TEXT/SSA) [number:8 uid:1203285810 codec_id:S_TEXT/SSA codec_private_length:783 codec_private_data:5b53637269707420496e666f5d0d0a3b20546869732069732061205375622053746174696f6e20416c706861207634207363726970742e0d0a3b20466f72205375622053746174696f6e20416c70686120696e666f20616e6420646f776e6c6f6164732c0d0a3b20676f20746f20687474703a2f2f7777772e65737761742e64656d6f6e2e636f2e756b2f0d0a3b206f7220656d61696c206b6f7475734065737761742e64656d6f6e2e636f2e756b0d0a5469746c653a204d61747269782052656c6f6164656420547261696c65720d0a4f726967696e616c205363726970743a206d660d0a4f726967696e616c2054696d696e673a204c69717569645f736b6965730d0a536372697074547970653a2076342e30300d0a436f6c6c6973696f6e733a204e6f726d616c0d0a506c6179526573593a203736380d0a506c617944657074683a20300d0a5761763a20302c2031333435382c433a5c446f63756d656e747320616e642053657474696e67735c4d616b2e50414b4f4e5c4465736b746f705c656e636f64696e675c456c6974652046616e737562735c4e61727565206e6f2053656b61695c6d61747269785f72656c6f616465642d386269742d32326b687a2e7761760d0a4c6173745761763a20310d0a54696d65723a203130302e303030300d0a0d0a5b5634205374796c65735d0d0a466f726d61743a204e616d652c20466f6e746e616d652c20466f6e7473697a652c205072696d617279436f6c6f75722c205365636f6e64617279436f6c6f75722c205465727469617279436f6c6f75722c204261636b436f6c6f75722c20426f6c642c204974616c69632c20426f726465725374796c652c204f75746c696e652c20536861646f772c20416c69676e6d656e742c204d617267696e4c2c204d617267696e522c204d617267696e562c20416c7068614c6576656c2c20456e636f64696e670d0a5374796c653a2044656661756c742c417269616c2c34302c31333433343837372c36353533352c36353533352c2d323134373438333634302c302c2d312c312c322c312c322c33302c33302c33302c302c300d0a language:fre track_name:French default_track:0 forced_track:0 enabled_track:1]
Track ID 8: subtitles (S_TEXT/SSA) [number:9 uid:1639611508 codec_id:S_TEXT/SSA codec_private_length:783 codec_private_data:5b53637269707420496e666f5d0d0a3b20546869732069732061205375622053746174696f6e20416c706861207634207363726970742e0d0a3b20466f72205375622053746174696f6e20416c70686120696e666f20616e6420646f776e6c6f6164732c0d0a3b20676f20746f20687474703a2f2f7777772e65737761742e64656d6f6e2e636f2e756b2f0d0a3b206f7220656d61696c206b6f7475734065737761742e64656d6f6e2e636f2e756b0d0a5469746c653a204d61747269782052656c6f6164656420547261696c65720d0a4f726967696e616c205363726970743a206d660d0a4f726967696e616c2054696d696e673a204c69717569645f736b6965730d0a536372697074547970653a2076342e30300d0a436f6c6c6973696f6e733a204e6f726d616c0d0a506c6179526573593a203736380d0a506c617944657074683a20300d0a5761763a20302c2031333435382c433a5c446f63756d656e747320616e642053657474696e67735c4d616b2e50414b4f4e5c4465736b746f705c656e636f64696e675c456c6974652046616e737562735c4e61727565206e6f2053656b61695c6d61747269785f72656c6f616465642d386269742d32326b687a2e7761760d0a4c6173745761763a20310d0a54696d65723a203130302e303030300d0a0d0a5b5634205374796c65735d0d0a466f726d61743a204e616d652c20466f6e746e616d652c20466f6e7473697a652c205072696d617279436f6c6f75722c205365636f6e64617279436f6c6f75722c205465727469617279436f6c6f75722c204261636b436f6c6f75722c20426f6c642c204974616c69632c20426f726465725374796c652c204f75746c696e652c20536861646f772c20416c69676e6d656e742c204d617267696e4c2c204d617267696e522c204d617267696e562c20416c7068614c6576656c2c20456e636f64696e670d0a5374796c653a2044656661756c742c417269616c2c34302c31333433343837372c36353533352c36353533352c2d323134373438333634302c302c2d312c312c322c312c322c33302c33302c33302c302c300d0a language:ger track_name:German default_track:0 forced_track:0 enabled_track:1]
Track ID 9: subtitles (S_TEXT/UTF8) [number:10 uid:3466603604 codec_id:S_TEXT/UTF8 codec_private_length:0 language:jpn track_name:Japanese default_track:0 forced_track:0 enabled_track:1]
Track ID 10: subtitles (S_TEXT/SSA) [number:11 uid:3705802066 codec_id:S_TEXT/SSA codec_private_length:783 codec_private_data:5b53637269707420496e666f5d0d0a3b20546869732069732061205375622053746174696f6e20416c706861207634207363726970742e0d0a3b20466f72205375622053746174696f6e20416c70686120696e666f20616e6420646f776e6c6f6164732c0d0a3b20676f20746f20687474703a2f2f7777772e65737761742e64656d6f6e2e636f2e756b2f0d0a3b206f7220656d61696c206b6f7475734065737761742e64656d6f6e2e636f2e756b0d0a5469746c653a204d61747269782052656c6f6164656420547261696c65720d0a4f726967696e616c205363726970743a206d660d0a4f726967696e616c2054696d696e673a204c69717569645f736b6965730d0a536372697074547970653a2076342e30300d0a436f6c6c6973696f6e733a204e6f726d616c0d0a506c6179526573593a203736380d0a506c617944657074683a20300d0a5761763a20302c2031333435382c433a5c446f63756d656e747320616e642053657474696e67735c4d616b2e50414b4f4e5c4465736b746f705c656e636f64696e675c456c6974652046616e737562735c4e61727565206e6f2053656b61695c6d61747269785f72656c6f616465642d386269742d32326b687a2e7761760d0a4c6173745761763a20310d0a54696d65723a203130302e303030300d0a0d0a5b5634205374796c65735d0d0a466f726d61743a204e616d652c20466f6e746e616d652c20466f6e7473697a652c205072696d617279436f6c6f75722c205365636f6e64617279436f6c6f75722c205465727469617279436f6c6f75722c204261636b436f6c6f75722c20426f6c642c204974616c69632c20426f726465725374796c652c204f75746c696e652c20536861646f772c20416c69676e6d656e742c204d617267696e4c2c204d617267696e522c204d617267696e562c20416c7068614c6576656c2c20456e636f64696e670d0a5374796c653a2044656661756c742c417269616c2c34302c31333433343837372c36353533352...

[Mosu]

No, there isn't, and there will be none. "identify verbose" is meant for machine consumption. If you want something that's more easily readable for humans then filter the output into something you need yourself or use mkvinfo's output.

[Atak_Snajpera]

mkvinfo's output is even less readable than old mkvmerge output.

[Atak_Snajpera]

Mosu
Could you at least disable Word Wraping caused by -r switch

http://i.imgur.com/CRTYY.png

[Mosu]

Huh!? mkvmerge's identification mode outputs a single line per entry. It has NO influence whatsoever about how editors/viewers display the content.

This cannot be changed as any tool parsing mkvmerge's identification output relies upon the fact that there's only a single line per entry ("entry" meaning the container, a track, an attachment etc.).

[Atak_Snajpera]

I turned out I had to switch from Memo component to RichEdit in delphi :)

[Mosu]

Hey,

I've released v5.6.0. It fixes a couple of important issues with the new "--split parts:" functionality. Other bugs were fixed as well. A Polish translation of the programs has been added as well as a Spanish translation of mmg's guide.

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

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.6.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.6.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.5.0:

2012-05-27 Moritz Bunkus <moritz@bunkus.org>
* Released v5.6.0.
* documentation: Added Spanish translation of mmg's guide by Israel Lucas Torrijos (see AUTHORS).

2012-05-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: SRT subtitle entries with colons as the decimal separator are accepted. Fix for issue 754 (https://www.bunkus.org/trac/ticket/754).

2012-05-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: XML tag files with <Simple> tags that only contained a name and nested <Simple> were wrongfully rejected as invalid. Fixes issue 752 (https://www.bunkus.org/trac/ticket/752).
* mkvmerge: enhancement: mkvmerge was optimizied to keep cluster timecodes strictly increasing in most situations.

2012-04-24 Moritz Bunkus <moritz@bunkus.org>
* all: Added a translation to Polish by Daniel (see AUTHORS).

2012-04-16 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Extraction of AVC/h.264 was completely broken after 2012-04-09 resulting in files with a length of 0 bytes.

2012-04-09 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: When adding a Matroska file that has either the "previous segment UID" or the "next segment UID" set then mmg will copy those two and the source file's segment UID into the corresponding controls on the "global" tab if they haven't been set before. Implements ticket 733 (https://www.bunkus.org/trac/ticket/733).
* mkvmerge: new feature: The verbose identification mode for Matroska files will now includes the "segment UID", the "next segment UID" and "previous segment UID" elements.
* mkvmerge: enhancement: In "--split parts:" mode mkvmerge will use the output file name as it is instead of adding a running number to it if all the ranges to be kept are to be written into a single output file. Implements ticket 743 (https://www.bunkus.org/trac/ticket/743).
* mkvextract: bug fix: mkvextract will no longer abort extracing h.264 tracks if it encounters a NAL smaller than its size field. Instead it will warn about it and drop the NAL.

2012-04-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Writing more than two parts into the same file with "--split parts:" resulted in the timecodes of the third and all following parts to be wrong. Fixes ticket 740 (https://www.bunkus.org/trac/ticket/740).
* mkvmerge: bug fix: The "--split parts:" functionality was not taking dropped ranges into account when calculating the segment duration for files that more than one range was written to. Fixes ticket 738 (https://www.bunkus.org/trac/ticket/738).
* mkvmerge: bug fix: The "--split parts:" functionality was producing a small gap between the first part's last packet's timecode and the second part's first packet's timecode if two parts are written to the same file. Fixes ticket 742 (https://www.bunkus.org/trac/ticket/742).

2012-04-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The "--split parts:" functionality was writing a superfluous and empty first part if the first range starts at 00:00:00. Fixes ticket 737 (https://www.bunkus.org/trac/ticket/737).

2012-04-07 Moritz Bunkus <moritz@bunkus.org>
* mmg, build system: Fixed building with wxWidgets 2.9.3.

Have fun.

mo

[robpdotcom]

* mmg: new feature: When adding a Matroska file that has either the "previous segment UID" or the "next segment UID" set then mmg will copy those two and the source file's segment UID into the corresponding controls on the "globla" tab if they haven't been set before.

That's a handy new feature. Thanks.:cool:

[rhaz]

Don't know about the others, but the latest version v5.6.0 became very slow. With v5.5.0 it took one minute to mux .mkv with .mp4 audio into 1GB total size file, now it takes up to 10 minutes on my 7 year old AMD. I reinstalled back to v5.5.0 and it works fast as always, about 1 minute for 1GB size and couple of minutes for 3-4GB.

[Mosu]

Unfortunately I cannot reproduce that at all. However, another user simply dropped a hint that it was slow for him as well -- though he disappeared as quickly as he came, so I couldn't ask specifics.

Would you mind uploading the files you're muxing to my FTP server, please (see signature)?

[rhaz]

I don't think that it would solve anything and uploading a gigabyte would take some time I think. I tried doing this with other files and got same slow response. 10-15 minutes for ~1GB (~800MB .mkv + ~200MB .mp4). The files I use are encoded using MeGUI, CRF x264 option for .mkv and just some audio convert to AAC .mp4 for lowest file size in best quality for my Blu-ray discs digital archive.

[SeeMoreDigital]

I've been re-muxing some of my 'movie only' DVD.ISO file back-ups to .MKV, but in doing so I've noticed something I'm not sure is a bug or not...

When I drag and drop my .VOB files into MKVmerge GUI v5.6.0 all tracks are detected except the VOBsubs!

Is this a bug or a feature that was never implemented?

[Mosu]

Reading VobSubs from VOBs is not supported. And may never be. Some user started working on that, but I haven't heard from him in months.

Problem? Well in order to create the VobSub's idx part you'd have to parse the whole friggin DVD IDX files and stuff like that. Nothing I'm ever going to do myself.

[Mosu]

I don't think that it would solve anything

Look, I'm not asking for the file because I want to annoy you, but because I cannot recreate the issue with the files I have here. And simply running software X with random parameters Y in order to get some file Z that's totally unrelated to your file ABC will most like not make any sense either.

and uploading a gigabyte would take some time I think

Of course it does, but it's not like it's taking you any effort to do so. Unlike me spending time chasing ghost conditions on files that may or may not show that effect you already have files on which the effect is definitely present. That's why I'm asking.

[SeeMoreDigital]

Reading VobSubs from VOBs is not supported. And may never be. Some user started working on that, but I haven't heard from him in months.

Problem? Well in order to create the VobSub's idx part you'd have to parse the whole friggin DVD IDX files and stuff like that. Nothing I'm ever going to do myself.
Thanks for the explanation. I guess I'll have to find a decent tool to extract these pesky VOBsubs from my VOB files :eek:

[soneca]

Hi Mosu,

In this version the extension(dtsma) to tracks in DTS-HD Master Audio is not available, despite being supported.

[Mosu]

In this version the extension(dtsma) to tracks in DTS-HD Master Audio is not available, despite being supported.

Just select "all files" and you're good to go. I won't add each and every possible extension on the planet for each and every file type; that's simply ridiculous.

[soneca]

I thought this extension existed in previous versions, I was wrong ... rarely use this type of audio.

[djesteban]

@mosu: I'm having a weird issue with one (hopefully it's the only one) of my mkv file. At one point during the movie, just before a scene transition, the playback seems to "hold a frame" for a moment just before it switches to the next image. I wouldn't describe it has stuttering, but it's definitively not smooth as the original. Now the footage comes from a blu-ray and the original m2ts doesn't display this problem. When I muxed the elementary stream with mmg.exe, it didn't log any errors at the end. I tried muxing the extracted elementary stream, muxing straight from the m2ts and on 2 different workstations and the problem persist. I also tested it in 2 media player: MPC-HC (32 and 64 bit) and VLC...

The first thing that makes me think the problem comes from mmg.exe is if I extract the h264 file from the problematic mkv, index it (using DGindexMV piped through a avs script) and launch it in MPC-HC, it plays correctly.
Also, if I convert this movie using MakeMKV (from the original blu-ray) to mkv, the resulting file plays fine! I know MakeMKV doesn't use the same library as mkvtoolnix, could that make the difference?

The only way I was able to make it work properly using mkvtoolnix is by... remuxing the working mkv created with MakeMKV with mmg.exe. Though if I demux the MakeMKV file with mkvextract and then mux the resulting elementary stream from that with mmg.exe, the problem shows up again...

Note that muxing the elementary stream with tsMuxer in a new m2ts will also display the same issue!

If you need a small sample of the movie with the problematic area, I'll be glad to upload it somewhere.

Let me know what you think the problem could be.
Thanks in advance

[Chetwood]

Don't know about the others, but the latest version v5.6.0 became very slow.
Started for me with 5.50 but wasn't reproducible.

Thanks for the explanation. I guess I'll have to find a decent tool to extract these pesky VOBsubs from my VOB files :eek:
VSrip.

[Mosu]

If you need a small sample of the movie with the problematic area, I'll be glad to upload it somewhere.

Please file a file a bug report (https://trac.bunkus.org/) and upload two sample files to my FTP server: one in which the problem is apparent and one which plays fine (e.g. created with MakeMKV but not yet remuxed with mkvmerge). Both must show the same scene(s) if they should be of any use to me.

Let me know what you think the problem could be.

No idea whatsoever so far.

[Carpo]

Don't know about the others, but the latest version v5.6.0 became very slow. With v5.5.0 it took one minute to mux .mkv with .mp4 audio into 1GB total size file, now it takes up to 10 minutes on my 7 year old AMD. I reinstalled back to v5.5.0 and it works fast as always, about 1 minute for 1GB size and couple of minutes for 3-4GB.

took me about 7 seconds to do a file roughly that size here

[Mosu]

took me about 7 seconds to do a file roughly that size here

That's what I meant with "I cannot reproduce it here" as well. For me muxing is as fast as always. That's why I'm asking for real-life samples -- meaning that someone for whom the problem manifests should upload such a file somewhere.

[djesteban]

Please file a file a bug report (https://trac.bunkus.org/) and upload two sample files to my FTP server: one in which the problem is apparent and one which plays fine (e.g. created with MakeMKV but not yet remuxed with mkvmerge). Both must show the same scene(s) if they should be of any use to me.

I can create a sample with mmg.exe no prob, but I have no idea how to upload a sample for the MakeMKV file, since it seems that there is NO WAY I can create a mkv using a 264 file with this damn tool. I even create a "fake BD" with my sample file and tried to rip it using MakeMKV and it refuses to create a mkv file for some reason... Now the original file is 22Gig so way too big to send.

Any idea how I could split a sample from the MakeMKV file without changing it's properties?

[vmb]

5.6.0 seems to be very slow for me. I try to remux a DVD to mkv or rearrange an mkv and it takes drastically more time and CPU.

Here it is a mediainfo and log on 1.4 Gb mkv — I've only tried to rearrange the order of audio tracks and subs (takes 25 min on 1.8 Gz AMD CPU with 100% load).

There were no such problems with older versions for years...

[Mosu]

5.6.0 seems to be very slow for me. I try to remux a DVD to mkv or rearrange an mkv and it takes drastically more time and CPU.

Please read http://forum.doom9.org/showthread.php?p=1576224#post1576224 and http://forum.doom9.org/showthread.php?p=1576251#post1576251. If you're willing to upload the original file (not the remuxed one) then please also provide either the .mmg file you've used or the corresponding command line.

[vmb]

Mosu
I've sent you a private message with a question.

[vmb]

I've just uploaded the input file to ftp. Command line from mmg.exe:

"C:\Program Files\MKVtoolnix\mkvmerge.exe" -o "J:\\temp\\Nocturna.2007 (1).mkv" "--language" "0:spa" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1019x434" "--compression" "0:none" "--language" "1:rus" "--track-name" "1:MVO" "--default-track" "1:no" "--forced-track" "1:no" "--compression" "1:none" "--language" "2:rus" "--track-name" "2:MVO [Superbit]" "--default-track" "2:yes" "--forced-track" "2:no" "--compression" "2:none" "--language" "3:spa" "--track-name" "3:Original" "--default-track" "3:no" "--forced-track" "3:no" "--compression" "3:none" "--language" "4:rus" "--track-name" "4:[Superbit]" "--default-track" "4:no" "--forced-track" "4:no" "--language" "5:eng" "--default-track" "5:yes" "--forced-track" "5:no" "--language" "6:spa" "--default-track" "6:no" "--forced-track" "6:no" "-a" "1,2,3" "-d" "0" "-s" "4,5,6" "-T" "--no-global-tags" "--no-chapters" "(" "J:\\temp\\Nocturna.2007.mkv" ")" "--track-order" "0:0,0:2,0:1,0:3,0:5,0:4,0:6"

[Mosu]

Those with a slow muxing process should try builds 446 and later from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/.

[vmb]

Mosu
Great fix! Thank you a lot. Now it takes 50 second instead of 25 min.

[Liisachan]

Those with a slow muxing process should try builds 446 and later from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/.

I was just about to report the same problem; 446 fixed it.
Was this a problem of mmg.exe?
mkvmerge v5.6.0 seemed to be working, while I experienced something like a thread deadlock with mmg, on my old, single-core machine and Win XP. I was going to see if I could reproduce the problem on a multicore machine, as I got a vague feeling that one thread was blocking needlessly the other threads. IMHO this is a bad bug. You might want to release a hot-fix 5.6.1 (or 5.7.0) sooner.

Thank you very much again for this great application, anyway :)

[Mosu]

Well. I had re-written the whole thread management in mmg due to problems on Mac OS (really bad lockups with code that worked just fine on both Windows and Linux -- I blame wxWidgets here). Unfortunately the main thread now polls the mkvmerge process continually which results in one CPU being used at full capacity. On single core systems this means that there's not processing power left for mkvmerge, hence the huge slow down for such systems. I don't have a single single core system anymore (including my laptop), which is why I wasn't really able to reproduce the problem before. I also didn't realize people actually meant that mmg was using the CPU. They all just said "muxing is slow", and I tend to test mkvmerge only in such cases.

No, I don't want to release a new release at the moment, I don't want to spend the two hours I always have to work on this. I can point people to the interims release, and Linux users can re-compile the package themselves.

[Selur]

btw. would be nice if mkvextract like mkvmerge would support the "--split parts:" option,..

[Mosu]

btw. would be nice if mkvextract like mkvmerge would support the "--split parts:" option,..

Never say never, but this will in no way happen ;)

[Selur]

Had to ask, it would just be a nice feature to have. :)

[MrVideo]

End users having to do anything in the command line in 2012 bewilders me. Should be totally unnecessary. I know this is a "power user" program (and a great one at that) but still, GUIs are so much easier to use.

GUIs are a PITA when it comes to automating the repetitive process. When the same thing is done over and over and over, scripts are the best way to go. When on a Windoze platform, installing cygwin and writing Zshell scripts, that also have command line options, make the repetitive job a lot easier.

A GUI doesn't exist to take MPEG-2/H.264/AC3 elementary streams, create DGI output, create the necessary AVISynth script and set the x264 encoder options, and lastly run mkvmerge to merge the video and audio streams into the MKV wrapper.

GUIs have their place, but complicated job runs require power user capability.

[MrVideo]

However, this would mean that the default_duration written to the file may be different than the value the user supplied. On the other hand it would make it easier for the user: no matter whether or not the input is 25p or 25i the user only has to enter "25fps". And I could leave mmg's "FPS" field as it is, meaning it wouldn't be renamed to "default duration".

Thoughts?

I know I am little late to this discussion and have more posts in the forum to read after this one, but I have been bitten by the dual meaning of "fps" too often. FPS mean Frames Per Second. As such, the --default-duration should be fps, no matter if the h.264 video is progressive or interlaced. Therfore, when I supply 29.97fps as input, mkvmerge should know to internally change it to 59.95 fields per second when creating the output, when dealing with interlaced input.

My thought.

But, it is basically moot for the latest versions. :D

[LeMoi]

I'm a litle disappointed with the latest split by parts feature. If i want to split a 10s part of a 1 hour movie, it doesn't only mux the 10s part, it muxes the whole file and create the 10s part file only. I mean that instead of taking few seconds to extract that little part, it takes few minutes... It's not really like a splitting feature that may offer other programs for AVI/MP4/etc. files...
Ultimately, it's as long as it was before but it doesn't take the same disk space.

[Mosu]

I'm a litle disappointed with the latest split by parts feature. If i want to split a 10s part of a 1 hour movie, it doesn't only mux the 10s part, it muxes the whole file and create the 10s part file only. I mean that instead of taking few seconds to extract that little part, it takes few minutes... It's not really like a splitting feature that may offer other programs for AVI/MP4/etc. files...
Ultimately, it's as long as it was before but it doesn't take the same disk space.

Yes, and you'll have to live with at least some of that. mkvmerge makes the decision whether or not to split before the current packet after the packet has been processed fully, especially after all the different possible methods of timecode manipulation have been applied (source container timecode calculation, appending from other files, command line options like --sync and timecode files). Therefore all source files have to be processed at least until the last part of the "--split parts:..." option has been fully written. I can make mkvmerge stop after that, though I'll have to test that somehow. That would at least cut the process down somewhat.

mkvmerge works rather differently than a video player. Therefore you cannot expect mkvmerge to simply seek in the input files to where it needs to process the data.

[LeMoi]

Therefore you cannot expect mkvmerge to simply seek in the input files to where it needs to process the data.

That's what i thought it would do, that's why i said i was disappointed :p

I can make mkvmerge stop after that, though I'll have to test that somehow. That would at least cut the process down somewhatGood idea :)

[MWD1001]

For the life of me I can't get any mkv file made with MKVMerge to play on my bluray player. It's a brand new 2012 model Sony BDP-S390 and this player has played every MKV I've thrown at it made from programs like MakeMKV, RipBot264 and TSMuxer. So I know it supports the file format. In fact, the same source content (AVC, not VC-1 which are known to be finicky with Sony players) plays just fine when I mux the file with MakeMKV, but when I mux with MKVMerge I get the infamous "File Not Supported" error message from Sony. I've tried every combination of possible settings in MKVMerge to try to get it to work (compression/no compression, flags on/off, etc.) but my player chokes on every single file and says it's not supported. What's strange is RipBot uses MKVmerge to remux re-encoded files upon completion and those files work just fine. So I know my player will play files muxed with MKVMerge. However, I can't seem to find the right combination of settings when using the GUI. What the hell?

[sneaker_ger]

Are you absolutely sure about the compression/no compression thing? Compared your command line to that of RipBot?

[MWD1001]

Are you absolutely sure about the compression/no compression thing? Compared your command line to that of RipBot?

Yes. I've gone through at least two dozen tests with compression on and off in every possible combination for video, audio, and srt subtitles but nothing is working. However, test mkv files I downloaded that were made with mkvmerge are playing just fine, including the support and playback of UTF-8 based subtitles. I can't seem to make my own mkv file with my own source material using MKVmerge that my player will play. I even remuxed the test file I downloaded and it played. Why can't I get my own backups to work? I'm ready to kill myself!

[sneaker_ger]

Correct compression setting is off for video and audio and on for subtitles. (Can be set globally in the options, "Disable header removal ....")
Also see:
https://www.bunkus.org/answers/?qa=11/improving-playback-players-implement-matroska-specification

[MWD1001]

Correct compression setting is off for video and audio and on for subtitles. (Can be set globally in the options, "Disable header removal ....")
Also see:
https://www.bunkus.org/answers/?qa=11/improving-playback-players-implement-matroska-specification

OK, since you are gracious enough to help me let me try another test, including the settings in the link above and I'll report back to you shortly. Thanks.

Update: Sweet mother of God. I finally found a sequence that worked. Here's what I did:


First made a MKV file with just the source audio and video using MakeMKV. Tested this file and it played flawlessly.
Added that MKV file to MKVMerge along with the srt forced subtitles I needed. Changed subtitle format to UTF-8 for compatibility with my player (Sony BDP-S390).
Made sure compression was off for both audio and video, but on for subtitles.
Added the three global command line settings from the suggestion link provided by sneaker_ger.
Remuxed the file in MKVMerge and prayed.


Somehow that worked. After 48 hours of testing I'm ready to watch this fricking movie with my forced subtitles in all its lossless glory. I have no idea what settings or combination I changed in MKVmerge (I think it might have been compression on the subtitles), but I wrote them down and I'll test another film later tonight/tomorrow to make sure this wasn't just a fluke.

Thanks sneaker_ger for your suggestions and for providing that link to the faq/suggestions written by mosu.

[LeMoi]

Maybe the included decoder is a little old, try to mux with a previous build of mkvtoolnix (v4.x for example ?)

[Chetwood]

Correct compression setting is off for video and audio and on for subtitles. (Can be set globally in the options, "Disable header removal ....")
Header compression is not the same as subtitle compression.

[sneaker_ger]

Header compression is not the same as subtitle compression.

True, but no one said otherwise. :confused:

[sneaker_ger]

Somehow that worked. After 48 hours of testing I'm ready to watch this fricking movie with my forced subtitles in all its lossless glory. I have no idea what settings or combination I changed in MKVmerge (I think it might have been compression on the subtitles), but I wrote them down and I'll test another film later tonight/tomorrow to make sure this wasn't just a fluke.

I'd try the global option only, without touching anything else. Even though I posted the link to the FAQ, these might be unnecessary for a 2012 player.

[MrVideo]

The options I use to package MKV files is:

mkvmerge --clusters-in-meta-seek --default-language eng -o OutputFile.mkv --compression -1:none InputFile.h264 --compression -1:none InputFile.ac3

To fix bad MKV files, it is:

mkvmerge --clusters-in-meta-seek --default-language eng -o OutputFile.mkv --compression -1:none InputFile.mkv

I've not had an issue yet.

[Mosu]

Hey,

I've released v5.7.0. It's purely a bug fix release. The most important bug fixed was the excessive CPU usage during muxing.

Unfortunately the bug fix for the CPU usage brought on a new bug. Due to timing issues between the child process (mkvmerge) ending and the GUI reading its output the very last line(s) of mkvmerge's output might not be shown by mmg. The progress bar might also not be updated to full. However, this is purely a cosmetic issue: the output file has been written completely by that point. See also issue 774 (https://trac.bunkus.org/ticket/774).

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

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

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

Here's the ChangeLog since v5.6.0:

2012-07-08 Moritz Bunkus <moritz@bunkus.org>
* Released v5.7.0.
* mmg: bug fix: mmg will no longer print false warnings about a chapter UID not being unique. Fixes #760 (https://www.bunkus.org/trac/ticket/760).
* mkvmerge, mkvpropedit, mmg: bug fix: All tools can now deal with 64bit UID values (chapter UIDs, edition UIDs etc).
* mkvmerge: new feature: If "splitting by parts" is active and the last split part has a finite end point then mkvmerge will finish muxing after the last part has been completed. Implements #768 (https://www.bunkus.org/trac/ticket/768).

2012-06-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The DTS and TrueHD packetizers were not flushed correctly. In some rare circumstances this could lead to mkvmerge aborting with an error message about the packet queue not being empty at the end of the muxing process. Fixes #772 (https://www.bunkus.org/trac/ticket/772).

2012-06-17 Moritz Bunkus <moritz@bunkus.org>
* mmg, mkvinfo's GUI, all .exes: enhancement: Added new icons by Ben Humpert based on the ones by Eduard Geier (see AUTHORS).

2012-06-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed handling of tracks in QuickTime/MP4 files with a constant sample size. This fixes the other reason for the "constant sample size and variable duration not supported" error. Fixes issue 764 (https://www.bunkus.org/trac/ticket/764).
* mkvmerge: bug fix: Tracks in QuickTime/MP4 files with empty chunk offset tables (STCO and CO64 atoms) are ignored. This fixes one of the reasons for the "constant sample size and variable duration not supported" error.

2012-06-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed mmg's excessive CPU usage during muxing.

2012-06-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Reading DTS from AVI files often resulted in the error message that DTS headers could not be found in the first frames. This has been fixed. Fixes issue 759 (https://www.bunkus.org/trac/ticket/759).

2012-05-31 Moritz Bunkus <moritz@bunkus.org>
* Documentation: Updated the cross-compilation guide and fixed the "setup_cross_compilation_env.sh" script.

Have fun.

[Keiyakusha]

Hi Mosu, thanks for the new build!
Regarding new "bug", maybe you can just make it draw full progress bar when everything is done? I mean it won't show any real progress since the work is finished, it will just look full. Or maybe just replace the whole thing by something like "DONE" text or whatever. Because right now it looks... well, you know (http://i.imgur.com/Enws3.png) :D

[Mosu]

I know how it looks right now, but people have also already noticed that the last line they usually see ("Writing the cues...") might be missing as well. Therefore simply filling the progress bar might confuse them even more, I'm afraid. I'm also not a big fan of masking bugs instead of fixing them. I will fix the issue, I will most likely do it in time for the next release, but I also have a two-week vacation coming up in which I won't be home. Therefore a timely fix is unlikely.

Also: mmg also says "mkvmerge exited with a return code of 0. Everything went fine." Something like "DONE" would just be... well... redundant.

[Keiyakusha]

Oh, for some reason I though that this is not fixable. No problem then.

[Mosu]

It is definitely fixable, though I have to admin that I'm not sure how exactly I'm going to. Maybe instead of reading directly from the child process I'll have mkvmerge write to a file (with "--redirect-output") that mmg reads at the same time. That way the output will never get lost. However, those are technical details that shouldn't matter to you, the user, as long as it gets fixed ;)

All of this is more or less due to the limited interface that the wxWidgets library provides, unfortunately.

[hello_hello]

Using the GUI, I open an MKV which makes no use of the "File/segment title" field. Naturally it contains no text. I remove the MKV and open a second one which does make use of the "File/segment title" field and it's title is included in the field accordingly. I remove the second MKV and add a third. Regardless of whether the third MKV makes use of the "File/segment title" field, the text in the field remains as the title of the second MKV.
So basically once an MKV which has a title is opened and removed, the "File/segment title" field is no longer updated to reflect the correct title of any subsequently opened MKVs. The only way to ensure the "File/segment title" field is updated correctly seems to be to close and re-open MKVMergeGUI each time rather than simply remove and add MKVs.

I assumed this behavior must be a version 5.7.0 bug as I'd only just upgraded MKVToolNix and this is the first time I'd noticed it, however I downgraded to version 5.6.0 and it behaves the same way, so maybe it's intended, but it seems logical to me if I open a single MKV, the "File/segment title" field should be updated or cleared accordingly.

Cheers.

[Mosu]

Use "File -> new" if you want to start over completely. This is a feature (!) that users actually expect to work: remove all files and the other inputs stay set instead of being cleared.

Adding a file will also only fill in certain input fields if there's no text in them when you add that file. Again, a feature.

[hello_hello]

I sort of figured it may be intended behavior but it seemed a little inconsistent to me, however I'm fairly sure I've never used the File/New menu. Now you've pointed it out, the behavior makes perfect sense.
I guess a dumb, dumb like me would have benefited from a "new" button above the "add" button or something similar, but at least now I know how to reset everything.

Cheers.

[Mosu]

Here's a build that should fix the problem with mmg not reading mkvmerge's output fully: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.7.0-build20120711-453-setup.exe

I'd appreciate some testing.

[hello_hello]

I'd appreciate some testing.

I was experiencing the problem with 5.7.0, but so far not with the build you posted.

[bugmen0t]

where i can find the full list of mkvmerge alias
like
"The Stars were mine"
"Healer"
"The Whirlwind" , etc?

[Mosu]

They're all listed in http://www.bunkus.org/videotools/mkvtoolnix/releases.xml.gz

[bugmen0t]

thanks so much, Mosu http://static.kaskus.co.id/images/smilies/cewek.gif

[mood]

Hi, Mosu...

Version 5.7.0 have a bug on progressbar stay in the middle when muxing is finish.

[sneaker_ger]

Test this:
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.7.0-build20120711-453-setup.exe

[Mosu]

Hi, Mosu...

Version 5.7.0 have a bug on progressbar stay in the middle when muxing is finish.

See this post and the following oes as well as issue 774 (https://trac.bunkus.org/ticket/774).

[Liisachan]

Tried 5.7.0, worked fine, including the progress-bar on my Windows XP (single core).
Maybe timing issue doesn't exist on a single-core system?
I'm encoding on a multi-core system, but am still using a single-core machine when muxing for some personal reason.
That bug in the official 5.6.0 is gone anyway. Reconfirmed here :)

[sneaker_ger]

What is the reason for the last timecode of a video track being extracted as a float, while all other timecodes are being extracted as integers? I suppose it's stored differently, as it's not a start time but an end time?
(If you need a sample download this (https://rapidshare.com/files/2377518186/delay_sample.mp4) and remux with 5.7.0 + extract video timecodes)

[Mosu]

In order to be able to calculate the frame durations for N tracks a timecode v2 file has to contain N+1 timecodes as the duration is always the difference between two consecutive timecodes. Therefore mkvextract will write one more timecode during extraction than there are frames in the file. That timecode is calculated as "last frame's timecode + last frame's duration".

Now internally all timecodes are floating point numbers, not integers. They're output with as few places as possible though, hence "40" instead of "40.000000". This is due to most Matroska files using a timecode resolution of 1ms and the timecode files using the very same resolution. However, the N+1st timecode is the sum of the Nth timecode and its duration -- and the duration is taken from the "default duration" header element. And that one is often enough not a rational number (think of 1000 / 23.796).

[sneaker_ger]

Now internally all timecodes are floating point numbers, not integers. They're output with as few places as possible though, hence "40" instead of "40.000000". This is due to most Matroska files using a timecode resolution of 1ms and the timecode files using the very same resolution.

So my real should've been: why did you make mkvmerge ignore the decimals? Does this serve any practical purpose worth the increased jitter?

However, the N+1st timecode is the sum of the Nth timecode and its duration -- and the duration is taken from the "default duration" header element.

What happens if there's no DefaultDuration or BlockDuration element? Duration of N-1?

And that one is often enough not a rational number (think of 1000 / 23.796).

What do rational numbers have to do with this, if timecodes aren't stored/extracted as rationals? :confused:

[Mosu]

So my real should've been: why did you make mkvmerge ignore the decimals? Does this serve any practical purpose worth the increased jitter?

Would you care to elaborate on "why did you make mkvmerge ignore the decimals"?

Matroska files have a maximum resolution of 1ns. The specs know a concept of a "timecode scaling" parameter. This parameter determines the effective resolution of timecodes in a Matroska file. That parameter is simply used as a factor by the reading program in order to scale to nanosecond resolution. The default value in the specs is 1,000,000 (American notation) resulting in an effective resolution of 1ms.

Why does this parameter exist in the first place? Because it's a trade-off between saving space and higher precision. Remember that all integer numbers (timecodes are integers) are stored in variable-length encoding.

Now to mkvmerge. Internally mkvmerge calculates all timecodes and durations in nanosecond precision. When outputting a file mkvmerge has to decide upon the timecode scaling factor. In general this defaults to 1,000,000 as well -- unless you create an audio-only file. In that case the timecode scaling parameter will be calculated to allow sample-precision for the file.

What happens if there's no DefaultDuration or BlockDuration element? Duration of N-1?

During extraction? I don't know from the top of my head.

What do rational numbers have to do with this, if timecodes aren't stored/extracted as rationals? :confused:

They are extracted as floating point numbers. However, if a floating point number's decimal places are 0 (as in 40.000000) then the decimal places are not written to the timecode file.

[sneaker_ger]

Would you care to elaborate on "why did you make mkvmerge ignore the decimals"?

Your answer covers my question completely, thx.

[Mosu]

You're quite welcome :)

[sneaker_ger]

Don't rejoice too quickly as a new question just popped my mind:
How can the audio track's timecodes have decimals, if TimecodeScale is 1000000 and a segment element, not a track element? (Like in a file with both video and audio)

[Mosu]

In audio tracks several frames are put into a single Matroska element (either a BlockGroup or a SimpleBlock; the difference does not matter for the sake of this discussion). This is called "lacing" in Matroska terms. That single Matroska element has a timecode that is indeed scaled with TimecodeScale. However, there's only a single timecode stored in the file for the whole BlockGroup/SimpleBlock (that's the whole reason for lacing frames: saving space, especially with codecs that use ultra small packet sizes like TrueHD for which single frames often have fewer than 100 bytes).

The timecodes of the second and all following frames in a lace are again calculated from the track's DefaultDuration element. For N frames in a single block programs use the following simple formula: timecode for frame N = BlockTimecode + (N - 1) * DefaultDuration As the DefaultDuration element itself is stored with nanosecond precision you end up with timecodes that are not divisible by TimecodeScale for audio tracks.

[sneaker_ger]

Thx.
That also explains why every 8th timecode does not have decimals, i.e. it's the start of a block. I never gave it much thought and assumed the timecodes would just add up to x.000000 in that location, which is obviously nonsense.

[KoD]

Hi, the test binary http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.7.0-build20120711-453-setup.exe also fails to display anything in the mkvmerge GUI, when trying to mux a small file, like the one here:
http://wikisend.com/download/415420/6_Channel_ID.flac

The result of the merge process is an empty window, with no log, and no progress bar, but with an "everything went fine" message.

[Mosu]

I will not fix that, I guess. <rant>Simply because the effort needed in order to re-write that particular part of mmg yet again (and this time it won't be a "small" time investment like roughly 20 hours). It all started with Jon asking for my help 'cause mmg wouldn't run that well on Mac OS as it did on Windows and Linux. Now everything's got a whole lot more complicated...</rant>

Anyway. I have a good idea why it happens, why it only happens with trivially short muxing cycles, and that there's no easy fix. So... I'll leave it like this for the time being.

[Atak_Snajpera]

are we far from support .opus audio format in matroska?

[Mosu]

As far as any other codec that hasn't been implemented yet. However, I will most likely work on that one day. No ETA, as usual.

[mastrboy]

are we far from support .opus audio format in matroska?

Opus does not seem to be a part of the matroska specification: http://matroska.org/technical/specs/codecid/index.html

So what good does it to add support in a muxer for it?
I might be misunderstanding something though...

Btw, i too would like to see more Opus support, and not just for the mkv container.

[Kurtnoise]

https://wiki.xiph.org/MatroskaOpus

[SeeMoreDigital]

I actually tried muxing an Opus audio file with MKVmerge GUI on Sunday. Needless to say it did not work :o

But even with Matroska container support, we still need software player splitter and decoder support to test Opus more fully ;)

[Kurtnoise]

With ffmpeg, you should be able to mux opus stream to matroska...

[Mosu]

As A_ACM? Well, that's completely unspecified by the specs, and it wouldn't solve some of the problems mentioned in the wiki page like seeking & preroll.

[Kurtnoise]

As A_OPUS but yeah, seeking problems remain for the moment...

[Mosu]

Well, that's even worse because it isn't even specified yet.

[SeeMoreDigital]

Well, that's even worse because it isn't even specified yet.

Well.... It may be of "no interest to you" what-so ever. But AVI-Mux GUI (v1.17.8.3 Dated 16 Feb 2010) is able to place Opus audio streams within the Matroska (.MKA) container ;)

EDIT: And the new version of MediaInfo (v0.7.59) can read their contents.

[Mosu]

It's nice that they all implement something like that but don't contact any of the Matroska devs regarding making the framing official ~~ I am definitely interested, just a bit disappointed.

[gonwk]

Hi folks,

I am combining Video form one source with the Audio form another source. The 2 MKV files are identical with the exception that video lengths are about 19.960 Seconds different and that causes my Audio to be off ... here is the info

Video 1 duration is 01:29:37.040
Video 2 duration is 01:29:57.000

I have tried the following with no luck ...
I used MKVMerge and put in -14000 ms Audio Delay ... and that works for about 20 minutes then Audio/Video sync problem again.

I saw something about Video Stretch ... but can't figure out how to use it.

Q1: Can someone tell me how to use the Video Stretch Function?

Q2: Is there a Better and Easier way of mixing the Good Video from one file with Good Audio of the other file?

Thanks!

G!:)

[DragonQ]

Sorry if this has been asked before but are there any plans to support LATM AAC? Does the MKV container even allow this?

[Mosu]

As far as I understood LATM is simply a different container/streaming format for AAC to be packaged in. So there's no specific requirements for Matroska -- only mkvmerge would have to be able to read that format. But no, there are no plans whatsoever.

[nevcairiel]

LATM also has the advantage that it carries an additional header for decoder configuration information, which allows mid-stream decoder re-configuration (change number of channels, and the like), which Matroska with raw AAC would not allow. (ADTS-AAC has the same feature as well)

[Mosu]

I see. Well no, that is not supported in Matroska.

[Mosu]

Hey,

I've released v5.8.0. It adds a couple of new features and fixes a few bugs; most prominently mmg not displaying mkvmerge's last couple of messages.

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

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

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

Here's the ChangeLog since v5.7.0:

2012-09-02 Moritz Bunkus <moritz@bunkus.org>
* Released v5.8.0.
* Build system: dropped support for gcc 4.6.0.
* mkvpropedit: new feature: Added support for adding, deleting and replacing attachments.

2012-09-01 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: chapter editor: Added support for the edition flags "hidden", "default" and "ordered" as well as the chapter values "segment UID" and "segment edition UID". Implements ticket #736 (https://www.bunkus.org/trac/ticket/736).

2012-08-30 Moritz Bunkus <moritz@bunkus.org>
* documentation: Added a Basque translation of mmg's guide by Xabier Aramendi (see AUTHORS).
* all: bug fix: Fixed a buffer overflow in the Base64 decoder routine.

2012-08-19 Moritz Bunkus <moritz@bunkus.org>
* source: Various fixes for building with g++ 4.7.x and clang 3.1.

2012-08-08 Moritz Bunkus <moritz@bunkus.org>
* Build system: Boost's "bind" library is not required anymore. The C++11 features from "functional" are used instead.

2012-08-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MPEG transport streams whose timecodes wrap around/overflow are handled correctly. Fixes #777 (https://www.bunkus.org/trac/ticket/777).

2012-08-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MP2/MP3 audio tracks in MPEG program streams that contained garbage at the start of the very first packet caused mkvmerge to use uninitialized/random values for certain parameters (sample rate, number of channels, and therefore also during timecode calculation).

2012-08-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading ALAC (Apple Lossless Audio Codec) from CAF (CoreAudio), MP4 and Matroska files. Implements #753 (https://www.bunkus.org/trac/ticket/753).

2012-08-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: mkvmerge will remove stuffing bytes from MPEG-1/-2 video streams that are used to keep the bit rate above certain levels (the 0 bytes between slices and the following start code). Implements #734 (https://www.bunkus.org/trac/ticket/734).

2012-08-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed audio/video synchronisation when reading MPEG program streams with MPEG-1/2 video with respect to B frames. Fixes #579 (https://www.bunkus.org/trac/ticket/579).
* mkvmerge: enhancement: SRT files can have spaces in their timecode line's arrow (e.g. "-- >").

2012-07-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: VC1: mkvmerge will now only mark frames as I frames if a sequence header precedes them directly. Fixes #755 (https://www.bunkus.org/trac/ticket/755).

2012-07-30 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: Added a Basque translation by Xabier Aramendi (see AUTHORS).

2012-07-20 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: The programs do not try to create directories with empty names anymore. This happened if the output file name for e.g. mkvmerge or mkvextract was only a file name without a directory component. With Boost v1.50.0 the call to "boost::filesystem::create_directory()" would result in an error if the name was empty (it didn't in earlier versions of Boost).

2012-07-11 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed mmg not reading the very last line of mkvmerge's output. The result was that messages like "the cues are being written" did not show up in mmg and that the progress bar was not filled completely. Fixes #774 (https://www.bunkus.org/trac/ticket/774).


Have fun.

[b66pak]

thanks a lot...
_

[Liisachan]

Thanks as always, Mosu :)
In case this isn't intentional... you forgot to post in the Matroska mailing list. I always got an email titled like "MKVToolNix v1.2.3 released", which I didn't this time.

[Isochroma]

Windows XP SP2 32-bit, MKVMerge GUI 5.8.0:

Trying to append "03 03_disorganisation.m4a" to "02 02_strength_of_movements.m4a" causes MKVMergeGUI to throw an error: "Assertion failed!".

Same happens if they are muxed individually to MKV and attempted merge.

Same also happens if they are muxed to MKV, extracted using MKVExtract to AAC and then appended.

After dismissing that dialog it just totally crashes out and process self-terminates.

It works fine to merge most of the other M4A parts by appendation.

I can also merge the files OK with the older MKVMerge 1.8.1, so it's a code regression since then.

Here are the files: MKVMerge GUI M4A Append Crash Source Files.rar (http://www.sendspace.com/file/nruiba)

[Mosu]

Thanks as always, Mosu :)
In case this isn't intentional... you forgot to post in the Matroska mailing list. I always got an email titled like "MKVToolNix v1.2.3 released", which I didn't this time.

Thanks for noticing. I totally forgot about that.

[Keiyakusha]

Hi Mosu! Thanks for the new version! I want to ask something about mkvmerge and official cleaning/validation tools. Maybe its not very follows this topic, but somehow I feel that you may know the answers.

Some people say TimecodeScale in matroska is mandatory but mkclean removes it. This makes "optimized" files incompatible with some matroska parsers/splitters/players. Is it normal to work around this issue or this is mkclean bug?
Then on every file muxed by mkvmerge validator reports that there is 5000+ bytes of void data and mkclean (probably) removes it. What is that? Oo
Also if I'll make mkv with 2 (or more?) video streams, validator reports a lot of things like "First Block for video track #2 in Cluster at 40801376 is not a keyframe". What is that? It expects that both streams will have keyframes at the same places? I have no idea how can I achieve that without reading frametype information from 1st stream and then manually overriding frametype decisions by creating lookup list of frames that I pass to encoder Oo

Finally, just curious, why you made header editor as separate window? To me it seems that having it as one more tab, just like chapter editor will be more consistent...

[Mosu]

Some people say TimecodeScale in matroska is mandatory but mkclean removes it. This makes "optimized" files incompatible with some matroska parsers/splitters/players. Is it normal to work around this issue or this is mkclean bug?

It is mandatory. However, in Matroska elements can also have default values in the specs. If an element's value equals its default value then it doesn't have to be written to the file. Turning this argument around means that a reader must assume that the element equals its default value if it isn't present in the file.

TimecodeScale (http://www.matroska.org/technical/specs/index.html) has a default value of 1.000.000 which is also the standard value that most muxers use resulting in ms precision for timecodes. That's why mkclean can safely remove it.

If software doesn't support this situation then it is buggy/doesn't implement the Matroska specs properly.

See also one of my FAQ entries (https://www.bunkus.org/answers/?qa=5/does-language-english-show-output-file-even-though-selected).

So what mkclean does is 100% spec compliant.

Then on every file muxed by mkvmerge validator reports that there is 5000+ bytes of void data and mkclean (probably) removes it. What is that? Oo

Void elements are placeholders that can be overwritten with other values. Readers must simply skip such values.

mkvmerge uses them after certain important elements during muxing, especially after the track headers. This is done because mkvmerge sometimes has to change and re-write the track headers during muxing because new information is available that wasn't available when muxing started. There are basically two approaches for dealing with it: 1. use two-pass muxing (after the first pass it is known how much space muxing will really need for such elements) or 2. create small void elements at the start of the muxing that can be overwritten/adjusted during muxing. mkvmerge choses 2. for two important reasons: implementing two-pass muxing is pretty time consuming to code, and enforcing two-pass muxing is very annoying to the user (it takes twice as long, obviously).

100% spec compliant. Wastes only ~5 KB of space.

Also if I'll make mkv with 2 (or more?) video streams, validator reports a lot of things like "First Block for video track #2 in Cluster at 40801376 is not a keyframe". What is that? It expects that both streams will have keyframes at the same places?

More or less, yes. This is just a question of how easy it is to seek in such files. As a user you will never, ever, ever notice a difference. Simply ignore this warning. It's also not a spec violation -- simply a matter of being only 99.9% optimal instead of 100%.

I have no idea how can I achieve that without reading frametype information from 1st stream and then manually overriding frametype decisions by creating lookup list of frames that I pass to encoder Oo

Well... From the programmer's view: simply start a new cluster before each and every video key frame. I refuse to do that because it wastes space for no gain at all. From the user's view: you cannot, at least not with mkvmerge.

Finally, just curious, why you made header editor as separate window? To me it seems that having it as one more tab, just like chapter editor will be more consistent...

Implementing the chapter editor as a separate tab was the wrong decision. It confused users to assume that the chapters they see there are actually taken into account during muxing. As a matter of fact the chapter editor is more of a separate application. That's why I decided against such a design for the header editor.

That I don't split up the chapter editor tab into a separate window today is simply a matter of not wanting to waste more time on wxWidgets programming than absolutely necessary.

[Keiyakusha]

More or less, yes. This is just a question of how easy it is to seek in such files. As a user you will never, ever, ever notice a difference. Simply ignore this warning. It's also not a spec violation -- simply a matter of being only 99.9% optimal instead of 100%
I see. Well I asked about this mainly because I encountered problems with such files. One of the video streams was having troubles with seeking. After seeking it just freezes for some time. In my case 1st stream was freezing and 2nd one with a lot higher amount of keyframes was playing alright. Interesting thing its that running the file through mkclean was fixing the seeking problem. However I wasn't able to replicate this issue today, so I removed this information from my initial question. Will check more about that.

About TimecodeScale, I see. I was guessing things are like that. The software I was dealing with will be fixed to support this default timescale value.

Thanks for your answers. Everything is perfectly clear now!

[Mosu]

I have seen it. I will take a look at it when I find the time and motivation (probably not before the weekend).

[cyberbeing]

From seeking + subtitle perspective, would it be possible to add a switch to mkvmerge to prioritize creating clusters based on subtitle start times which overlap a keyframe, on the subtitle start time instead of the keyframe?

It appears that Haali's GDSMux does this, but mkvmerge doesn't. The difference being that with a MKV created with GDSMux, you can seek to a chapter on a keyframe when paused, and subtitles with start times in very close proximity to that keyframe will be displayed. With a MKV created with mkvmerge, no subtitles will be displayed at all, even after resuming play, since the subtitle which overlaps this keyframe was placed in the previous cluster and never loaded since the splitter seeks directly to said keyframe cluster (which happens to be a chapter). I've noticed that disabling the meta-seek element in mkvmerge may resolve the issue, but that doesn't seem like an optimal solution.

[Mosu]

I won't add such a switch, sorry. There are several reasons (time, technical reasons, and there are better/proper solutions to this problem that solve other issues as well). No, I don't want to spend half an hour explaning this in detail at the moment. Sorry.

[cyberbeing]

I won't add such a switch, sorry.
No problem, what I suggested never really sounded optimal in the first place.

There are several reasons (time, technical reasons, and there are better/proper solutions to this problem that solve other issues as well). No, I don't want to spend half an hour explaning this in detail at the moment. Sorry.

Hmm... Well when you have a chance, I'd be curious and interested in hearing about what the better/proper solutions are for future reference.

Everybody seems to always blame the subtitle renderer for this issue, but as far as I can tell it's actually a MKV specific muxer/splitter issue?
None the less, if there is anything which we could do in xy-VSFilter to resolve this, we're open to suggestions.

[Mosu]

The proper way would be to add subtitle entries to the index (Matroska terms: the cues). This can already be enforced with mkvmerge for each track (option "--cues" (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.cues)). However, in order to provide a real benefit to splitters/players such cues would have to store not only the frame's start time but also its duration. That is currently not possible with Matroska specs.

There are also other related issues with the cues that don't relate to subtitles but to things like pre-roll. For example, Opus has such problems (see http://wiki.xiph.org/MatroskaOpus). This would not be solved by such an "duration-in-cues" field mentioned above, though.

So when we extend the Matroska specs regarding cues I'd like that extension to cover both use cases.

[Liisachan]

@Mosu - Questions (Muxing)

1) When a timecode file is used (with a VFR-as-CFR moive), what's the default value of Video track's DefaultDuration ? Is that value important in any way? Mkvmerge seems to write a rather random value for it. Since it's VFR, DefaultDuration should be meaningless anyway, I suppose.
2) --default-duration seems to be just ignored even if specified. On MMG, the "FPS" option is not disabled even after a timecode file is specified, but apparently this "FPS" setting doesn't change anything.

@cyberbeing
Just FYI I often set a chapter point about 3 video-frame after the intended chapter point (keyframe). That way, I don't have to hear the partial audio (not beautiful) from before the keyframe, which would be otherwise decoded (if the audio packet straddles the keyframe in question, timing-wise). And after the chapter jump, the video is decoded from the targeted keyframe anyway, because the player first has to decode the keyframe before it can decode the chaptered bvop.

Also, you might want to tweak the subtitle start time to see if it helps. For example, if the chapter point frame is t=1000, and the previous frame is t=950, then the sub-start=1000 is unsafe. You can edit the subtitles so that, for example, the sub-start will be 990 (basically, this change has no bad effects: relative timing--or rendering--doesn't change as long as it's after the previous frame, t=950). Then, the probability that the sub in question is shown right at t=1000 will increase.

But admittedly, controlling softsubs is very difficult. We may have to use several workarounds.

[sneaker_ger]

@Mosu - Questions (Muxing)

1) When a timecode file is used (with a VFR-as-CFR moive), what's the default value of Video track's DefaultDuration ? Is that value important in any way? Mkvmerge seems to write a rather random value for it.

Look here (http://forum.doom9.org/showpost.php?p=1563861&postcount=1436) for an explanation on how this is set with timecode file input.
That value is not important for video tracks, though, since each frame has its own timecode anyways. Some programs might choose to make use of that info in one way or another, but I haven't really seen it being put to use. (Because of the rounding, LAV/madVR for example uses the bitstream info instead of container info)

2) --default-duration seems to be just ignored even if specified. On MMG, the "FPS" option is not disabled even after a timecode file is specified, but apparently this "FPS" setting doesn't change anything.

If you specify a timecode file, the "FPS" field is ignored. If you don't set a timecode file, "FPS" controls all the timecodes and the defaultduration header element.
If you open a mkv file in mmg, the "FPS" field is always empty, which just means that it will copy whatever value has been used in the source file (both timecodes and header element). It does not mean that the element has not been set. If you want to check the element use mkvinfo or the header editor.

[Mosu]

@Mosu - Questions (Muxing)

sneaker_ger has answered both questions very well (and correctly) already. I only have this link to add to the first question: Why is the FPS/frame rate wrong? (https://www.bunkus.org/answers/?qa=205/why-is-the-fps-frame-rate-wrong) It's from my FAQ and explains a bit more about what DefaultDuration really is and how readers are supposed to interpret it.

[cyberbeing]

Just FYI I often set a chapter point about 3 video-frame after the intended chapter point (keyframe).
This would work only in cases when the desired start time of the subtitle is the keyframe, or else the subtitle will likely end up in the previous MKV cluster and never get decoded on seek.

Also, you might want to tweak the subtitle start time to see if it helps. For example, if the chapter point frame is t=1000, and the previous frame is t=950, then the sub-start=1000 is unsafe. You can edit the subtitles so that, for example, the sub-start will be 990 (basically, this change has no bad effects: relative timing--or rendering--doesn't change as long as it's after the previous frame, t=950). Then, the probability that the sub in question is shown right at t=1000 will increase.
Similar as above, this usually won't work when the chapter point is a keyframe. If you set the sub-start time to 990, it will often end up in cluster prior to the one containing the keyframe/chapter. If the chapter point is _not_ a keyframe this method you mention will usually work.

But admittedly, controlling softsubs is very difficult. We may have to use several workarounds.

It is difficult. There are little workarounds like what you mentioned, but what we really need is a solution which allows subtitles which overlap multiple clusters to be displayed, even if you seek near the end of a line. This issue doesn't occur with external softsubs at all, since VSFilter pre-loads the entire script. Theoretically I could imagine a hackish solution involving MKV attachments and a splitter modification to allow VSFilter to pre-load the entire attached script as if it were external, but that would be completely non-standard and conflict with the MKV spec's support of embedded subtitles (bad idea).

I'm hopeful something like the "duration-in-cues" which Mosu mentioned will turn into a proper solution, but it sounds like it would require an overhaul of MKV splitters to actually support it. Luckily (or not) we do now have the Opus codec which requires a decoding 'pre-roll' (the need to decode audio frames prior to the one seeked to for proper decoding) which will require a splitter overhaul anyway. If the MKV spec extension for Opus can be extended to support subtitle start/end times as well, that will be excellent.

[Liisachan]

@sneaker_ger
@Mosu
Thanks a lot, and I'm sorry I asked the essentially same question that was already asked. The FAQ page is so informative. Let me add another nitpick, though. The FAQ says that the Matroska specifications do not know about a concept called "FPS", which is not entirely true: "FPS" is explicitly defined in the Tag specifications. But that's not the point, I know~ :P

Well, I kind of suggested this: it would be more user-friendly if a control in MMG was disabled when not available. For example, it would be ideal if the [Start muxing] button was grayed until the Output file name is specified. In the ideal world, the FPS list would be disabled when the Timecodes editbox is non-empty. But that's only idealism. I'm not complaining here.

@cyberbeing
I can see your point. That said, you can at least make it a keyframe if a frame is chaptered, using a qpfile if it's x264. Also, you can try a workaround like this, if subtitles are text-based like SSA/ASS.

; Example 1
Dialogue: 0,0:00:10.00,0:00:15.00,...,,A keyframe at 00:11.23 is bad?!

; Example 2 (Workaround)
Dialogue: 0,0:00:10.00,0:00:11.23,...,,A keyframe at 00:11.23 is bad?!
Dialogue: 0,0:00:11.23,0:00:15.00,...,,A keyframe at 00:11.23 is bad?!

Conversion from Example 1 to Example 2 could be done trivially with a simple program, using a keyframe list, before muxing. I'm not saying your problem is trivial; I'm simply offering a possible workaround.

Edit: fixed example 2

[Keiyakusha]

if by some chance Mosu will mess with GUI to make something grayed out, maybe its good idea to disable language selection for chapters, since it does nothing anyway. However I wouldn't mind if it will actually override language set for chapters, will be very handy :P

[Mosu]

You can count on me spending as little time as possible implementing changes to mmg ;)

[cyberbeing]

I'm not saying your problem is trivial; I'm simply offering a possible workaround.
This is another known workaround, but it becomes impractical whenever dealing with animated effects.

The main reason I brought back up this years old issue, is not because I was looking for a solution for myself, as it only affects me indirectly. It has more to do with how the majority of people have mistakenly come to believe this is a VSFilter bug, when it's actually a MKV limitation. It's all just part of my process of looking into and sorting issues which can be fixed by xy-VSFilter from issues caused by other factors which are outside our control. When I find time, I'll add an entry for this on the xy-VSFilter Troubleshooting FAQ. It was a happy coincidence that there may now actually be a proper solution in planning as a side-effect addition of needing to support the Opus codec.

[Mosu]

Opus has nothing to do with this solution (or the planning of it). Both issues have different solutions as far as I know. The subtitle problem (and the solution for it regarding Matroska) has also been known for years; the question is whether or not we will get around to adding elements for it.

[cyberbeing]

Technically it's completely different, but if adding new elements never occurs, couldn't you re-purpose whatever is implemented for Opus as a partial solution acting as a subtitle pre-roll?

[Mosu]

My guess is the solution for Opus will require new elements as well.

[cyberbeing]

My question was if any new Opus pre-roll elements could theoretically be re-purposed for adding a subtitle pre-roll, without adding new subtitle-specific elements?

[Mosu]

No idea, I haven't thought through what's required for Opus. Maybe, maybe not.

[73ChargerFan]

The subtitle issue might be able to be solved outside of mmg / matroska.

Splitting subtitles at chapter points sounds good for a seek, but may cause flashing when watching the video straight through. Who knows.

For static subtitles, the splitter might be able to find the current subtitle and feed it when seeking to a chapter.

Or an app could check the subtitle timing against the chapter timing and issue a warning. Chapters shouldn't be in the middle of a sentence anyways.

This could be asked of other tools' authors. For myself, the issue doesn't affect me.

[Liisachan]

Come to think of it, Gabest planned to implement optional SyncPoints in his DSM container 7 years ago (2005). I don't fully understand it, but it sounds like some kind of map that tells you, "If you jump to time t, then you should start decoding from file position f(t)". So it's a Cue in Matroska? In dsm.txt (http://guliverkli.svn.sourceforge.net/viewvc/guliverkli/trunk/guliverkli/include/dsm/dsm.txt?revision=308&pathrev=308), he also noted that even with this mechanism, subtitles could be problematic.

It would be nice if an optional, smarter seeking mechanism is implemented in MKV in such a way that an old decoder not knowing about it doesn't need to handle it. But that's also pure idealism, I suppose. The realistic solution we can use right now is to "de-overlap" subtitles before muxing. By de-overlapping, one can also avoid MPC(-HC)'s shadow-alpha bug (http://sourceforge.net/apps/trac/mpc-hc/ticket/2460). De-overlapping is usually so trivial that one might want Mkvmerge to have an option to do this automatically, but this workaround is difficult in general case, especially when karaoke is involved.

Splitting subtitles at chapter points sounds good for a seek, but may cause flashing when watching the video straight through. Who knows.
Usually that doesn't happen, no worry :) Subtitle start time is inclusive and subtitle end time ie exclusive, (almost) consistently. Otherwise you couldn't even write a simple script like--

1.00-5.00 Alice: "Hello!"
5.00-8.00 Bob: "Hi!"

I mean, you wouldn't believe it if two subs (or no subs) were shown at 5.00. Since the above will work as expected, doing this is also safe, usually:

1.00-5.00 Alice: "Hello!"
5.00-8.00 Alice: "Hello!"

This is another known workaround, but it becomes impractical whenever dealing with animated effects. Splitting animated effects timing-wise is not only practically doable, but actually much easier than one might imagine. In the second line, you'll just offset t1 and t2, and use a negative t1. This is getting off-topic, so I'll simply post examples (where 10.00 is t=-2340 for 12.34). You can PM me if you have questions.

Style: Sty1,Times New Roman,64,&H00ffffff,&H00ff9999,&H0000000,&H80000000,
-1,0,0,0,100,100,0,0,1,1,1,7,0,0,0,0

Dialogue: 1,0:00:10.00,0:00:15.01,Sty1,,0000,0000,0000,,{\fad(1000,1000)}Trivial
Dialogue: 2,0:00:10.00,0:00:12.34,Sty1,,0000,0000,0050,,{\fad(1000,0)}Trivial
Dialogue: 2,0:00:12.34,0:00:15.01,Sty1,,0000,0000,0050,,{\fad(0,1000)}Trivial

Dialogue: 1,0:00:10.00,0:00:15.01,Sty1,,0000,0000,0000,,{\move(300, 0,400, 0)}move
Dialogue: 2,0:00:10.00,0:00:12.34,Sty1,,0000,0000,0000,,{\move(300,50,400,50, 0,5010)}move
Dialogue: 2,0:00:12.34,0:00:15.01,Sty1,,0000,0000,0000,,{\move(300,50,400,50, -2340,+2670)}move

Dialogue: 1,0:00:10.00,0:00:15.01,Sty1,,0000,0000,0100,,
{\1a&Hff\4a&Hff\3c&Hff0000\t(0,3000,\1a&H00\4a&H80\3c&H0000ff\fscx200)}t-animation
Dialogue: 2,0:00:10.00,0:00:12.34,Sty1,,0000,0000,0150,,
{\1a&Hff\4a&Hff\3c&Hff0000\t(0,3000,\1a&H00\4a&H80\3c&H0000ff\fscx200)}t-animation
Dialogue: 2,0:00:12.34,0:00:15.01,Sty1,,0000,0000,0150,,
{\t(-2341,-2341,\1a&Hff\4a&Hff\3c&Hff0000)\t(-2340,+660,\1a&H00\4a&H80\3c&H0000ff\fscx200)}t-animation

What can be difficult is splitting a karaoke line, but that's also practically doable. Then again, I agree with you that this is just an ugly workaround...

[Joniii]

Im having a problem with Pirates of The Caribbean Blu-ray. Ripped mkv plays back vertically compressed with ffdshow DXVA. With default Windows decoder it is fine, also muxing the video to m2ts plays with correct AR with ffdsow DXVA. I'm not really sure if this is a problem with ffdshow or mkvtoolnix.

Here is a sample.
https://skydrive.live.com/redir?resid=5AA520AF9EAB7FD8!163

Also don't know if this is related to my problem:
http://www.makemkv.com/forum2/viewtopic.php?f=8&t=4264

[sneaker_ger]

I see nothing wrong - neither bitstream nor container AR seem to suggest anything but square pixels. :confused:
Maybe you should pose your question in the ffdshow thread.

[Atak_Snajpera]

any progress on opus in matroska? i have a feeling that unusal opus specification will never be compatible with current containers.

[Keiyakusha]

Since from what I understand they need to extend matroska specs, maybe this will push mkv v3 progress... cause its soo slow, I don't even see it ^__^
Speaking of, anyone knows something about current mkv v3 status?

[sneaker_ger]

Isn't that already finished?
Mkvmerge will output v3 if you use 3D.

[Keiyakusha]

I don't know... that's why I ask. I don't have anything 3D. Oo Will check it out thanks! The only thing I tried before is to make normal file v3, but it failed to play in most cases...

[mastrandrea]

A little request: what about a combination (example: shift+click on the up/down button) to move the selected stream at the very beginning or very end of the list?

[Mosu]

Patches are welcome.

[skampy]

I am hoping someone could help me with this.

I have a pgs .sup file from a source that is 23.976fps and I need to put it with another video that is 24fps.

Is mkvmerge able to stretch the sub file to 24fps with the use of its stretch option? If so, what floating point/fraction would you put in as the value? I'm just a little confused as to how it works.

Any help will be much appreciated.

Thanks

[73ChargerFan]

Bug report - Title tag copied

I process videos in batches, a dozen or so at a time, and use the job queue. I add the video, change stream info or delete streams, add chapter timing if necessary, add to queue, then hit 'remove all' and repeat for the next one. Later, I start the jobs and go eat dinner or what ever. Later I check each video to see if it works fine, and determine the final bit rate with MediaInfo.

Today I noticed that the Title tag from one of the videos was copied into other six videos in the same batch. All files were muxed with mkvmerge v5.6.0 and had the same date stamp.

Looking harder, I saw the same thing happened to 8 files I did yesterday with v5.8.0 - they all got the same Title tag, although the text was correct for only one of the group.

I never even knew about the Title tag, but used the header editor to remove it from the affected files.

Thanks as always Mosu.

[Chetwood]

If anyone actually is interested in adding patches to add functionality, please consider adding

- CTRL-A to add job to queue
- SHIFT-CTRL-A to remove all sources
- use TAB to cycle from the tracks, chapters, tags pane to general track options
- moving tracks up and down with the mouse rather than clicking on a track and the on the up/down buttons

Thanks!

[Mosu]

Bug report - Title tag copied

I process videos in batches, a dozen or so at a time, and use the job queue. I add the video, change stream info or delete streams, add chapter timing if necessary, add to queue, then hit 'remove all'

That is intentional behavior so that people can use similar settings for a bunch of different muxings. If you want to start over completely then use "File" -> "New".

[Mosu]

If anyone actually is interested in adding patches to add functionality, please consider adding

- CTRL-A to add job to queue

Won't be accepted. Alt-A should work already as it is an accelerator for the button at the bottom of the window, "&Add to job queue". This does work on Linux, and it used to work on Windows, though for quite some time it hasn't. So a patch I would accept would be making this work again.

- SHIFT-CTRL-A to remove all sources

Won't be accepted. One thing I would accept would be giving that button an accelerator.

- use TAB to cycle from the tracks, chapters, tags pane to general track options

I just tried it on Windows, and it works for me.

[73ChargerFan]

That is intentional behavior so that people can use similar settings for a bunch of different muxings. If you want to start over completely then use "File" -> "New".
Where is the Title tag shown / expressed in the mkvmerge GUI? Why would items that can't be set be assumed to be the same across all muxings and be copied?

And why would anything on the Attachments, Global or Chapter Editor tabs be the same across multiple jobs, except perhaps "splitting?"

Perhaps "remove all" should be replaced with "new job".

[Mosu]

Perhaps you should take a step back and acknowledge that your particular use cases for mmg don't necessarily match everyone else's. Both features, "remove all inputs while leaving the settings intact" and "start over from scratch as if you had just started mmg", have been requested by users and are actively used. Therefore I will most certainly not change this.

As for the title: it's called "file/segment title" and can be found on the "global" tab. It can be set just fine. mmg sets it automatically when you add an input file that already has such a title (e.g. a Matroska or OGM file), but only if the input is currently empty.

If you really, really cannot think of a use case then think about muxing several episodes of a TV series, e.g. with special fonts (not uncommon with anime) -- use case for attachments. You often have nearly identical titles ("The Awesome Series With A Long Name S04E01") which only varies in one place; it's quite convenient not having to type it all the time -- use case for keeping the title.

Do I really have to go on?

[73ChargerFan]

No, I understand the examples, and now see Title in the global tab. (I looked, didn't recognize it.)

I asked before about why the chapters file text box wasn't cleared when "remove all" was hit, and I don't remember being directed to use "File->New".

This never affected me until I started using the job queue, because I'd rarely process more than one video at a time.

[Chetwood]

Won't be accepted. Alt-A should work
It doesn't. What changed?

Won't be accepted. One thing I would accept would be giving that button an accelerator.
Exactly what I was asking for. SHIFT-CTRL-A was just an example.

I just tried it on Windows, and it works for me.
You can click on any track and then move down several tracks with the arrow down key? I can't, cause as soon as a new track is marked mmg sets focus on track name. Wouldn't be too bad if I could SHIFT-TAB back to the Tracks, chapters and tags pane but I can't. I have to TAB 18x to get back there to go down and select the next track (if I don't want to use the mouse which is kinda my point here).

[Mosu]

It doesn't. What changed?

wxWidgets changed. Not saying I blame them, I may be doing something wrong, too, but it sill works on Linux. So it's yet another case of wxWidgets behaving differently on different OS, and I'm damn tired of fixing such issues. It's like looking for a needle in a haystack.

[sneaker_ger]

I have a pgs .sup file from a source that is 23.976fps and I need to put it with another video that is 24fps.

Is mkvmerge able to stretch the sub file to 24fps with the use of its stretch option? If so, what floating point/fraction would you put in as the value? I'm just a little confused as to how it works.

Yes, try "24000/24024" for the "Stretch by" field.

[Lincoln Burrows]

I had this error while muxing a bunch of files:

'D:\Video\O Silêncio dos Inocentes (1991)\00001.track_4113.mpv': Using the demultiplexer for the format 'MPEG video elementary stream'.
'D:\Video\O Silêncio dos Inocentes (1991)\00001.track_4352.dts': Using the demultiplexer for the format 'DTS'.
'D:\Video\O Silêncio dos Inocentes (1991)\00001.track_4354.ac3': Using the demultiplexer for the format 'AC3'.
'D:\Video\O Silêncio dos Inocentes (1991)\00001.track_4608.sup': Using the demultiplexer for the format 'PGSSUP'.
'D:\Video\O Silêncio dos Inocentes (1991)\00001.track_4610.sup': Using the demultiplexer for the format 'PGSSUP'.
'D:\Video\O Silêncio dos Inocentes (1991)\00001.track_4113.mpv' track 0: Using the output module for the format 'MPEG-1/2'.
'D:\Video\O Silêncio dos Inocentes (1991)\00001.track_4352.dts' track 0: Using the output module for the format 'DTS'.
'D:\Video\O Silêncio dos Inocentes (1991)\00001.track_4354.ac3' track 0: Using the output module for the format 'AC3'.
'D:\Video\O Silêncio dos Inocentes (1991)\00001.track_4608.sup' track 0: Using the output module for the format 'PGS'.
'D:\Video\O Silêncio dos Inocentes (1991)\00001.track_4610.sup' track 0: Using the output module for the format 'PGS'.
The file 'D:\Video\O Silêncio dos Inocentes (1991)\00001.track_4113.mkv' has been opened for writing.
The cue entries (the index) are being written...
Muxing took 18 minutes 0 seconds.

Warning: Video ended with a shortened group of pictures. Some frames have been dropped. You may want to fix the MPEG2 video stream before attempting to multiplex it.My steps:

Blu-ray Silence of the Lambs, MPEG-2.

1) Decrypted using AnyDVD (in the past);
2) MakeMKV warned the files were used by AnyDVD. This warning means I can convert to MKV other contents, but there's a risk for this to fail if I attempt to do that with the movie;
3) I used TSMuxer to demux some streams;
4) And MKVToolnix to create the MKV from step 2).

Playing the file I didn't noticed anything wrong until now (the length seems to be the same, too). However, I need to do step 4) and make sure the generated Matroska is 100% similar to the m2ts file from the decrypted Blu-ray files.

Can you confirm this is the case, and if not what should I look for / what kind of error is this?

I never saw this warning before today.

Ops, I think I understand now what's going on. The BD has this extra feature:

High Definition Exclusive Bonus features:
"Breaking the Silence" picture-in-picture video commentaryMaybe this warning means the extra was dropped? This must be the reason!

[Mosu]

Shortened group of pictures means that a B frame cannot be decoded because one of its references is missing. You can usually ignore those warnings as codecs couldn't and wouldn't display such frames anyway.

[smok3]

how would i abuse:

mkvmerge -o out.mkv --split size:3999m in.mkv

for fat32 splitting that is;

a. can it use -o in_%d.mkv automagically somehow?
b. is 3999m correct size?
c. is gui doing something else as well?

[Mosu]

I don't understand what you mean in a) and c).

b) depends on your files. mkvmerge will always split before the first key frame _after_ the split point has been reached. Meaning if there is really a lot of space between key frames then a file might become bigger than your anticipated 3999M with those settings. Don't chose the split size too niggardly; use something like 3950M.

[smok3]

thanks for b.,

what i meant with a. is if there is a way to reuse input filename + 001.mkv, 002.mkv logic (or will i have to script that)

c. Gui is doing exactly the same when spliting?

[Mosu]

mkvmerge will automatically expand the output file name with the current file number when splitting is active. Read more about it in the documentation to --split (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split).

I still don't understand what exactly you want to know with c). The GUI simply passes what the user enters to the command line with a bit more text where appropriate. E.g. depending on the choice which method to split a user input of "3999m" would be turned into "--split size:3999m" ("size:" is optional, but the GUI still uses it for clarity). The output file name is passed as-is to mkvmerge.

[Keiyakusha]

Couple of questions/suggestions, but not requests (I know Mosu is not going to mess with UI, but maybe this at least can be included at the end of the long todo list or something):
Can we make mmg gui use font that is default in windows and not something hardcoded? Currently when English language selected it looks like Tahoma (maybe not I didn't compared that closely) and for Japanese language it uses legacy MS Gothic or similar, which looks especially ugly. Only toolbar menu and tree view in header editor uses what is set in windows. Mine default ui font is MeiryoUI, it is used since Vista (SegoeUI should be default for English page I think).
Then, for charset selection (for ogm chapters) maybe it makes sense to have most used charsets grouped at the top of the list (just like with languages). Not a problem, but it takes some effort to scroll for UTF-8 each time ^__^

[Mosu]

Can we make mmg gui use font that is default in windows and not something hardcoded?

This is a wxWidgets issue. I don't mess around with fonts AT ALL. So these are wxWidgets' defaults, and I don't really want to dig into that area.

Then, for charset selection (for ogm chapters) maybe it makes sense to have most used charsets grouped at the top of the list (just like with languages). Not a problem, but it takes some effort to scroll for UTF-8 each time ^__^

I don't have any time for programming at the moment, so this would be a definite "patches are welcome, otherwise it won't get done".

[sneaker_ger]

What exactly is the purpose of "mkvextract cuesheet source-filename [options]"? What informations are supposed to be extracted?

[Mosu]

You can merge cue sheets with mkvmerge. Those result in both chapters and tags being created in the resulting Matroska file. mkvextract's "cuesheet" extraction mode tries to combine those chapters & tags into a .cue file again.

[sneaker_ger]

And without those tags - but with chapters - it won't extract anything?

[Mosu]

Probably not.

[DragonQ]

Some of my TS files seem to be breaking when running them through MKV Merge. The original TS files play fine but the resulting MKVs aren't deinterlaced properly by MadVR and EVR has issues too (deinterlacing seems to work but the FPS says 46-48 instead of 50, the playback is jerky and the graph is dodgy also).

Original TS - Sample Clip (http://www.mediafire.com/?1ii1q1nhnlhm6zs)
Dodgy MKV - Sample Clip (http://www.mediafire.com/?ho71875bvmy8m5d)

Original TS - EVR Stats (http://www.aotplaza.com/Files/HTPC/Screengrabs/Dodgy%2050i%20MKV%20Merge/TS.png)
Dodgy MKV - EVR Stats (http://www.aotplaza.com/Files/HTPC/Screengrabs/Dodgy%2050i%20MKV%20Merge/MKV.png)

Any ideas?

[sneaker_ger]

@Mosu:
Could you take a look at this (http://forum.doom9.org/showthread.php?t=166237) thread? I think one of your FAQ answers might be wrong.

[Lincoln Burrows]

Mosu,
as I have explained here:
http://www.makemkv.com/forum2/viewtopic.php?f=8&t=5193

MakeMKV is not converting to MKV properly some discs/contents (extra features to be exact). However, until now I used TSMuxer to demux the m2ts files (in the JFK Blu-ray case, a .vc1 stream, .ac3 and .sup). Then I used MKVToolnix plus all of them and saved into a new Matroska file.

TSMuxer + MKVToolnix was working and giving me the proper aspect ratio, the same as the m2ts file.

Which means I could use them instead of MakeMKV, if something went wrong.

However, for the first time EVER this is not working. I am still receiving a wrong 3:2 AR. I checked the m2ts files, and they have a 4:3 AR.

That can only mean either something was changed in MKVToolnix or such contents cannot be converted to MKV even if I use TSMuxer. But so far, using TSMuxer + MKVToolnix worked in 100% cases I tested.

Do you have any idea why this is not working... now?

The disc I tested was the JFK (1991) Blu-ray. This is happening with all extra features. And MKVToolnix didn't reported anything wrong while merging the .vc1 / .ac3 / .sup streams into MKV.

m2ts:
http://i.imgur.com/Qbj9Z.png

Matroska (converted using MAKEMKV or TSMuxer + MKVToolnix):
http://i.imgur.com/mIyJw.png

[Mosu]

Do you have any idea why this is not working... now?

No.

You can try to find out whether or not older versions of MKVToolNix had different behavior. You can get the Windows builds from http://www.bunkus.org/videotools/mkvtoolnix/win32/

[DMD]

Good evening.

I detected a fault in the 5.8.0 release, I do not know if it's a bug.
When I make the muxing to MKV with audio-video files mpg, the total size of the file is lower than that of origin.

Verifying the value of the bit rate of the mkv file is lower than that of the source file mpg.

For example, the source file has a size of 899MB with a bit rate 7.5 MB / s, instead of the file obtained is 777.6 MB mkv with a bitrate of 6.5 MB / s

Doing the same tesyt with version 5.7.0 I get a value of 883 MB with a bit rate of 7.4 MB / s, these values ​​are very close to the original, checked with MediaInfo, so I think that are acceptable tolerances, so the release 5.7.0 works
regularly.

Instead, the release 5.8.0 which produces a higher tolerance why is this happening?

thanks

[Mosu]

As I've just answered you over at my forum (https://www.bunkus.org/answers/?qa=675/problems-with-release-0-bitrate-reduction-in-lossless-mode):

That is not a bug, it's a feature.

mkvmerge 5.8.0 can drop stuffing bytes inside an MPEG stream. v5.7.0 could not do that. Those stuffing bytes are complete garbage and are skipped by any decoder. They're only used so that a stream fulfills certain requirements -- requirements that are not valid inside a Matroska file.

[DMD]

Thank you for fast response.

If I understand Benei the bitrate reduction means that the excess value is not necessary for the mkv container.

But if I perform demuxing with MKVExtractGUI2, I get the mpg file with bitrate reduced

So I confirm that the bitrate reduction does not affect the lossless quality.

Greetings

[Mosu]

Stuffing bytes are garbage. Zeros. Trash. Dropping them is a lossless process. MPEG video streams in MPEG transport streams may require a minimum bitrate, and for such bitrates a muxer muxing from MPEG video elementary streams (that's what mkvextract creates) to a transport stream may re-add such stuffing bytes again.

There is no loss in quality whatsoever.

[Lincoln Burrows]

No.

You can try to find out whether or not older versions of MKVToolNix had different behavior. You can get the Windows builds from http://www.bunkus.org/videotools/mkvtoolnix/win32/Thanks. I tried with 5.2.1 (older version), but the problem is still there. So it's not MKVToolnix related, perhaps it's something encoded in those m2ts files very specific that prevents TSMuxer (and MakeMKV) from recognizing the correct/original AR, whether it's 4:3 or 16:9, and records 3:2 instead.

Since you don't do m2ts > MKV conversions you can't help on this one... :(

I hope the author from MakeMKV can fix this thing.

[DragonQ]

Some of my TS files seem to be breaking when running them through MKV Merge. The original TS files play fine but the resulting MKVs aren't deinterlaced properly by MadVR and EVR has issues too (deinterlacing seems to work but the FPS says 46-48 instead of 50, the playback is jerky and the graph is dodgy also).

Original TS - Sample Clip (http://www.mediafire.com/?1ii1q1nhnlhm6zs)
Dodgy MKV - Sample Clip (http://www.mediafire.com/?ho71875bvmy8m5d)

Original TS - EVR Stats (http://www.aotplaza.com/Files/HTPC/Screengrabs/Dodgy%2050i%20MKV%20Merge/TS.png)
Dodgy MKV - EVR Stats (http://www.aotplaza.com/Files/HTPC/Screengrabs/Dodgy%2050i%20MKV%20Merge/MKV.png)

Any ideas?

Nothing? I'm using the latest Windows build.

[Selur]

Small question: will there be an official Mac OS X 10.6.x build of mkvtoolnix 5.8+ or did the Mac OS X 10.6.x support end with 5.7.x?

[Mosu]

That's up to Jonathan. Please direct all Mac OS related questions to him (http://jonthn.free.fr/MKVtoolnix/CONTACT).

His latest comment to me about this was the following:

I'll see in the future to make a 10.6 (aka Snow Leopard) but no guarantee.

Sorry for the delay (job related & computer broken & more .. :( )

[Selur]

I'lll write him an email and ask. :)

[Selur]

Small question: What values make up the 'codec's private data' ?
background: I split a file at the keyframes using mkvmerge, reencoded one and now mkvmerge is complaining about 'The codec's private data does not match' because of a length mismatch 'lengths: 43 and 46' and I'm unsure what could cause the problem. :)
original file: http://pastebin.com/NAD5eb4k to which I now want to append my new file: http://pastebin.com/A9Dd8UCK
I don't the the problem, so I wanted to investigate, but I got no clue how the codecs private data is composed. :)

[Mosu]

That data is pretty much private to the codec in question. For h.264 this is all the codec initialization data a h.264 decoder needs in order to be able to decode the frames. Re-encoding changes them almost every time.

mkvmerge does not do any deep inspection whether or not the old and new private parameters could match (meaning if a decoder could decode the first/old video with the private init data from the second/recoded part). That is totally out of mkvmerge's scope. And as a merged track only has one set of codec private data only one of them could be kept -- most likely resulting in broken decoding.

[Selur]

That data is pretty much private to the codec in question.
:( hmm, not the answer I was hoping for. ;)
-> I'll do some trial and error than and hope for the best. Thanks for the quick reply. :)

[Mosu]

I aim to please but miss often enough ;)

Anyway, you're quite welcome.

[Selur]

Thanks to sneaker2 I learned that it works fine if I extract all the streams I want to merge to raw streams beforehand.

"G:\Test\mkvmerge.exe" -o "D:\Test\output\test.mkv" "D:\Test\temp\test-001_reencode.264" + "D:\Test\temp\test-002.mkv" + "D:\Test\temp\test-003_reencode.264" "D:\Test\temp\test_AudioCut.mkv"
mkvmerge is complaining and no output is generated, or sometimes a broken output

"G:\Test\mkvmerge.exe" -o "D:\Test\output\test.mkv" "D:\Test\temp\test-001_reencode.264" + "D:\Test\temp\test-002.264" + "D:\Test\temp\test-003_reencode.264" "D:\Test\temp\test_AudioCut.mkv"
mkvmerge is complaining but the output plays fine

-> is there some magic option to tell mkvmerge to handle the videostream in the mkv container as if they were raw streams? (to avoid having to demux even the stream parts I didn't reencode)

Cu Selur

[Mosu]

-> is there some magic option to tell mkvmerge to handle the videostream in the mkv container as if they were raw streams? (to avoid having to demux even the stream parts I didn't reencode)

Nope, there isn't.

[Selur]

Nope, there isn't.
-> new feature request. (https://trac.bunkus.org/ticket/798) :D

[Mosu]

Won't be done by me, sorry. You're quite welcome to contribute patches that implement such functionality.

[Selur]

I added it to the bugtracker, so I can find if I run into the problem again :)

[sneaker_ger]

What else does mkvmerge change?

Here's a sample:
https://rapidshare.com/files/384744953/iterations.7z

I muxed and demuxed a source a few times and all resulting raws differed from each other. ( source.h264 -> 1.mkv -> 1.h264 -> 2.mkv -> 2.h264 -> .... -> 5.h264 )

Since it just came up in a discussion somewhere else again, I thought I'd ask if there has been any change on this?

Here's what is added after an iteration of mkvmerge -> mkvextract:

http://www.abload.de/img/differenceb0pc0.png

Sample:
https://rapidshare.com/files/1548641564/mkvtoolnix_h264_muxing_demuxing_bug.7z

[Mosu]

No, there hasn't, and as Matroska is not supposed to be used (or thought of) a lossless container like ZIP or RAR I will most likely never spend time working on this.

[sneaker_ger]

I understand, but could you tell me what the marked part actually is? It is a bit unsettling that every iteration adds new bytes when you have no idea why and what.

[Mosu]

During extraction mkvextract copies the content of the CodecPrivate (the SPS, PPS etc stuff) into NALUs. However, that information is not removed during muxing, hence you get that content added nevertheless. It's also perfectly fine to repeat SPS/PPS information in the raw bitstream, so _playback_ should be bit-identical in each case.

[sneaker_ger]

Yes, now I see that it is just being repeated over and over.
And what is getting removed during muxing? All SPS/PPS from all GOPs? Something else? Basically Blu-Ray compatiblity is lost after muxing h.264 ES to mkv and now there was some discussion about what is exactly being removed/what would have to be restored/recalculated in order to get the original file back.

[Mosu]

A bit of historical context. Initially mkvmerge removed all SPS/PPS NALUs and only created them in the CodecPrivate element in the same format they're stored in MP4 in as well: as an AVCC. During extraction mkvextract converted CodecPrivate content (the 'AVCC') back to SPS/PPS NALUs exactly once at the beginning of the stream. This was producing bit-identical content before merging and after extraction if and only if the source stream contained exactly one occurrence of the SPS/PPS NALUs.

Of course this immediately failed with streams whose SPS/PPS parameters changed in the middle of the stream which often happens after intros etc.

So the current scheme is to convert the first SPS/PPS NALUs found to the AVCC but to leave all SPS/PPS (to be more precise: their Matroska bitstream representation; those are not NALUs but called something else which I don't recall -- same as in MP4. Not prefixed with 00 00 00 01 but with a size field etc) intact in the blocks inside the Matroska file. During extraction mkvextract converts the AVCC back to the SPS/PPS NALUs as long as it doesn't encounter SPS/PPS frames that differ from the ones in CodecPrivate (or something similar to that algorithm). Hence not bit identical before and after merging, but way more compatible.

This

[sneaker_ger]

What happens to things like HRD, pic-struct and AUD?

[Mosu]

As they're not part of the AVCC they receive to special treatment. They should be kept where they are in the bitstream.

[sneaker_ger]

So they are not removed? Thx.

[Mosu]

mkvmerge does not throw anything away from the h.264 bitstream.

Edit: Oh, except for filler NALUs. Just like stuffing bytes from MPEG2 bitstreams and other such space-wasting garbage.

[sneaker_ger]

Edit: Oh, except for filler NALUs. Just like stuffing bytes from MPEG2 bitstreams and other such space-wasting garbage.

That would be the stuff x264 uses when specifying --nal-hrd cbr?

[Mosu]

I have no frigging clue. Why don't you ask the x264 developpers? :)

[Helios61]

Hi community!

While trying to mux a mkv movie with ordered chapters i get the following error message in mkvmerge 5.8.0:

mkvmerge v5.8.0 ('No Sleep / Pillow') built on Sep 2 2012 15:37:04

Error: The XML segmentinfo file 'E:\tags.xml' contains an error: The root element must be <Info>.

This is the related tags.xml ->
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Tags SYSTEM "matroskatags.dtd">
<Tags>
<Tag>
<Targets>
<EditionUID>640704807</EditionUID>
</Targets>
<Simple>
<Name>TITLE</Name>
<String>Kinofassung</String>
</Simple>
</Tag>
<Tag>
<Targets>
<EditionUID>2119351024</EditionUID>
</Targets>
<Simple>
<Name>TITLE</Name>
<String>Directors Cut</String>
</Simple>
</Tag>
</Tags>

Could anybody please help?

Thanks in advance

Helios

[Mosu]

You seem to be severely confused. You're mixing up three things:

1. You're talking about ordered chapters.
2. The file you're using contains tags, not chapters.
3. You're passing that file to the --segmentinfo option which has nothing to do with either of those two things.

[Helios61]

Hi Mosu!
Big Thanks! You are fully right. I've entered the tag file in segment field of mkvmerge GUI! Maybe the last beer last night (Uuups)!

Again Thanks
Helios

[zeropc]

any chance to finally add the option to keep embedded ac3 from dolby true-hd?

btw, is it possible to add pictures into the mkv file like movie posters? i couldn't find a definite answer to that.

[Mosu]

No, sorry. See https://www.bunkus.org/answers/?qa=25/how-does-mkvmerge-handle-truehd-tracks-with-embedded-ac3-data

[nevcairiel]

any chance to finally add the option to keep embedded ac3 from dolby true-hd?

That would simply be wrong (and most likely break playback with a lot of things). You should never mux two individual tracks into one mkv track. Simply mux the two into two tracks, and you have the choice which to use for playback.

[Selur]

1st Thanks again for the advanced --split options. :) (I really like '--split parts'.)
2nd feature request: would be nice if mkvmerge could also extract the time codes or if mkvextract would also get a --split parts option like mkvmerge
background: I'm playing around with a frame accurate cutting application based on mkvmerge&co and atm. the only way to handle time codes atm. would be to a. extract them and then b. cut them.
Video cutting on I-Frames, reencoding parts of the gops that get modified and cutting the audio works excellent with mkvmerge.
Time codes get problematic, since afaik mkvextract doesn't allow to only extract the time codes of specific parts,..

Cu Selur

[Mosu]

Sorry, but that is such a niche request that I won't spend time on it.

[Selur]

Okay,... :( But thanks for the reply :D

[TheRancher]

Mosu, check this topic (http://forum.doom9.org/showthread.php?t=166592) out. It seems the H.264 bitstream is broken and hence MKVExtract cannot extract it. Can you try to fix it? I've tried many GUI applications and non of them seem to work. Thanks.

[Mosu]

sneaker_ger was right in his assumption: I'm not spending time on trying to fix broken h.264 bitstreams. Sorry.

[73ChargerFan]

Feature request:

.thd+ac3 stream adds only the TrueHD stream and discards the AC3 stream. Please add both streams (as separate, e.g. #2 is TrueHD, #3 is AC3) then let me deselect one if I want.

I'm not asking for a combined stream, which you've rejected, but instead to be able to add the AC3 stream from a .thd+ac3 file.

[Mosu]

Will most likely not happen. I've looked into this in the past, and the effort required didn't seem worth the gain. Often legitimate sources of .thd+ac3 files also contain the raw ac3 file in a separate track. And there are other ways to separate .thd+ac3 into something else; eac3to if I'm not mistaken.

[[ReX]]

Hey Mosu, I was testing the ability to add attachments with mkvpropedit and I noticed something weird happens when you chain the command to add attachments with another command - like changing the name of the first audio stream - and open the file in mmg, go to the Attachments tab, the list is empty (even the attachments that were already there disappear), even though the new attachment was added successfully and works as expected.

Something like this:
mkvpropedit movie.mkv --add-attachment Arial.ttf --edit track:a1 --set name="English Audio"

Changing the order of the commands doesn't have any effect.

[Mosu]

Sounds like a bug. I'll look into it.

[Mosu]

Quick heads up: it's a bug in mkvmerge, not in mkvpropedit. The changed file is OK, mkvmerge just doesn't find the attachments it should.

[Mosu]

Fixed pre-build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.8.0-build20121202-474-setup.exe

[DragonQ]

Some of my TS files seem to be breaking when running them through MKV Merge. The original TS files play fine but the resulting MKVs aren't deinterlaced properly by MadVR and EVR has issues too (deinterlacing seems to work but the FPS says 46-48 instead of 50, the playback is jerky and the graph is dodgy also).

Original TS - Sample Clip (http://www.mediafire.com/?1ii1q1nhnlhm6zs)
Dodgy MKV - Sample Clip (http://www.mediafire.com/?ho71875bvmy8m5d)

Original TS - EVR Stats (http://www.aotplaza.com/Files/HTPC/Screengrabs/Dodgy%2050i%20MKV%20Merge/TS.png)
Dodgy MKV - EVR Stats (http://www.aotplaza.com/Files/HTPC/Screengrabs/Dodgy%2050i%20MKV%20Merge/MKV.png)

Any ideas?

Six weeks and no reply? :confused:

[Mosu]

It's a playback issue; I chose not to lend a hand with such issues.

[DragonQ]

Last time something similar happened it turned out to be an error in how MKVMerge dealt with AC3. :/

It seems to only happen with streams from that channel (ITV1 HD). Streams from other channels don't have the same issue.

EDIT: However, it seems that all new MKVs fail to get auto-detected as interlaced by MadVR. My old MKVs aren't affected by this so I'm guessing something broke in a fairly recent version of MKVMerge, or maybe in TS-Doctor. Or maybe it's due to my switch to Windows 8 during that time...

[Mosu]

Get Madshi to look into it; if he can tell me why detection fails I might spend time on it.

[DragonQ]

Will do!

[[ReX]]

Thanks Mosu, pre-build works fine now.
But MKVExtractGUI-2 still can't list the attachments, I think it uses mkvinfo and mkvinfo has the same bug as mkvmerge,.

[Mosu]

mkvinfo shows the attachments just fine. But if mkvinfo is used in that capacity then he's simply using the wrong tool for the job. He's trying to drive in a nail with a screwdriver (mkvinfo) while ignoring the perfectly good hammer (mkvmerge) lying next to it in the tool box. Yes, it is possible to get nearly the same job done with that screwdriver, but it takes more patience, has a lot more potential for injury, simply because the tool was not designed for that particular purpose.

GUIs wanting to call mkvmerge / mkvextract /mkvpropedit should always get their information from "mkvmerge --identify" (or "mkvmerge --identify-verbose"). It has always been this way.

[[ReX]]

Yeah I think it's actually a different problem with mkvinfo, it took me a while but I remembered what I did, now I'm able to reproduce it.
For this test movie.mkv will be a Matroska file with a single audio and video stream and Arial muxed as arial.ttf.

Now run this command on it:
mkvpropedit movie.mkv --add-attachment verdana.ttf --attachment-name arialbd.ttf --replace-attachment name:arial.ttf:arialbd.ttf

Now mkvinfo can't see any attachments, I say it's a different problem because even v5.8.0 mkvmerge without the fix can see them.

[Mosu]

mkvinfo can see the attachments just fine. However, mkvpropedit moves to the attachments to the end of the file, and that's why you don't see them in mkvinfo's output with default settings. Why? Easy. mkvinfo parses the file from front to back, so seeking involved whatsoever (that's its purpose). In order not to overwhelm the user with information mkvinfo stops when it finds the first cluster by default. If the attachments are located behind the cluster then mkvinfo will not print them by default.

Adding one or more "-v" (or "--verbose") will cause mkvinfo to parse the whole file. That way you'll see the attachments near the end.

There is no problem with mkvinfo!

[[ReX]]

Interesting...
Sorry for bothering you and thanks for the information!

[Mosu]

No problem at all.

[DragonQ]

Get Madshi to look into it; if he can tell me why detection fails I might spend time on it.
I've asked him to take a look. Some more info that might help in the mean time:

1) All TS files with AAC audio:
- EVR: TS plays fine, MKV plays fine.
- MadVR: TS plays fine, MKV is treated as progressive so not deinterlaced.

2) Older TS files (e.g. from 10/11/2012) with AC3 audio:
- EVR: TS plays fine, MKV plays fine.
- MadVR: TS plays fine, MKV plays fine.

3) Newer TS files (e.g. from 02/12/2012) with AC3 audio:
- EVR: TS plays fine, MKV plays slowly (46-48 fps) with playback speed jumping all over the place and a really dodgy graph.
- MadVR: TS plays fine, MKV is treated as progressive so not deinterlaced and also playback speed is all over the place.


Looks like two separate issues: one with AAC audio not being detected as interlaced at all (possibly MadVR fault), one with newer files with AC3 audio not having correct timestamps. For the latter, maybe something has changed in the broadcast streams that has broken MKVMerge compatibility?

[Keiyakusha]

Does zlib, bz2, lzo are the only possible compresion options for pgs subs or in theory it can use something else?
because out of these three zlib seems to do best compression, yet it is still 15 times worse than 7z. it is even 2 times worse than good old zip. By OCRing subs or by not including them in container I can save gigabytes of space...

[nevcairiel]

zlib is the only compression still valid in Matroska, bz2 and lzo have been removed from the spec, and will most likely not work properly with most players. And no, you cannot use any other compression.
Also note that compression is done on a per-frame basis, so compression always works rather limited because you only get small packets to work with, and not the whole stream in one go.

If your subtitles are a big space concern for you, something seems wrong. They should be a rather minimal factor in a video file.

[Keiyakusha]

zlib is the only compression still valid in Matroska, bz2 and lzo have been removed from the spec, and will most likely not work properly with most players. And no, you cannot use any other compression.

If your subtitles are a big space concern for you, something seems wrong. They should be a rather minimal factor in a video file.

I see, thanks.
As for my concerns. It maybe sounds like it suddenly become an issue for me, no I was just curious. Actually everything is a space concern for me as long as there is chances to compress something better without sacrificing quality. I never use reference flac encoder for example (too slow, too low compression compared to alternatives) ^__^

Edit: well I wouldn't call 50MB per episode (zlib-compressed) a "minimal factor" (2 sub tracks). I can compress the whole episode to less than 100MB in a way it will be watchable.

[Mosu]

Does zlib, bz2, lzo are the only possible compresion options for pgs subs or in theory it can use something else?
because out of these three zlib seems to do best compression, yet it is still 15 times worse than 7z. it is even 2 times worse than good old zip. By OCRing subs or by not including them in container I can save gigabytes of space...

At the moment only zlib, bz2, lzo and header removal are compression schemes that are (or were) official part of the Matroska specs (bz2 and lzo have since been removed/retired). Of those bz2 and lzo are not widely supported, and I would be somewhat surprised if significantly more programs than mkvmerge were able to read (let alone write) such files.

You cannot simply use any compression scheme you want, even if 7z seems to be better (7z is also a program; the compression scheme to use would be lzma which 7z uses internally and which is a stream compressor format -- meaning 7z itself is a combination of a packaging format like tar and a compression scheme like lzma; for Matroska we only need stream compressors, not package formats).

[Chetwood]

Edit: well I wouldn't call 50MB per episode (zlib-compressed) a "minimal factor" (2 sub tracks). I can compress the whole episode to less than 100MB in a way it will be watchable.
What resolution has the ep? Can't imagine that big subs on such a small file. Resize them or convert to ASS or something...

[Keiyakusha]

What resolution has the ep? Can't imagine that big subs on such a small file. Resize them or convert to ASS or something...

Ep is 720p. Of course I'm not going to use these subs with such video. This is just an example. But all possible conversions require a bit too much of effort. Especially OCRing. English maybe fine, but I have no much luck with Japanese subs. It is probably easier to rewrite them by hand than correct all OCR failures. Not to mention that I haven't yet figured out what to do if they are written vertically at the right side instead of horizontally at the bottom. But this is already offtopic here. Sorry.

[Liisachan]

Hi, Mosu!
This is not a real request, but something I happened to notice.

MMG can't transmux an existing Matroska file into a new one IF a track in the source file has an obsolete language code (scr, scc, or mol), unless the user explicitly selects a new language code for every one of such tracks. By default, an exsisting value is passed as --language to mkvmerge, and mkvmerge refuses an obsolete value. Those 3 codes got deprecated (http://www.loc.gov/standards/iso639-2/php/code_changes.php) (though not invalidated) by ISO in 2008. In my quick check, mkvtoolnix used scr/scc until 2009, mol until 2010. So files created a few years ago (or with old tools) may contain them. By default, mkvmerge itself just copies any langauge code, valid or invalid, when transmuxing Matroska to Matroska. The problem occurs only when an obsolete value is *explicitly* specified as --language, possibly by a user, but more likely by MMG.

I'd think that handling those tags in the mkvmerge level sounds reasonable (converting transparently "scr" to "hrv"; "scc" to "srp"; "mol" to "rum"), somewhat like when it handles "eng".
But this may be an unimportant, niche problem after all :)

Also, the language list box of MMG doesn't know what to do if the item it needs to show is not in the list. If that happens, it keeps showing whatever item it previously shows. Suppose you have an MKV file with track0=video, track1=audio, track2="scr" (sub), track3="scr" (sub). You open it with MMG and manually select "hrv" for the track2, knowing that this tag should be updated. The problem is, when you select track3, the language list says "hrv" as if the new value was already selected, when it isn't. The file won't mux, and the error message says "scr" is bad. You double-check track2 and track3, but they're both "hrv" on MMG. I was puzzled for a while.

Thank you again for your wonderful tool anyway!

[Mosu]

Actually mkvmerge does nothing special to "eng" at all. That's libmatroska -- to be more precise, "eng" is set as the default value in the library for the language element, and libmatroska generally checks all elements whether or not they equal their default value before writing them.

Your conclusions about what you've seen sound reasonable and correct to me; it's most likely mmg setting that value. I'll try to keep it in mind so that it can get fixed one of these days.

[Mosu]

Oh, and I've taken the liberty to open a bug report by copying your post: https://trac.bunkus.org/ticket/803

[Liisachan]

Thanks, Mosu. I thought about going to the tracker directly, but wasn't sure if this would be a valid bug report. BTW I was not complaining about "eng" - I know the repeated discussion about "eng" and the logic behind it.

[Mosu]

It's definitely a bug, more like two bugs: mkvmerge should change those values on the fly, and mmg should do the same. It might be enough to fix mkvmerge as mmg queries mkvmerge for a file's language, though.

[DragonQ]

Mosu, madshi reckons the MKVs I'm making have "50p" in the header, which is why they're not being deinterlaced by MadVR. I am setting all of these MKVs to "50i" when using MKVMerge so presumably there's a bug somewhere?

[Mosu]

The "50p" vs "50i" only tells mkvmerge how to calculate timecodes. No other setting AT ALL is affected by this. Meaning there is no "interlaced" or "progressive" flag, neither can the "default duration" be interpreted as the number of frames or fields per second! See https://www.bunkus.org/answers/?qa=205/why-is-the-fps-frame-rate-wrong

Perhaps you could ask Madshi to post in this very thread what he means with "50p in the header".

[sneaker_ger]

I cannot reproduce it, anyways. Setting "50i" makes standard duration 40ms as expected.

[DragonQ]

Perhaps you could ask Madshi to post in this very thread what he means with "50p in the header".

I have asked him to post here.

I cannot reproduce it, anyways. Setting "50i" makes standard duration 40ms as expected.

But does the sample I posted earlier work properly for you?

[Mosu]

I haven't played it yet, won't do so until Madshi chimes in here. Busy days at the moment.

[sneaker_ger]

But does the sample I posted earlier work properly for you?

50i -> 20ms standard duration for TS -> MKV

The remuxed MKV does not play properly for me. No deinterlacing and not fluid. (Jumping back and forth)
Maybe we should ask Nev and not madshi.

/edit:
How did you create the mkv?
Mine is different from yours if I create one from the TS myself. Yours is even bigger than the source TS.

[DragonQ]

50i -> 20ms standard duration for TS -> MKV

The remuxed MKV does not play properly for me. No deinterlacing and not fluid. (Jumping back and forth)
Maybe we should ask Nev and not madshi.

/edit:
How did you create the mkv?
Mine is different from yours if I create one from the TS myself. Yours is even bigger than the source TS.
It could well be an issue with LAV Filters, but MadVR seems to be affected worse than EVR so it could be an issue with just one or all three (mkvtoolnix, MadVR, LAV)! :D

My step for making the file is as follows:

- Open mmg and add TS file
- Set audio & video to language="eng" and default="yes"
- Set video to 1920x1080 and 50i
- Mux

Using latest Windows build.

[nevcairiel]

LAV just uses the DefaultDuration to create the FPS info. I know, its semantic does not necessarily mean "fps", but without any other fps info available, what are you gonna do. All other splitters seem to behave this way, and users complained when it didn't, so now it does. Its not my fault Matroska fails to actually have a FPS field.
If i turn this off, and let my code try to probe the FPS, it results in 25 fps and the file plays fine. But again, people complained when i had the probing active, i don't remember why though. Probably a problem with the H264 headers saying 24 fps but they remuxed it to 25 fps, or something like that.

I can run some tests some day to see if i find one of such files and see if it can be properly fixed.

DirectShow also says that the "AvgTimePerFrame" (DirectShows "FPS" info) in the media type is an optional element and should not be relied on (in fact, it specifically states it may be 0), so using it for anything critical is also a design problem.

[Zenitram]

LAV just uses the DefaultDuration to create the FPS info. I know, its semantic does not necessarily mean "fps", but without any other fps info available, what are you gonna do.

I am not alone :).
But it definitely fails, especially with VFR files (and you don't know if it is a VFR file, no flags). You must read the raw stream (H.264...) headers in order to have the FPS, as I do with my tool now instead on relying on DefaultDuration field.

[madshi]

Hey guys,

I'm wondering what practical use the "DefaultDuration" in MKV really has. I mean, if you can't use it to find out the (likely) FPS then it's pretty much useless. Why? Because DVDs and broadcasts video streams can often switch between different encoding modes. The encoder might encode some sequences as 24p with telecine flags, then some sequences as 30p without telecine flags, then some sequences as 60i (60 separate interlaced fields), and all of this can switch back and forth *in the same file*. So from my point of view, the "DefaultDuration" can't have any meaningful value for such files. I know what the MKV spec says, but most devs actually do treat "DefaultDuration" for getting a quick hint about which FPS this video file probably has. FWIW, I've always set "DefaultDuration" to the FPS when muxing mkv files in eac3to, and I've not heard of any problems with this approach yet. If you (Mosu) want to stick to the letter of the spec then I can understand that. In that case we should probably talk to the MKV spec guys and ask them to re-add a proper "fps" information field? I do believe that MKV files do need some sort of "fps" information header field. If "DefaultDuration" can't be used for that, then we need a dedicated field.

Anyway, from madVR's point of view, I have no direct contact to the MKV at all. So in theory it doesn't matter to madVR which value MKVs have their "DefaultDuration" value set to. However, since pretty much all MKV splitters out there read out the "DefaultDuration" and pass it untouched on to madVR as the "AvgTimePerFrame", it does matter to madVR after all. Because "AvgTimePerFrame" has a very specific definition to define the FPS. Ok, "AvgTimePerFrame" might sometimes be 0. But still, it's the easiest information field to look at when trying to understand what kind of FPS the video file has. madVR currently uses "AvgTimePerFrame" for 2 purposes:

(1) To find the correct display refresh rate to switch to (auto display mode switcher).
(2) To decide whether the source video should be deinterlaced or not. madVR only deinterlaces 50i and 60i content. If "AvgTimePerFrame" indicates 50p, madVR turns deinterlacing off.

Maybe I'll implement some complicated fps guessing algorithms in a future madVR version, but such guessing algorithms can always fail, especially if you need them to work quickly. madVR needs to decide which refresh rate to switch to right at the very start of playback, before the first video frame is shown. I can't switch display modes after half a minute of playback or so (users would very much hate that), so I can't use a (reliable) long term frame rate analyzer to find out the FPS.

[Mosu]

Hey guys,

I'm wondering what practical use the "DefaultDuration" in MKV really has. I mean, if you can't use it to find out the (likely) FPS then it's pretty much useless. Why? Because DVDs and broadcasts video streams can often switch between different encoding modes. The encoder might encode some sequences as 24p with telecine flags, then some sequences as 30p without telecine flags, then some sequences as 60i (60 separate interlaced fields), and all of this can switch back and forth *in the same file*. So from my point of view, the "DefaultDuration" can't have any meaningful value for such files.

An FPS field would have the very same issue. If such a hypothetical FPS field contained 30p FPS for such a file then it would be just as invaild for most sequences that use other material.

What the default duration does? It tells you how long to display a frame you've just read without having to read the next frame in the file. Similar to how the granulepos works in Ogg files (the granulepos tells you the end timecode of of the current package).

I know what the MKV spec says

It has said that forever. There has never been an FPS field in Matroska that was used.

but most devs actually do treat "DefaultDuration" for getting a quick hint about which FPS this video file probably has

And that is wrong.

In that case we should probably talk to the MKV spec guys and ask them to re-add a proper "fps" information field?

That would not solve anything. What would you put into that field for mixed content such as you've described above? And what information could a player gain reliably from such a field that it cannot get from the default duration?

And how do you suppose players should act when the timecodes do not match multiples of the FPS field anymore? Try to force timecodes to multiples (resulting in very jerky playback in case of FPS switching content)? Ignore the discrepancy, potentially syncing content to display frequencies of completely different FPSed content?

You can already derive the FPS from the combination of the DefaultDuration and the video content. Yes, it's ugly; I haven't said it's a nice way, just a possibility.

First method: analyse the bitstream headers and see which FPS is stored there. Obvious drawback: a) it somewhat violates the spirit of Matroska which says that container information has precendence over bitstream information (e.g. if bitstream says 24fps and container says 25fps, judging from the default duration, then the blocks will most likely be 40ms apart, and a player assuming 24fps would always find the blocks arriving a bit too early for its taste); b) the user wouldn't have a way of correcting wrong information at the bitstream level

Second method: combine default duration with frame/field type of first frame(s). Take the default duration. Look for the first video blocks. If they're fields then 1/2*DefaultDuration is your likely FPS; if they're full frames then 1/DefaultDuration is your likely FPS.

[nevcairiel]

If you follow the letter of the spec, you should not use DefaultDuration at all for FPS, and simply compute it from the frame timestamps, which is what ffmpeg/LAV can do, if i tell it to ignore the DefaultDuration (but caused complains before).
There is no guarantee that the DefaultDuration is related to the FPS at all. Its a implementation specific thing in mkvmerge that it happens to be related.

So the only two valid options for me are either to trust the DefaultDuration, or don't trust it at all, but trying to "guess" based on an implementation detail in mkvmerge seems even more fragile.
I'll most likely stop trusting it at some point, when i find the time to investigate properly how this affects files with different muxing "issues" (bitstream headers different to mkv headers, etc).

PS:
No matter how you determine a FPS value, in mixed content/VFR you fail in every case.

PPS:
Why is matroska.org broken anyway?

[Mosu]

PPS:
Why is matroska.org broken anyway?

No idea, I don't host the site. But thanks for noticing; I'll try to contact Steve about it.

[Zenitram]

And what information could a player gain reliably from such a field that it cannot get from the default duration?

The same reliably as the "duration" field = not a lot, but it is a good hint (especially in case of VFR, currently it is not possible to have any hint about FPS change without parsing Gigabytes of data, or did I miss something? I appreciate a lot mp4 files for this...). Surprise, "Duration" field is present ;-).
If Matroska specs are logical, "Duration" field would not exist, it is useless (or not) and reliable (or not) as FPS field is.

It is a design choice, why not, we only say it is a pain for developers: yes, FPS is useful, as duration field is. We can live without both, but both are good for a quick scan. Currently, with a quick scan, we fail to detect correctly FPS because the muxer (it does know the value at the end of the muxing) doesn't provide this useful piece of information and we must guess it (and we often fail if we don't accept, for performance reasons, to parse the whole file).

Don't worry, I'll live with it and I will continue to say to people complaining about errors that I can not guess correctly due to lack of data in the file during a quick scan :). Or do you have a method for detecting the average/min/max frame rate without parsing the whole file? I know how to do it with mp4 files, but I did not find for Matroska files.

[madshi]

An FPS field would have the very same issue. If such a hypothetical FPS field contained 30p FPS for such a file then it would be just as invaild for most sequences that use other material.
That would not solve anything. What would you put into that field for mixed content such as you've described above? And what information could a player gain reliably from such a field that it cannot get from the default duration?
The situation I talked about is a totally "valid" movie encoding which after running through a proper IVTC algorithm produces perfect 24p. Whether the encoder used 24p with telecine flags, 30p without telecine flags or 60i, the FPS information in the video bitstream will always be "30p/60i", because that's what you get after "honoring" the telecine flags. 24p with telecine flags = 30p/60i. So that's what the MKV "fps" field should contain. It would be *VERY* useful because it would allow the video renderer to automatically switch to the correct display refresh rate.

What the default duration does? It tells you how long to display a frame you've just read without having to read the next frame in the file.
I'm sorry but that just makes no sense for interlaced video. A proper video renderer will not display interlaced frames untouched. You first run them through a deinterlacer. So the "DefaultDuration" as officially spec'ed has zero practical use for interlaced video, from my point of view as a video renderer developer.

The way the source is encoded (24p + telecine flags, or 30p, or 60i) has no direct consequence as for how long the video renderer will display every "MKV frame". Depending on the content type every frame that comes out of the deinterlacer could be shown either for 1/24seconds or for 1/60 seconds.

And how do you suppose players should act when the timecodes do not match multiples of the FPS field anymore?
I don't know, but this conflict potential is always there. E.g. what happens if the timecodes do not match the video bitstream FPS information? I don't think that's reason enough to not have a valid FPS container header field.

You can already derive the FPS from the combination of the DefaultDuration and the video content. Yes, it's ugly; I haven't said it's a nice way, just a possibility.
Well, the problem is that not all MKVs are muxed the same. For MKV files created with the latest mkvtoolnix version that might work, but for other MKV files it might produce invalid results. Of course you could claim that those other MKV files are violating the spec, but that doesn't really matter in real life. The users won't care that half of their MKV files violate the spec, they just care about having everything work correctly.

First method: analyse the bitstream headers and see which FPS is stored there. Obvious drawback: a) it somewhat violates the spirit of Matroska which says that container information has precendence over bitstream information (e.g. if bitstream says 24fps and container says 25fps, judging from the default duration, then the blocks will most likely be 40ms apart, and a player assuming 24fps would always find the blocks arriving a bit too early for its taste); b) the user wouldn't have a way of correcting wrong information at the bitstream level
Looking at the bitstream headers is probably not a good idea. Most MKV files have audio muxed with the video. So if the container timestamps contradict the video bitstream FPS information then using the video bitstream FPS information for playback would likely make audio and video go async very quickly.

Second method: combine default duration with frame/field type of first frame(s). Take the default duration. Look for the first video blocks. If they're fields then 1/2*DefaultDuration is your likely FPS; if they're full frames then 1/DefaultDuration is your likely FPS.
This would produce wrong results for many many many MKVs already out there today.

[Zenitram]

TLooking at the bitstream headers is probably not a good idea. Most MKV files have audio muxed with the video. So if the container timestamps contradict the video bitstream FPS information then using the video bitstream FPS information for playback would likely make audio and video go async very quickly.

I don't understand this part: if you need syncrhonization, you play/read the whole file, so you don't need any FPS field: you read the time stamps, one per one, nothing else. Any FPS field would be an hint (as duration field is today) for display, nothing else.

[Mosu]

The same reliably as the "duration" field = not a lot, but it is a good hint (especially in case of VFR, currently it is not possible to have any hint about FPS change without parsing Gigabytes of data, or did I miss something? I appreciate a lot mp4 files for this...). Surprise, "Duration" field is present ;-).

A block's duration is very well defined in Matroska, and there's only one situation in which a block's duration could be undefined: if the track does not have a default duration and the very last block in the file does not have a "duration" member.

In all other cases a block's duration is well-defined by:

- For a BlockGroup: if "duration" is present then this duration it is. If it isn't present and the track has a "default duration" then use that. In all other cases the duration is the difference between the next block's start timecode and this block's start timecode. A block's duration also applies to the whole block, meaning to all laced frames. So if you have a BlockGroup with e.g. four laced frames and no "Duration" element, then the block's full duration is 4 * DefaultDuration.
- For a SimpleBlock element: as above, you just cannot have a "duration" child, so only the cases "track with DefaultDuration" and "track without DefaultDuration" are relevant.

Writing the "duration" member of a BlockGroup is only necessary if the block's duration does not equal the track's default duration (scaled to the number of laced frames). So "DefaultDuration" is a major space saver.

It is a design choice, why not, we only say it is a pain for developers: yes, FPS is useful, as duration field is.

I'm not arguing that Matroska's system is the best all around.[1]

I'm arguing against adding another header field whose semantics are not much better than what we have now. It wouldn't give you measurable gain in information and cause a lot of confusion, especially if the then similar fields "FPS" and "DefaultDuration" were obviously mismatched.

Don't worry, I'll live with it and I will continue to say to people complaining about errors that I can not guess correctly due to lack of data in the file during a quick scan :). Or do you have a method for detecting the average/min/max frame rate without parsing the whole file? I know how to do it with mp4 files, but I did not find for Matroska files.

There isn't. It's a design decision in Matroska: being able to recover most of the file even if essential parts are damaged. If the index in an MP4 file is damaged you can throw away the whole file because you don't know where the data blocks start and end for each track (same in AVI). The obvious disadvantage of not having a central index including all elements is having less information available at the start of playback.

[1] Far from it. I know how pretty much all other relevant containers work as I've written parsers for all of them. Matroska's system is better than a lot of them, and worse than others, often due to different goals in what those containers try to achieve. Examples:


All other containers whose timecodes are calculated by multiplying a set value in the header with an integral number (especially AVI): there's no way to account for arbitrarily-sized gaps in the stream. Think of 25fps video in which you have a 60ms gap for whatever reason in one track but not in the others. AVI is especially bad as it only has timecodes for video tracks, not for audio tracks, requiring the use of garbage data in audio tracks for such gaps.
Containers that lack proper container headers: it's... interesting to find out about the FPS of e.g. MPEG-TS requiring sending the stream headers periodically. Again, it's a design decision: MPEG-TS was designed for streaming. Matroska wasn't.
Central index pointing to all data blocks: very bad for streaming; requires splitting such indices into very small chunks (e.g. for every 400ms create headers & said index). The obvious advantage is in non-streaming situations: you have all information there is about a file before starting playback


etc. etc.

[nevcairiel]

Looking at the bitstream headers is probably not a good idea. Most MKV files have audio muxed with the video. So if the container timestamps contradict the video bitstream FPS information then using the video bitstream FPS information for playback would likely make audio and video go async very quickly.

Sync should always be based on the actual stored timestamps, and not some FPS information. Thats what we have timestamps for. :)
So the only thing that would go wrong is the detected FPS again, you should still honor frame timestamps as stored in the file.

[Mosu]

I'm sorry but that just makes no sense for interlaced video. A proper video renderer will not display interlaced frames untouched. You first run them through a deinterlacer.

Last I checked this was still optional in pretty much each and every player.

The way the source is encoded (24p + telecine flags, or 30p, or 60i) has no direct consequence as for how long the video renderer will display every "MKV frame". Depending on the content type every frame that comes out of the deinterlacer could be shown either for 1/24seconds or for 1/60 seconds.

The "DefaultDuration" is not concerned with how long a "frame" is. It concerns itself with the (logical) duration of a single Matroska block. Matroska is agnostic about the display system; it doesn't enforce a deinterlacer to be present, nor does it assume so. It could also be used for hypothetical formats in which frames are split up into more than two fields.

[Zenitram]

being able to recover most of the file even if essential parts are damaged.

???
Fail. If H.264 private part is damaged (few bytes inside Matroska headers), the whole file is unreadable. Matroska as exactly the same risk of loss of the complete file in case of damaged essential parts. If SeekHead + a cluster header is damaged, you lose all after the damaged cluster header (no sync magic value). And so on...
If recovering was the goal, the goal is not met.

I completely understand that you have different goals, my reaction is when you argue Matroska is better that other format for such specific point. In you example, MP4 and Matrsoka have the same exact point of potential failure (corrupted header), Matroska is not better thant MP4 for this. You can not use this argument.

Central index pointing to all data blocks: very bad for streaming; requires splitting such indices into very small chunks (e.g. for every 400ms create headers & said index). The obvious advantage is in non-streaming situations: you have all information there is about a file before starting playback

In the case of ismv (streamable MP4), index are sent every ~10 seconds usually, so I can parse all index relatively quickly (no need to read each MB of the file, for Matroska it is each frame header). We have different goals, MP4 fits better my (and my users') needs, maybe... Matroska as some advantages (e.g. it accepts lot of formats: PGS, srt... Very useful!), but recovering capability is definitely not one! (Ogg, with sync magic value before each frame, is better on this part...)

Matroska is good, but not for everybody :).

[Mosu]

???
Fail. If H.264 private part is damaged (few bytes inside Matroska headers), the whole file is unreadable. Matroska as exactly the same risk of loss of the complete file in case of damaged essential parts.

Well, it's more a theoretical advantage at the moment, I admit, but the specs clearly allow multiple copies of the whole track headers be spread throughout the file.

If SeekHead + a cluster header is damaged, you lose all after the damaged cluster header (no sync magic value).

Wrong, you can resync to all level 1 elements (e.g. clusters) pretty reliably. I have several damaged files in my test case repo for which this works rather nicely.

Matroska is good, but not for everybody :).

You could say the same for Ogg, MPEG-TS, MP4 etc. etc. etc.

But let's stop here and get back to the original problem, please.

[madshi]

Let's talk about practical use:

madVR needs a halfway reliable way to identify the likely FPS of any source video, including MKV. If the latest mkvtoolnix version insists on writing 20000 in there for video frames which have 50 interlaced fields per second then MKVs created by the latest mkvtoolnix version are not compatible to a very big number of MKVs already out there, for any software which guesses FPS by looking at DefaultDuration. All current MKV DirectShow splitters directly see DefaultDuration as the FPS hint, without looking at whether the "MKV blocks" contain one interlaced field or a field pair. And this has worked well so far. So if you insist on writing DefaultDuration the way you currently do, all currently existing MKV splitters need to be changed. And that would result in them breaking with many older MKV files. It would practically mean that splitters couldn't produce correct FPS guesses for all MKVs out there, when looking at DefaultDuration. Do you really think that is a good idea?

IMHO, the only proper way to solve this is to re-add a dedicated FPS field to MKV for which interpretation is totally clear, so every software will treat it the same way. This would result in that all newly muxed MKV files would be detected with the intended FPS written by the muxer. While for all old MKV files splitters could continue to interpret DefaultDuration as they do today.

[Mosu]

So I cannot convince you that such a field won't be added? Alright, I may be wrong. Please send that proposal along with your argument why this is needed in the first place to the Matroska devel mailing list so that Steve can chime in on it. See http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel

[madshi]

@Mosu, just for my interest: Did mkvtoolnix always write DefaultDuration like it is doing now? Or is it a recent change?

What do nevcairiel and Zenitram say? Am I the only one who things a dedicated FPS field might be useful/necessary?

[Mosu]

mkvmerge has long had bugs in which it didn't handle the default duration for AND THE TIMECODES for interlaced content properly. Users always had to say things like '--default-duration 20ms' (meaning they would have to figure out a) the FPS and b) whether or not its interlaced before muxing and tell mkvmerge the correct default duration). If they didn't then playback was pretty much always broken, no matter if things like madshi's video renderer were involved.

I've fixed that this year so that mkvmerge now does "the right thing" automatically and users do not have to specify --default-duration for most cases anymore. That was when I added "50i" etc. to be valid values to "--default-duration".

[madshi]

I see. But then which value did users manually set for default-duration in the past for e.g. a video file which was encoded as 50 separate interlaced fields? Did they set default-duration to 20ms or to 40ms? I rather think they used 40ms, or am I wrong?

[Mosu]

50 interlaced fields, meaning one field per Matroska block? The correct value to use would have been 20ms. mkvmerge wrongly used 40ms resulting in slowed-down display in pretty much all players.

Note that mkvmerge was not just putting 40ms into the header but using 20ms when calculating timecodes for the individual blocks. No. Old mkvmerge versions would use the 40ms for the timecode calculation as well (meaning "default duration" and the actual timecodes would have been consistent, but both consistently wrong).

[madshi]

So basically every 50i video file (with one field per Matroska block), muxed with any mkvtoolnix version, always has/had a DefaultDuration of 20ms. Is that correct? In that case maybe the MKV splitters (and mediainfo) could check which MKV muxer was used and interpret DefaultDuration accordingly to create an FPS hint? For mkvtoolnix muxed MKVs, for such 50i video files, DefaultDuration * 2 would be the proper FPS hint. For other MKV muxers, maybe DefaultDuration * 1 would be the proper FPS hint for such files, though.

Hmmmm... I'm wondering: What happens if the first 2 Matroska blocks have one interlaced field each, but for the rest of the file every Matroska block has a frame (field pair)? Which DefaultDuration are you using then in the latest mkvtoolnix?

I'm still wondering how the MKV spec should be interpreted. On a first check it seems clear. But when thinking about it, I'm not so sure, anymore. The MKV spec reads:

"DefaultDuration: Number of nanoseconds per frame ('frame' in the Matroska sense -- one element put into a (Simple)Block)."

But I find this is somewhat open for interpretation when talking about interlaced video, especially when telecine flags are involved. E.g. which value should DefaultDuration be set to when muxing a 24p/48i stream with telecine flags? The video bitstream header will say it's 60i. A sat receiver will send it as 60i to the display. A DVD player will either send it as 60i or 24p to the display (depending on settings). A DirectShow software decoder might simply ignore the telecine flags and output it as 24p. So which value should DefaultDuration be set to? 1/24? 1/30? 1/60? I really think the whole concept of "DefaultDuration" is not very useful for interlaced video and a "DefaultFPS" would have been much more useful. There's a reason why all video codecs (that I know) have an FPS header field, but no "DefaultDuration" alike header field...

[Zenitram]

Hmmmm... I'm wondering: What happens if the first 2 Matroska blocks have one interlaced field each, but for the rest of the file every Matroska block has a frame (field pair)? Which DefaultDuration are you using then in the latest mkvtoolnix?

DefaultDuration is... Default. so DefaultDuration is the duration of the field pair, and you have specific duration for the 2 other fields. It is explicitely described ("Default"), you can not blame specs for this.

I'm still wondering how the MKV spec should be interpreted. On a first check it seems clear. But when thinking about it, I'm not so sure, anymore. The MKV spec reads:

"DefaultDuration: Number of nanoseconds per frame ('frame' in the Matroska sense -- one element put into a (Simple)Block)."

But I find this is somewhat open for interpretation when talking about interlaced video

It was explicited due to my request to Mosu few months ago: "one element". Now, it is clear ;-).

There's a reason why all video codecs (that I know) have an FPS header field, but no "DefaultDuration" alike header field...

You know not enough ;-).
H.264 frame rate is optional, and I have several files without it.

"DefaultDuration" is 100% internal to Matroska, and it is a default, no more. When we discuss with Mosu, we need to be clear about the meaning of each Matroska field, else the discussion is impossible.

[DragonQ]

Just a quick note since it may be relevant: the "files with AAC audio" that I was talking about earlier also have MBAFF video, which is probably more likely to be the reason that they behave differently to the "files with AC3 audio" than the audio type itself.

[Mosu]

Hmmmm... I'm wondering: What happens if the first 2 Matroska blocks have one interlaced field each, but for the rest of the file every Matroska block has a frame (field pair)? Which DefaultDuration are you using then in the latest mkvtoolnix?

mkvmerge is deriving the most likely default duration from the source container and source bitstream. For blocks whose actual duration does not match that derived value anymore mkvmerge writes "BlockGroup" elements with properly set "Duration" children.

But I find this is somewhat open for interpretation when talking about interlaced video,

No, it isn't. DefaultDuration only has semantics for the Matroska block structure. That's why it is indeed hard to derive the display FPS from it...

especially when telecine flags are involved.

Correct, it is hard, but not DefaultDuration's meaning is perfectly well-defined no matter what the content of a block is. A field, a full frame, telecined or not. I understand where you come from. However, DefaultDuration is not a simple multiplier for display FPS. It always refers to one Matroska block (I'm always taking about a single block; laced blocks require multiplication where appropriate -- I just skip that in my explanation in order not to make it any longer than it already is).

You argue completely from the point of view of the displaying device. DefaultDuration was designed from the point of storage and still keeping information about each individual block, no matter the block's content.

Having an additional "display FPS" field might indeed be a good idea, hence me requesting you take that discussion over to the Matroska devel mailing list.

[madshi]

You know not enough ;-).
H.264 frame rate is optional, and I have several files without it.
I know that, I have such sample files, too. That the h264 FPS field is optional doesn't change my point.

You argue completely from the point of view of the displaying device. DefaultDuration was designed from the point of storage and still keeping information about each individual block, no matter the block's content.

Having an additional "display FPS" field might indeed be a good idea, hence me requesting you take that discussion over to the Matroska devel mailing list.
Will do.

[DragonQ]

So...are you guys saying that MKV just can't handle interlaced files properly? Lot of technical talk there, not entirely sure what the consequences are. :p

[nevcairiel]

Its not directly related to interlaced. The real problem is that MKV just has no reliable FPS info.

[DragonQ]

But I don't understand how this is only a problem with certain files - what is different about them? In the case of the interlaced files with AC3 audio, the only difference I can see between the working and non-working ones is that the latter are newer. :/

Look at these two MediaInfo screenshots - I can't see any difference between the two, yet one file plays perfectly and the other has timecode issues in both EVR and MadVR, and doesn't deinterlace in MadVR. :confused:

[Fullmetal Encoder]

Reading VobSubs from VOBs is not supported. And may never be. Some user started working on that, but I haven't heard from him in months.

Problem? Well in order to create the VobSub's idx part you'd have to parse the whole friggin DVD IDX files and stuff like that. Nothing I'm ever going to do myself.

I am still here. I am still working (slowly) on this. I had to spend a lot of time learning about DVD structures pertaining to chapters and subpictures. Then I had to learn to program. I also went a long time without being able to work on it due to having two jobs and various other life issues happening. But it's still my goal to give mkvmerge this functionality along with at least some basic chapter point detection for DVDs and blu-rays. But I need to carefully study your code to get a better idea of how to proceed.

[Mosu]

So...are you guys saying that MKV just can't handle interlaced files properly?

Not at all, and please read my answer in full and carefully.

Such a broad answer is simply wrong. Matroska can handle interlaced files just fine. In general playback works with current Matroska format, no matter if content is progressive, interlaced, telcined or a mix thereof. Millions of people watching files on a myriad of different devices and players are a testimony to that.

However, there are use cases for which the information stored in Matroska's file/track headers is not enough. One such use case is a special video renderer like Madshi's that has to work within the confines of its framework (DiretctShow): it cannot parse arbitrary amounts of the source file in order to determine the display FPS, it has to know it before receiving the very first frame. However, such renderers are not a prerequisite to watching Matroska files in general, therefore we do not have a general problem.

Madshi's specific circumstances and needs are the ones we're trying to address with a new header element. Note that this has nothing to do with the video content's type; it's the same issue for interlaced, progressive, telecined, mixed.

Now to the problem of your concrete example. This is something I have not looked into yet. It may be connected to the problems mentioned above, but it may also be a) a bug in mkvmerge or b) wrong usage on your end.

[Mosu]

Some of my TS files seem to be breaking when running them through MKV Merge. The original TS files play fine but the resulting MKVs aren't deinterlaced properly by MadVR and EVR has issues too (deinterlacing seems to work but the FPS says 46-48 instead of 50, the playback is jerky and the graph is dodgy also).

Original TS - Sample Clip
Dodgy MKV - Sample Clip

Original TS - EVR Stats
Dodgy MKV - EVR Stats

Any ideas?

I've downloaded this TS, remuxed to Matroska with mkvmerge without specifying any additional commend line arguments, and watched it with VLC. It plays back perfectly, with or without deinterlacing turned on. No dodgyness, no jumpding around. A/V sync cannot be easily judged from such a football game, though, so I cannot vouch for that 100%.

This was on Linux with VLC. So both mkvmerge and the file are fine, and your problems are again due to the special requirements certain video renderers impose.

Edit: current mkvmerge 5.8.0, remuxing simply with "mkvmerge -o out.mkv 'Broken 50i Clip.ts'", followed by "vlc out.mkv". Once again, there is no bug in mkvmerge. Those video renderers simply need information in order to work reliably that just isn't there in Matroska yet. However, that information is generally NOT required for playback as VLC proves.

Edit2: I also tried mplayer for playback (you know, the OSS project, not "wmplayer.exe"). It plays the file just as well.

[madshi]

Just for the record: madVR plays this file just fine, too, except that it disables deinterlacing because the framerate reported by the MKV splitter is 50p. This is not really a bug in madVR. It could be seen as a bug in the current MKV splitters which report incorrect FPS to madVR with this specific file. Or it could be seen as an MKV spec related problem because getting the right FPS information from this MKV file is rather difficult with the current MKV spec. In any case, it is not a bug in madVR. madVR is being told that the file is 50p. It's not an information madVR gets itself, it's reported by the upstream filters (splitter, decoder). So since madVR is being told that the file is 50p, why should it try to deinterlace it?

@nevcairiel, maybe you could add an option to parse/interpret the timecodes to get the FPS information for MKV files? I think you said you already had this implemented, but removed it again. So maybe an option would be useful?

[nevcairiel]

I try to stay away from options like this, too much confusion. I'll check my sample archives for files that may have issues with the probing, if i find any, and will see how/if that can be fixed so i don't have to rely on the DefaultDuration at all anymore.

[madshi]

@Mosu, maybe you can help out here? Is there an easy way to detect files where DefaultDuration might be different from FPS for video tracks? I suppose if the very first MKV block contains a single field, only, that would be one possible indicator? Anything else? Thanks!

[Mosu]

@madshi: not an easy one. I'm at work at the moment, don't have much time to talk, and I'm out of town tonight. Please expect a more comprehensive answer tomorrow.

[DragonQ]

I've downloaded this TS, remuxed to Matroska with mkvmerge without specifying any additional commend line arguments, and watched it with VLC. It plays back perfectly, with or without deinterlacing turned on. No dodgyness, no jumpding around. A/V sync cannot be easily judged from such a football game, though, so I cannot vouch for that 100%.

This was on Linux with VLC. So both mkvmerge and the file are fine, and your problems are again due to the special requirements certain video renderers impose.

Edit: current mkvmerge 5.8.0, remuxing simply with "mkvmerge -o out.mkv 'Broken 50i Clip.ts'", followed by "vlc out.mkv". Once again, there is no bug in mkvmerge. Those video renderers simply need information in order to work reliably that just isn't there in Matroska yet. However, that information is generally NOT required for playback as VLC proves.

Edit2: I also tried mplayer for playback (you know, the OSS project, not "wmplayer.exe"). It plays the file just as well.
If it's a renderer issue then are you saying even EVR has this problem then? Because when I do the equivalent thing ("C:\Users\Adam\Documents\Audio & Video\MKV Tools\mkvmerge" -o out.mkv "Broken 50i Clip.ts"), the MKV plays back incorrectly in MPC-HC using LAV Filters and EVR (see here (http://www.aotplaza.com/Files/HTPC/Screengrabs/Dodgy%2050i%20MKV%20Merge/Broken%20MKV%202.png)).

If I switch to MPC-HC Matroska Splitter, I get the same problem, so I guess that rules out a problem unique to LAV Splitter. I again get the same issue if I use MPC-HC's H.264 decoder and MPC-HC's AC3 decoder.

If I try to play the MKV in VLC, I get a green screen when using GPU acceleration. If I disable that, it uses ~35% CPU and doesn't play smoothly at all. Worse than MPC-HC, I'd say.

This might sound like a stupid question but are you sure it's playing back smoothly? Cos the sample I posted looks pretty good initially (in MPC-HC anyway) but in panning shots you can see it's not smooth (and the EVR graph proves this).

One thing I wanna try is playing the file in MediaPortal - that'd still use EVR and LAV decoding but the player and splitter would be different.

[Mosu]

I'm 200% sure that my eyes are completely OK and that I'm not imagining things here. Yes, it plays smoothly on both players in Linux. I don't have a Windows workstation here, nor do I have a powerful PC running Windows anyway, and I don't use madshi or EVR. So... yes. It works for me.

[DragonQ]

Just tested MediaPortal, it plays the MKV smoothly at 50 fps. The audio and video are out of sync but I'm sure that's just an issue with making the cut sample using TSMuxer - the original file was in sync.

[madshi]

@DragonQ, try using "eac3to broken.ts broken.mkv" and then using mkvtoolnix afterwards to mux the video+ac3 together. That fixes the FPS problem on my PC. You could argue, though, that eac3to writes a wrong DefaultDuration to the file, though. In any case, I plan to add a detection & correction for twice as high "FPS" information coming from the splitter to the next madVR build. This might already fix the problem when using madVR.

[DragonQ]

@DragonQ, try using "eac3to broken.ts broken.mkv" and then using mkvtoolnix afterwards to mux the video+ac3 together. That fixes the FPS problem on my PC. You could argue, though, that eac3to writes a wrong DefaultDuration to the file, though. In any case, I plan to add a detection & correction for twice as high "FPS" information coming from the splitter to the next madVR build. This might already fix the problem when using madVR.

You're right, that does seem to fix the issues in both EVR and MadVR. Surely if both EVR and MadVR work correctly when the DefaultDuration is 40 ms, it makes sense for MKVMerge to set it to this when muxing? I know it might not be technically correct and a new fps field would be better, but if it works...

There's still the mystery of what possesses MKVMerge to make the DefaultDuration 20 ms rather than 40 ms for these newer files and not older ones...maybe there's some really subtle change in the TS stream that doesn't show up in MediaInfo?

[nevcairiel]

You can't just change the DefaultDuration like that, its also used to avoid having to write a duration for every single block. If every block has the same duration, you can just skip writing it, and use the DefaultDuration for that.
Since your file does indeed seem to have one field per block, a DefaultDuration of 20ms makes sense (50 fields per second), two blocks/fields make one frame and give you 40ms/25 frames per second.

So the real problem still is that you can't use the DefaultDuration as a plain FPS value.
madVR will fix it, so that deinterlacing is still performed, and i'll do also some fix in LAV to try to detect a more accurate FPS value.

[madshi]

@DragonQ, truth be told mkvtoolnix does the "right" thing and eac3to does it "wrong", if you follow the MKV spec to the letter. I don't see any negative consequence of doing it "wrong", but I understand that Mosu wants to follow the spec perfectly. I've already modified madVR now to auto-detect this situation and to auto-correct wrong FPS information coming from the splitter/decoder. And I think nevcairiel is planning to implement a similar patch in LAV Splitter. So the problem should be gone soon. Personally, I'm always using eac3to first to mux the video to MKV, then I'm using mkvtoolnix in a 2nd step to add the audio tracks. This has always worked very well for me. But as I said, what eac3to does is technically not really correct, according to the MKV spec. I don't plan to change this, though, unless MKV gets a new dedicated FPS field, then I'll adjust eac3to accordingly.

[DragonQ]

So the real problem still is that you can't use the DefaultDuration as a plain FPS value.
madVR will fix it, so that deinterlacing is still performed, and i'll do also some fix in LAV to try to detect a more accurate FPS value.
So would a change in LAV fix the issue for EVR then? I can't use MadVR on my laptop (although I use it on my desktop).

@DragonQ, truth be told mkvtoolnix does the "right" thing and eac3to does it "wrong", if you follow the MKV spec to the letter. I don't see any negative consequence of doing it "wrong", but I understand that Mosu wants to follow the spec perfectly.
Yeah, I understand.

Thanks to all three of you for your help with this matter, it'll be great to see this issue fixed in the future! :)

[nevcairiel]

So would a change in LAV fix the issue for EVR then? I can't use MadVR on my laptop (although I use it on my desktop).

Yes, it will. As long as you use LAV Splitter. ;)

[DragonQ]

Yes, it will. As long as you use LAV Splitter. ;)
Cool. It seems MediaPortal's splitter already works fine anyway (rightly or wrongly) and that's the only time I don't use LAV Splitter. :p

[DragonQ]

@DragonQ, try using "eac3to broken.ts broken.mkv" and then using mkvtoolnix afterwards to mux the video+ac3 together. That fixes the FPS problem on my PC. You could argue, though, that eac3to writes a wrong DefaultDuration to the file, though. In any case, I plan to add a detection & correction for twice as high "FPS" information coming from the splitter to the next madVR build. This might already fix the problem when using madVR.
FYI, whilst this trick fixes MadVR and EVR compatibility for files with AC3 audio, it doesn't work for files with HE-AAC audio - MadVR still doesn't deinterlace these.

[Mosu]

Hey,

I've released v5.9.0.

I've released MKVToolNix v5.9.0. It fixes several bugs: 793 (appending empty subtitle tracks); 795 (file names containing '%' read from .mmg files); reading linked seek heads in mkvmerge (fixes mkvmerge not finding attachments after usage of mkvpropedit); 801 & 802 (discarding EBML void elements when writing and reading XML chapter files); 804 (mkvmerge will keep timecodes of PCM tracks read from containers that provide timecodes); 805 (reading seek position elements bigger than 2 GB).

Enhancements include writing the newly introduced elements "cue duration" and "cue relative position" which provide more detailed information for seeking. Due to this compilation requires new versions of libEBML (1.3.0) and libMatroska (1.4.0), neither of which has been released yet: they're only available from the Subversion repository so far. However, MKVToolNix comes bundled with internal copies of both libraries which will be used.

Here are the usual links: the home page (http://www.bunkus.org/videotools/mkvtoolnix/), the source code (http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-5.9.0.tar.bz2) and the Windows installer (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.9.0-setup.exe) and 7zip archive (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.9.0.7z).

All of the binaries (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html) that I provide myself are already available.

Here's the full ChangeLog (http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since release 5.8.0:

2012-12-09 Moritz Bunkus <moritz@bunkus.org>
* Released v5.9.0.
* mkvmerge: bug fix: Fixed reading seek position values bigger than 2 GB. Fixes #805 (https://www.bunkus.org/trac/ticket/805).

2012-12-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed appending non-empty tracks to empty tracks. Fixes #793 (https://www.bunkus.org/trac/ticket/793).
* mkvmerge: bug fix: mkvmerge will now keep timecodes of PCM tracks from source files if they're available. Fixes #804 (https://www.bunkus.org/trac/ticket/804).

2012-12-05 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: EBML void elements will be skipped when reading structures from XML (e.g. chapters). Fixes #802 (https://www.bunkus.org/trac/ticket/802).

2012-12-02 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: EBML void elements will be skipped when saving structures to XML (e.g. chapters). Fixes #801 (https://www.bunkus.org/trac/ticket/801).
* mkvmerge: bug fix: Fixed reading linked seek heads in Matroska files.

2012-11-13 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed reading file names containing a '%' from a .mmg settings file (both normally saved files and the job queue files). Fixes #795 (https://www.bunkus.org/trac/ticket/795).

2012-10-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Dirac video code: Added four more pre-defined video types from Dirac spec v2.2.2 and two from Dirac Pro.

2012-09-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: enhancement: Added options for turning off writing "CueDuration" elements ("--engage no_cue_duration") and "CueRelativePosition" elements ("--engage no_cue_relative_positions").
* mkvmerge: new feature: The element "CueRelativePosition" is written for all cue entries.
* mkvmerge: new feature: The element "CueDuration" will be written for all cue entries referring to subtitle tracks.
* mkvmerge: new feature: mkvmerge will write cues for subtitle tracks by default now.
* mkvinfo: new feature: added support for the new elements CueDuration, CueRelativePosition and TimecodeScaleDenimonator. The denominator's value is only shown so far but not taken into account when calculating any timecode.
* mkvpropedit, mmg, mkvmerge: removal: removed support for the deprecated element TrackTimecodeScale.

Have fun.

[Selur]

Thanks for the new release.
Are their expected problems the cue-elements are added? (like when the header removal compression was added?)

[Mosu]

No. They're additional elements. So any player that properly handles elements it doesn't know (meaning simply skipping and disregarding them) will not have any problem. Won't be able to take advantage of the additional information, of course, but won't be off any worse either.

[nevcairiel]

Thanks for the new release.
Are their expected problems the cue-elements are added? (like when the header removal compression was added?)

Only if you have a broken parser which doesn't simply ignore unknown tags.

[Mosu]

Additional information I forgot. As those elements belong to version 4 of the Matroska specs mkvmerge will write "DocTypeVersion = 4" instead of "DocTypeVersion = 3". This may pose problems for players, yes, if they're shittily implemented.

But: the element more important for players, "DocTypeReadVersion", stays at 2 because any player not supporting those elements should still be able to use the file 100% fine.

[nevcairiel]

I just noticed a small inconsistency, in your mail to matroska-devel you assigned the id 0x53 b3 to CueDuration, but in the spec sheet on matroska.org it got the id 0xb2 .. i assume the spec sheet is correct?

[Mosu]

The specs are indeed correct. Both new elements, CueDuration and CueRelativePosition, only use one-byte long IDs (0xb2 and 0xf0, respectively). Thanks for catching this; I'll send a mail to matroska-devel.

[Keiyakusha]

The specs are indeed correct. Both new elements, CueDuration and CueRelativePosition, only use one-byte long IDs (0xb2 and 0xf0, respectively). Thanks for catching this; I'll send a mail to matroska-devel.

So do we need to wait for new build before using mkvtoolnix? or current v5.9.0 is safe after all?

BTW are these new elements supposed to solve issues with OPUS?

[Mosu]

The specs and libMatroska are both generated automatically from the same file. So mkvmerge is fine. Only the email sent to the mailing list was wrong.

The elements are not supposed to "fix Opus" because it is still unclear whether or not changes are required at all. Steve disagrees strongly with the Opus people on how timecodes should be stored in a container. Please read he discussion on the mailing list if you want the details,

[Mosu]

Well well well... VLC does have its problems with those new elements. Would not have thought so. The reason is simple. VLC does not skip elements it does not know about. It can be turned on, but it isn't on by default. You can find that option here: Tools -> Preferences -> “Show settings: all” at the bottom left; In the tree on the left side: Input/Codecs -> Matroska; make sure “Dummy elements” is turned on. See this screenshot (http://www.bunkus.org/pics/vlc-preferences-matroska-dummy-elements.png).

The tooltip for the option says something about being bad for damaged files. So I can understand the reasoning behind it. However, it also violates the Matroska specs (or at least its spirit). Note that I'm talking about skipping unknown elements, which should be supported by the application. Not knowing an element and not supporting it are two different things: it's perfectly OK to say "we don't support elements X, Y and Z", but to say "we found an element we don't know, so let's abort reading the whole tree from here on" is bad. Very bad.

I'll file a bug report. They'll add support for those elements. Everyone will update their players.

[sneaker_ger]

I have VLC 2.0.4 with standard settings ("Dummy Elements" not checked) and it seemed to work fine in a short test. What's broken exactly?

[Mosu]

Seeking, but that's broken bad. See the two bug reports I've submitted for VLC: 7884 (https://trac.videolan.org/vlc/ticket/7884) and [https://trac.videolan.org/vlc/ticket/7887]7887[/url].

[sneaker_ger]

I've looked at your reports, but I don't know in what way seeking is broken. I quickly remuxed a .mov trailer to mkv with mkvmerge 5.9.0 and seeked a bit around with VLC 2.0.4. It seems to just work at expected.
Is the playback supposed to stop? Your report says it will "abort"? Are the elements only created under specific conditions?

[Mosu]

Use any not trivially small file that doesn't fit easily into your machine's cache/memory (e.g. one over 4 GB) that has been muxed with v5.9.0. Make sure "dummy elements" is off. Start playback and seek far into the file. VLC locks up until it has reached that point by manually skipping over clusters because it wasn't able to read the cues properly.

What happens (technically) is that VLC aborts reading the rest of the file/section as soon as it finds an element that it doesn't know about. As each cue entry contains such an element now VLC does not read a single cue element successfully, resulting in VLC not having an index helping it seek.

Your trailer is most likely way too short to notice the slow method of skipping over content instead of using the index.

[sneaker_ger]

Thx for the explanation. I could indeed reproduce the problem with a file that was bigger. I hope the VLC devs know about this.

[Mosu]

TypX, the guy responsible for the two bugs, told me on IRC that he has seen them and that he'd respond over the weekend. His schedule is as full as mine though; and the holidays are coming up, so... Well. I made a couple of proposals how they can improve the situation while still keeping good user experience for heavily damaged files.

[Snowknight26]

The Windows installer doesn't show the image on the first installation screen; the label "MKVToolNix 5.9.0 by Moritz Bunkus" has a black background.

[Mosu]

I know, but I don't consider this to be of any significance. If you want to spend some time investigating why this happens then by all means, be my guest. I'd welcome the results. I'm running on Arch Linux using nsis compiled from the AUR; the NSI script and auxiliary files are publicly available on github (https://github.com/mbunkus/mkvtoolnix/tree/master/installer).

[Mosu]

The Windows installer doesn't show the image on the first installation screen; the label "MKVToolNix 5.9.0 by Moritz Bunkus" has a black background.

BTW, I've had too much free time on my hands today and fixed the problem. The issue is that the NSIS package in Arch Linux does not contain some of the patches that the package in the Ubuntu/Debian repositories contains. I've ported those packages and am using a modified NSIS on my Arch now which shows both the picture and the text properly.

[Mosu]

Here's a little Christmas present. I've implemented support for the Macromedia Flash Video file format over the last couple of days. As I don't have that many test files I'd appreciate some testing from you.

Support is implemented for:

MP3
AAC audio tracks (only tested with 2 channels, non-SBR)
h.264 video tracks (only tested with B-frame-less files; also: even if the timecodes were right B frames wouldn't be marked as such; in Matroska terms: only one reference and not two for BlockGroups and the 'Discardable' flag is not set for SimpleBlocks)
FLV1 (Flash's own variation of the h.263 codec)
FLV4 (untested)

What does not work: any other audio or video codec.

And here's the build (480 and newer) (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/).

Happy holidays!

[Superb]

Adobe* :P Nice feature. gj!

[Mosu]

Hmm. It has been Macromedia once upon a time. But you're right. I've renamed that stuff to "Flash Video" without a company name.

[Taurus]

Thanks for sharing.:thanks:
Really appreciated.
A Merry Christmas and a Happy New Year to you.

[Overdrive80]

Hi, I have various videos a 23.976 and audios with samplerate accord to their, synchronized.

However, I want reproduce video's parts to different framerate. I use this timecodes file for video.

# timecode format v1
assume 23.976
0,2615,25
2616,32423,24
3242,34727,25
34728,34916,24

I tried to assign the same timecodes to audio, but never in sync

My question is: How could I do for that audio is sync in?

Thanks in advance.

[Mosu]

Timecodes are assigned one to each Matroska block. Each Matroska block contains one... "unit". For video this is either a full progressive frame or one interlaced field. For audio, however, it's one audio frame (the smallest indivisible unit that audio codec can handle). How long such an audio frame is depends on how many samples there are in that block. Most audio formats have a fixed number of samples per frame (e.g. always 1024 for AAC). However, there are several problems that make playing around with those timecodes rather hard:

Different audio codecs use different number of samples per frame (e.g. AAC 1024, AC3 1536).
Even within the same audio codec it may depend on the frame headers (e.g. MP3: several possible numbers of samples: 384, 576 or 1152)
For some audio codecs it is only possible to estimate the number of samples in a frame without fully decoding it (Vorbis)
Even if you do manage to calculate the number of samples in each frame a lot of players will have real problems with playback speed and/or audio/video synchronization if the duration between two audio frames deviates too much from what it should normally be.

If you do have the number of samples in a unit you have its duration by calculating samples/sample_rate (this would be in seconds, then). The frame's timecode is the sum of all durations of all the preceding frames.

[Overdrive80]

Ohhh, maybe I must forget this idea... I dont understand the way to do it. Thanks

[Simon88]

FLV to MKV Conversion of a variable framerate FLV seems OK. I just opened the FLV without ANY changes to any settings... Just hit "add", then "start muxing".. Both Audio & Video were inside the MKV & were in sync. Also, the video is 640x480, where did the "640/485" come from, (the video stream had a wrong dimension descriptor??).. But I also received the following warning:

mkvmerge v5.9.0 ('On The Loose') built on Dec 31 2012 17:36:59


'C:\Downloads\mkvtoolnix-unicode-5.9.0-build20121231-488\video.flv' track 0: Using the output module for the format 'AVC/h.264'.


'C:\Downloads\mkvtoolnix-unicode-5.9.0-build20121231-488\video.flv' track 1: Using the output module for the format 'AAC'.


Warning: 'C:\Downloads\mkvtoolnix-unicode-5.9.0-build20121231-488\video.flv': A track with the ID 1 was requested but not found in the file. The corresponding option will be ignored.


The file 'C:\Downloads\mkvtoolnix-unicode-5.9.0-build20121231-488\video.mkv' has been opened for writing.


'C:\Downloads\mkvtoolnix-unicode-5.9.0-build20121231-488\video.flv' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 640/485.


Progress: 0%
Progress: 10%
Progress: 25%
Progress: 36%
Progress: 48%
Progress: 60%
Progress: 74%
Progress: 81%
Progress: 92%
Progress: 100%
Progress: 100%



The cue entries (the index) are being written...


Muxing took 4 seconds.

---------

I use to use "FLVExtractCL.exe", then import it into "mkvmerge", but variable framerate FLVs had issues, obviously. I had to use ffmpeg to convert to an intermediate format before importing into mkvmerge in order to get proper A/V sync...

Anyhow, thanks for this new feature... and happy new year!!

edit: thanks for remaindering me, sneaker_ger: I meant variable frame-rate FLVs, as opposed to variable bitrate ... I got those two terms switched :-(

[sneaker_ger]

Variable bitrate does not pose any problems, only variable framerate if you don't use the timecodes when using FLVExtract + mkvmerge.

If you think mkvmerge does not handle your file correctly you should upload a sample, but if the information inside the flv is wrong, likely nothing will be done about it.

[Simon88]

"mkvtoolnix-unicode-5.9.0-build20130106-489", released only a few hours ago, seems to have fixed the issue I mentioned!

Thanx Mosu...

[Mosu]

Uhm... yeah, I meant to answer here that I've fixed the issue yesterday, but luckily you've found out by yourself already ;)

For reference, the issue Simon88 & I mean is this warning when reading FLV files:

Warning: 'C:\Downloads\mkvtoolnix-unicode-5.9.0-build20121231-488\video.flv': A track with the ID 1 was requested but not found in the file. The corresponding option will be ignored.

[[ReX]]

Are there any more supported formats for mkvextract that haven't been added to the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvextract.html#mkvextract.output_file_formats) like Theora and VP8?

[Mosu]

Likely. Are you offering to look at mkvextract's source code (https://github.com/mbunkus/mkvtoolnix/tree/master/src/extract) and to provide a patch for the documentation (https://github.com/mbunkus/mkvtoolnix/blob/master/doc/man/mkvextract.xml)? 'Cause that would be great.

[[ReX]]

Likely. Are you offering to look at mkvextract's source code (https://github.com/mbunkus/mkvtoolnix/tree/master/src/extract) and to provide a patch for the documentation (https://github.com/mbunkus/mkvtoolnix/blob/master/doc/man/mkvextract.xml)? 'Cause that would be great.

I was hoping you had a list, I can do that though. ;)

Edit: 0.4.2 had this change:
* Removed the '--sub-type' switch as all text subtitles will be
stored in UTF-8 format. Made iconv mandatory in the configure
checks for this very reason.

Does that mean S_TEXT/ASCII doesn't need to be documented along with S_TEXT/UTF8?

Another edit:
Is S_VOBSUB/ZLIB still applicable?
I tried muxing an IDX file with an equivalent ZIP file with the SUB file inside it, but mmg wouldn't accept it; I also tried setting the track compression to zlib, the resulting codec id was just S_VOBSUB.

Also it seems that setting the compression to lzo makes the track invisible to mkvmerge, and by extension, to mmg; mkvinfo can see it though.

[Sparktank]

I'm wondering if there's any work-around or solution to using mmg to do a complicated split.
I tried to search but couldn't find anything, or couldn't find the right words.

What I want to do is extract a Blu-Ray movie to MKV with splits (chapters or custom time codes).
Also with no "segment linking".

But to make things complicated, I want mmg to write only the segments I want to keep and not write unwanted segments/chapters.
As if it were to write a "null file" or "empty file" for the unwanted segments (even if it has to read through the unwanted segments to get to the wanted segments) so that no HDD space is taken and no manual deleting (to avoid any accidental deleting).

Only files written with data are the ones wanted.

Right now, I just remux to MKV with split time codes for the whole movie and manually delete the unwanted segments (sometimes deleting wanted segments).

It's not segment linked mostly for editing (like extracting Blu-Ray audio of the end credits; or experimenting with other AviSynth scripts (2Dto3D anaglyph; Interframe for Pseudo 60fps; etc)). Or sometimes just to have a favorite part of the movie to watch whenever I feel inclined (intense action scenes or graphically entertaining).

Example:
Movie.m2ts/Movie.mpls (from Blu-Ray) to Movie.mkv (split)
time codes in red are unwanted: split=00:00:00 to 00:05:00,00:05:00 to 00:15:00,00:15:00 to 00:45:00,00:45:00 to 00:47:00,00:47:00 to 01:00:00,01:00:00 to 01:10:00,01:10:00 to End Of File,

Keep/Write: [00:05:00 to 00:15:00], [00:45:00 to 00:47:00], [01:00:00 to 01:10:00]
Lose/Delete/Null Write: [00:00:00 to 00:05:00], [00:15:00 to 00:45:00], [00:47:00 to 01:00:00], [01:10:00 to End Of File]

I hope that seemed clear. It took awhile to think how to word it. :o :confused:
(Time for some more coffee.)

Is any of that possible with mmg? Perhaps in combination with a batch script or perl script?
Any ideas or help would be greatly appreciated.

[sneaker_ger]

Yes, that is possible. See doc (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html) 2.5 subchapter "4. Keeping specific parts by specifying timecode ranges while discarding others.".

[Pomegranate]

@ sneaker_ger
Thank you for that tip! I never managed to do this with MKVMergeGui and didn't even think to try the command line.

[Sparktank]

Yes, that is possible. See doc (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html) 2.5 subchapter "4. Keeping specific parts by specifying timecode ranges while discarding others.".

That's perfect! Thank you so much!
I feel so noobish for not seeing that part before. ; ;

[Mosu]

;1610542']I was hoping you had a list, I can do that though. ;)

The man page's list is the only list I have. Other than the source code, of course ;)

Does that mean S_TEXT/ASCII doesn't need to be documented along with S_TEXT/UTF8?

I don't know of a single program that can produce or read S_TEXT/ASCII subtitles (mkvmerge cannot create them). I think we even deprecated that CodecID.

Is S_VOBSUB/ZLIB still applicable?

No. That was from back in the day (roughly ten years ago) when we thought of using the CodecID for providing addition information like the compression scheme used. I've never seen a file with that CodecID in the wild.

There's something similar for A_AAC (e.g. A_AAC/LTP etc.) before we decided to store AAC's data in CodecPrivate and simply use the shorter CodecID A_AAC, and as mkvmerge had been writing such files for some time there are actually files out there with the longer CodecIDs.

I tried muxing an IDX file with an equivalent ZIP file with the SUB file inside it

mkvmerge has never supported that, and that isn't what the /ZLIB postfix was about (btw, zlib = gzip != zip).

I also tried setting the track compression to zlib, the resulting codec id was just S_VOBSUB.

Correct. The compression scheme used is stored in a separate element hierarchy ("ContentEncodings") in the track headers.

Also it seems that setting the compression to lzo makes the track invisible to mkvmerge, and by extension, to mmg; mkvinfo can see it though.

Hmmm sounds like a bug. Although I somehow doubt there are five people on this planet who've ever used lzo in mkvmerge ;) It's faster than zlib but has worse compression. bzip2 is the other way around. However, most devices only support zlib, and that's what should be used.

[Mosu]

@ sneaker_ger
Thank you for that tip! I never managed to do this with MKVMergeGui and didn't even think to try the command line.

No need to use the command line for this. In mmg this is called "splitting by parts".

[Mosu]

That's perfect! Thank you so much!
I feel so noobish for not seeing that part before. ; ;

In was implemented with release v5.5.0 on 2012-04-06. So it's only been available for a little while.

[Pomegranate]

No need to use the command line for this. In mmg this is called "splitting by parts".

That is indeed very useful. Thanks.

Out of curiosity, is it possible do this with frame numbers?

[Mosu]

:) See https://trac.bunkus.org/ticket/819.

[Atak_Snajpera]

@mosu
I've noticed that you are experimenting with .opus in matroska. Has matroska team finally figured out how to handle .opus audio in .mkv container?

[Mosu]

See my reply from yesterday (http://forum.doom9.org/showthread.php?p=1610364#post1610364).

[Sparktank]

:) See https://trac.bunkus.org/ticket/819.

+1 for frames. I'm so used to working with frames for everything now, lol.

[Mosu]

You can split by frames/fields in the upcoming 6.0.0 ("--split frames:..."). That ticket is only about "--split parts:..." working with frame/field numbers. That won't happen too soon, I guess.

[hello_hello]

I recently discovered a couple of my old encodes were taken from video which used forced subtitles to display the English subtitles for the non-English parts and I guess I missed it at the time. As it's only a couple of sections of around 1 minute in each encode which uses forced subtitles and I want to encode them, rather than re-rip and encode the whole video from scratch I thought I'd just split off the small sections, re-encode them with the subtitles and then join the parts together again. The problem with that is when joining them MKVMergeGUI gives me a warning message and the appended MKVs don't play correctly.

"The codec's private data does not match (lengths: 45 and 41). Please make sure that the resulting file plays correctly the whole time."

Could someone please explain to me what "codec's private data" actually is? So far I've tried remuxing the encoded version with ffmpeg while changing the frame rate in the h264 stream which worked, but left the "codec's private data" unaltered. I've tried appending the original and encoded streams using MP4Box with the method suggested in this thread (http://forum.doom9.org/showthread.php?t=129920), which appeared to work.... MKVMergeGUI happily remuxed the resulting MP4 as an MKV without warnings, but neither the MP4 or the MKV would play (just a grey screen using MPC-HC) and according to MKVInfo the codec's private data was now 83 even though the frame rate was still 23.976fps, and I even downloaded and used the same version of x264 as was originally used but the encoded version's private data still didn't match.

Even if there's no way to fix the problem and I simply have to live with re-ripping/encoding the whole video I'd still like to know what the codec's private data actually means. Thanks.

PS. I've just discovered when using a different GUI for re-encoding (ffcoder) the resulting private data, according to MKVInfo, remains the same as the original file, even when using the same version x264 as when I was re-encoding with the first GUI (MeGUI). So thinking it's a GUI related issue and I'd fixed the problem, I tried appending the original and re-encoded streams again, only MKVMergeGUI still complained and the resulting MKV still wouldn't play correctly.

"The codec's private data does not match (lengths: 41 and 41). Please make sure that the resulting file plays correctly the whole time."

Now I'm totally lost as to what the codec's private data might be, given MKVMergeGUI says they don't match even when it appears they do.

[hello_hello]

See my reply from yesterday (http://forum.doom9.org/showthread.php?p=1610364#post1610364).

Just for clarification.....

meaning there is a definite chance you won't be able to play back A_OPUS/EXPERIMENTAL files in the future. So this means that you should not throw away the source files after using mkvmerge for muxing Opus at the moment ;)

Does that mean in the future if things change, newer versions of MKVMerge won't be able to simply open and correctly remux MKVs created today and it'll be necessary to start again with the source files?

[Chetwood]

I recently discovered a couple of my old encodes were taken from video which used forced subtitles to display the English subtitles for the non-English parts and I guess I missed it at the time. As it's only a couple of sections of around 1 minute in each encode which uses forced subtitles and I want to encode them, rather than re-rip and encode the whole video from scratch I thought I'd just split off the small sections, re-encode them with the subtitles and then join the parts together again.
AFAIK an mkv's track flag overrides any item's flag of said track, but you can use these flags to identify forced items in BDSUP2SUB. So why not extract the track, export only the forced items into a new track and remux this back into the mkv?

[Mosu]

Just for clarification.....



Does that mean in the future if things change, newer versions of MKVMerge won't be able to simply open and correctly remux MKVs created today and it'll be necessary to start again with the source files?

That is most likely correct. However, depending on how long this state lasts I might add the functionality to read such files. I might also not do that.

One thing to consider is that there currently is no way to store at least one piece of information: the number of samples to trim in the very last packet. So even if future mkvmerge were able to read A_OPUS/EXPERIMENTAL files that information would still be lost.

[Mosu]

"The codec's private data does not match (lengths: 45 and 41). Please make sure that the resulting file plays correctly the whole time."

CodecPrivate data is an element that stores data that the codec in question needs in order to decode the file properly. Different codecs have very different requirements for their private data (it's often called "codec initialization data" as wel). For example, Vorbis needs its codebook which tells the codec how to expand the encoded/compressed stuff back to the uncompressed stuff that can be played back.

Same with AVC/h.264. The CodecPrivate data contains (amongst other things) the sequence parameter sets and picture parameter sets. They contain important information like pixel resolution, codec features used etc.

So it is generally technially impossible to decode video from an encoding A with the private data from encoding B (and mkvmerge can do nothing about it). However, there are situations in which that will work: if the codec private data only differns in unimportant fields (e.g. the frame rate is also stored in the sequence parameter sets, and if they and only they differ then there should not be any problem). That's why mkvmerge doesn't prevent you from doing it.

[sneaker_ger]

One thing to consider is that there currently is no way to store at least one piece of information: the number of samples to trim in the very last packet. So even if future mkvmerge were able to read A_OPUS/EXPERIMENTAL files that information would still be lost.

Though this applies to all kinds of audio formats already, doesn't it? (MP3, AAC, AC3, DTS etc.) What makes Opus so special in this regard that it warrants a spec change?

[sneaker_ger]

@hello_hello

Try to demux to raw H.264 ES and append those in mkvmerge.

[Mosu]

Though this applies to all kinds of audio formats already, doesn't it? (MP3, AAC, AC3, DTS etc.) What makes Opus so special in this regard that it warrants a spec change?

True, true. Only that fact that the Opus folks would not like to "repeat this disaster with Opus" (http://wiki.xiph.org/MatroskaOpus).

[sneaker_ger]

Will it also be possible to have sample accurate encoder delay information, so that with both infos we could theoretically have gap-less mkv audio playback? Will you implement this for other formats as well?

[Mosu]

Highly unlikely.

[sneaker_ger]

If we don't get that, I don't understand why they are this hung-up on end trimming. It's pretty meaningless if we don't have both. Very half-assed. Is this "pressure" only coming from the Opus guys or does it have to do something with the WebM people?

[Mosu]

I honestly have no clue how the WebM people do the Opus stuff at the moment.

Me personally I could simply ignore both pre-skip and end trimming. Other codecs are already handled in exactly the same way. And that way I could implement Opus support in Matroska right now. I'll only have to write the proper cue elements for providing proper points to seek to for pre-roll.

[sneaker_ger]

Those new cue elements for seeking at least make sense, even more so for subtitles than for any audio codec.

[Mosu]

If you're so invested in seeing proper audio support why don't you join the Opus discussion on the Matroska mailing list (http://lists.matroska.org/pipermail/matroska-devel/2011-December/004153.html)? More like restarting it than joining it, I guess. At the moment it feels like I'm the only one doing any work in that direction (no further replies from Steve or Ralph).

[hello_hello]

AFAIK an mkv's track flag overrides any item's flag of said track, but you can use these flags to identify forced items in BDSUP2SUB. So why not extract the track, export only the forced items into a new track and remux this back into the mkv?

Identifying the forced subs wasn't the issue as such, at the time I didn't bother including any subtitles at all as I didn't realise the need for some of them.
I was hoping to encode them rather than add them as a separate stream so as avoid worrying about standalone player subtitle support. Or having to explain to others in the house the need to enable them. Do many hardware players automatically display forced subtitles in MKVs as they would DVDs or Bluray discs? I'm not aware of any software players which do.


Try to demux to raw H.264 ES and append those in mkvmerge.

I'm fairly sure I did with the same result but I tried so many different things maybe I should try again to be certain.

CodecPrivate data is an element that stores data that the codec in question needs in order to decode the file properly. Different codecs have very different requirements for their private data (it's often called "codec initialization data" as wel). For example, Vorbis needs its codebook which tells the codec how to expand the encoded/compressed stuff back to the uncompressed stuff that can be played back.

Same with AVC/h.264. The CodecPrivate data contains (amongst other things) the sequence parameter sets and picture parameter sets. They contain important information like pixel resolution, codec features used etc.

Thanks for the info. I just found it curious because I'm sure I've re-encoded sections of video a few times in the past without a "codec private data" issue, but maybe I'm just remembering that incorrectly and it's never worked. It's not something I'd try to do very often.

Cheers.

[sneaker_ger]

If you're so invested in seeing proper audio support why don't you join the Opus discussion on the Matroska mailing list (http://lists.matroska.org/pipermail/matroska-devel/2011-December/004153.html)? More like restarting it than joining it, I guess. At the moment it feels like I'm the only one doing any work in that direction (no further replies from Steve or Ralph).

I think I read that and some other discussion some time ago (and forgot most of it), but to be honest I'm not really that invested in gap-less mkv audio support, because their "native" containers are already providing what's necessary and will continue to provide the best hardware compatibility. I just don't understand the reasoning behind implementing half-assed end trimming for a single audio format if it does not even serve any real purpose. Just seems like introducing lots of work for everyone involved, breaking some (defect) players, fixing bugs etc. It's just not worth the hassle if you're not doing it right from the start.

Buuut, now reading it again it seems like the pre-skip could actually provide sample accurate encoder delay signalization?
The OpusHead 'pre-skip' field lets a muxer prepend extra data to help
the decoder converge before samples are output. For example, when
cropping a stream, a muxer can prepend ~500ms of data from before the
cut point, and then set the pre-skip field to 24000 samples, asking
the playback engine to discard those samples. This also allows
lossless sample-accurate cropping, since the pre-skip can indicate
playback start in the middle of a frame.

This is about ogg though, so I'll have to re-read everything later to see what the current plans for mkv are.

[Mosu]

Buuut, now reading it again it seems like the pre-skip could actually provide sample accurate encoder delay signalization?

For Opus, yes. In gerenal: probably. One problem I see with such an element is its unit. For most codecs you could say the unit is "samples", but as far as I understood Opus there's nothing like "the sampling frequency" for which the number of samples could be calculated. In Ogg the pre-skip is given in ms instead of samples, too.

So, would we have to use a time-based field or a sample-based one? If the latter: how to signal how long a sample is? (Same for video codecs, I guess....)

[sneaker_ger]

Yes, the decision to do integer timecodes in matroska seems to not have been very wise. MP4 with samples and timebases seems to work out better in practice. But since I have basically no understanding of Opus and little of Matroska, I will likely not be able to contribute anything meaningful to your discussion with the Opus people.

[Chetwood]

Do many hardware players automatically display forced subtitles in MKVs as they would DVDs or Bluray discs? I'm not aware of any software players which do.

VLC does and standalones are the usual mixed bag. As long as the forced sub is muxed as the first subtitle track into the MKV and flagged as default and forced it should work on many players.

[Mosu]

Hey,

I've released MKVToolNix 6.0.0. It packs quite a punch: several new features, a couple of bugfixes. The new features include a reader for the FlashVideo file format (.flv -- yes, for those YouTube videos), splitting by frame/field numbers, splitting by chapter numbers, splitting into parts by frame/field numbers, reading VobSubs from MP4 files and the ability to save additional command line options as default options in mmg.

Then there's a major change regarding one of the most controversial features in MKVToolNix: header removal compression has been turned off by default in both mkvmerge and mmg.

The list of fixed bugs is even longer than the one for new features, so please look at the ChangeLog below for the details.

There are three things to note for package maintainers: the source code archive is now compressed with xz instead of bzip2 (file name ends in ...tar.xz); Boost's "variant" library is now required; MKVToolNix still requires its bundled versions of libEBML and libMatroska because new versions of them haven't been released yet (just like in 5.9.0).

Here are the usual links: the home page (http://www.bunkus.org/videotools/mkvtoolnix/), the source code (http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-6.0.0.tar.xz) and the Windows installer (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-6.0.0-setup.exe) and 7zip archive (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-6.0.0.7z).

All of the binaries (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html) that I provide myself are already available.

Here's the full ChangeLog (http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since release 5.9.0:

2013-01-20 Moritz Bunkus <moritz@bunkus.org>
* Released v6.0.0.

2013-01-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Implemented splitting by parts based on frame/field numbers ("--split parts-frames:" in mkvmerge). Implements #819 (https://www.bunkus.org/trac/ticket/819).

2013-01-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Re-writing the track headers after they'd grown a lot (to more than the EBML void size located after them allowed for) led to an integer underflow. Then mkvmerge tried to write a void element the size of that integer (e.g. nearly 4 GB on 32bit platforms). Fixes #822 (https://www.bunkus.org/trac/ticket/822) and #828 (https://www.bunkus.org/trac/ticket/828).

2013-01-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix in the MP4 reader: Fixed language code conversion from what is used in MP4 to the ISO 639-2 codes used in Matroska (e.g. convert from "deu" to "ger").
* Source distribution: source code archives (tarballs) will be compressed with xz instead of bzip2 from now on. The file name's extension will therefore change from ".tar.bz2" to ".tar.xz". The download URL changes accordingly.

2013-01-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Implemented reading VobSubs from MP4 files if they're stored in the Nero Digital way (track sub-type 'mp4s', ESDS object type identifier 0xe0). Implements #821 (https://www.bunkus.org/trac/ticket/821) and the second half of #815 (https://www.bunkus.org/trac/ticket/815).

2013-01-08 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Command line options can be saved as default for new jobs by clicking a check box in the "add command line options" dialog.

2013-01-02 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed a crash in the chapter editor if the root was selected and the user used the "Set values" button.

2013-01-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: removal: The 'header removal compression' method is not turned on by default anymore. This affects the following track types: AC3, AVC/h.264, Dirac, DTS, MP3. The setting in mmg that turned it off by default has been removed.

2012-12-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added experimental support for the Opus audio codec. Parts of an implementation of #779 (https://www.bunkus.org/trac/ticket/779).

2012-12-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: "text"-type tracks in MP4 files are only treated as chapters if their track ID is listed on a "chap" atom inside a "tref" track reference atom. Fixes #815 (https://www.bunkus.org/trac/ticket/815).

2012-12-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: new feature: Implemented splitting by chapter numbers. Implements #504 (https://www.bunkus.org/trac/ticket/504) and #814 (https://www.bunkus.org/trac/ticket/814).

2012-12-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Removed several warnings from the MPEG-2 video parser code about open GOPs, missing references. Those were too confusing for most users, even after being given additional information via email and FAQs.
* mkvextract: new feature: Implemented extraction of ALAC into Core Audio Format files (CAF). Implements #786 (https://www.bunkus.org/trac/ticket/786).

2012-12-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: new feature: Implemented splitting by frame/field numbers. Implements #771 (https://www.bunkus.org/trac/ticket/771).
* mmg: bug fix: Fixed consistency checks when appending files and at least one track is disabled.
* mkvmerge: new feature: Implemented a reader for the Flash Video format (.flv). Implements #735 (https://www.bunkus.org/trac/ticket/735).

2012-12-22 Moritz Bunkus <moritz@bunkus.org>
* Build system: Boost's "variant" library is now required.

2012-12-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: ISO 639-2 language handling: The deprecated language codes "scr", "scc" and "mol" are replaced by their respective successors "hrv", "srp" and "rum". Fixes #803 (https://www.bunkus.org/trac/ticket/803).
* mkvmerge: bug fix: Matroska reader: Fixed finding the "segment info" element if it is located behind the clusters.

2012-12-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MP3 parser code: Fixed skipping ID3 tags so that the header directly behind the ID3 tag is recognized properly. Fixes #747 (https://www.bunkus.org/trac/ticket/747).
* mkvmerge: bug fix: MP4 reader: Fixed handling of edit lists if the edit list is used to adjust the track's timecodes by a fixed amount (either positive or negative). Fixes #780 (https://www.bunkus.org/trac/ticket/780).

2012-12-10 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit: bug fix: Giving a non-existent file name in tags mode will result in a proper error message. Fixes #806 (https://www.bunkus.org/trac/ticket/806).


Have fun.

[vid.user]

Wow, cool.

[filler56789]

Many :thanks: :)

[Pomegranate]

Thanks for 6.0.0!

Splitting by parts using frame numbers is already implemented!?! :cool:

[Mosu]

Yes, it is.

[nautilus7]

The header removal compression feature fired a lot of talk in the past, so i can't help not asking why you turned it off by default now? Did anything changed in the specs?

[Mosu]

Nothing changed in the specs regarding header removal compression. I simply admit defeat to all the implementations that still do not HRC.

[Pomegranate]

Okay, I just tried splitting by parts using frame numbers, and if I'm not using the command corectly, I apologise, but I keep getting this error. http://i.imgbox.com/abodJEOc.png

Using timecodes works perfectly well however.

[Mosu]

Damn. That's a bug in mmg. The format is fine, if you'd use that on the command line everything would be OK.

[Atak_Snajpera]

Has someone managed to correctly play remuxed FLV(VP6 codec)? This what I get in MPC with enabled all filters and without (Haali media splitter + latest FFDshow). FFms2 also shows the same problem. Original FLV plays correctly.

http://i.imgur.com/UVz1Qim.png

[sneaker_ger]

Sample?

[Atak_Snajpera]

http://www.mediafire.com/?cg5fobvcavi82b8

[sneaker_ger]

ffms2 r725 returns insanity detected on the mkv but not on the flv.

/edit:
Wait, does not work in VLC and LAV anymore... either I just confused the files or something strange happened.

[sneaker_ger]

Remuxes from ffmpeg seem to work - also uses a different FourCC than mkvmerge.

[Mosu]

I haven't tested VP6 in FLV at all because I didn't have a sample file for it. So I don't expect it to work.

[Selur]

not sure if it helps, but if I use:

ffmpeg -y -threads 8 -analyzeduration 14M -i "H:\TestClips&Co\vp6_mp3.flv" -vn -acodec copy "H:\Temp\iId_1_aid_0_19_28_31_4610_01.mp3"
ffmpeg -y -analyzeduration 14M -i "H:\TestClips&Co\vp6_mp3.flv" -vcodec copy -an -f rawvideo "H:\Temp\19_28_31_4610_02.vp6"
mkvmerge --ui-language en -o "H:\Output\test.mkv" -d 0 --default-track 0:yes --aspect-ratio-factor 0:1 --no-chapters --forced-track 0:yes --no-audio --no-subtitles "H:\Temp\19_28_31_4610_02.vp6" --default-track 0:yes --forced-track 0:no -a 0 --no-video --no-subtitles --no-chapters "H:\Temp\iId_1_aid_0_19_28_31_4610_01.mp3"

on the file I end up with something like this:
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Codec ID : V_MPEG4/ISO/AVC
Duration : 2mn 41s
Bit rate : 174 Kbps
Width : 16 pixels
Height : 16 pixels
Display aspect ratio : 1.000
Frame rate mode : Constant
Frame rate : 25.000 fps
Bits/(Pixel*Frame) : 27.211
Stream size : 3.34 MiB (63%)
Default : Yes
Forced : Yes

Audio
ID : 2
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Dual mono
Codec ID : A_MPEG/L3
Codec ID/Hint : MP3
Duration : 2mn 40s
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 1.84 MiB (35%)
Default : Yes
Forced : No
seems like mkvmerge thinks the input is H.264 instead of VP6

[Mosu]

Like I said, VP6 hasn't been tested one tiny bit. I've opened a ticket in my bug tracker for it, though.

[Mosu]

Okay, I just tried splitting by parts using frame numbers, and if I'm not using the command corectly, I apologise, but I keep getting this error. http://i.imgbox.com/abodJEOc.png

Using timecodes works perfectly well however.

A new build with a fix is available (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) (build numbers 491 and newer).

[Pomegranate]

That was lightning fast!

But yes, it's working perfectly now. :thanks:

[Selur]

@Mosu: is there an option to force a specifc output module when feeding mkvmerge with raw video ?
Using the steps described above the new build still reports:
'H:\Output\19_28_31_4610_02.vp6' track 0: Using the output module for the format 'AVC/h.264'.

Cu Selur

[Mosu]

Nope, there isn't, and there never will be. The new build does nothing for VP6 in FLV; it only fixes split arg parsing issues in mmg.

[Selur]

doh,.. :)

[filler56789]

Just remux VP6 into AVI :devil: and only then give it to MKVmerge,
case solved. :) :D

[Mosu]

@Mosu: is there an option to force a specifc output module when feeding mkvmerge with raw video ?
Using the steps described above the new build still reports:
'H:\Output\19_28_31_4610_02.vp6' track 0: Using the output module for the format 'AVC/h.264'.

Oh, and BTW: raw VP6 streams have never been supported as input files by mkvmerge (and most likely never will be). This is in addition to forcing special kinds of output modules, which will never be possible either.

[Selur]

VP6 streams have never been supported as input files by mkvmerge (
got it :)

[Mosu]

A new build is available (492 and higher) (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) that fixes the VP6-in-FLV issue.

[Simon88]

I recently purchased a Hauppauge 2250 TV Card to watch TV while using the computer. The WinTV 7 software can create MPEG-TS OR MPEG-PS.

However, only the MPEG-PS muxed the MPEG2 & AC3, the EIA-608, EIA-708 (A/53 / DTVCC Transport) subtitles were not muxed into the MKV. Is it possible to store the "raw" subtitle data into the MKV container or an srt file? VLC seems to display the subtitles without issues.

Also, the MPEG-TS file gave an error when trying to import it into an MKV,:

Output:

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


Is this a known unsupported feature?

I hate having to post-process the files before importing into an MKV. eg. re-stream the MPEG-2/audio & extract the subtitles.

Thanks...

[Mosu]

However, only the MPEG-PS muxed the MPEG2 & AC3, the EIA-608, EIA-708 (A/53 / DTVCC Transport) subtitles were not muxed into the MKV. Is it possible to store the "raw" subtitle data into the MKV container or an srt file?

Nope. Subtitles in MPEG PS and TS streams are not supported. See also https://trac.bunkus.org/ticket/773

Unfortunately it seems that a single TS subtitle stream can contain several logical subtitle streams which make demuxing them a major PITA. That's why I've practically stopped looking into it.

Also, the MPEG-TS file gave an error when trying to import it into an MKV,:

Output:

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


Is this a known unsupported feature?

Yes, otherwise such an error message wouldn't exist. Improving my MPEG2 handling code has almost zero priority for me.

[Kurtnoise]

However, only the MPEG-PS muxed the MPEG2 & AC3, the EIA-608, EIA-708 (A/53 / DTVCC Transport) subtitles were not muxed into the MKV. Is it possible to store the "raw" subtitle data into the MKV container or an srt file?
you should try TS-Doctor to extract subtitles streams from TS files...this tool is able to convert them to srt.

[Simon88]

Thanx for the suggestion, Kurtnoise, I'll definitely give TS-Doctor a close look.

I was having issues with ccextractor 0.64 creating subs that were not synced correctly. I had to cut a few frames in the beginning of the MPEG-PS/TS file before extracting the subs. And then muxing into an Matroska file.

[Thunderbolt8]

The header removal compression feature fired a lot of talk in the past, so i can't help not asking why you turned it off by default now? Did anything changed in the specs?that header options seems to be removed now from options. does that mean when I normally mux audio and video files I dont have to change any setting, header compression will automatically be deactivated?

[Mosu]

Quoting from my ChangeLog:

2013-01-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: removal: The 'header removal compression' method is not turned on by default anymore. This affects the following track types: AC3, AVC/h.264, Dirac, DTS, MP3. The setting in mmg that turned it off by default has been removed.

[Simon88]

On the subject of compression, why is it that I get the following error when trying to compress "video" using "bz2" under the "Extra options"

Error: bzip2 compression failed. Result: 3

AVC/h.264 & Xvid was used for my test of various compressions, although I wouldn't expect ANY space savings for such already highly compressed videos... I was thinking of using it for a few short uncompressed avi files that was unnecessarily large, which was not at hand at the moment.

[Mosu]

That is an error that I cannot reproduce at the moment. Could you upload a sample file for which it does happen, please?

[nevcairiel]

Unrelated to your error, however note that bz2 is deprecated, and only zlib is officially part of the Matroska spec now. That means that a bunch of players may have issues with bz2 compressed streams.

[sneaker_ger]

Why not just remove them?

[Mosu]

From the specs? Because you don't just remove stuff from specs if they've been there for some time, you deprecate them. And in revision N you forbid them.

[sneaker_ger]

I mean the ability to compress using those schemes from mkvmerge.

[Mosu]

Ah. Yes, it will be removed one of these days.

[Simon88]

That is an error that I cannot reproduce at the moment. Could you upload a sample file for which it does happen, please?

Ah... I finally was able to consistently re-produce it... Apparently bz2 does not like ANY filename/path names which contain Chinese characters OR many brackets. zlib, lzo, blank, none are OK... only bz2 produces this error:

Error: bzip2 compression failed. Result: 3

If I upload a CJK filenamed file, I'm not sure if the UTF-8 filenames will be preserved.

Can you rename an MP4 (AVC) or AVI (XviD) to "一二三四.mp4" & "一二三四.avi" and test it out. In English it just means "1234.mp4" & "1234.avi"... Just copy & paste these 4 chars for the rename.

[Mosu]

Ah... I finally was able to consistently re-produce it... Apparently bz2 does not like ANY filename/path names...

Stop right there. Compression is completely internal. The compression code has no access to file names whatsoever.

But anyway, Sneaker_ger's right, I'll remove the support for BZ2 compression soon anyway, so I won't be fixing this.

[fakey]

Hi
http://i45.tinypic.com/vevlnt.png
The redbox here(Edit19 in control name) became dropdownstyle with recent updates.
In this way it's a bit cumbersome to paste a timecode in there because activating mmg window always makes the box select-all state.
Is there a way the dropdownstyle could apply only when we select split-by-size mode?

http://i46.tinypic.com/34476nn.png
dozens of items in ListBox1 -> maximize mmg window -> restore -> layout off

[Mosu]

Hi
http://i45.tinypic.com/vevlnt.png
The redbox here(Edit19 in control name) became dropdownstyle with recent updates.
In this way it's a bit cumbersome to paste a timecode in there because activating mmg window always makes the box select-all state.
Is there a way the dropdownstyle could apply only when we select split-by-size mode?

I won't spend a few hours coding this (no, it's not just a flag; I would have to hide that control and show a normal input one; then handle loading & saving of arguments, arg validation, build command lines, tooltips etc etc -- yes, this would amount to two or three hours) so you can save a second or two. Sorry. I'm open to patches, though.

http://i46.tinypic.com/34476nn.png
dozens of items in ListBox1 -> maximize mmg window -> restore -> layout off

Not my problem. The toolkit I use, wxWidgets, handles all layouting. So if it does something like that then it's a bug in wxWidgets that I will certainly not try to fix myself.

[Overdrive80]

Hi Mosu, I create mkv file with ordered chapters. I understand that chapters havent correlative tempos, but If I create subchapters is necesary to use global times.

I put example. Using this script, I get times of episode:

DGDecode_mpeg2source("E:\DBZ\DBZ1_22\127\Title_3.d2v", info=3)

ColorMatrix(hints=true, threads=0)

trim(2616,32431)++trim(34736,0)

# ^Episodio^ ^Avance^

If I choose times for subchapters by this script, will not create subchapters in position.

http://s6.postimage.org/sln0nrfy5/image.jpg (http://postimage.org/image/sln0nrfy5/)

However, If I use times of this script (without split):

DGDecode_mpeg2source("E:\DBZ\DBZ1_22\127\Title_3.d2v", info=3)

ColorMatrix(hints=true, threads=0)


mkvmerge create subchapters in position properly.

I dont understand that for subentries of chapter I need global times and for principal chapters relative times. It is correct??

[Mosu]

All chapter timecodes are absolute and not relative. No matter on which layer they're located.

[Overdrive80]

Then I dont understand that ocurr.

Metric of full episode without split is:


Opening: frames 0-2615 --> times 00:00.000-01:49.067
Episode: frames 2616-32431 --> times 01:49.109-22:32.643
First part episode: frames 2616-16047 --> times 01:49.109-11:09.294
Eyecatch: frames 16048-16339 --> times 11:09.335-11:21.472
Second part episode: frames 16340-32431 --> times 11:21.514-22:32.643

Ending: frames 32432-34735 --> times 22:32.685-24:08.739
Preview: frames 34736-35472 --> times 24:08.781-24:39.478


If I use times in bold, mkvmerge create subchapters properly.

Metric with split is (episode+preview):


Opening: frames 0-2615 --> times 00:00.000-01:49.067
Episode: frames 0-29815 --> times 00:00.000-20:43.534
First part episode: frames 0-13431--> times 00:00.000-09:20.185
Eyecatch: frames 13432-13723 --> times 09:20.226-09:32.363
Second part episode: frames 13724-32431 --> times 09:32.405-20:43.534
Ending: frames 0-2303 --> times 00:00.000-01:36.054
Preview: frames 29816-30552 --> times 20:43.576-21:14.273


If I use times no bold, mkvmerge create subchapters wrong.

Why?

Ordered Chapters Correct (https://dl.dropbox.com/u/19135067/ordered%20chapters_Correct.xml)

[Mosu]

I have no experience with prdered chapters, sorry.

[vdcrim]

I don't think that subchapters + ordered is a very common combination. It could also be the splitter's fault. Did you try adding your subchapters at the top level instead?

[Overdrive80]

I don't think that subchapters + ordered is a very common combination. It could also be the splitter's fault. Did you try adding your subchapters at the top level instead?

I could create it properly, my dude is: Why I have use different times? Its as if time chapters were relative times, and subchapters absolute times?

I think that to muxing generate times of playback adjust to times of chapters, and subchapters times arent adjust and for this reason is necessary provide absolute times.

[Mosu]

The chapter timecodes are only adjusted by mkvmerge if you use splitting as well. If you don't it writes the chapter timecodes to the output file as they were.

[yonta]

2013-02-03 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: Implemented support for reading MPLS
BluRay playlist files. All M2TS files referenced from an MPLS file
are processed. Chapter entries from that MPLS file are used as
well. Implements #765.

Good to have a great new feature and thank you for your effort. But, mmg doesn't accept MPLS files and I don't see MPLS in the mkvmerge's supported file types?

One more thing, does MPLS support include support for seamless branching Blu-ray?

[Mosu]

Good to have a great new feature and thank you for your effort. But, mmg doesn't accept MPLS files and I don't see MPLS in the mkvmerge's supported file types?

Hrmph, forgot to add it to the list. For the time being you can drag & drop MPLS files and you can change the file selector to "all files" in the "add file" dialog. I'll see that I get MPLS listed as their own type so you won't have to resort to workarounds.

One more thing, does MPLS support include support for seamless branching Blu-ray?

No idea. I only own two BluRay discs (due to me not being willing to shell out hundreds of bucks for high-end equipment when I have a Linux-based media PC right here...). For one the main MPLS file only lists a single M2TS file. For the other it's > 30 M2TS files. Both cases work just fine for me, but that's as far as I could test it.

Please also note that the error messages might be confusing. For some MPLS mkvmerge will claim not to support this file type. This usually means that the underlying M2TS file(s) don't contain enough video information for mkvmerge to recognize them properly. This often happens for stills or short clips usually used in menu background stuff.

[nautilus7]

Latest build seems to have problems with m2ts files.

Command line used:

"C:\Program Files (x86)\MKVToolNix\mkvmerge.exe" --output-charset UTF-8 --identify-for-mmg "D:\POLAR_BEAR\BDMV\STREAM\00001.m2ts"

Output:

Error: memory.cpp/safemalloc() called from file src/common/memory.h, line 203: malloc() returned nullptr for a size of 3956920320 bytes.

[Mosu]

Edit: I think I don't need that upload, I just thought of something...

[zeropc]

i encountered something very while demuxing a mkv file (created with mkvtoolnix 5.9.0) with eac3to

eac3to v3.24
command line: "C:\eac3to\eac3to.exe" "J:\movie.mkv" 1: "E:\movie.h264" 3: "E:\movie.sup" 2: "E:\movie.flac"
------------------------------------------------------------------------------
MKV, 1 video track, 1 audio track, 1 subtitle track, 1:39:53, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
"Main Program [AVC]"
2: FLAC, 2.0 channels, 1:39:53, 24 bits, 48kHz
"Main Audio [FLAC 2.0 Mono]"
3: Subtitle (PGS), "Subtitle [SDH]"
[v01] Extracting video track number 1...
[a02] Extracting audio track number 2...
[a02] Decoding FLAC...
[a02] Encoding FLAC with libFlac...
[v01] Creating file "E:\movie.h264"...
[a02] Creating file "E:\movie.flac"...
[s03] Extracting subtitle track number 3...
[s03] Creating file "E:\movie.sup"...
[v01] Video has a gap of 1 frames at playtime 0:01:25. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:28. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:31. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:33. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:36. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:39. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:42. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:45. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:48. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:51. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:54. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:57. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:00. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:03. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:05. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:09. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:11. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:15. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:18. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:20. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:23. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:26. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:29. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:32. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:35. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:38. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:41. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:44. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:47. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:50. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:52. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:55. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:59. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:02. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:05. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:07. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:10. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:13. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:16. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:19. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:22. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:25. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:28. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:31. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:34. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:37. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:40. <WARNING>
<snip>
[v01] Video has a gap of 1 frames at playtime 1:39:35. <WARNING>
[v01] Video has a gap of 1 frames at playtime 1:39:37. <WARNING>
[v01] Video has a gap of 1 frames at playtime 1:39:40. <WARNING>
[a02] The original audio track has a constant bit depth of 24 bits.
Video track 1 contains 143698 frames.
Subtitle track 3 contains 1 forced caption.
eac3to processing took 12 minutes, 12 seconds.
Done.



any idea what's causing this. i had no error message when muxing this to mkv and i don't have a similar problem with another file. when watching the movie, there are dropouts or other problems. i run the same demux with eac3to 3.27 just to be sure it's not a problem with eac3to 3.24.

[Mosu]

I suggest you ask the eac3to author directly or open a new thread for it. This is not a eac3to support thread. It's big enough as it is already.

[zeropc]

i was adding it in here, in case this was a problem with mkvtoolnix muxing and not a demuxing problem from eac3to

[Mosu]

Well, how should I know why eac3to outputs what it outputs? So please make sure to check strange messages in program A with the author of program A first. My time's already used up with stuff I'm 100% certain are related to MKVToolNix. Thanks.

[Mosu]

Latest build seems to have problems with m2ts files.

Should be fixed in builds 495 and higher (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/).

[nautilus7]

Yes, thanks.

[ImAhNoBoDy]

What are VobButtons [btn]? I saw this on the Supported file types in Mkvmerge. If there are any documentation on it, I'll like to read it. It just sounds interesting.

[Mosu]

That's something Steve Lhomme invented a while ago when he worked on menu support in Matroska. The idea was to export certain VobSub-like stuff from DVDs, put it into Matroska and have that working as buttons. I don't think there's any documentation anywhere, and I solely keep it for compatibility purposes.

[doomNoNine]

My VLC 2.0.0.4 have problems with files I created with MKVToolNix 6.0.0.0. The video plays well until I jump to another time (e.g. from 00:01:00 to 00:44:00). From that moment on the video stops and I have wait a very long time or I have to close and reopen VLC. If I jump a short time (e.g. from 00:01:00 to 00:02:00) VLC continues the video correctly after a short thinking time (maybe 500ms).
The video works well with other players like KMPlayer or MPC-HC.
The mkv parts were ripped with eac3to. The video format is h264/AVC, 1080p24, the audio format is DTS, 5.1 channels, 1509kbps, 48kHz

Is this a known issue? Or am I the only one with that problem? Any ideas what can causes this issue?


PS: many thanks for the great tool!

[Mosu]

Read several posts in this very thread, or just read this: https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590

[doomNoNine]

Thank you very much for your answer. That answers my question and also give me the solution :).

Please keep you work going on your awesome tool.

[Chumbo]

Do the new frame/field splitting features supposed to be frame accurate splitting? I ask because I just tried these on some junk I wanted to remove from the beginning and end of one of my files but am not getting frame accurate. So the i-frame at the beginning of the file is at frame 213 but when I split the file, the first file created has 252 frames. Does this sound right?

I also tried the "by parts" which worked but not correctly on the end of the file. The end of the file was split too soon, i.e., needed to include another 15,715 frames. The source file is an 50fps AVC progressive video.

[Mosu]

Do the new frame/field splitting features supposed to be frame accurate splitting?

Of course not. mkvmerge will still only split on key frame boundaries.

So the i-frame at the beginning of the file is at frame 213 but when I split the file, the first file created has 252 frames. Does this sound right?

Sounds like you're providing the wrong numbers.

1. Mux the file without splitting.
2. Run "mkvinfo -s" on the resulting file.
3. Count the line numbers for the video track.
4. Use the proper line number for splitting.

[Chumbo]

Of course not. mkvmerge will still only split on key frame boundaries.



Sounds like you're providing the wrong numbers.

1. Mux the file without splitting.
2. Run "mkvinfo -s" on the resulting file.
3. Count the line numbers for the video track.
4. Use the proper line number for splitting.
I got the numbers by loading the source in VideoReDo. I just changed its timecode display to frames. I guess the i-frame is NOT the same as the key frame that mkvmerge uses?

I used mkvinfo, out of curiosity, but it's not really helpful in that I can't really use it to figure out the cut spot without a visual cue. I'd still have to load the file into something like VRD or MPC-HC and note the time code and then look up the closest one in the generated output from mkvinfo.

BTW, is it possible to update mkvmerge to split on i-frames? If it is, it would be tremendous as it would give us more accurate cutting/splitting.

Here's some of the output from mkvinfo. Note that VRD shows the cut point I want is at time code 00:00:04.13 which is an i-frame. I have a couple question regarding the output below. The closest time is the line in red below but that doesn't show as an i-frame as VRD showed. How do I determine what is a key frame? Why do some lines below display out of sequence in that the time code on a line may be after the next line (see the time code of the line above the red line which is larger).Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: Main @L4.0),
mkvmerge/mkvextract track ID: 0,
default duration: 20.000ms (50.000 frames/fields per second for a video track),
language: und, pixel width: 1280, pixel height: 720, display width: 1280, display height: 720
Track 2: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 1,
default duration: 32.000ms (31.250 frames/fields per second for a video track),
sampling freq: 48000, channels: 2
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0xa600c17d
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0xfa3707b5
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0x7b86e8ec
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0x0efb0179
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0xa7f8e99d
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0xa4e30b41
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0xe478f7ce
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0x9425ff1e
I frame, track 1, timecode 50 (00:00:00.050), duration 17.000, size 26203, adler 0x6d83acb8
P frame, track 1, timecode 117 (00:00:00.117), duration 17.000, size 8561, adler 0x0896c834
P frame, track 1, timecode 67 (00:00:00.067), duration 17.000, size 6769, adler 0x11713793
P frame, track 1, timecode 83 (00:00:00.083), duration 17.000, size 5196, adler 0x79701d13
P frame, track 1, timecode 100 (00:00:00.100), duration 17.000, size 9341, adler 0x99401e5a
P frame, track 1, timecode 183 (00:00:00.183), duration 17.000, size 24597, adler 0xe1b3edfb
P frame, track 1, timecode 133 (00:00:00.133), duration 17.000, size 8295, adler 0xff7bf89b
P frame, track 1, timecode 150 (00:00:00.150), duration 17.000, size 5846, adler 0x05424def
P frame, track 1, timecode 167 (00:00:00.167), duration 17.000, size 8942, adler 0x780c5d87
P frame, track 1, timecode 250 (00:00:00.250), duration 17.000, size 21551, adler 0x281023d8
P frame, track 1, timecode 200 (00:00:00.200), duration 17.000, size 8390, adler 0x28452b21
P frame, track 1, timecode 217 (00:00:00.217), duration 17.000, size 6116, adler 0x2ccb050b
P frame, track 1, timecode 233 (00:00:00.233), duration 17.000, size 11348, adler 0x61f22e32
. . .
P frame, track 1, timecode 4050 (00:00:04.050), duration 17.000, size 24013, adler 0x01178a0d
P frame, track 1, timecode 4000 (00:00:04.000), duration 17.000, size 13182, adler 0x2e919ed3
P frame, track 1, timecode 4017 (00:00:04.017), duration 17.000, size 7637, adler 0x64bed522
P frame, track 1, timecode 4033 (00:00:04.033), duration 17.000, size 12911, adler 0x663e07d6
P frame, track 1, timecode 4117 (00:00:04.117), duration 17.000, size 14352, adler 0xf15906a7
P frame, track 1, timecode 4067 (00:00:04.067), duration 17.000, size 12235, adler 0x4032ec87
P frame, track 1, timecode 4083 (00:00:04.083), duration 17.000, size 9814, adler 0xf8cbe7a1
P frame, track 1, timecode 4100 (00:00:04.100), duration 17.000, size 7123, adler 0xe27ae2f9
P frame, track 1, timecode 4183 (00:00:04.183), duration 17.000, size 8621, adler 0x613cc166
P frame, track 1, timecode 4133 (00:00:04.133), duration 17.000, size 3868, adler 0x42adaa57
P frame, track 1, timecode 4150 (00:00:04.150), duration 17.000, size 5307, adler 0xd7fc7d9c
P frame, track 1, timecode 4167 (00:00:04.167), duration 17.000, size 5644, adler 0x47e7f2d0
P frame, track 1, timecode 4250 (00:00:04.250), size 8404, adler 0xe3e049d7

[Overdrive80]

Hi Mosu, the option "adjust timecodes" of "Chapter editor" doesnt save the changes.

[Mosu]

Hi Mosu, the option "adjust timecodes" of "Chapter editor" doesnt save the changes.

If you mean that the same value you've entered once is not pre-selected the next time you use that function: of course not. The moment you use that option the offset you've entered is added to all chapter timecodes. It would be highly confusing to the user if, after having applied an offset of e.g. 2min, the dialog box would be pre-selected with 2min yet again. This would lead the user to the assumption that it simply stays the same if he hits enter right now, while in truth it would apply another 2min of offset.

If you mean that the offset you enter is not actually added to the start/end timecodes: I cannot reproduce that.

For me this is working as intended.

[Mosu]

I got the numbers by loading the source in VideoReDo. I just changed its timecode display to frames. I guess the i-frame is NOT the same as the key frame that mkvmerge uses?

How would I know? I've never used VideoReDo, nor have I written it myself. Quoting mkvmerge's documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split):

Note:

The numbers given with this argument are interpreted based on the number of Matroska(tm) blocks that are output. A single Matroska(tm) block contains either a full frame (for progressive content) or a single field (for interlaced content). mkvmerge does not distinguish between those two and simply counts the number of blocks. For example: If one wanted to split after the 25th full frame with interlaced content one would have to use 50 (two fields per full frame) as the split point.

BTW, is it possible to update mkvmerge to split on i-frames? If it is, it would be tremendous as it would give us more accurate cutting/splitting.

I don't really understand what you want here. Being able to enter the n-th I frame (e.g. "5" would split on the fifth key frame encountered)? Anyway, the answer is almost certainly "no interest in implementing that, sorry".

Here's some of the output from mkvinfo. Note that VRD shows the cut point I want is at time code 00:00:04.13 which is an i-frame.

Not according to how it is stored in Matroska. I'm not saying that it isn't a key frame, I'm just saying that it isn't marked as one. That's the fault of whatever software didn't mark it as a key frame, and mkvmerge cannot do anything about it.

How do I determine what is a key frame?

mkvmerge relies on the information on the container level for frame type distinction. The frames it can split on are the ones that mkvinfo reports as "I frame ....".

I stress that again: mkvmerge is not in the business of fixing the container information if a previous program gets that wrong! So if the source container said "the video frame at 00:00:04.whatever is a P frame, not a key frame" then mkvmerge will believe it.

Why do some lines below display out of sequence

B frames not marked as B frames. Read up on presentation timecodes vs. decode timecodes somewhere if you don't know what that means.

[Chumbo]

How would I know? I've never used VideoReDo, nor have I written it myself...
It was really a rhetorical question meaning shouldn't there be consistency in the standard in how the apps read and parse these streams? So what VRD would show as an i-frame would still be an i-frame in the stream when mkvmerge works with it or whatever software.

I don't know enough about this stuff that's deeper than below the surface which is why I'm asking some of these questions. From my perspective, it seems that regardless of the container, the elementary stream would contain the same info.

Yeah, I'll definitely have to read up on more than just the B frames stuff.

In regards to using i-frames rather than key frames. I noticed that key frames can really be problematic when splitting a file because they can have long intervals between them, e.g., 10 seconds between each key frame. So you can never get a clean split. Again, not knowing much about this, I know that other software splits on i-frames and is more accurate for splitting. So that's all I was asking. Maybe that's not doable in mkvmerge and that's fine, but I thought I'd ask.

[Mosu]

From the point of view of mkvmerge/Matroska key frames and I frames are the same thing. If your source signals wrong frame type flags on the container level then that is not mkvmerge's problem, sorry.

[magic75]

I just upgraded from 5.1.0 to 6.0.0 (Linux) and I am having problems with the --aspect-ratio option.

excerpts from mediainfo

Writing application : mkvmerge v5.1.0 ('And so it goes') built on Feb 1 2012 11:31:23
Writing library : libebml v1.2.2 + libmatroska v1.3.0
Width : 700 pixels
Height : 420 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 1.667

Writing application : mkvmerge v6.0.0 ('Coming Up For Air') built on Jan 20 2013 10:28:01
Writing library : libebml v1.3.0 + libmatroska v1.4.0
Width : 700 pixels
Height : 420 pixels
Display aspect ratio : 1.667

The files created with 5.1.0 are stretched to 16/9 when played in mplayer, but the files created with 6.0.0 are played as is at 700x420.

[sneaker_ger]

And this is with the same source file?