MKVToolNix v24.0.0 released

[Sparktank]

if you really want to try I can go into more detail.

+1 on seeing a guide on this. I'd archive it for future references.

[stax76]

Technically it would be possible, of course, but I cannot simply change the output. There are way too many tools out there that parse mkvinfo's output somehow, and modifying the numbers presented would provide ample opportunity for breakage.

In my case I started to parse mkvinfo and mp4box output with regex and this was how it worked many years. Just recently started over from scratch using MediaInfo exclusively with great success.

[stax76]

@Mosu

I wonder if I could automate mkvmerge to cut various audio formats, it would be no problem creating a video stream with very little data using avisynth's blankclip and virtualdub, I'm in particularly interested in aac and dts.

[sneaker_ger]

It cuts audio just fine. Any specific problems you ran into?

[stax76]

I thought I rather ask about potential problems before I write 2-3 hours code.

edit: I created a "fake" avi file with avisynth blankclip and ffmpeg, first try with DTS-MA worked which is awesome, mkvmerge rocks!

[Dogway]

Since version 6.7.0 or so it is specially slow, almost double slow... I waited for a fix since 7.1.0 was the version I was testing, downloaded 7.5.0 and it's still slow as hell.

[stax76]

@mosu

After many tests with many different formats and no issues found I changed StaxRip to use mkvmerge as default audio cutter for all audio formats, it's great mkvmerge has such features and everything works reliable.

TS DVB muxing caused a sync issue in my last test, Haali's muxer didn't cause the issue. What I did is first remux ts to mkv and then use StaxRip's cut feature (that now cuts with mkvmerge by default) to encode a short dialog. What also helped is to fix the ts file with TS-Doctor prior mkvmerge muxing. I'll run some more test shortly, maybe it's a known problem.

[hello_hello]

I'm a bit late to the party but.....

Thanks, I think this essential limitation should make it into the tool tip because right now the GUI makes it look like you could split at any desired time stamp.

If you open a video with MPC-HC and use the Shift key in combination with the left and right arrows on your keyboard, it'll jump between keyframes. The Navigate/GoTo menu will tell you exact frame numbers if you need it.

To do it manually, you have to find the right times, split it into the video before the split, the video after, and the segment itself, re-encode each half of the segment, and then merge them back together. That's what a smart copy editor is supposed to do for you. It's some really annoying manual labor, I've done it a few times, and if you really want to try I can go into more detail.

Pretty please!
I can do the splitting and re-encoding myself, but finding matching encoder settings to avoid the "codec private data doesn't match" errors, that's the part I'd be keen to understand.

Every so often I would like to re-encode just a section of a movie to hardcode some subtitles I didn't know were needed, or I forgot, or to fix some banding I didn't notice etc, and almost every time I end up re-encoding the whole thing because I can't get the bits to join. I know there's --stitchable and it works when I split encodes, but if it wasn't used when the video was originally encoded or if those encoder settings aren't known there must be some serious black magic required. :)

[Thunderbolt8]

Im curious how splitting files works. I try to split a part of a movie (23.976fps, mkv blu-ray remux, video stream only) from I-frame to I-frame, but I cannot get the end split point right. tried with with split after duration and split based on frame numbers. the end point is always a few frames off, like some frames short or too many. why is that?

e.g. I want to have a piece of 26 frames, the first and last frame are an I-frame. it begins correctly with the first I frame, but then either is 10 frames too long with the exact frame number after 26 frames, or 3 frames too short when I try to have it end 1 frame before that next I-frame.

how can I find out which are the key frames or the key frame positions in my movie?

edit: it seems like the cut always has to begin at an I-frame. thats fine, the problem is just that it always ends with a P-frame 2 frames before the next I-frame and the B-frame in between then gets skipped or rather said its causing image corruption when appending the cuts together (the next B-frame after the I-frame is also corrupted for some reason)

edit: just to clarify, I get this problem when trying to combine cuts from two differnt BDs of the same movie. the frame types at and around the syncing points are the same in both versions though, so I dont know whats causing that problem.

[foxyshadis]

You're not losing B-frames, thanks to open GOP they might be referencing the now-missing future I-frame. Those first few corrupted frames after the I-frame are also referencing frames before the I-frame, which is perfectly legal in H.264. That's the difference between an I and IDR frame.

[Ex0rcist]

