MKVToolNix v24.0.0 released

[gonwk]

Use a different player/settings. Some video players re-size the screen by squishing the image by about 32-40 pixels and displaying the Subs below the video, try overlaying the Subs on-top of video and re-calculate the container aspect ratio. Also, resetting the preferences in latest VLC should fix this issue.

Hi Simon88,

Thanks for taking the time and answering.

Simon, when I am comparing the 2 MKV files, I am not even enabling the playback of the Subtitles in VLC so it would not distract my viewing of the Video and comparing the pictures.

Simon, are you saying that if I use MPC-HC the pictures of the Original MKV vs my new re-muxed one might look identical!?!?

Appreciate the help again.

G!:)

[gonwk]

Hi Mosu,

I download and use your "Portable" version of MKVToolNix.

I don't believe the Tool is "really" Portable ... and why do I say this, because I have versions 5.8.0 and 6.2.0 on my laptop in their Separate folders and have made separate shortcuts to both of their mmg's BUT when I click on 6.2.0 MKVToolNix shortcut ... the program tells me that is pointing to the MKVMerge in my 5.8.0 folder.

Q1: If the program is in fact Portable and Self-contained in it's own folder ... how is it that it tells me there is another version floating on my PC?

Q2: How can I have 2 different versions of your program, portable ones, on my PC that I can switch back & forth on demand? Without going thru redirecting the Pathway each and every time?

Thanks,

G! :thanks:

[Simon88]

Hi Simon88,

Thanks for taking the time and answering.

Simon, when I am comparing the 2 MKV files, I am not even enabling the playback of the Subtitles in VLC so it would not distract my viewing of the Video and comparing the pictures.

Simon, are you saying that if I use MPC-HC the pictures of the Original MKV vs my new re-muxed one might look identical!?!?

Appreciate the help again.

G!:)
I'm assuming the Subs are SoftSubs and NOT hard coded. Using MKVToolNix v6.2.0, the Default track flag & Forced track flag should allow your video player to properly read the container settings properly of whether to display or not display Subs by default. Set a correction value for the MKV aspect value, taking to account the extra pixels used by borders/subtitles, etc. Use the following formula: SAR*PAR=DAR to set proper aspect ratio.

For new users playing MKVs, K-Lite Mega Pack is quite good... it is bundled w/ latest MPC-HC...

[Simon88]

Hi Mosu,

I download and use your "Portable" version of MKVToolNix.

I don't believe the Tool is "really" Portable ... and why do I say this, because I have versions 5.8.0 and 6.2.0 on my laptop in their Separate folders and have made separate shortcuts to both of their mmg's BUT when I click on 6.2.0 MKVToolNix shortcut ... the program tells me that is pointing to the MKVMerge in my 5.8.0 folder.

Q1: If the program is in fact Portable and Self-contained in it's own folder ... how is it that it tells me there is another version floating on my PC?

Q2: How can I have 2 different versions of your program, portable ones, on my PC that I can switch back & forth on demand? Without going thru redirecting the Pathway each and every time?

Thanks,

G! :thanks:

I do it all the time... You need to create the shortcut initially within their respective directory and give the shortcut a UNIQUE name. Then move the shortcut away, eg. to the desktop.

[Mosu]

I don't believe the Tool is "really" Portable...

True, as they still store their settings in the registry. Patches to fix this are welcome, but I will most likely not spend time on this myself.

Q2: How can I have 2 different versions of your program, portable ones, on my PC that I can switch back & forth on demand? Without going thru redirecting the Pathway each and every time?

Remove all MKVToolNix settings from the registry and don't set the path to mkvmerge.exe yourself. That way mmg.exe will look for mkvmerge.exe in the same folder the currently running mmg.exe is located in.

[gonwk]

Hi Mosu & Simon88,

Appreciate your replies and feedback.

@ Mosu, Thanks for your GREAT Program.

Mosu, between Your suggestion Not to set the Path manually & Simon's suggestion to create the Shortcut within the portable folder ... the Solution worked like a Charm, problem Solved.

So, no need for Reg Clean Up, and since the program was never installed ... I don't know if something like "Revo Uninstaller" would work. Goooogling said may be CCleaner would do it ... but some recommended against messing with the Registry.

