MKVToolNix v24.0.0 released

[Mosu]

Originally Posted by kuchikirukia

Can we get a big "Abort Job Queue" button?

Nope. Not every functionality deserves its own button. The function you're looking for is "Job queue" tool → "Job queue" menu → "Stop job queue" → "Abort all running jobs and stop immediately", or Alt+7 Alt+j t i.

Wasn't just mkvtoolnix, either. I had another program revert a setting I had changed days earlier. Windows 10 really needs a place to submit bug reports.

If power outages are such a common occurrence, and if your computer reacts that badly to them, then I highly suggest you buy a UPS. Those nice devices can protect against power surges, bridge short power outages and shut down the computer cleanly in case the power outage lasts longer.

[Mosu]

Originally Posted by ndjamena

Is this expected behaviour for MKVMerge with this kind of material?

I'm not quite sure how to take this question. To me it sounds like "is mkvmerge supposed to create defective files", to which the answer is obviously "no". mkvmerge is supposed to produce a properly working Matroska file in case of a properly working source file. If it isn't, then chances are it's a bug.

[Mosu]

It's time for v9.9.0 of MKVToolNix. This is mostly a bug fix release. Especially the MP4 input module has received a lot of love. See below for details.

Important note for packagers: pre-built man pages are no longer included. Instead they're built during compilation requiring xsltproc, the DocBook XSL stylesheets. Additionally the system version of pugixml can now be used. See the news below for details.

Here are the usual links: the MKVToolNix home page, the Windows installer/portable version & Mac OS DMG and the source code.

The Windows and Mac OS binaries have been built already and are available for download. The Linux binaries will be available later today.

Here are the NEWS since the previous release:

# Version 9.9.0 "Pick Up" 2017-02-19

## New features and enhancements

* GUI: chapter editor: added a character set selection in the preferences for text files. If a character set is selected there, it will be used instead of asking the user when opening text chapter files. Implements #1874.
* GUI: multiplexer: added a column "character set" to the "tracks, chapters and tags" list view showing the currently selected character set for that track. Implements #1873.
* mkvmerge: added an --engage option "all_i_slices_are_key_frames" for treating all I slices of an h.264/AVC stream as key frames in pathological streams that lack real key frames. Implements #1876.
* GUI: running programs after jobs: added a new variable <MTX_INSTALLATION_DIRECTORY> for the directory the MKVToolNix GUI executable is located in.
* mkvmerge: DVB subtitle tracks whose CodecPrivate data is only four bytes long will now be fixed up to the proper five bytes by adding the subtitling type byte.
* mkvmerge: MP4 reader: "ctts" version 1 atoms are now supported.

## Bug fixes