Today I was looking through .mkv Header values and I noticed something which I dont understand, why does all audio headers have the same default duration (21333333 = 21.3ms ) value no matter which FPS video has?

[nevcairiel]

The FPS of the video is entirely unrelated to any audio things. Audio doesn't work that way, the default duration for audio only depends on the codec used, and on the sample rate, but not the video.

[Ex0rcist]

Ok.. but what does that value actually tell me? How do I know it is actually correct, because sometimes I remux from different containers and I'd like to be sure everything is as it should be. Is it possible to use some kind of formula just to check if it's valid?

[cyberbeing]

At least in terms of mkvtoolnix, a single audio frame should match the default duration if set correctly. You can check this by opening your mkv with mkvinfo and checking the timecode and number of frames in each simpleblock containing the audio track. For example, if you have a simpleblock with 8 audio frames, and an audio track default duration of 21.333333ms, the duration of each simpleblock containing the audio track should be 170.666664ms. So you would end up with timecodes like 0ms, 170.666664ms, 341.333328ms, 511.999992ms, and so on for your audio simpleblocks within the mkv.

[mariner]

Question on delay

Greetings Mosu.

Have a question on how MKVToolNix deals with delays present in source when split & join operation is performed.

It seems the delay is preserved the new mkv container if the source is a ts container, but not when the source is mkv container. Is there a reason for the discrepancy?

Many thanks and best regards.

[Mosu]

Delays are always preserved. So I'll need much more detailed information on what you're doing and what you're observing if I am to comment further.

[mariner]

Delays are always preserved. So I'll need much more detailed information on what you're doing and what you're observing if I am to comment further.

Which was what I thought. Here's what I did:

1. Original ts has 200ms delay in video.
2. If original ts remuxed to mkv, delay preserved.
3. If original ts remuxed to mkv with split/join, delay preserved.
4. If the mkv from (2) is used for remuxing with split/join, delay no longer preserved.

Shouldn't (3) and (4) produce identical results?

Thanks for your kind reply.

[Mosu]

Yes, it should, and in a quick test here it does. So I still need more information.

Here's my evidence:

[0 mosu@sweet-chili ~/prog/video/data] mkvinfo -s v.mkv|head -n 5
Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: Main @L5.1), mkvmerge/mkvextract track ID: 0, language: und, pixel width: 640, pixel height: 352, display width: 640, display height: 352, default duration: 41.708ms (23.976 frames/fields per second for a video track)
Track 2: audio, codec ID: A_AAC, mkvmerge/mkvextract track ID: 1, default duration: 21.333ms (46.875 frames/fields per second for a video track), language: und, sampling freq: 48000, channels: 2
I frame, track 1, timecode 200 (00:00:00.200), size 12973, adler 0xc59f1503
I frame, track 2, timecode 200 (00:00:00.200), size 502, adler 0x379d04bd
I frame, track 2, timecode 200 (00:00:00.200), size 450, adler 0x2ebbd8e2
[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o remuxed.mkv v.mkv --split 30s --split-max-files 2 > /dev/null
[0 mosu@sweet-chili ~/prog/video/data] mkvinfo -s remuxed-001.mkv|head -n 5
Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: Main @L5.1), mkvmerge/mkvextract track ID: 0, default duration: 41.708ms (23.976 frames/fields per second for a video track), language: und, pixel width: 640, pixel height: 352, display width: 640, display height: 352
Track 2: audio, codec ID: A_AAC, mkvmerge/mkvextract track ID: 1, default duration: 21.333ms (46.875 frames/fields per second for a video track), language: und, sampling freq: 48000, channels: 2
I frame, track 1, timecode 200 (00:00:00.200), size 12973, adler 0xc59f1503
I frame, track 2, timecode 200 (00:00:00.200), size 502, adler 0x379d04bd
I frame, track 2, timecode 200 (00:00:00.200), size 450, adler 0x2ebbd8e2
[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o joined.mkv remuxed-001.mkv + remuxed-002.mkv > /dev/null
[0 mosu@sweet-chili ~/prog/video/data] mkvinfo -s joined.mkv|head -n 5
Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: Main @L5.1), mkvmerge/mkvextract track ID: 0, default duration: 41.708ms (23.976 frames/fields per second for a video track), language: und, pixel width: 640, pixel height: 352, display width: 640, display height: 352
Track 2: audio, codec ID: A_AAC, mkvmerge/mkvextract track ID: 1, default duration: 21.333ms (46.875 frames/fields per second for a video track), language: und, sampling freq: 48000, channels: 2
I frame, track 1, timecode 200 (00:00:00.200), size 12973, adler 0xc59f1503
I frame, track 2, timecode 200 (00:00:00.200), size 502, adler 0x379d04bd
I frame, track 2, timecode 200 (00:00:00.200), size 450, adler 0x2ebbd8e2