@ Simon88, dude YOU are Smarter than Average Bear ... your Solution worked like a Charm. Thanks my man!

Thanks again guys!

G! :thanks:

[Keiyakusha]

Hi Mosu. I want to clarify something...
Let's say I created mkv with 2 editions. 1st edition just plays the whole file. Second - replaces some part in the middle of the file with external segment. Splitter that supports ordered chapters/linked segments/editions plays it fine.
Now if I'll take these 2 mkv files and binary-append them, virtual timeline will work as before. Splitter without ordered chapters support just ignores appended segment.
Question: is this a right thing to do? If not, is there a proper way of creating multi-segment mkv? If I'll simply append streams within one mkv, splitter that does not supports ordered chapters will be outputting main file + additional segment. I want this extra segment to be ignored.

[Mosu]

I cannot really help you with such question as I've never played with ordered XYZ myself.

[Keiyakusha]

I cannot really help you with such question as I've never played with ordered XYZ myself.

Well, ok. How about this.
If I binary append 2 mkv files, resulting file is a valid file from a perspective of the mkv spec, or hack that only by chance works the way I want it to?

mediainfo seems to be aware of such thing. it displays something like
Format : Matroska / Matroska
Format version : Version 4 / Version 2 / Version 4 / Version 2

[Mosu]

More or less a hack because the EBML header is repeated in the middle. However, I'm not sure whether or not we really allow this intentionally. Sorry. You should ask on matroska-users, maybe Steve Lhomme has some more insight.

[Keiyakusha]

Hi Mosu. I have another question about Chapter editor in mkvtoolnix.
It allows to create chapters without specifying end time, but isn't end time is mandatory? At least ordered chapters/linked segments don't work correctly without it...

Also lets say I have 2 chapters:
First [00:00.000; und]
Second [19:06.545; und] <- starts at I-frame, lets say... #61299
In this situation what time should I specify for end of the 1st chapter? is it also time of the frame #61299 (19:06.545)? Or it should be time of the frame #61298 (19:06.529)?
What abut end of the 2nd chapter? Should it be timecode of the last frame or last+1 frame?

[sneaker_ger]

but isn't end time is mandatory?

It is not.

At least ordered chapters/linked segments don't work correctly without it...

Maybe since it may be ambiguous as you can leave out parts in ordered chapters? I don't know if this is a quirk of the splitters or something the spec demands, though.

Also lets say I have 2 chapters:
First [00:00.000; und]
Second [19:06.545; und] <- starts at I-frame, lets say... #61299
In this situation what time should I specify for end of the 1st chapter? is it also time of the frame #61299 (19:06.545)?

Yes.

What abut end of the 2nd chapter? Should it be timecode of the last frame or last+1 frame?

I guess so, but last frame + 1 timecode is a topic on its own concerning mkv. Maybe Mosu can say more.

[Mosu]

Hi Mosu. I have another question about Chapter editor in mkvtoolnix.
It allows to create chapters without specifying end time, but isn't end time is mandatory?

No, in general it isn't. If there is no end time then the implicit end time is the start time of the next chapter on the same nesting layer. If the chapter in quesiton is the last one on that layer then the implicit end time is the end time of the layer above it (which could be more chapters or the segment iself).

Why ordered chapters don't work without an explicit end time I cannot say.

[hubblec4]

Why ordered chapters don't work without an explicit end time I cannot say.

the explicit end time is necessary to generate the new virtual timeline exactly.

[Selur]

Got a problem remuxing a stream, first I extract the streams using:
mkvextract tracks "H:\Output\avc_1440x1080i.mkv" 1:"H:\Output\iId_12_aid_0_DELAY_-80ms_13_19_13_3010_39.ac3"
and
mkvextract tracks "H:\Output\avc_1440x1080i.mkv" 0:"H:\Output\13_19_13_3010_40.264"
then I remux the stream using:
mkvmerge --ui-language en -o "H:\Output\test50i.mkv" -d 0 --default-track 0:yes --default-duration 0:5000000/100000i --aspect-ratio-factor 0:1.333 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Output\13_19_13_3010_40.264" --default-track 0:yes --sync 0:-80 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "H:\Output\iId_12_aid_0_DELAY_-80ms_13_19_13_3010_39.ac3"
since I was unsure wheter I should use 50i or 25i for muxing I also tried:
mkvmerge --ui-language en -o "H:\Output\test25i.mkv" -d 0 --default-track 0:yes --default-duration 0:5000000/100000i --aspect-ratio-factor 0:1.333 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Output\13_19_13_3010_40.264" --default-track 0:yes --sync 0:-80 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "H:\Output\iId_12_aid_0_DELAY_-80ms_13_19_13_3010_39.ac3"
Problem is: both remuxes are async.

