MKVToolNix v24.0.0 released

[Mosu]

Oh right, I totally forgot about that. Thanks.

[Nexin]

That example is meant to be recreated with the GUI and not copy paste into a text file. If you need example files for the text format then look in the installation folder, there should be examples (unless I don't package them for Windows... I don't remember at the moment).
Thanks for the info will have to try next simple chapter format with txt files which would be easier.

Having made a simple .txt file for subtitles now extension .srt with a .txt working backup copy. Subtitles are extra comments for the video. Soon realise what I needed was chapters to do this. I didn't check to see if mp4 supported chapters or any software to add .srt or sub-idx to mp4 container but knew mkv could do that and still not sub video hard-copy which is preferred.

Made the chapters using video player to see where each comment subtitle needed to be . Does mkvtoolnix mkmerge have or integrate with a video player we can use to set chapters that is internally sent to mkvmerge for use ?

Your guide that sneaker-ger linked isn't the same as the one in v.7.3.0 package but the same info is there.

[Mosu]

Hey,

I've released mkvtoolnix v7.4.0. It's mostly a bug-fix release, though
kind of important if you mux HEVC or teletext subtitles.

For packagers: nothing has changed since the previous release.

Here are the usual links...

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

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-7.4.0.tar.xz

...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 since the previous release:

2014-12-12 Moritz Bunkus <moritz@bunkus.org>
* Released v7.4.0.

2014-12-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge was sometimes dropping lines from teletext subtitles read from MPEG transport streams. See #773 (https://www.bunkus.org/trac/ticket/773).

2014-12-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The PCM packetizer was producing wrong track statistics by disregarding the last packet's duration when reading PCM data from packaged sources (Matroska, MP4 files). Fixes #1075 (https://www.bunkus.org/trac/ticket/1075).
* build system: enhancement: configure will look for a system version of the pugixml library and use that instead of the bundled version if it is found. Fixes #1090 (https://www.bunkus.org/trac/ticket/1090).
* mkvextract: bug fix for chapter & tag extraction: If locale is set to a non-UTF locale (including C or POSIX) then no XML data was output at all even if the XML data contained ASCII characters only. Fixes #1086 (https://www.bunkus.org/trac/ticket/1086). This also fixes mkvextract writing two BOMs when extracting tags with the »--redirect-output« option on Windows.

2014-11-19 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: summary mode: reported frame types in block groups are now derived from the number of references found and not by the references' values.

2014-11-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed muxing open GOPs after I frames in MPEG-1/2 video (patch by Stefan Pöschel). Fixes #1084 (https://www.bunkus.org/trac/ticket/1084).

2014-11-15 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: VP9 video tracks are accepted in WebM mode.

2014-11-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Cherry-picked several commits from DivX' mkvmerge fork for improved HEVC handling. Fixes #1076 (https://www.bunkus.org/trac/ticket/1076).
* all: new feature: added a Catalan translation of the programs by Antoni Bella Pérez (see AUTHORS).

2014-11-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the handling of Big Endian PCM tracks read from MP4 files. Fixes #1078 (https://www.bunkus.org/trac/ticket/1078).

Have fun.

[Boulder]

Thanks again for a new version!

[hubblec4]

This also fixes mkvextract writing two BOMs when extracting tags with the »--redirect-output« option on Windows.

Yes it works. Thanks a lot.

[AYColumbia]

Thank you Mosu. Don't forget to change thread title. ;)

[73ChargerFan]

End of year - time for everyone to donate!

[Gravitator]

