MKVToolNix v99.0 released

[Nico8583]

Perfect, I'll try it ! Thanks

[Liisachan]

An odd (?) behavior of
mkvextract video.mkv timestamps_v2 0:timestamps.txt
Tested with several 24000/1001 fps videos. Let's say I have a video with only 5 frames. The folloing is expected (or not?):
# timestamp format v2
0
42
83
125
167
209
But mkvextract writes 208.708333 instead of 209. If it wants to be accurate, the number should be 208.541667, so the "708333" part doesn't make sense.

Similarly, if MKV is created with --timestamp-scale 100000, then mkvextract says:
0
41.7
83.4
125.1
166.8
208.508333
The last number seems odd (208.5 is expected, or not?).

The above is, however, a minor detail, perhaps almost harmless. The real problem that my friend and I are trying to solve is, sometimes mkvmerge makes the first frame non-0. For example:
# timestamp format v2
21
63
105
146 This may happen when the source is MP4, and I'm guessing that such an MP4 video file already has ~21ms offset for some reason (i.e. the first frame is ~21ms after the first audio sample), and mkvmerge is simply copying the timestamps from MP4... So this is probably not an MKV-side issue, but does anyone have any idea why such a strange MP4 file is written by ffmpeg (where the first frame is not 0:00.000)?

[Liisachan]

On Windows (at least), both 32- and 64-bit, mkvmerge rounds down the video frame timestamps with the fraction part ~0.54, like this:

Conditions:
- ntsc_film i.e. 24000/1001 fps CFR
- Frame# >= 31253, and ≡ 5 (mod 24)
- Input is .264 file (and not .mp4 file) written by x264.exe

First problem frame:
Frame 31253 (0:21:43.510 541 667) =
1303510.541667 ms
1303511 is expected
1303510 is used by mkvmerge.

The following mux-time option doesn't change this behavior:
--default-duration 0:24000/1001p --fix-bitstream-timing-information 0:1

Edit: This might be a problem of x264.exe ... because this does not happen when transmuxing from xvid.avi, but happens when reading x264.264. How can I check timestamps in .264 file?

Edit2: One thing I can reproduce consistently is, mkvmerge rounds down the fraction 0.5, for each "12 mod 24" frame.

Edit3: It seems that timestamps are as expected if input is video.mp4. Either the .264 write of x264 or the .264 parser of mkvmerge may be strange.

[Snowknight26]

There seems to be a bug in the track selection section of the Input pane in the multiplexer.

If you highlight a track/chapter/tag by clicking on the row corresponding to the item, while the item is highlighted, double clicking the checkbox causes the checkbox state to be changed 3 times. Once on the initial click, once on the 2nd click's mouse down, and a 3rd time on the click's mouse up.

Easy way to see it if you have multiple tracks:

Select the first track
Double click the left-most checkbox (the 'Copy this item' checkbox) of the 2nd track
The 2nd track's state correctly toggles twice (since you double clicked) but the first also track toggles once because it's highlighted

[Mosu]

Double clicks are handled the same way as pressing return; they act on all selected tracks. The checkboxes on the left are only visual indicators, not actual checkboxes. So whatever the current behavior is, it is going to stay that way.

[Snowknight26]

Double clicks are handled the same way as pressing return

They aren't though. The 2nd click of the double click causes the checkbox state to be toggled up to twice, once on mouse down, once on mouse up. Pressing enter only causes the checkbox state to be toggled once. Double clicking causes it to be toggled up to 3 times.

Video of reproduction steps, with a mouse intercept hook showing you exactly what state the mouse is in:
https://www.stfcc.org/misc/2022-02-23_07-57-09.mp4

Ran through several different scenarios, in this order:

Single clicking checkbox of a when no item is highlighted
Double clicking checkbox of a when no item is highlighted
Double clicking checkbox of the only item that's highlighted (did this twice)
Pressed up key to change highlighted item
Double clicking checkbox of a non-highlighted item (did this 3x)

[Mosu]

To be quite honest… I don't really care. I only register signal handlers for Qt's signals of "entry double cliked" and "return pressed" and do the same action in both cases. Everything else, including the management of which entry gets (de-)selected when or which click events are actually triggered, is handled by Qt, and I have no control over that.

[Snowknight26]

To be quite honest… I don't really care.

Likewise, so no hard feelings. ;) At least it's now documented for any pour soul that notices this quirk.

[shae]