-> Does anyone know where the problem is?
(Uploaded the the avc_1440x1080i, test50i, the test25i clip and the extracted raw files to: http://www.embedupload.com/?d=8UU3UQQYYN)

Is this me missing something obvious, me doing something wrong, a bug during playback or a bug in mkvmerge?

[Mosu]

You're demuxing from a container that has timecodes (Matroska) to two containers that don't (AC3 and raw h.264 elementary streams). That is bound to cause trouble. Don't. Just re-mux directly from Matroska to Matroska.

[Selur]

I assumed I would only need the time codes if they indicate vfr.
since:
mkvextract timecodes_v2 "H:\Output\avc_1440x1080i.mkv" 0:"H:\Output\timeCode_14_58_15_554.txt"
produces an output file which has a constant difference of 20 (<> matching 50fps), I assumed the time codes weren't necessary,...
(uploaded the time codes to: http://pastebin.com/DcgbsRyy)

Also extracting the time codes and adding them to the video stream, fixes the problem, question is:

Why do I need them? (shouldn't either '--default-duration 0:5000000/100000i' or '--default-duration 0:2500000/100000i' tell mkvmerge to create exactly the same time codes?


Cu Selur

[Mosu]

Maybe it's a bug, maybe not. Not sure, don't have time to investigate for the time being.

[Selur]

okay, no problem will test a bit more :)
-> using "--default-duration 0:2500000/100000p" fixes the issue, so seems like there's something wrong with the interpretation of the '--default-duration' values

[Mosu]

--default duration 0:25p and --default-duration 0:50i end up being the same internally. There's no distinction. The provided value (25) is multiplied by 2 if it's p and 1 if it's i, so in both cases the reciprocal comes out as 1s/50 = 20ms per field.

I'm pretty sure you changed something else, too.

[Selur]

I'm pretty sure I didn't,...

I checked:
1. downloaded and extracted http://www.embedupload.com/?d=8UU3UQQYYN (to make sure I really use the same files)
2. deleted test50i.mkv and test25i.mkv
3. called:
mkvmerge --ui-language en -o "H:\Output\test50i.mkv" -d 0 --default-track 0:yes --default-duration 0:5000000/100000i --aspect-ratio-factor 0:1.333 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Output\13_19_13_3010_40.264" --default-track 0:yes --sync 0:-80 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "H:\Output\iId_12_aid_0_DELAY_-80ms_13_19_13_3010_39.ac3"
then
mkvmerge --ui-language en -o "H:\Output\test25i.mkv" -d 0 --default-track 0:yes --default-duration 0:2500000/100000i --aspect-ratio-factor 0:1.333 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Output\13_19_13_3010_40.264" --default-track 0:yes --sync 0:-80 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "H:\Output\iId_12_aid_0_DELAY_-80ms_13_19_13_3010_39.ac3"
then
mkvmerge --ui-language en -o "H:\Output\test25p.mkv" -d 0 --default-track 0:yes --default-duration 0:2500000/100000p --aspect-ratio-factor 0:1.333 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "H:\Output\13_19_13_3010_40.264" --default-track 0:yes --sync 0:-80 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "H:\Output\iId_12_aid_0_DELAY_-80ms_13_19_13_3010_39.ac3"

-> only the test25p file plays properly.
As a side note: notice that the content is not mbaff, but paff interlaced.

Cu Selur

[Mosu]

Your very first case has one 0 too few. 0:5000000/100000i = 0:5/1i = 5 fields per second? :)

[Selur]

Sorry (well spotted!), but still there is something wrong, since the last three calls are all fine and still the only file that plays properly is the 25p one.

[Mosu]

I don't know how paff interlacing differs from mbaff. But from what you're sayin it seems thon the frame /field flag.

at one Matroska block contains one full frame. In such a case a duration of 40ms per Matroska block is appropriate. Remember : you're setting the default duration for a single Matroska block. You're not setting a frame rate. Mkvmerge does not think in frames. It thinks in single blocks. The h264 code (as well as other similar places) calculate a block's duration by multiplying the default duration by either 1 or
2 dependingThat’s why the nomenclature "50i" or "25p" doesn't always make sense.

However, that's how mkvmerge works internally. Changing that to work on a frame basis amounts to rewriting the whole application. Not something I'm willing to consider.

[Selur]

Remember : you're setting the default duration for a single Matroska block. You're not setting a frame rate.
I always forget that. :)