* mkvmerge: AC-3 handling: some source files provide timestamps for audio tracks only once every n audio frames. In such situations mkvmerge was buffering too much data resulting in a single gap in the timestamps of one frame duration after frame number n - 1 (the second audio timestamp read from the source file was used one output frame too early). Fixes #1864.
* mkvmerge: MP4 reader: mkvmerge was only reading a small part of MP4 DASH files where the first "moov" "mdat" atoms occur before the first "moof" atom. This is part of the fix for #1867.
* mkvmerge: MP4 reader: edit list ("edts" atoms) that are part of the "moof" atoms used in MP4 DASH files weren't parsed. Instead the edit lists from the main track headers inside the "moov" atom were used. This is part of the fix for #1867.
* mkvmerge: MP4 reader: when an MP4 DASH file contained both normal chunk offset table ("stco"/"co64" atoms) in their regular "moov" atoms, a sample-to-chunk table ("stsc" atom) whose last entry had a "samples per chunk" count greater than 1 and DASH "trun" atoms, then mkvmerge was calculating wrong positions the frame content. This is part of the fix for #1867.
* mkvmerge: MP4 reader: mkvmerge couldn't deal with the key frame index table having duplicate entries. The result was that only key frames up to and including the first duplicate entry were marked as key frames in the output file. All other frames weren't, even though some of them were referenced from the key frame table after the first duplicate entry. This is part of the fix for #1867.
* mkvmerge: MP4 reader: when an MP4 file contained more than one copy of the "moov" atom (the track headers etc.), mkvmerge was parsing them all adding tracks multiple times. Fix for #1877.
* mkvmerge: MP4 reader: fixed an integer overflow during the timestamp calculation leading to files with wrong timestamps. Such files could not be played back properly by most players. Fixes #1883.
* mkvmerge: MPEG TS reader: if the PMT lists a DVBSUB track, mkvmerge will now recognize it without having to find a packet for it within the probed range.
* mkvmerge: splitting by parts (both the "timestamps" and the "frames" variants): fixed the calculation of track statistics tags. When calculating the duration the skipped portions weren't taken into account leading to a too-high duration. As a consequence the BPS tag (bits per second) was wrong, too. Fixes #1885.
* mkvmerge: reading files with DVB/HDMV TextSV subtitle tracks with invalid CodecPrivate caused mkvmerge to abort with an error from boost::format about the format string not having enough arguments. Fixes #1894.
* mkvmerge: fixed misdetection of certain AC-3 files as MP3 files which led to an error message that "the demultiplexer could not be initialized".
* mkvmerge: fixed huge memory consumption when appending big Matroska files with sparse tracks (e.g. forced subtitle tracks). The Matroska reader will now queue at most 128 MB of data. Fixes #1893.
* mkvmerge: MP4 reader: the timestamps of all multiplexed tracks will now be 0-based properly.
* mkvmerge: MP4 reader: the DTS-to-PTS offsets given by the "ctts" atoms are now applied for all tracks containing a "ctts" atom, not just h.264 & h.265 tracks.

## Build system changes

* Up to and including release 9.8.0 the man pages and their translations came pre-built and bundled with the source code. Those pre-built files have now been removed and must be built during the build process. Therefore the tool "xsltproc" and the DocBook XSL stylesheets for man pages are now required dependencies. Additionally the tool "po4a" must be installed for the translated man pages to be built and installed, though this is optional.
In order to facilitate finding the new requirements new options have been added to confiure: "--with-xsltproc=prog", "--with-docbook-xsl-root=dir", "--with-po4a=prog" and "--with-po4a-translate=prog.
* pugixml detection will be attempted via "pkg-config" first. If that fails, "configure" will fall back to the previous method of trying just to compile and link a test program with the standard include and library locations. Implements #1891.

Have fun

[Midzuki]

Many for yet another update.

Hmmm, I wasn't aware that the MP4 container is even more evil than I thought

[Rinzler]

Hi, Mosu. I would like to ask about mkvtoolnix and TS files. I have some ts files. Here is Media Info

Video

Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Bit rate : 7 457 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First



Audio

Format : AC-3
Format settings, Endianness : Big
Codec ID : 6
Duration : 2mn 58s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels


I need to remux them to mkv. Should I use software like tsMuxer first to extract streams and then use mkvtoolnix or I can just safely add those ts files in mkvtoolnix?

[Mosu]

Never demultiplex to elementary streams if at all possible. That loses important information such as but not limited to: the timestamps (regarding potential gaps in the track or mixed frame rate), the relationship between the timestamps of all tracks (e.g. video starts 40ms later than audio), track languages…

Just let mkvmerge read the transport stream directly.

Important exception: if you're multiplexing from Blu-rays, don't use the .m2ts files directly. Use the playlists instead (the .mpls files). mkvmerge is able to retrieve much more data from them, e.g. which .m2ts make up that particular playlist, track languages, chapter information. The GUI, if used, can also scan all playlists for you and present you with a nice dialog with information about all playlists such as length, number and types of tracks, size, where you can decide which playlist to actually use.

[Rinzler]

One more question about frame rate. Original ts files are 25.000 fps. I noticed that some file (basically with 720x576 resolution, it does not affect HD videos for some reason) after remux have 50fps in mediainfo. I guess this is because of interlaced video. Is there a way to change it? And should I bother about it at all?

[Mosu]

Matroska does not have an FPS setting. See this FAQ entry. Don't try to play with it unless you know what you're doing as mkvmerge is already doing the right thing.

[ndjamena]

Originally Posted by Rinzler