Happy New Year!!!
Check the file > NX1_UHD_30p.mp4 (http://forum.videohelp.com/attachments/28897-1417273258/NX1_UHD_30p.mp4) (does not see a video stream HEVC).

[Mosu]

Thanks. In my current development version reading h.265/HEVC from MP4 has already been implemented. Still, mkvmerge didn't recognize the video track out of the box, but I only had to add »hev1« as yet another FourCC for h.265/HEVC video and it started working.

[Mosu]

Hey,

I've released MKVToolNix v7.5.0. It contains a lot of new features dealing with h.265/HEVC video & AAC audio, some minor assorted enhancements and quite a number of bug fixes – especially some which prevent invalid memory access.

MKVToolNix' own configure script has therefore been changed to look for the libraries via their respective pkg-config files. This means that the configure options »--with-extra-includes« and »--with-extra-libs« don't affect the detection of libEBML/libMatroska anymore. Instead you can set the environment variable »PKG_CONFIG_PATH« to where the pkg-config scripts of libEBML and libMatroska are located.

MKVToolNix' own configure script has therefore been changed to look for the libraries via their respective pkg-config files. This means that the configure options »--with-ebml-headers«, »--with-ebml-libs«, »--with-matroska-headers« and »--with-matroska-libs« are not supported anymore. Instead you can set the environment variable »PKG_CONFIG_PATH« to where the pkg-config scripts of libEBML and libMatroska are located.

Here are the usual links...

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

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-7.5.0.tar.xz

...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 since the previous release:

2015-01-04 Moritz Bunkus <moritz@bunkus.org>
* Released v7.5.0.
* mkvmerge: bug fix: If the target drive is full then a nicer error message is output instead of simply crashing due to an uncaught exception.
* mkvmerge: bug fix: Fixed reading MPEG transport streams in which all PATs and/or PMTs have CRC errors. Fixes #1100 (https://www.bunkus.org/trac/ticket/1100).

2015-01-03 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: Re-wrote the whole checksum calculation code. This lead to a fix for the Adler32 checksum algorithm that was triggered under certain circumstances. Adler32 is used in mkvinfo's output (e.g. in summary mode or if checksums are activated), in the h.265/HEVC bitstream and TrueAudio (TTA) file headers.

2015-01-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed handling of HE-AACv2 with object type »parametric stereo«.
* mkvmerge: new feature: implemented support for MP4 DASH files. Implements #1038 (https://www.bunkus.org/trac/ticket/1038).

2014-12-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: implemented reading MPEG-H p2/HEVC video tracks from MP4 files. Implements #996 (https://www.bunkus.org/trac/ticket/996).

2014-12-30 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: track statistics: the duration (and therefore the estimated bitrate) was wrong for files in which the frame with the maximum timecode wasn't the last frame in the file. Fixes #1092 (https://www.bunkus.org/trac/ticket/1092).
* mkvmerge: new feature: implemented support for AAC in LOAS/LATM multiplex if read from MPEG transport streams or raw LOAS/LATM AAC files. Implements #877 (https://www.bunkus.org/trac/ticket/877) and fixes the underlying issue in #832 (https://www.bunkus.org/trac/ticket/832).

2014-12-21 Moritz Bunkus <moritz@bunkus.org>
* build system: libEBML and libMatroska have been changed to provide pkg-config configuration files. Therefore MKVToolNix' build system has been switched to look for both libraries via pkg-config.

2014-12-20 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: several fixes have gone into libEBML and libMatroska that prevent illegal memory access (both reading from and writing to unallocated addresses). The bugs #1089 (https://www.bunkus.org/trac/ticket/1089) and #1096 (https://www.bunkus.org/trac/ticket/1096) have thus been fixed.

2014-12-19 Moritz Bunkus <moritz@bunkus.org>
* build system: libMatroska v1.4.2 is now required as part of a fix for #1096 (https://www.bunkus.org/trac/ticket/1096).

2014-12-18 Moritz Bunkus <moritz@bunkus.org>
* build system: libEBML v1.3.1 is now required as a part of a fix for #1089 (https://www.bunkus.org/trac/ticket/1089).
* mkvinfo: bug fix: mkvinfo will abort with a proper error message if the first element found is not an EBML head element. See #1089 (https://www.bunkus.org/trac/ticket/1089).
* all: enhancement: improved exception messages that can occur when reading damaged Matroska files to make it clearer for the user what's happening. See #1089 (https://www.bunkus.org/trac/ticket/1089).

2014-12-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading h.265/HEVC video tracks from MPEG transport streams. Implements #995 (https://www.bunkus.org/trac/ticket/995).
* mkvinfo: bug fix: Timecodes output with ms resolution are now rounded to ms instead of simply cut off. Fixes #1093 (https://www.bunkus.org/trac/ticket/1093).

Have fun.

[filler56789]

Thanks a lot for the fixes and improvements :thanks:

BUT the title of this thread was not updated accordingly ;) :)

[DarkSpace]

* mkvinfo: bug fix: Timecodes output with ms resolution are now rounded to ms instead of simply cut off. Fixes #1093 (https://www.bunkus.org/trac/ticket/1093).
Speaking of timecodes, how do you calculate video timecodes? I tried looking at the source, but from what I recognized*, it seems like you're doing simple rounding when calculating timecodes, and that does not match up with the results I'm getting from mkvmerge with e.g. 24000/1001 fps.
Now what's most interesting about that is, in my opinion, that the results I'm getting are sometimes neither rounded nor truncated (and the standard deviation is lower than with simple rounding, with a different mean) results of the calculation
framenumber / fps = framenumber * fps_denominator / fps_numerator