Edit: added an example with actual splitting & joining.

[mariner]

Thanks for your reply, Mosu.

I lack the sophisticated tools needed for detail analysis, so had to rely on mediainfo and eac3to, as well as visual inspection for change in video/audio delay. Here's a ts sample and would appreciate if you could kindly take a look.

https://www.sendspace.com/file/k3ex0j

I've used the following for "split by parts based on timecodes", and also ticked "fix bitstream timing information".
00:00:00.000-00:01:27.158,+00:01:41.163-00:08:29.161

Many thanks and best regards.

[Ex0rcist]

At least in terms of mkvtoolnix, a single audio frame should match the default duration if set correctly. You can check this by opening your mkv with mkvinfo and checking the timecode and number of frames in each simpleblock containing the audio track. For example, if you have a simpleblock with 8 audio frames, and an audio track default duration of 21.333333ms, the duration of each simpleblock containing the audio track should be 170.666664ms. So you would end up with timecodes like 0ms, 170.666664ms, 341.333328ms, 511.999992ms, and so on for your audio simpleblocks within the mkv.

:thanks:

[Mosu]

Here's a ts sample and would appreciate if you could kindly take a look.

I still cannot reproduce it, even with your file. Please post the exact command lines you've used in order to create the fourth file – meaning both the command line used for creating 2 from 1 and the one creating 4 from 2.

[mariner]

Here you go. I have the tags removed.

Step (2)
"C:\Program Files\MKVToolNix\mkvmerge.exe" -o "F:\\mkv\\50_.mkv" "--forced-track" "0:no" "--default-duration" "0:25p" "--aac-is-sbr" "1:1" "--forced-track" "1:no" "-a" "1" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "F:\\50\\50_.ts" ")" "--track-order" "0:0,0:1"

Step (4)
"C:\Program Files\MKVToolNix\mkvmerge.exe" -o "F:\\mkv\\cutmkv_.mkv" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1280x720" "--default-duration" "0:25p" "--fix-bitstream-timing-information" "0:1" "--aac-is-sbr" "1:1" "--default-track" "1:yes" "--forced-track" "1:no" "-a" "1" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "F:\\50\\50_.mkv" ")" "--track-order" "0:0,0:1" "--split" "parts:00:00:00.000-00:01:27.158,+00:01:41.163-00:08:29.161"

[Mosu]

Using --default-duration doesn't just set some header files. It also causes mkvmerge to re-calculate all timecodes based on the supplied value, 25fps. This causes the timecodes to start at 0. The --default-duration option, just like the similar --timecodes option, tells mkvmerge »I know better than you how to timecode!« and mkvmerge will simply get out of the way in that case.

So unless you actually need --default-duration don't use it.

[mariner]

1. I've selected 25fps because if left out, the mkv created is in VFR frame rate mode instead of the fixed 25fps. This seems to confuse eac3to in to reporting the frame rate as 25.381 and giving a warning that the video bitstream framerate field doesn't match the container framerate. Is this the intended behavior? And what's the proper way to create a fixed fps?

2. The 25fps --default-duration option was used in all the three steps. Delay was preserved in steps 2 & 3 (using ts as source), but not in step 4, when the source is mkv. Why the discrepancy?

Many thanks and best regards.

[Mosu]

1. If you use mkvmerge's append function the the file is inherently VFR. Nothing you can do about that. Ignore eac3to's warning.

2. They use different code paths for packetizing the video.

[mariner]

Thanks for your kind explanations, Mosu.

Just to reconfirm, if --default-duration is selected when using mkvmerge's append function, delay would be preserved for ts input, but not for mkv input.

Many thanks and best regards.

[Mosu]

More or less, though the deciding factor isn't the input format but the output module used. For h.264 and h.265 there are two output modules each, depending on whether the track is already in NALU format or not. Inside MPEG TS h.26x isn't in NALU format, inside Matroska it is, therefore the different output code paths.