However, that's how mkvmerge works internally. Changing that to work on a frame basis amounts to rewriting the whole application. Not something I'm willing to consider.
No, real problem now that I know how to set the flags for paff content I can remux my files. :)

[Atak_Snajpera]

I'm trying to combine 4 flacs (the same frequency , bitdepth , channels ) using append feature

http://s23.postimg.org/i2f8yt2mz/Untitled_2.png

http://s1.postimg.org/rjuz8m8pb/Untitled_3.png

Everything seems to be ok after remuxing. Duration is correct and plays ok in media player.

General
Complete name : E:\combined_flacs.mka
Format : Matroska
Format version : Version 4 / Version 2
File size : 1.35 GiB
Duration : 2h 41mn
Overall bit rate mode : Variable
Overall bit rate : 1 192 Kbps
Encoded date : UTC 2013-06-14 12:53:02
Writing application : mkvmerge v6.2.0 ('Promised Land') built on Apr 28 2013 12:22:01
Writing library : libebml v1.3.0 + libmatroska v1.4.0

Audio
ID : 1
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 2h 41mn
Bit rate mode : Variable
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Writing library : libFLAC 1.3.0 (UTC 2013-05-26)
Default : Yes
Forced : No


However after demuxing with mkvextract new flac file has incorrect duration despite correct file size. All media players see only first 40 min (duration of first chunk)

General
Complete name : C:\temp\0_audio_Undetermined.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 1.34 GiB
Duration : 40mn 25s
Overall bit rate mode : Variable
Overall bit rate : 4 760 Kbps

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 40mn 25s
Bit rate mode : Variable
Bit rate : 4 706 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 1.33 GiB (99%)
Writing library : libFLAC 1.3.0 (UTC 2013-05-26)



I've even tried demuxing .mka with ffmpeg and still no luck.
ffmpeg throws out bunch of errors and final file again has correct size but duration is wrong (see above mediainfo report)

http://s23.postimg.org/5khje24nv/Untitled_1.png

[Mosu]

I'm trying to combine 4 flacs (the same frequency , bitdepth , channels ) using append feature

Yeah that won't work correctly as you noticed. FLAC streams start with a metadata block (http://flac.sourceforge.net/format.html#metadata_block_streaminfo). This block is required for playback, that's why mkvmerge keeps them.

The problem is twofold: 1. all of the four files contain metadata blocks and 2. each metadata block contains the number of samples in this stream. mkvmerge keeps all metadata blocks (which is not really correct), and it doesn't update the very first one (which isn't correct either).

So when you extract the single track back into a FLAC file it starts with the original metadata block of the first of the four original files. It still contains the number of samples appropriate for that first file, not the sum of all samples of all the files. Hence MediaInfo reporting the duration it is reporting.

I will most likely never fix that. You're free to open a bug report (https://trac.bunkus.org) for it, of course; that way there's at least a chance I might get around to it one day.

[Atak_Snajpera]

