MKVToolNix v24.0.0 released

[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 :)