In muxes where the audio is longer than video, splitting on video length doesn't seem to do anything.
A roundabout way, that sometimes works, is to append more video to the "real" video. But that doesn't always help.

Instead of all that, would it be possible to add a "cut to video stream length" option?

VVVV VVVV
aaaaaa -> aaaa

[Mosu]

Due to how many container types work, knowing which video packet is the last packet while it is processed is rather difficult to achieve and would require substantial buffering of content & for that substantial rewrites of the program. I won't spend time on that.

[hubblec4]

In muxes where the audio is longer than video, splitting on video length doesn't seem to do anything.
A roundabout way, that sometimes works, is to append more video to the "real" video. But that doesn't always help.

Instead of all that, would it be possible to add a "cut to video stream length" option?

VVVV VVVV
aaaaaa -> aaaa

Yeah, and that's the reason why you don't should cut and/or append mkv's.

[shae]

knowing which video packet is the last

Thanks for all the MKV tools!

Isn't it a matter of "no more video frames, stop here and truncate any pre-buffered audio"?

If not that, any way to get manual splitting to work when setting to split after frame == number_of_frames_in_video?

If not that, any way to get back the ability to append video to self (to pad length, which seems needed for splitting to work)?
Older versions allowed that, new ones seemingly disallow the same video file twice.

Yeah, and that's the reason why you don't should cut and/or append mkv's.
What do you mean?

The specific goal here is to truncate audio. I encountered it in some Bluray M2TS files.

[Mosu]

Isn't it a matter of "no more video frames, stop here and truncate any pre-buffered audio"?

Again, there's no way to know that there won't be any more video frames unless mkvmerge is completely done processing everything. This can mean that it would have to buffer gigabytes of other data in certain cases, potentially spanning reading multiple appended files and other structures, also affecting all other content generated in the meantime (e.g. chapters). Would that happen often? No. Would I have to implement all the code for that anyway? Yes, I would. There are no real shortcuts for me to take; it would take a huge amount of work.

If not that, any way to get manual splitting to work when setting to split after frame == number_of_frames_in_video?

Same problem; the program would have to know for certain that there will not be any more frames for that track coming. So no, no way.

If not that, any way to get back the ability to append video to self (to pad length, which seems needed for splitting to work)? Older versions allowed that, new ones seemingly disallow the same video file twice.

Not sure what you're referring to, but you can use the same file name as source files as often as you want. Yes, you can append it to itself by listing it twice (e.g. "mkvmerge -o out.mkv in.mp4 + in.mp4").

[Mosu]

On Windows (at least), both 32- and 64-bit, mkvmerge rounds down the video frame timestamps with the fraction part ~0.54, like this:

Liisachan, I'm not really replying to you not because I'm willfully ignoring you or because I've overlooked your posts, but because I simply don't want to deal with rounding issues. Those are some of the most excruciating issues to fix, and I simply lack the motivation & energy to tackle those. I postponed replying a bit, hoping I'd find the energy to look into it, but I just… haven't. I'm sorry.

[shae]

If not that, any way to get manual splitting to work when setting to split after frame == number_of_frames_in_video?

the program would have to know for certain that there will not be any more frames for that track coming. So no, no way.
There are currently options to split after frame or time. I did get split-after-frame to work at least once (which required the video to be append-padded). Under what circumstances is it supposed to work, and when is it supposed not to work?

Not sure what you're referring to, but you can use the same file name as source files as often as you want.
It was in the GUI. Will check again. I tried recently, but after the popup asking whether to append/start a new mux/etc., choosing "append" lead to no visible action; the file didn't appear as a child in the source list.

[ProWo]

I wrote a simple GUI for mkvalidator (for Windows only). It needs .net 4.8.
It works with any CPU.
You can download it here
https://files.videohelp.com/u/292773/mkvalidator-gui_120.7z
Enjoy

NB March 7, 2022 update to v1.2.0

[oniiz86]

I was wondering if anyone may know the technical reason why TrueHD & Dolby Digital Plus with Atmos causes intermittent subtle motion jerkiness when muxed with MKVToolNix on OPPO's BDP-10X players but when remuxed using @ProWo's superb "Clever FFmpeg-GUI" program there are no such motion issues, does it have to do with the LAV filters during the encoding process?

These same files with TrueHD & DDP/Atmos are fine when played on OPPO's UDP-20X players when muxed with MKVToolNix so obviously it is not the program, so it must be an unusual quirk of the earlier MediaTek MT8580 SoC in the BDP-10X players, first I thought it was a variable bit-rate issue with TrueHD but DDP/Atmos being constant bit-rate squashed that idea, what would the LAV filters be doing differently to what MKVToolNix is using?