S**T! I was hoping to find a workaround for joining flacs without re-encoding process. It turns out that after all those years there is no tool which could merge flacs without lengthy re-encoding. You can split/join lossy OGG Vorbis losslessly but you can not do the same with plain lossless format! :(

[Mosu]

As far as I know there's nothing really preventing appending two FLAC files if their basic parameters match (sample rate, number of channels). Of course a tool that can do that will have to adjust the metadata (at least the STREAMINFO and SEEKTABLE blocks, but it should also deal gracefully with VORBIS_COMMENTS and PICTURE blocks). However, I've never done that myself and cannot give you pointers to tools that manage to do it.

[SeeMoreDigital]

Hi Atak,

I actually tried doing the same as you a few months ago, with no success...

In the end I had to re-encode using CUETools 2.1.4 which performed the task very quickly. So quickly in fact that I'm not sure if it did actually re-encode them. :scared:

[Skylinestar]

My CPU processor is Intel Core2Duo. Will I get significant improvement (less time) in demuxing and muxing MKV files if I were to upgrade to Intel Core i5 cpu?
I don't encode/convert video files. I just add on srt subs and remux the mkv.

[nevcairiel]

Muxing is mostly limited to IO speed, i don't think a faster CPU is going to help you much.

[Mosu]

What nevcairiel said. mkvmerge is I/O bound in almost all cases. Where it isn't limited by hard drive I/O speed it is limited by memory I/O speed.

[smok3]

S**T! I was hoping to find a workaround for joining flacs without re-encoding process. It turns out that after all those years there is no tool which could merge flacs without lengthy re-encoding. You can split/join lossy OGG Vorbis losslessly but you can not do the same with plain lossless format! :(

How is recoding flac lengthy in 2013 (just wondering), it should be a matter of seconds?

[Chetwood]

mkvmerge is I/O bound in almost all cases.
Mmh, recently it felt like an old bug returned you had fixed some while ago cause muxing took 10+ min longer than simlpy copying over the file.

[Snowknight26]

VC-1 muxing takes considerably longer than other formats.

[Atak_Snajpera]

How is recoding flac lengthy in 2013 (just wondering), it should be a matter of seconds?

When I encode 2h - 3h 6 channel movie soundtrack encoding process using plain FLAC encoder on my Q6600@3Ghz can take even 10 minutes. Simple remuxing would take less than 30 seconds.
FLAC CL is obviously faster but it does not support wave64 and multiple input files (joining on fly).

[Mosu]

Hey,

I've released MKVToolNix 6.3.0. It fixes a couple of minor issues and contains only two small enhancements: saving the window positions and mmg being truly portable now (if it's not installed via the installer).

For package maintainers: nothing's changed compared to MKVToolNix 6.2.0.

You can download the source code (http://www.bunkus.org/videotools/mkvtoolnix/source.html) or one of the binaries (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html).

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

2013-06-27 Moritz Bunkus <moritz@bunkus.org>
* Released v6.3.0.
* mkvmerge: bug fix: When appending unframed AVC/h.264 tracks and setting the default duration the second and all following source parts will use the same default duration as set for the first part. Fixes #889 (https://www.bunkus.org/trac/ticket/889).
* all: enhancement (Windows only): mmg will store its settings in a file "mkvtoolnix.ini" in the same folder mmg.exe is located in if MKVToolNix hasn't been installed via its installer. If it has been installed then the settings are stored in the Windows registry. This way MKVToolNix is truly portable.
* mmg: new feature: mmg's windows and dialogs will remember and restore their positions and sizes. Implements #878 (https://www.bunkus.org/trac/ticket/878).

2013-06-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: AVC/h.264 output module: fixed writing the wrong values if --fix-bitstream-timing-information is used. Fixes #888 (https://www.bunkus.org/trac/ticket/888).

2013-06-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: FLV reader: Implemented deriving the video dimensions for FLV1 type tracks from the frame content if they're not given within a script tag. Fixes #880 (https://www.bunkus.org/trac/ticket/880).
* mkvmerge: bug fix: Fixed handling MPEG transport streams with broken PES packet streams. Fixes #879 (https://www.bunkus.org/trac/ticket/879) and #887 (https://www.bunkus.org/trac/ticket/887).
* mkvextract: bug fix: mkvextract writes the correct value for the "block alignment" value in the header of WAV files (mostly affects mono PCM audio tracks). Fixes #883 (https://www.bunkus.org/trac/ticket/883).

2013-05-26 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: added a Portuguese translation of the programs by Ricardo Perdigão (see AUTHORS).

Have fun.

[Selur]

Thanks!! :)

[filler56789]

* all: enhancement (Windows only): mmg will store its settings in a file "mkvtoolnix.ini" in the same folder mmg.exe is located in if MKVToolNix hasn't been installed via its installer. If it has been installed then the settings are stored in the Windows registry. This way MKVToolNix is truly portable.

:goodpost:

:thanks: :thanks: :thanks:

[Keiyakusha]

Hi Mosu. I have a problem with windows installer.
For some reason after starting mmg it only appears after 10-15 seconds and it appears behind the active window...
Also fonts in some parts of the gui changed to something ugly...
Edit: basically all text that is "gray", inactive now uses bigger and uglier font (no cleartype support?)
Edit2: also I am talking about English version of the gui and I'm on Japanese locale. Japanese translation never was really beautiful to begin with.
File->Options takes ages to appear too. But some other dialogs, like header editor, are fine.

[Mosu]

I build against a new version of wxWidgets (the current series, 2.9.x). Unfortunately it's a lot slower than the old one, but that's something you'll have to live with for the time being, I'm afraid. The current series is going to be the new stable series 3.0.x soon enough, and I'm not willing to stay on an old series (2.8.x) indefinitely.

[Mosu]

Note that the current 6.3.0 Windows builds were done against a slightly out-of-date version of wxWidgets 2.9.x. It also contains a bug that manifests when you drag & drop a file to the "attachments" tab causing mmg to show an error message and quit/crash. I've re-built against the latest 2.9.4 which works regarding the drag & drop issue, but I haven't uploaded it yet. Instead I will try to build another version against the latest from the 2.8 series, 2.8.12, and see if that works better.

In any way expect new Windows builds soon. They'll be identical to the 6.3.0 release but built against a different wxWidgets library version as said above -- meaning they'll also use 6.3.0 and their version number, likely postfixed with "-1" in the installer/portable archive file, but not in the programs themselves.

[Mosu]

The new build against wxWidgets 2.8.12 is available now (http://www.downloadbestsoft.com/MKVToolNix.html) as v6.3.0-1. Drag & drop works well with it as far as I can tell. I'll keep using that version for the time being.

[Keiyakusha]

Thanks Mosu, this solved the issues for me.

[hubblec4]

hi mosu

why is the childelement "<ChapProcess>" not supported?

Error: The XML chapter file 'c:\test.xml' contains an error: <ChapProcess> is not a valid child element of <ChapterAtom> at position 590.

[Mosu]

That element is called <ChapterProcess> in mmg's XML dialect. Here's the DTD (https://github.com/mbunkus/mkvtoolnix/blob/master/examples/matroskachapters.dtd) for the XML files listing all know element names.

[Overdrive80]

Hi Mosu, when you refer to "unframed" that meaning it. Excuse my ignorance. T_T

[Mosu]

AVC/h.264 video bit streams consist of NALUs. Those NALUs can either be separated by certain start codes or they can be prefixed with the NALU's length. Which it is depends on what container they're stored in (see e.g. this description (http://msdn.microsoft.com/en-us/library/windows/desktop/dd757808(v=vs.85).aspx)); e.g. raw AVC/h.264 elementary bit streams use start codes while length fields are used when they're stored inside MP4 or Matroska.

mkvmerge has different output modules for those two. "Framed" refers to the output module that accepts tracks that already contain those length fields. For these each memory slice that's handed over to the output module contains a full field or frame (depending on interlacing, of course), meaning those memory slices don't have to be post-processed anymore. The "unframed" output module accepts bits treams that use start codes. For those each memory slice can contain pretty much anything: less than a single frame, exactly one frame or even multiple frames at once. mkvmerge has to find those start codes itself and determine the length fields to add instead.

[hubblec4]

That element is called <ChapterProcess> in mmg's XML dialect. Here's the DTD (https://github.com/mbunkus/mkvtoolnix/blob/master/examples/matroskachapters.dtd) for the XML files listing all know element names.

thx,
but 4 childelements of the segmentinfo are missing.

ChapterTranslate 2 [69][24] - * - - m * * * * A tuple of corresponding ID used by chapter codecs to represent this segment.
ChapterTranslateEditionUID 3 [69][FC] - * - - u * * * * Specify an edition UID on which this correspondance applies. When not specified, it means for all editions found in the segment.
ChapterTranslateCodec 3 [69][BF] * - - - u * * * * The chapter codec using this ID (0: Matroska Script, 1: DVD-menu).
ChapterTranslateID 3 [69][A5] * - - - b * * * * The binary value used to represent this segment in the chapter codec data. The format depends on the ChapProcessCodecID used.


could you add this elements?