* I looked at timecode_factory (.h (https://github.com/mbunkus/mkvtoolnix/blob/master/src/merge/timecode_factory.h) and .cpp (https://github.com/mbunkus/mkvtoolnix/blob/master/src/merge/timecode_factory.cpp)), timecodes_v2.cpp (https://github.com/mbunkus/mkvtoolnix/blob/master/src/extract/timecodes_v2.cpp), samples_timecode_conv.h (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/samples_timecode_conv.h), and timecode.h (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/timecode.h). I may have missed something, of course.

[Mosu]

Well, »it depends« ;) For the simplest case in which the source file doesn't provide its own set of timestamps the following happens (see src/output/p_video.cpp):

The timecode in nanoseconds is calculated as 1000000000.0 * number_of_frames_output / frames_per_second.
This value is immediately truncated to an integer (meaning the sub-ns precision is lost).
The packet is handed over to the core muxing code.
When the core muxing code (src/merge/cluster_helper.cpp) writes a packet into the file it has to scale the timecode to the file's timecode scale value whose default is 1000000 (resulting in nanosecond precision). This is done in src/merge/packet.cpp, function normalize_timecodes(), which uses the preprocessor macro RND_TIMECODE_SCALE. The calculation is: timecode_in_scale_units = integer-round(timecode_in_ns / timecode_scale)
That integer-round() function in turn is pretty much only cast-to-double, add 0.5, cast-to-integer.

Timecode factories only come into play in certain situations. If the source container provides timecodes (Matroska, MP4, MPEG TS mostly, MPEG PS mostly…) then those timecodes are used instead.

And then there are situations in which the source container provides timecodes for some but not all packets. MPEG TS and MPEG PS are notable candidates for such behavior, especially for the audio tracks. In such situations the audio packetizers remember the timecode that was provided by the container last and calculate new timecodes from there on (instead of from 0) based on the number of samples.

Of course options like --sync and --timecodes (this is what the factories are for) also apply somewhere.

The initial calculation doesn't have to use floating-point numbers either. Several packetizers only use integer calculation. For example the h.264/AVC parser code does; it simply adds the number of nanoseconds per frame/field to the last known provided timecode.

Internally mkvmerge calculates all timecodes in nanosecond precision. It only scales to the file's precision (timecode_scale) right before it writes out a packet. Yes, such calculations (e.g. adding the number of nanoseconds per frame/field) is prone to rounding errors, but you'd need over a million video frames before this makes any difference to the default millisecond timecodes of a Matroska file.

[manolito]

Are out of range chapters legal in an MKV file?

Sorry if this has been treated before, but I could not find any information about it...

I often need to add chapters at a fixed interval to MKV files. There is a software called MKV Chapterizer which should do exactly what I want, but unfortunately it does not work on my computer.

So I normally use a template chapter file in the OGG format which has chapters up to 4 hours. I manually edit this file to remove out of range chapters before muxing the chapter file into the MKV using MKVMergeGUI.

Just the other day I simply forgot to edit the chapter file so I ended up with an MKV where the movie was under 2 hours, but had chapters for 4 hours. MediaInfo reported all the chapters, they had not been truncated at the end of the movie. And the MKV played flawlessly on all my players.

Is such a file legal by the MKV specs, or am I pushing my luck?


Cheers
manolito

[qyot27]

Which Qt modules do mkvinfo and mkvtoolnix-gui rely on?

I ask, because the Windows builds of mkvinfo and mkvtoolnix-gui crash on startup on pre-SSE2 CPUs (because of Qt5.3+ automatically assuming SSE2 now unless it's disabled during configure), and have since 7.2.0. I was thinking of recompiling everything myself, but I'd rather not build Qt modules I won't need.

It's more of a problem for mkvinfo, since it stops the CLI from being used too.

[DarkSpace]

Well, »it depends« ;) For the simplest case in which the source file doesn't provide its own set of timestamps the following happens (see src/output/p_video.cpp)
Thanks for the quick answer! I'll think about it sometime when I'm more awake, and I'll ask again if I have any questions left.

[hubblec4]

[B]...I often need to add chapters at a fixed interval to MKV files. There is a software called MKV Chapterizer which should do exactly what I want, but unfortunately it does not work on my computer.



Hi manolito

You can try my chapterEditor (windows only).

It is based on the chapter editor in the mmg, with a lot of more functions.

[Mosu]

Are out of range chapters legal in an MKV file?

There are no limitations on the chapter timecodes with respect to the whole file's timecodes.

[Mosu]

Which Qt modules do mkvinfo and mkvtoolnix-gui rely on?

I ask, because the Windows builds of mkvinfo and mkvtoolnix-gui crash on startup on pre-SSE2 CPUs (because of Qt5.3+ automatically assuming SSE2 now unless it's disabled during configure), and have since 7.2.0. I was thinking of recompiling everything myself, but I'd rather not build Qt modules I won't need.

It's more of a problem for mkvinfo, since it stops the CLI from being used too.

Some clarification on which GUI toolkits are used by which program: mmg doesn't use Qt at all but wxWidgets. mkvinfo has two GUI implementations, one based on wxWidgets and one based on Qt; the Windows build currently uses Qt 5.3.1. The new mkvtoolnix-gui is based on Qt, again built with 5.3.1.

So with the current Windows builds you get: mmg built with wxWidgets 3.0.0; mkvinfo & mkvtoolnix-gui built with Qt 5.3.1.

I wasn't aware of the SSE2 requirement. Do you know which option to pass to Qt's configure? I can certainly do without such a strict requirement; it's not as if I'm using Qt for anything performance-sensitive.

If you're building from source then you can build mkvinfo with wxWidgets, of course, completely circumventing the problem for the time being. If you're building with Qt then you do need Qt 5.x, though I'm currently uncertain of the minimum version required – probably 5.2.x. As for the Qt modules: both GUIs are compiled with and linked against the following pkg-config elements: Qt5Core Qt5Gui Qt5Widgets Qt5PlatformSupport (just the basics here – no SQL, no QtQuick, no HTML so far, but that may change once help support has been implemented).

Edit: Also note that I'm cross-compiling from Linux for Windows with the MXE project (http://mxe.cc/). I've never built directly on Windows (e.g. with Cygwin or mingw or even Visual C++), and that's not something that I support in any shape or form. Build instructions are available (https://github.com/mbunkus/mkvtoolnix/blob/master/README.Windows.txt), though they're slightly outdated and somewhat incomplete (e.g. no mention of how to build a 64bit version).

[sl1pkn07]

try to add "-no-sse2" in your Qt5 build options (no need in 64bits environment. only if build lib32 libs)

https://bugreports.qt-project.org/browse/QTBUG-35430

[Mosu]

I've re-built Qt 5.3.1 with -no-sse2 as well as MKVToolNix with that newly built Qt. You can get the build here (build number 642) (https://www.bunkus.org/videotools/mkvtoolnix/win32/pre/).

[qyot27]

Thanks.

Some clarification on which GUI toolkits are used by which program: mmg doesn't use Qt at all but wxWidgets. mkvinfo has two GUI implementations, one based on wxWidgets and one based on Qt; the Windows build currently uses Qt 5.3.1. The new mkvtoolnix-gui is based on Qt, again built with 5.3.1.

So with the current Windows builds you get: mmg built with wxWidgets 3.0.0; mkvinfo & mkvtoolnix-gui built with Qt 5.3.1.
If you're building from source then you can build mkvinfo with wxWidgets, of course, completely circumventing the problem for the time being. If you're building with Qt then you do need Qt 5.x, though I'm currently uncertain of the minimum version required – probably 5.2.x. As for the Qt modules: both GUIs are compiled with and linked against the following pkg-config elements: Qt5Core Qt5Gui Qt5Widgets Qt5PlatformSupport (just the basics here – no SQL, no QtQuick, no HTML so far, but that may change once help support has been implemented).
Ok, I wasn't sure if the wxWidgets GUI for mkvinfo had been removed, since the recent Changelog entries only mention the Qt one. I wasn't having issues with mmg, that's why I didn't mention wxWidgets (and I'd worked out how to cross-compile wxWidgets for another project some time ago).

Edit: Also note that I'm cross-compiling from Linux for Windows with the MXE project (http://mxe.cc/). I've never built directly on Windows (e.g. with Cygwin or mingw or even Visual C++), and that's not something that I support in any shape or form. Build instructions are available (https://github.com/mbunkus/mkvtoolnix/blob/master/README.Windows.txt), though they're slightly outdated and somewhat incomplete (e.g. no mention of how to build a 64bit version).
Likewise, I usually only ever cross-compile, albeit from a manually-built toolchain. Aside from Qt, the only dependencies mentioned in the README that I hadn't already worked out instructions for with other projects were gettext (not for lack of trying, though), file, and lzo.

[Mosu]

The relationship goes something like this:

mkvinfo's GUI is the wxWidgets version by default unless you tell configure »--enable-qt«. If you do mkvinfo's Qt GUI is built instead.

If you »--enable-qt« then you can also tell configure »--with-mkvtoolnix-gui« which will build the mkvtoolnix-gui (the preview of the mmg rewrite with Qt).

If you're generally cross-compiling then I strongly suggest that you take a look at MXE. I've used a self-built chain myself in the past, but keeping it up to date regarding the mingw version, the required patches (and build instructions) for the various libraries etc. proved to be a lot of work. With MXE you get a 32bit compiler, a 64bit compiler, a static build and shared build (still work in progress) – and all of that is pretty darn easy to set up and use afterwards.

You can still read my build instructions for Windows (https://github.com/mbunkus/mkvtoolnix/blob/d50315e0fd5e890516079b80ec0d5bdcfd7ade1f/README.Windows.txt) before the change to MXE. Maybe it'll help you somewhat if you don't want to give MXE a try.

[Simon88]

Hi Mosu,

I was going to upgrade to mkvtoolnix is v7.5.0 today and notice FOSSUB has changed their D/L procedures and now forces one to download their small *.EXE stub first (Free_Download.exe or Free_Download_Setup.exe). I don't know if it is malware, spyware, or whatnot, but I've seen a few other sites are doing this as well.

I just went to your old bunkus site and D/L it instead... You might consider changing to sourceforge, sites.google, or some other place.

Edit: after I hit cancel a few times, and try to D/L again, it no longer tried to force feed their *.EXE stub. Appears they wrote something to my cookie file indicating, I'm smart enough not to download their stub file and the correct *.EXE now downloads.

[Mosu]

The correct place to download is http://www.fosshub.com/MKVToolNix.html (intentionally not linked). I can download from there just fine without going through a different exe, especially not anything with free in the name.

Did you click on the link on my site? Did you Google for it? Type the URL from memory?

Note that the FossHub.com admin staff is very forward with their projects regarding any changes in their infrastructure and procedures, and I haven't heard anything about any forced setup.exe. It also goes against pretty much everything they're working on.

Therefore I think you've simply visited the wrong site.

[Simon88]

I think I got it now, some sort of pop-up windows overlaps EXACTLY over my present window and it re-directs me to: http://www.soft-disc.com/lp/free-download/552/ with a D/L button immediately next to it.

Very tricky of FossHub... a bit un-ethical perhaps.. But I guess they must pay the bills... I had to switch windows to get back at the link. Thanks Mosu...

[Mosu]

I'm pretty certain that they're not doing it on purpose but that such a popup is the result of one of the advertisements. I'll contact the FossHub.com stuff about it.

[foxyshadis]

I think I got it now, some sort of pop-up windows overlaps EXACTLY over my present window and it re-directs me to: http://www.soft-disc.com/lp/free-download/552/ with a D/L button immediately next to it.

Very tricky of FossHub... a bit un-ethical perhaps.. But I guess they must pay the bills... I had to switch windows to get back at the link. Thanks Mosu...

That's the ad broker's fault, not Fosshub. Contact them with a screenshot and they'll immediately remove the offending ad (and possibly the whole broker). Ads pay the bills, but some go rogue and have to be removed.

[Mosu]

It was indeed due to an ad. Sam, the admin from FossHub.com, has taken a look and disabled the offending ad. Here's what Sam said/wrote:

Hello,

Mr. Moritz Bunkus, thank you for reporting this!

NO! Under no circumstances we would be doing this. I assume it is a bad advertiser that somehow has managed to bypass our ads. I am manually reviewing all the ads 1-2 times a day and didn't noticed anything like that. Obviously if you can ask that user to show a screenshot we will be blocking that advertiser and its crappy ads immediately!

I will look ASAP based on the info the user has posted and look-up for any similar ads matching his words.

I repeat, we are not associated or promoting anything like that - that single ad Google Adsense ad is our only source of revenue and as I said we are blocking ads.

Regards, Sam - FossHub

Later:

Hello,

Mr. Moritz Bunkus, another update, I just search by "soft" word and indeed there was an advertiser named "soft-disc.com". The reason for not seeing that ad was because of an internal error from Google that was not showing me the entire ad correctly - please take a look at the screenshots.

If I would've noticed that ad - the entire ad it would've been blocked.

I apologize for this, I will try to post on the forum and explain what happened.

Regards, Sam - FossHub

He had difficulties registering an account, therefore I'm posting this in his stead.

Anyway, I hope this eases your worries.

[Simon88]

Thanks Mosu & foxyshadis,

I just went to http://www.fosshub.com/MKVToolNix.html again and the offending ad is no longer there. Now it's just a simple "non-rogue" banner ad from some other company...

Good to see FossHub was so proactive in disabling the offending ad... :)

[LeMoi]

Even though the Windows shortcut of mkvmergeGUI is set to open the program in a maximized window, it doesn't. It used to with previous versions (but I don't know in which version it started to behave like that...).

[Mosu]

Sorry, but I don't fix such issues with the old GUI anymore.

[LeMoi]

OK, I hope the new GUI is coming soon... Even if the window is maximized, when the muxing process begins, the progression windows is not in a maximized window

[DarkSpace]

For the simplest case in which the source file doesn't provide its own set of timestamps the following happens (see src/output/p_video.cpp):

The timecode in nanoseconds is calculated as 1000000000.0 * number_of_frames_output / frames_per_second.
This value is immediately truncated to an integer (meaning the sub-ns precision is lost).
The packet is handed over to the core muxing code.
When the core muxing code (src/merge/cluster_helper.cpp) writes a packet into the file it has to scale the timecode to the file's timecode scale value whose default is 1000000 (resulting in nanosecond precision). This is done in src/merge/packet.cpp, function normalize_timecodes(), which uses the preprocessor macro RND_TIMECODE_SCALE. The calculation is: timecode_in_scale_units = integer-round(timecode_in_ns / timecode_scale)
That integer-round() function in turn is pretty much only cast-to-double, add 0.5, cast-to-integer.
I tried building something like what you described here, but it doesn't quite work yet. I also looked at the source code you mentioned, but I couldn't find anything where I might have misunderstood your description, so I'm somewhat puzzled right now, and hope that you can provide further answers.
Nitpick: "scale the timecode to the file's timecode scale value whose default is 1000000 (resulting in nanosecond precision)" in list item #4 - I think you meant "millisecond precision" there.

The initial calculation doesn't have to use floating-point numbers either. Several packetizers only use integer calculation. For example the h.264/AVC parser code does; it simply adds the number of nanoseconds per frame/field to the last known provided timecode.
For what it's worth, I tried both frame-based timecode calculation and timecode incremention, but neither quite worked.

For easier testing, I tried emulating the timecode generation mechanism in Python 3, using the following code:
import decimal
import fractions

def _tcns(frame, rate=fractions.Fraction(24000, 1001), shift_ns=0):
"""
Returns a decimal.Decimal that represents the timecode at frame, truncated to
nanoseconds.
"""
return decimal.Decimal(10**9 * frame // rate) + int(shift_ns)

def _tcscale(tcns, scale=10**6):
"""
Scales the decimal.Decimal timecode, plus shift scaled to ns, in nanosecond
precision to the specified timecode scale, and returns the result as int.
"""
raw = tcns / scale
time = raw.quantize(decimal.Decimal('1'), rounding=decimal.ROUND_HALF_DOWN)
return int(time)

def tc(frame, rate=fractions.Fraction(24000, 1001), scale=10**6, shift_ns=0):
"""
Calculates the timecode at the specified frame number at the given frame rate
plus the specified shift using direct calculation.
"""
tcns = _tcns(frame=frame, rate=rate, shift_ns=shift_ns)
return _tcscale(tcns, scale=scale)

def inc(frame, rate=fractions.Fraction(24000, 1001), scale=10**6, shift_ns=0):
"""
Calculates the timecode at the specified frame number at the given frame rate
plus the specified shift by incrementing the timecode at frame 1.
"""
tcns = frame*_tcns(frame=1, rate=rate, shift_ns=0) + int(shift_ns)
return _tcscale(tcns, scale=scale)
For my tests, I created an h264 video of 480,000 frames length at 24000/1001 fps, which I muxed into mkv using mkvmerge --output out.mkv --default-track 0:True --forced-track 0:False --default-duration 0:24000/1001p in.264 and extracted the video stream's timecodes into a file using mkvextract timecodes_v2 out.mkv 0:timecodes.txt (is it possible to output the timecodes to stdout using some special switch?), which I then compared my functions' results with.

My tests showed that for the end result, it is irrelevant whether I calculate using a fraction or a 64-bit floating point value (I went with a fraction because it seems cleaner to me), and that in order to be consistent with your integer-round(), I would have to round down half values.
Even so, however, I get 143748 mismatches between my function's (tc) results and the timecodes that mkvmerge produced, of which a subset of 114998 mismatches still exists when using the incremental timecode generation (inc).
Usually, I'd expect that I need to re-check my calculations, because when my results are wrong, they're always one ms too large (the difference between the reference timecode from the mkv file and my calculated timecodes (before rounding) is always between -0.458334 and 1.125).
I already did that, however, trying all kinds of permutations of using fractional or floating point values, and the mismatches remain. This leads me to believe that
my calculations are incorrect,
my interpretation is incorrect,
there is a weird floating point behavior in C++ which is different in Python3,
you calculate the full timecodes at special frames (I-frames?) rather than just incrementing them and then continue incrementing from there,
the fps information from the raw h264 file (which also says 24000/1001 fps) somehow influences the timecode generation even though I specified the --default-duration*,
or a combination of the above.
If it helps, I can supply the video (it's just a blank screen at max. qp, the filesize is ~7.5 MB), the timecodes, or any other requirements for reproducing my issues.

* If I specified a default duration and provided some timecode (v2) files, would the default duration take care of the remaining frames if the timecode file is incomplete? If the timecode file is complete, will the value still be written to the header (e.g. if I want to write a default duration of 120p for a VFR file of mixed 24, 30, and 60 fps)?

[Mosu]

I'm sorry, but I'm not really interested in debugging your Python code. Note that mkvmerge doesn't use fractions internally, it uses 64bit integers with nanosecond precision. Meaning that your default duration of 24000/1001fps is parsed as as 41708333 (https://github.com/mbunkus/mkvtoolnix/blob/master/src/merge/mkvmerge.cpp#L414), and that is given to the h.264 packetizer code. The h.264 packetizer code in turn uses half of that value (https://github.com/mbunkus/mkvtoolnix/blob/master/src/output/p_avc.cpp#L68), 20854166, (because it deals in fields and not in full frames) and passes that to the h.264 parser code. The h.264 parser in turn uses that forced value as its internal value for the duration of a single field (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/mpeg4_p10.cpp#L1500).

[DarkSpace]

I'm sorry, but I'm not really interested in debugging your Python code. Note that mkvmerge doesn't use fractions internally, it uses 64bit integers with nanosecond precision. Meaning that your default duration of 24000/1001fps is parsed as as 41708333 (https://github.com/mbunkus/mkvtoolnix/blob/master/src/merge/mkvmerge.cpp#L414), and that is given to the h.264 packetizer code.
Thank you. I checked, and I got the same value for my code, so I know that this part was correct.

The h.264 packetizer code in turn uses half of that value (https://github.com/mbunkus/mkvtoolnix/blob/master/src/output/p_avc.cpp#L68), 20854166, (because it deals in fields and not in full frames) and passes that to the h.264 parser code. The h.264 parser in turn uses that forced value as its internal value for the duration of a single field (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/mpeg4_p10.cpp#L1500).
And that's where my error was, thank you. I calculated the frame's timecode, rather taking the integer half of that timecode and multiplying it by two.
Now I'm down to exactly one error (at 480000), but I'm going to check my maths first.
Thanks again for the quick response!

[DarkSpace]

Now I'm down to exactly one error (at 480000), but I'm going to check my maths first.
So I re-checked my calculation steps, but I found no error.
According to my insights (read: your information) so far, at 24,000/1,001 fps (h264), the timecode for frame #480,000 should be 20,019,999.36 ms (rounded to 20,019,999), yet the timecode file says that mkvmerge calculated 20,020,000 ms there.
I reached the 20,019,999.36 value the following way:
## ** denotes the power operator; // denotes integer division
duration = 10**9 // (24,000/1,001) # equivalent to int(10**9 / (24,000/1,001)) ### 41,708,333
duration_per_frame = duration - (duration % 2) # I'm dealing with progressive content here ### 41,708,332
timecode_ms = 480,000*duration_per_frame / 10**6 # the nanosecond value, scaled to ms, in floating point ### 20,019,999.36
timecode = round_half_up(timecode_ms) # I was wrong, I have to round up for half values, after all ### 20,019,999
Do you know anything about how mkvmerge reaches 20,020,000 as a result, even though it (presumably) also increments the field-duration?

[Mosu]

No, I don't. Sorry.

[DarkSpace]

Thanks anyway. In the meantime, I found out that this affects only the last frame, if it happens (it happened with a length of 480,000 and 1,200,000, but not with 1,200,001), so I guess I'll ignore it.

[73ChargerFan]

Ah, edge cases...

[hubblec4]

Hi Mosu

Is it possible to change the duration info for a Matroska file with nanosecond precision in the output of mkvinfo.exe?

|+ Segment information size 160
| + Timecode scale: 1000000 size 7
| + Muxing application: libebml v1.3.1 + libmatroska v1.4.2 size 38
| + Writing application: mkvmerge v7.5.0 ('Glass Culture') 32bit built on Jan 4 2015 16:37:25 size 72
| + Duration: 1.024s (00:00:01.024) size 7
| + Date: Sun Jan 11 19:34:03 2015 UTC size 11
| + Segment UID: 0x8d 0x9e 0xca 0x68 0xc3 0x5e 0x44 0xb0 0xb8 0x4c 0x77 0x47 0xd8 0x59 0x21 0xdf size 19

Optionally you could output the frames and the fps.

[Mosu]

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.

One option would be to add a switch that enables outputting all timecode values in ns. However, this would require a couple of hours of work and is not something I'm about to do any time soon.

[Korgnex]

Anyone else having strange issues with splitting a mkv file (encoded with H.264, default settings with mkvmerge GUI (7.5.0)?

I want to split a file into 2 at certain time stamps. However it always ignores those and makes the split about 5 seconds later. When I try it a different way by creating chapters and saving them into the mkv, then load it again and tell it to split by chapters, it still ignores that and makes EXACTLY the same unwanted split as before, 5 seconds from where I told it to split.

The file isn't corrupt either, nothing strange at the beginning of the file, so playback of video and audio is without any flaws from first second to last one.

This is almost like Handbrake used to behave before its recent update. I have a feeling mkvmerge GUI is buggy and currently can't do a simple split job.

[HeadlessCow]

Anyone else having strange issues with splitting a mkv file (encoded with H.264, default settings with mkvmerge GUI (7.5.0)?

I want to split a file into 2 at certain time stamps. However it always ignores those and makes the split about 5 seconds later. When I try it a different way by creating chapters and saving them into the mkv, then load it again and tell it to split by chapters, it still ignores that and makes EXACTLY the same unwanted split as before, 5 seconds from where I told it to split.

The file isn't corrupt either, nothing strange at the beginning of the file, so playback of video and audio is without any flaws from first second to last one.

This is almost like Handbrake used to behave before its recent update. I have a feeling mkvmerge GUI is buggy and currently can't do a simple split job.


You can only split at video keyframes. Is there one at the point you're trying to split?

[Mosu]

mkvmerge is not a video encoder and can therefore split at key frames. Due to technical reasons mkvmerge splits right before the first key frame after the split point. This is not a bug but conscious design.

[Korgnex]

There is about 7 seconds blank screen before a new scene starts. Is that a key frame??
I tried to cut within that segment at any possible moment. Yet whatever I enter into "Global ==> Splitting ==> split after duration", it simply cuts too late - already INTO the new scene - as if the just mentioned method the GUI provides doesn't work.

Or does splitting not work the way I assumed it to do? How else would I split it then?

[hubblec4]

Or does splitting not work the way I assumed it to do? How else would I split it then?

mkvmerge can split a video only at keyframes. it seems you have not a key frame in your video that correspond to your cut time stamp.

the next following key frame will be used for cutting.

you have to check your video with DGIndexNV or AVIDemux to get information about the key frames.

when you encode a video then allways create a key frame for cutting for this specified time stamp.

[Korgnex]

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.

[Asmodian]

This is one of those "of course it works like that" limitations for those experienced with video but it does make sense to let novice users know. It is slightly more complicated due to the behavior being dependent on the video format. A small mention in the help file could be nice, if the tool tip is too full. :)

[foxyshadis]

I was going to say "Use AviDemux", but it turns out its smart copy function is only for MPEG-4 ASP. The only ones out there for AVC are SolveigMM Video Splitter (http://www.videohelp.com/tools/SolveigMM-Video-Splitter) and VideoReDo (http://www.videohelp.com/tools/VideoReDo), both with a right hefty price tag.

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.