[Klaus1189]

Upload two short sample output files on google drive or similar and we can compare them precisely.

[oniiz86]

@Klaus1189 This is the MKVToolNix sample https://ufile.io/qrd01dyt which for some strange reason has had its frame rate changed from 24000/1001 to 23976/1000, it is only a short 20 second clip but the motion jerkiness should be apparent at several points as it pans from left to right across the fence & also the kids running in the background tend to have some motion skipping too.

The sample https://ufile.io/r2u6z4ft made with ProWo's clever FFmpeg-GUI does not exhibit any motion jerkiness at all & has not had its frame rate changed, remains at 24000/1001.

The secondary lossy DD 5.1 track plays fine on both files, not sure why the TrueHD track is being problematic only when muxed with MKVToolNix.

Is it a case of the LAV filters are more forgiving in terms of the player's MTK SoC not strictly adhering to the Matroska spec vs MKVToolNix's libebml + libmatroska encoding process handles it more strictly to provide overall better spec compliant muxes?

Most owners should see the issue with the first sample if they have any of the following, OPPO's BDP-103/105(D), Cambridge Audio 752BD/CXU & Pioneer BDP-LX58/88 players.

[von Suppé]

This is the MKVToolNix sample https://ufile.io/qrd01dyt which for some strange reason has had its frame rate changed from 24000/1001 to 23976/1000.
I suspect this framerate change being introduced way earlier than when remuxing with MKVToolnix. Incorrect timecodes can be set during a flawed recode (the mkv's obviously are recodes) of 24000/1001 source. Where the exact 23.976 value is used as framerate instead of using the 24000/1001 fraction. As I understand ffmpeg always rewrites timecodes during mux, it could be the difference here.
If I'm right with this, MKVToolnix could be able to solve this for AVC by setting FPS to 24000/1001p and checking "Fix bitstream timing info" before muxing.

Additionally, I can imagine different playback results because of different players honouring container framerate or videostream framerate.

[oniiz86]

I suspect this framerate change being introduced way earlier than when remuxing with MKVToolnix. Incorrect timecodes can be set during a flawed recode (the mkv's obviously are recodes) of 24000/1001 source. Where the exact 23.976 value is used as framerate instead of using the 24000/1001 fraction. As I understand ffmpeg always rewrites timecodes during mux, it could be the difference here.
If I'm right with this, MKVToolnix could be able to solve this for AVC by setting FPS to 24000/1001p and checking "Fix bitstream timing info" before muxing.

Additionally, I can imagine different playback results because of different players honouring container framerate or videostream framerate.

The file is 24000/1001 but only when I used the splitting option "Parts by Timestamps" did it then change to 23976/1000, it mentions Original Frame Rate 24000/1001 & Frame Rate 23976/1000 according to MediaInfo but like I said when the sample was remuxed using @ProWo's Clever ffmpeg-GUI it shows correctly as 24000/1001.

I did try setting FPS to 24000/1001p & checking "Fix bitstream timing info" but it made no difference, I understand playback results will differ across different players but in this instance it seems to be MKVToolNix causing this difference with intermittent motion jerkiness on my OPPO BDP-105D that Clever ffmpeg-GUI does not.

[von Suppé]

I understand your post. For my own sanity I chopped several "real" 24/1001 mkv files to smithereens, all parts came out correctly showing 24/1001. I just can't imagine that MKVToolnix would introduce the exact 23.976 value out of nowhere.

I imported the "sample https://ufile.io/r2u6z4ft made with ProWo's clever FFmpeg-GUI" into MKVToolnix and did a clean full remux (no cutting). MediaInfo states on that result:

Frame rate: 23.976 (23976/1000) FPS
Original frame rate: 23.976 (24000/1001) FPS

Again, I don't think MKVToolnix grasps the 23976/1000 out of thin air. I'd still think there's something not 100% correct with the sourcefile you created these two samples with. BTW their elementary videostreams show bit-equal. Maybe flawed container metada is inherited?

I also demuxed the clever ffmpeg mkv into elementary streams, which I imported in MKVtoolnix for a clean remux. MediaInfo does not show 23976/1000 anywhere.
To me, this also would confirm that there's something in the source container that makes the difference.

[hubblec4]

Hi Mosu

Is there a way to force mkvmerge to write CRC32 elements?

[Mosu]

Neither of my tools currently supports CRC elements, mostly for actual technical issue with libebml. So the answer is no, unfortunately.

[hubblec4]

OK.
And no support means "only writing" or also reading?

In MkInfo tool I can see an entry called Adler-32, this has nothing to do with CRC32?

[Mosu]

Neither mkvmerge nor mkvpropedit can write them, and almost none of the tools can read them. mkvinfo has very, very limited support for displaying a CRC element's value without actually validating it, but as far as I remember there are situations in which libebml does some CRC handling internally without actually reporting the elements to the calling applications, meaning mkvinfo might not even show the element's presence.

Adler-32 checksums have nothing to do with CRC32 elements. Adler-32 checksums are calculated on the fly and are solely intended to be used for us humans to compare elements between different files (e.g. in order to be able to determine if CodecPrivate elements of two video tracks in different files are actually identical).

[oniiz86]

I understand your post. For my own sanity I chopped several "real" 24/1001 mkv files to smithereens, all parts came out correctly showing 24/1001. I just can't imagine that MKVToolnix would introduce the exact 23.976 value out of nowhere.

I imported the "sample https://ufile.io/r2u6z4ft made with ProWo's clever FFmpeg-GUI" into MKVToolnix and did a clean full remux (no cutting). MediaInfo states on that result:

Frame rate: 23.976 (23976/1000) FPS
Original frame rate: 23.976 (24000/1001) FPS

Again, I don't think MKVToolnix grasps the 23976/1000 out of thin air. I'd still think there's something not 100% correct with the sourcefile you created these two samples with. BTW their elementary videostreams show bit-equal. Maybe flawed container metada is inherited?

I also demuxed the clever ffmpeg mkv into elementary streams, which I imported in MKVtoolnix for a clean remux. MediaInfo does not show 23976/1000 anywhere.
To me, this also would confirm that there's something in the source container that makes the difference.

Do you think you know how the container may be causing this difference? It is very odd that the frame rate would change like that, I thought it may have been a certain audio track causing this issue because the split file has a duration of 23 secs but the duration should be 17 secs, I chose 00:16:23-00:16:40, I tried with other files that had TrueHD tracks & there was no altered frame rate from 24000/1001 to 23976/1000 & the split file was the exact duration, I just noticed the sample I've uploaded has different audio track lengths, the AC-3 track being slightly longer at 17ms, any reason why?

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 23 s 24 ms
Bit rate : 23.4 Mb/s
Width : 1 920 pixels
Height : 816 pixels
Display aspect ratio : 2.35:1
Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Original frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.624
Stream size : 64.3 MiB (86%)
Default : Yes
Forced : No

Audio #1
ID : 2
Format : MLP FBA
Format/Info : Meridian Lossless Packing FBA
Commercial name : Dolby TrueHD
Codec ID : A_TRUEHD
Duration : 23 s 23 ms
Bit rate mode : Variable
Bit rate : 3 154 kb/s
Maximum bit rate : 4 470 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 1 200.000 FPS (40 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : 1 ms
Stream size : 8.66 MiB (12%)
Title : TrueHD 7.1
Language : English
Default : Yes
Forced : No

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 23 s 40 ms
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Delay relative to video : 12 ms
Stream size : 1.76 MiB (2%)
Title : AC-3 5.1
Language : English
Service kind : Complete Main
Default : No
Forced : No

[von Suppé]

First off, I think that files with wrong metadata can cause duration discrepancies, even without chopping them into smaller parts. Can't prove it though; my knowledge simply is too limited. Therefor I also don't know what metadata would be inherited to make MKVToolnix files framerate show up as 23976/1000.
To me it would seem unlikely that some corrupt audiotrack could affect video framerate. But, never say never.
Hopefully Mosu can tell us more about all this.

As to 23976/1000 framerate, I've always been suspicious. I wouldn't know what source would have this natively. As I mentioned earlier, very often the video turned out to be a recode where the exact value was set instead of using the 24000/1001 fraction. Where, eventhough MKVToolnix has the ability to "Fix bitstream timing info" for AVC, often the ultimate fix meant taking the video out of its container and change framerate of the ES.

[Liisachan]

Okay, more info to share with other users (Not a bug report). ffmpeg may have some issues too (we're still studying), but MKVToolNix is somewhat strange, in the following way.

Can anyone reproduce this strangeness?

1. Prepare a sample NTSC (24000/1001 fps) video with many frames (for me more than 31253 frames) as AVS, say, test.avs like this:


BlankClip(length=31800, width=640, height=4800, fps=24000, fps_denominator=1001, pixel_type="YV12")
KillAudio()


2. Encode it as MP4 (or MKV) with x264.


x264 --fps 24000/1001 -o x264-video.mkv "test.avs"


3. Mux it as MKV with mkvmerge. Timestamps in MKV are *GOOD* at this point:


mkvmerge -o mkvmerge.mkv "x264-video.mp4"
mkvextract "mkvmerge.mkv" timestamps_v2 0:good-timestamps.txt


4. Extract .264 and remux. Then, timestamps become bad:


mkvextract "mkvmerge.mkv" tracks 0:mkvextract.264
mkvmerge -o remuxed.mkv "mkvextract.264"
mkvextract "remuxed.mkv" timestamps_v2 0:bad-timestamps.txt


Bad how? For example Frame 31253 = 31253*1001*1000/24000 = 1303510.541666... ms (0:21:43.510541666) should be 1303511 if rounded, when the default timestamp format is used. Indeed good-timestamps.txt has 1303511; bad-timestamps.txt instead has 1303510, rounded down 0.54...; this fraction 0.54.. is always rounded DOWN in frame 5 mod 24 >= 31253. This is a bigger problem, causing subtitle-off-by-one-frame problems in some edge cases.

Solution for end-users: try not to let MKVToolNix do math about 24000/1001. Several other tools, e.g. AviSynth, x264 / Haali Matroska Writer b0, or even old AVI format, can handle a rational fps. MKVToolNix tends to break good timestamps, and once broken it's generally hard to fix them using MKVToolnix itself, except one can manually do --timestamps "0:good.txt" frame by frame. MKV is more flexible than CFR-only formats, at the cost that it can't handle CFR intrinsically, every MKV technically being VFR for MKV.

So, we can just use a tool that supports a rational FPS, and just let Mkvmerge COPY timestamps. Don't let it calculate them.

Solution for coders: when handling a rational number divide last. 31253*1001*1000/24000 instead of 31253*(1001/24000)*1000

PS: A smaller problem (not important) just fyi: a theoretical exact-0.5 ms fraction (every ntsc frame 12 mod 24 has it) is rounded DOWN if MkvToolNix does math. The tool doesn't support a rational fps by design. E.g. --default-duration 0:24000/1001p is approximated by integer, --default-duration 0:41708333ns, the tool unable to handle a rational number, not supporting round(rational) in this context. This is probably by design, not a bug. Rounding down 0.54... is still not good, counter-intuitive, nevertheless. A dirty workaround is, use
0:41708334ns i.e. 2/3 ns too large
instead of
0:41708333ns i.e. 1/3 ns too small

[oniiz86]

First off, I think that files with wrong metadata can cause duration discrepancies, even without chopping them into smaller parts. Can't prove it though; my knowledge simply is too limited. Therefor I also don't know what metadata would be inherited to make MKVToolnix files framerate show up as 23976/1000.
To me it would seem unlikely that some corrupt audiotrack could affect video framerate. But, never say never.
Hopefully Mosu can tell us more about all this.

As to 23976/1000 framerate, I've always been suspicious. I wouldn't know what source would have this natively. As I mentioned earlier, very often the video turned out to be a recode where the exact value was set instead of using the 24000/1001 fraction. Where, eventhough MKVToolnix has the ability to "Fix bitstream timing info" for AVC, often the ultimate fix meant taking the video out of its container and change framerate of the ES.

This file is explicitly set to 24000/1001, it's an odd one for sure why MKVToolNix is reporting it as 23976/1000 in split mode, the elementary AVC stream seems to be fine as clever ffmpeg-gui identifies it correctly, if the AVC stream were corrupted would it not matter which program was used to create the mux encode, what makes the LAV filters so special as to not cause any intermittent motion jerkiness on my OPPO player, what exactly is MKVToolNix's libebml + libmatroska doing differently during the encoding process to have an effect on the motion playback on certain MediaTek SoC players?

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 30 min
Width : 1 920 pixels
Height : 816 pixels
Display aspect ratio : 2.35:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 157 r2932 303c484
Encoding settings : cabac=1 / ref=5 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.10:0.00 / mixed_ref=1 / me_range=48 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=25 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=crf / mbtree=0 / crf=17.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.30 / pb_ratio=1.20 / aq=3:0.75
Default : Yes
Forced : No
FromStats_BitRate : 20275985
FromStats_Duration : 01:30:56.451000000
FromStats_FrameCount : 130824
FromStats_StreamSize : 13829365409

Audio #1
ID : 2
Format : MLP FBA
Format/Info : Meridian Lossless Packing FBA
Commercial name : Dolby TrueHD
Codec ID : A_TRUEHD
Duration : 1 h 30 min
Bit rate mode : Variable
Maximum bit rate : 4 470 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 1 200.000 FPS (40 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Title : TrueHD 7.1
Language : English
Default : Yes
Forced : No
FromStats_BitRate : 2967497
FromStats_Duration : 01:30:56.452000000
FromStats_FrameCount : 6547742
FromStats_StreamSize : 2024001148

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 1 h 30 min
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 416 MiB (3%)
Title : AC-3 5.1
Language : English
Service kind : Complete Main
Default : No
Forced : No
FromStats_BitRate : 640000
FromStats_Duration : 01:30:56.480000000
FromStats_FrameCount : 170515
FromStats_StreamSize : 436518400

[Liisachan]

A Matroska file does not work that way, not directly supporting any fixed frame rate at all. Instead, each frame has its timestamp (by default, the unit is 0.001 second = 1 millisecond aka 1 ms). A typical example is:

Frame 0 = time 0
Frame 1 = time 42 (fps between Frame 0 and 1 is 1000/42 = 23.809...)
Frame 2 = time 83 (fps between Frame 1 and 2 is 1000/41 = 24.390...)
Frame 3 = time 125 (fps between Frame 2 and 2 is 1000/42 = 23.809...) and so on.

There is also a per-track metadata called DefaultDuration, which might be 41708333 ns (41.708333 ms; ~23.976024168 fps), when an info tool can guess the source video is NTSC (24000/1001 fps) and may show an approximate value of it (e.g. 24 fps, 23.9760 fps, etc.); but it is only the default value. Since each frame has its own timestamp explicitly, this default value is basically irrelevant and unnecessary and generally not used, except maybe when calculating the end time of the very last frame.

This system may look confusing and (in specific cases) indeed it can be inconvenient, yet it is much more flexible this way, since one can use a variable frame rate (VFR) easily. That is how Matroska works. It is a feature - a design decision.

See also: https://matroska.org/technical/notes.html#timestampscale-rounding

@hubblec4
There are some tools that do write ebml CRCs (and there is a tool that can verify it), but like Mosu said, mkvmerge doesn't do that. To make sure the file is not corrupted after years, one can record the hash value of the file. An "insecure" hash like MD5 is enough for this purpose. If you're worried that an accidental writing error might occur when muxing, then you can simply mux twice with --deterministic and check the 2 files are bit-identical :)

[oniiz86]

A Matroska file does not work that way, not directly supporting any fixed frame rate at all. Instead, each frame has its timestamp (by default, the unit is 0.001 second = 1 millisecond aka 1 ms). A typical example is:

Frame 0 = time 0
Frame 1 = time 42 (fps between Frame 0 and 1 is 1000/42 = 23.809...)
Frame 2 = time 83 (fps between Frame 1 and 2 is 1000/41 = 24.390...)
Frame 3 = time 125 (fps between Frame 2 and 2 is 1000/42 = 23.809...) and so on.

There is also a per-track metadata called DefaultDuration, which might be 41708333 ns (41.708333 ms; ~23.976024168 fps), when an info tool can guess the source video is NTSC (24000/1001 fps) and may show an approximate value of it (e.g. 24 fps, 23.9760 fps, etc.); but it is only the default value. Since each frame has its own timestamp explicitly, this default value is basically irrelevant and unnecessary and generally not used, except maybe when calculating the end time of the very last frame.

This system may look confusing and (in specific cases) indeed it can be inconvenient, yet it is much more flexible this way, since one can use a variable frame rate (VFR) easily. That is how Matroska works. It is a feature - a design decision.

See also: https://matroska.org/technical/notes.html#timestampscale-rounding


@Liisachan Thanks for that, I noticed the DefaultDuration in the Header Editor section & it states 41708333 for 24000/1001 & I heard 41708375 is 23976/1000 but even files with 23976/1000 still have the DefaultDuration listed as 41708333 so not sure why the Header Editor does not reflect the small 42 ns difference, perhaps you may know why MKVToolNix's libebml + libmatroska is causing intermittent motion jerkiness where @ProWo's clever ffmpeg-gui program does not on my OPPO BDP-105D player, only TrueHD & E-AC3 JOC streams seem to be affected?

[shae]

Any idea what might make the GUI reject some or most Bluray MPLS files, even though they dump fine with bluray_dump and are also accepted by the Chapter Editor?

The rejected MPLS don't show up when opening the Bluray root (the window that shows the available playlists), nor are they accepted when dropped into the Multiplexer tab, where the GUI says (* = filename dropped):
The file '*.mpls' was not recognized as a supported format (exit code: 0).

[Liisachan]

@Liisachan Thanks for that, I noticed the DefaultDuration in the Header Editor section & it states 41708333 for 24000/1001 & I heard 41708375 is 23976/1000 but even files with 23976/1000 still have the DefaultDuration listed as 41708333 so not sure why the Header Editor does not reflect the small 42 ns difference Do you know the exact command line you're using via your GUI? If it has
--default-duration 0:24000/1001p
then, mkvmerge may set 41708333. While I have no idea why you're having problems with mkvmerge, by comparing the 2 command lines (one that works for you, and the other one that doesn't work well), perhaps you can guess what causes the difference for your specific player. This may be a player-side issue - MKV file written by mkvmerge is most probably well-formed.

(Mkvmerge is not as good at rounding as other muxers, but usually this does not cause any practical problems at all, since the frame timing written by mkvmerge is only off by less than 1 ms, and the frame timing is still off by up to 0.5 ms anyway even if rounding is done normally. If one insists 1 or 0.5 ms errors are too big, one can just use a smaller TimestampScale - mkvmerge can do that too.)

A few things you can try:
1) If you believe that DefaultDuration is problematic for your player, you can set that value as you like, this way:
mkvpropedit "your.mkv" --edit track:v1 --set default-duration=41708375

2) It is possible that ffmpeg automatically "corrects" the audio delay by shifting (delaying) video frame timestamps. To see this, try:
mkvextract "your.mkv" timestamps_v2 0:timestamps.txt

In timestamps.txt, you can see actual time stamps for each frame. If the first frame is not 0, some kind of issues might occur.

Like I said, DefaultDuration should be irrelevant (because each frame has its own timestamp), but some players might depend on this irrelevant number... I don't know. If you create an MKV file with --timestamps, where the first & second frames are 0 and 42 respectively, then
DefaultDuration 42000000 ns (42 ms; ~23.809523810 fps)
may be written, even if the video is essentially 24000/1001 fps, and this is not a problem - such an MKV file plays fine for me. Thus:

3) You can try other players, to see if the problem is in your MKV file itself, or it's your specific player...