One more question about frame rate. Original ts files are 25.000 fps. I noticed that some file (basically with 720x576 resolution, it does not affect HD videos for some reason) after remux have 50fps in mediainfo. I guess this is because of interlaced video. Is there a way to change it? And should I bother about it at all?

I think you'll find those files are h264 (h265) where the fields are stored separately rather than as a single frame. MKVMerge puts each of the fields in their own packet, leaving 50 packets per second. MKVMerge then writes the number of packets into the NUMBER_OF_FRAMES track statistics tag and MediaInfo translates that as being 50fps.

I assume this would be the cause of your issue:

Scan type, store method : Separated fields

[Rinzler]

Got it. Thank you for the explanation.

[hubblec4]

Originally Posted by Mosu

Important exception: if you're multiplexing from Blu-rays, don't use the .m2ts files directly. Use the playlists instead (the .mpls files). mkvmerge is able to retrieve much more data from them, e.g. which .m2ts make up that particular playlist, track languages, chapter information. The GUI, if used, can also scan all playlists for you and present you with a nice dialog with information about all playlists such as length, number and types of tracks, size, where you can decide which playlist to actually use.

There is one limitation:
If the Bluray have seamless branching multi-editions, you should demux the streams first (with eac3to).
MTX is not able to skip the identical frames.

[73ChargerFan]

I did not know that! I assumed the different versions would be stored linearly in unique playlists, like Disney BDs which offer multiple playlists that localize the written language, e.g. signs, titles, credits.

Any limitation on duplicate audio packets being removed? Does mkvmerge not function the same as eac3to's second pass?

[hubblec4]

Originally Posted by 73ChargerFan

I did not know that! I assumed the different versions would be stored linearly in unique playlists, like Disney BDs which offer multiple playlists that localize the written language, e.g. signs, titles, credits.

What you mean, are Multi-Angle-Blurays and there is the same behaviour like Multi-Edition-Blurays. All different content of the movie is stored in different m2ts files.

Originally Posted by 73ChargerFan

Any limitation on duplicate audio packets being removed? Does mkvmerge not function the same as eac3to's second pass?

No and no.

I have much Multi-Edition-Blurays tested. With some there was no problems, and for the other: all play fine but the chapter marks don't match correctly. After using my Multi-Editon-Editor from cE with "demux-mode" all works excellent.

Hey Mosu,
Could you implement such functionality? Or is it to much work?

[Overdrive80]

Hi, folks.

I am merging ts files with mkvmerge but I can not get that all characters of teletex subtitle be shown properly. In concrete, characters: á, é, í, ó, ú, ñ. One sample here.

I tried several charset without being able to get it. Any help?? Thanks.

[Mosu]

Originally Posted by hubblec4

MTX is not able to skip the identical frames.

That is correct. I currently don't have plans to implement such functionality.

[Mosu]

Originally Posted by Overdrive80

I am merging ts files with mkvmerge but I can not get that all characters of teletex subtitle be shown properly. In concrete, characters: á, é, í, ó, ú, ñ.

Teletext pages use their own, country-dependent character sets. There's no way to detect them unambiguously. Therefore mkvmerge uses a mapping that depends on the track language, and there's currently no way to override this.

[hubblec4]

Hey Mosu,

Could you explain/show me where and how VOB-Buttons are stored in Matroska.
I found no info in Matroska specs, expect you can use/save such data.

[Mosu]

Not really. Yes, mkvmerge supports such files, but that code was contributed by Steve Lhomme who did some experiments with the whole DVD menu system. I've never used it myself. Sorry.

[ndjamena]

I just ripped a vob file from an NTSC DVD using MKVMerge, remuxed the resulting MKV using TS muxer, then ran the ts file through ccextractor and the 608 captions were still in the video stream...

Is that intentional behaviour? Theoretically if a player could be told they're there those captions should be playable directly from the MKV. In the same situation MakeMKV simply removes them.

What is the correct Matroska way of handling 608 captions in a video stream?

[hubblec4]

Originally Posted by Mosu

Not really. Yes, mkvmerge supports such files, but that code was contributed by Steve Lhomme who did some experiments with the whole DVD menu system. I've never used it myself. Sorry.

I have here a VOB-Button test file. I could find out the VOB-Buttons will be stored as a "normal" track.