I may change the behavior of the h.264-as-NALU code to match the behavior of other code path so that such delays will be preserved even if --default-duration is used, but it depends on how invasive that change will turn out to be – if it turns out to require too many changes then I will not do it soon.

[mariner]

It may not be obvious from the short uploaded sample, but the video is lagging the audio, most likely due to the 158ms delay. Many other hls recordings suffer from the same problem.

So the current behavior actually solves this problem without having to manually compensate for the delay. I wanted to makes sure that my eyes were not fooling me.

[Mosu]

Hey,

I've released MKVToolNix v7.6.0. It's mainly a bug fix release. Nothing major had to be fixed, though.

Nothing has changed for package maintainers.

Here are the usual links...

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

...to the source code:
https://www.bunkus.org/videotools/mkvtoolnix/source.html

...to the Windows installer and 7zip archive:
http://www.fosshub.com/MKVToolNix.html

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

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

2015-02-08 Moritz Bunkus <moritz@bunkus.org>
* Released v7.6.0.

2015-02-03 Moritz Bunkus <moritz@bunkus.org>
* all programs: bug fix: Since release 7.0.0 the wrong exit code was used when warnings were finished (0 instead of 1). Fixes #1101 (https://github.com/mbunkus/mkvtoolnix/issues/1101).

2015-02-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Appending chapters with the same chapter UID was dropping all sub-chapters from the one of the two merged chapters. Now the sub-chapters are merged recursively as well.
* mkvmerge: bug fix: The wrong Codec ID was written when reading PCM tracks from Matroska files in Big Endian byte order. Fixes #1113 (https://github.com/mbunkus/mkvtoolnix/issues/1113).

2015-01-23 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: added a Serbian (Latin) translation of the programs by Danko (see AUTHORS).

2015-01-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: If splitting was active and AC3 tracks read from Matroska files were shorter than a split point then the following output file would contain an AC3 packet with the timecode of 00:00:00 somewhere in the middle. Fixes #1104 (https://github.com/mbunkus/mkvtoolnix/issues/1104).

2015-01-14 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: If a chapter track from a Matroska file is selected then the »language« drop-down box is disabled. Fixes #1105 (https://github.com/mbunkus/mkvtoolnix/issues/1105).

2015-01-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: On Windows the end-of-file-reached status wasn't tracked correctly for certain file operations. This could manifest in e.g. mkvmerge not finding tracks in MPEG transport streams when probing MPLS playlist files. Fixes #1100 (https://github.com/mbunkus/mkvtoolnix/issues/1100).
* mmg: bug fix: When scanning for play lists the window presenting the results listed some properties in an unescaped way (e.g. »\s« instead of spaces).
* mmg: bug fix: When adding MPLS files mmg was only offering to scan for more playlists if there were at least two additional MPLS files present. This has been fixed to one MPLS file (in addition to the one just added).

Have fun.

[Ex0rcist]

Hi,

What could be causing synchronization problem when extracting streams from .flv or .mp4 container and then remuxing them again to .mkv, but when directly remuxing the file audio is perfectly synchronized.

Thanks.

[Mosu]

When you extract tracks from containers into their elementary streams then a lot of information is lot on the way, among them their timecodes. Therefore: don't do it. Re-mux directly from the source files if at all possible.

One notable exception are subtitle files as they already carry timecode information in their native/elementary formats.

[Boulder]

So does mkvmerge use existing timecodes for video tracks if VFR Matroska files are used as a source? That does not show up in the GUI and I've sometimes wondered which is the correct way to remux if I just want to re-encode audio into some lossy format.

[Ex0rcist]

When you extract tracks from containers into their elementary streams then a lot of information is lot on the way, among them their timecodes. Therefore: don't do it. Re-mux directly from the source files if at all possible.

One notable exception are subtitle files as they already carry timecode information in their native/elementary formats.

Is it possible to somehow get timecodes from .mp4 files and use them later when remuxing?

[Mosu]

So does mkvmerge use existing timecodes for video tracks if VFR Matroska files are used as a source? That does not show up in the GUI and I've sometimes wondered which is the correct way to remux if I just want to re-encode audio into some lossy format.

Of course. mkvmerge keeps as much information as possible unless you tell it otherwise.

[Mosu]

Is it possible to somehow get timecodes from .mp4 files and use them later when remuxing?

No idea how to extract timecodes from MP4 files. On mkvmerge's end you can use the --timecode option.