[shae]

Is there a way to add custom commandline options in the GUI?

Looking to enable "deterministic".

[derf]

Perhaps the following is unrelated to your issue, but apparently similar problems are also happening due to LAV Filter-side issues. So, if someone has a problem where MPC-HC doesn't show all the audio tracks, various possibilities should be considered. The issue reported at https://forum.doom9.org/showthread.php?p=1963574#post1963574 on 2022-02-09 is:

and clsid's comment is:


So, according to clsid, sometimes this kind of issue is not (directly) related to MKVToolNix nor to MPC-HC itself. I figured maybe I should share this info.
It is the most likely scenario as, like I mentioned, the audio tracks are detected correctly with VLC and Plex.

Also, thanks for the link, I was stuck at MPC-HC 1.7.13 because there were no updates and the website said that development had ceased. Now I can update to 1.9.19! :D

[Liisachan]

@shae
You can go to the "Output" tab, and click the small button by the "Additional options" editbox.

@derf
MPC-BE is also being actively developed.
https://forum.doom9.org/showthread.php?t=165890

[shae]

"Output" tab, and click the small button by the "Additional options" editbox.Thanks.

[Mosu]

Heyo!

just keeping up with my usual release cadence & releasing MKVToolNix v66, a rather small release.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG & Linux AppImage (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

Version 66.0.0 "Josie" 2022-03-13
New features and enhancements

mkvpropedit: added a new option "--chapter-charset" allowing the user to specify the character set to use when reading the following chapter file. Implements #3276 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3276).
MKVToolNix GUI: each language shortcut can now be associated with an optional track name that is set along with the language when the shortcut is used. This is an alternative to the feature requested in #3283 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3283).

Bug fixes

mkvmerge: Ogg/OGM reader: mkvmerge will no longer abort with an exception when it encounters Vorbis comments that contain data that isn't valid UTF-8. Fixes #3290 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3290).
MKVToolNix GUI: multiplexer: fixed several issues with the tab order of elements in the "properties" pane and the "output" tab. Also fixed the language display widgets (e.g. "track language" in the "properties" pane) never receiving tab focus. Fixes #3274 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3274).
MKVToolNix GUI: multiplexer: the chapter name template will now be passed to "mkvmerge" if a chapter file is selected on the "output" tab. Fixes #3295 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3295).


Have fun 😁

[VBB]

Thanks!

[Liisachan]

Thanks, Mosu!

As for that rounding weirdness... the original problem my friends and I were trying to fix was, most probably, related to how ffmpeg works (perhaps "by design"), and your tools are NOT responsible for that one. While investigating, I happened to notice the rounding error in mkvmerge too, but that is not the main problem at all. Technically there may be indeed a problem in mkvmerge like you suggested yourself, rounding down 0.5416... being clearly weird, but this part is practically harmless when muxing video; so, please, don't worry about it too much :)

We've already found a way to avoid the main problem (perhaps related to ffmpeg), and the (harmless) rounding error in mkvmerge could be easily avoided if one would like to. I guess a subtle rounding error might be bad for audiophiles in HA who want 1/44100 sample accurateness, but it's not a real problem for doom9 users at all.

Sorry if I annoyed you & thanks again!

[Mosu]

You never annoy me, Liisachan, and didn't with the recent venture into rounding issues either. Don't worry about it.

[Dogway]

I don't know if this is a limitation, but I tried to set a custom aspect ratio to a H.261 stream but the player (MPC-HC + LAV 0.76 + madVR) didn't recognize it.
I read that H.261 streams don't accept DAR flags but I thought this was done at container level? I'm using v66.0

[shae]

Is there a way to remap PTSes so that frame 0 is at 0:00.00?

[Liisachan]

One can always set (redefine) the timestamp of each frame explicitly:
https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.external_timestamp_files
Matroska is really flexible here.

[shae]

It's plain CFR, so I'm not looking to provide PTS files, but just set the times plainly, where frame 0 is at time 0.
The framerate could either be as set in the source container, or commandline.

[Liisachan]

@shae
MKV is so flexible that it's sometimes counter-intuitive and confusing: you may find it strange that MKV doesn't support "plain old CFR" in general.

@Mosu
1/ My friend is confused, and is complaining about this behavior: Even if "Use legacy MIME types for font attachments" is checked in GUI, it transmuxes the font files attached in existing MKV (without updating MIME types) to a newly written MKV, even without any warning.

2/ When transmuxing MKV to MKV: let's say "foo.ttf" is attached to source MKV - then if one tries to manually add "foo.ttf" (redundantly, so to speak, hoping "overriding" the existing attachment), GUI silently fails to add "foo.ttf" without any error/warning messages. This further confuses an inexperienced GUI user, as to how they can update the font mime type.

[Mosu]

@Mosu
1/ My friend is confused, and is complaining about this behavior: Even if "Use legacy MIME types for font attachments" is checked in GUI, it transmuxes the font files attached in existing MKV (without updating MIME types) to a newly written MKV, even without any warning.

That setting is a GUI-only setting that solely affects how MIME type auto-detection is done (= what the MIME type drop down will be set to when you add a new attachment to your multiplexer job). It has no affect on existing attachments as their MIME type will be kept as-is. Additionally the mkvmerge CLI doesn't have a function for altering the MIME type of existing attachments yet either; so I cannot simply extend the function to existing ones without some serious work.

2/ When transmuxing MKV to MKV: let's say "foo.ttf" is attached to source MKV - then if one tries to manually add "foo.ttf" (redundantly, so to speak, hoping "overriding" the existing attachment), GUI silently fails to add "foo.ttf" without any error/warning messages. This further confuses an inexperienced GUI user, as to how they can update the font mime type.

That might be a bug as a warning should be shown in that case if I remember correctly (but then again, it might not be as you can disable certain warnings in the preferences). I'll look into it.

[varekai]

@Mosu
This is very interesting! Not shure if doable but here goes:
How do I add a ClearSans.ttf to an existing mkv that will be used as subtitle when playing in a mediaplayer lik PotPlayer, MPC-HC or VLC?
I have tried but no subs show up in either player.

Really appreciate your dedicated work with MKVToolNix! :D

Thanks and best regards,
varekai

[Mosu]

Matroska the container format doesn't have provisions for signalling a player to use a certain font (or any other type of attachment). If and how fonts are used is up to the subtitle format in question. The best (only?) supported format using fonts is probably SSA/ASS, which will have to refer to the attached font's name.