[foxyshadis]

Is it possible to somehow get timecodes from .mp4 files and use them later when remuxing?

mp4fpsmod (https://sites.google.com/site/qaacpage/junk) ~ download (https://sites.google.com/site/qaacpage/cabinet/mp4fpsmod_0.24.zip?attredirects=0&d=1)

[hello_hello]

Hi Mosu (or anyone else who can help).
I thought I'd ask this question here because while I don't think it's an MKVMerge problem as such (I can duplicate it with GDSMux) I don't know where else to ask. I can duplicate this problem time and time again, at least at this frame rate. The problem is one that arose when discussing a MeGUI related issue here (http://forum.videohelp.com/threads/369714-QTGMC-Script-in-meGUI?p=2374638&viewfull=1#post2374638).

Anyway, the MKV I've linked to is written by the x264 encoder. MediaInfo sees the frame rate as 59.940fps, which is exactly as it should be. After remuxing though, it appears to be 59.880fps. If I remux while specifying a 59.940 frame rate ("--default-duration" "0:60000/1001p"), MediaInfo sees it as being 60fps (MediaInfo actually shows two frame rates, one being "original frame rate"). VLC shows the remuxed MKVs as being 59.94157

I've never seen this sort of oddness when remuxing at other frame rates, so I'm just trying to work out if something odd is happening, or whether the programs are lying and I should just ignore it all.

Thanks.

http://ge.tt/5ApLhZA2/v/0 (7.7MB)

[ndjamena]

Really, you're posting VideoHelp links here?

I'll raise you one:

http://forum.videohelp.com/threads/368819-MKV-Merge-Makes-29-97-file-into-30

And give you some Sourceforge to boot:

https://sourceforge.net/p/mediainfo/bugs/882/

MKVMerge uses a time base of 1000000ns, which amounts to an accuracy of 1ms. X264 and quite a few other programs use a time base of 50000ns, which gives a far more accurate representation of display time. Apparently 1ms isn't accurate enough for whatever frame rate heuristic MediaInfo uses to detect the frame rate at 60/1.001 fps. Since each frame at that frame rate has a shorter duration than in most other standard frame rates small inaccuracies in the time codes have a greater effect.

[Mosu]

Also related: this fine FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/Wrong-frame-rate-displayed) about frame rates and Matroska.

[ndjamena]

The information is simply not there – simply because it is not needed for playback which can work just fine without that information.

I don't completely agree with that statement. My WDTV Live SMP actually sets the frame rate being passed to my TV through HDMI to 23.976fps when I'm playing a blu ray rip. I know it shouldn't and I know it shouldn't be getting frame rate info from the stream headers but the alternative is to simply up the frame rate as far as possible and hope for the best. Since the HDMI link is limited to 60 or 50 frames per second and TVs can come at 120fps now days it's probably better to transfer the actual frame rate through the link for the TV to display as it will rather than relying on it auto establishing some kind of film mode.

[hello_hello]

Really, you're posting VideoHelp links here?

Yeah. I post doom9 links at VideoHelp too. Is there a rule or something?

Anyway, thanks guys. I assume the difference in reported frame rate is nothing to worry about.

[foxyshadis]

MKVMerge uses a time base of 1000000ns, which amounts to an accuracy of 1ms.

Anything more is a waste for playback, since most renderers have a jitter well above 1ms anyway. You can always set your own with --timecode-scale, if MediaInfo's accuracy is absolutely necessary, but this is really more of a MediaInfo missing feature: if it scanned 30 seconds in, it'd see the duration overrides, but MediaInfo doesn't ever do deep scans of files if there's a way not to, and no option to override to get better data. For the same reason it can't detect VFR. Just take anything it says with a grain of salt.

In fact, because MediaInfo simply reports DefaultDuration, a badly broken muxer could set the value to anything and then override it with the real frame time on every frame. Only mkvinfo's debug report will be truly accurate. Fortunately, pathological behavior is rare.

Yeah. I post doom9 links at VideoHelp too. Is there a rule or something?

Not at all, nothing wrong with VideoHelp and others like AVSForum.

[ndjamena]

I was just a little taken aback that you had to ask it over here. I guess I was absent then. (Plus, you obviously hadn't read the thread that dealt with that topic already, or the report on the MKVToolNix bug tracker that mentioned it, or the MediaInfo thread... Maybe I'm thinking of someone else.)

[Zenitram]

Anything more is a waste for playback, since most renderers have a jitter well above 1ms anyway.

If you consider MKV only as a "lossy" container format, right, but some people would like to not lose some piece of information.
Example: some people (here, I don't say they are right, I say what they want) want to see the difference between the following frame rates:
29.970000000 fps (which is not the exact US typical frame rate, see the number below), frame duration is 0.033366700 second
30000/1001 fps [~29.970029970 fps), frame duration is 0.033366667 second
30.000000000 fps, frame duration is 0.033333333 second

and Matroska does not permit easily, as far as I know, to differentiate these frame rates, even if the complete file is parsed.
In some other containers (e.g. MP4), timescale has a numerator and denominator, so timescale can be e.g. 1000/2997, 1001/30000, 1/30.
In some other containers (e.g. MPEG-TS), time is at 90 kHz (so easy to catch the US frame rate)

This is true it is useless for playback.
But it may be useful if you want to know the exact frame rate (and yes, it matters for some people).


if MediaInfo's accuracy is absolutely necessary, but this is really more of a MediaInfo missing feature: if it scanned 30 seconds in, it'd see the duration overrides, but MediaInfo doesn't ever do deep scans of files if there's a way not to, and no option to override to get better data. For the same reason it can't detect VFR. Just take anything it says with a grain of salt.

MediaInfo is definitely buggy on this side, the algo is crappy and I did not take the time to find a better one.
FYI, it is possible to override MediaInfo default behavior in order to scan the complete file but it has not been tested for Matroska (maybe something else in the code will prevent MediaInfo to compute right information) because there is currently no sponsorship for Matroska (it may change in the near future (https://mediaarea.net/en/PreForma_MediaInfo_Phase1)).

Keep in mind that default MediaInfo behavior has a goal of quickly (=without parsing the whole file) being able to report information, it has not the goal of detecting uncommon and difficult to detect cases (e.g. fixed frame rate during 1 hour, then 10 seconds of VFR), specific implementation of MediaInfo (with some constraints e.g. parsing time) may be coded for that.

But Mosu has added few months ago some statistical metadata, and it may help to resolve the issue with new files.

DR;TL: for the moment, the biggest issue is in MediaInfo, for sure.

Jérôme, developer of MediaInfo.

[Mosu]

Thanks for the detailed information, Jérôme. Would you mind me including this info almost verbatim in my FAQ entry about FPS in Matroska (https://github.com/mbunkus/mkvtoolnix/wiki/Wrong-frame-rate-displayed)?

[Zenitram]

Thanks for the detailed information, Jérôme. Would you mind me including this info almost verbatim in my FAQ entry about FPS in Matroska (https://github.com/mbunkus/mkvtoolnix/wiki/Wrong-frame-rate-displayed)?

I don't see exactly which information you want to include, but feel free to do whatever you want with my comment, my comment is CC0 (https://creativecommons.org/publicdomain/zero/1.0/) licensed.

BTW mosu, I publicly apologize for the little mess I introduced with current MediaInfo Matroska framerate detection algo, and I hope I'll have the time soon to focus on this issue (which is not easy, unfortunately, some of my users complain if I remove the current code).

[ndjamena]

What would be nice additions to the tags would be "Maximum [Frame] Duration" and "Minimum [Frame] Duration", just to catch the statistically unlikely situation where "duration" / "number of frames" pans out to constant frame rate when it's not supposed to.

"Active Duration" would be nice too ("Duration" minus "Gaps in Stream"), or "Peak Bitrate". But I've already been there.

[sneaker_ger]

What do you mean by "Gaps in Stream"? A gap just means there's a huge difference between two consecutive frames' timecodes, with "huge" being a loose, undefined term.

[ndjamena]

That would make sense. The time code files seem to indicate that. Mosu gave me the word "gap" though, so I assume it means something.

Then what's default duration for, if time-codes are all important then duration is redundant isn't it...

[sneaker_ger]

They can be needed to calculate timecodes. (see FAQ posted by Mosu above)

That would make sense. The time code files seem to indicate that. Mosu gave me the word "gap" though, so I assume it means something.
I think it makes most sense when talking about audio streams since they are practically continuous, i.e. one audio "frame" ends when the next one starts. For video it would be more complicated to define.

Trying to say: deciding what a gap is is not trivial and would have to be defined before implementing anything like you suggested.