MKVToolNix v24.0.0 released

[Mosu]

The GUI writes the modified job files as soon as they're modified. However, the operating system does its own caching, and it's quite normal that such changes stay cached quite a while before they're finally written to disk — especially if the disk is otherwise fully engaged (by writing files via mkvmerge, for example). When a power outage happens, that cached content is lost. Such is life.

Modern file systems only guarantee that they don't suffer structural damage during outages, not that no data is lost. There are ways (a forced flush of the caches), but those do slow down other operations.

Power outages and similar sudden problems (e.g. pressing the hardware reset button) suck.

[hello_hello]

Currently I have MKVToolNixGUI configured so that completed jobs are only removed from the queue if completed without errors or warnings. Rather than have jobs "completed with warnings" sit in the queue until I manually delete them, or until they're automatically removed after "x number of days" (if that option is enabled), when the right click option in the Multiplex window to acknowledge all warning or errors is used, would it make sense for it to also automatically remove the jobs that created those warnings and errors from the queue? I think it does to me. Thanks.

[Mosu]

I disagree. Sorry.

[hello_hello]

Could there be an option? It's just that I almost never use the Acknowledge All Warnings option because I've still got to manually switch to the job tab to remove those jobs manually, which effectively acknowledges all the warnings when they're removed, making the Acknowledge All Warnings function somewhat obsolete. At least for me.

The only time MKVToolNixGUI makes me want to cry a little is when I have to switch to the Job tab to remove a job with a warning because acknowledging that warning didn't get it done, or when I have to switch to the Job tab to abort running jobs, because I still always click the Job Queue tab first expecting to find the Abort button there (my brain apparently insists I'm aborting a job in the queue and won't accept anything else), or when I move the mouse to click the Start Job Queue button at the bottom of the Job Queue window, because the Multiplex tab has a Start Multiplexing button in exactly the same way the Job Queue tab doesn't have a Start Waiting Jobs button, and that still confuses me. ;)

Seriously though, I don't know what it is about the Abort button. I kind of get why it's to be found under the Job Output tab but my brain thinks of that as the "log file" tab and wants all the Job Queue functionality to be found in the Job Queue tab, and I can't get my brain to stop thinking that way. To this day I've still not managed to go directly to the Job Output tab to abort a running job. Oh well..... :)

[Mosu]

I won't add such an option. I simply don't think that being able to configure each and every tiny little thing makes the program easier to use for the majority of users. Additionally, every option I implement adds complexity that I have to test and maintain. Sorry.

[hello_hello]

That's okay, but still being willing to argue.... :)

There's an option to automatically remove jobs resulting in warnings or errors from the queue. If it makes sense to have an option to acknowledge warnings, and an option to remove jobs resulting in warnings from the queue automatically, but to remove them before they're acknowledged, I'll confess the logic escapes me. It almost like highlighting a file in Explorer, hitting delete, watch it disappear, then have Windows confirm you want to delete it.

The "remove jobs with errors/warnings" option seems a little dumb to me because if you don't notice there's a warning or error till after the job completes and you've closed it in the multiplex tab, you've got to re-create it from scratch instead of editing it from the job queue. If I'd acknowledged the warning first though....

For every "acknowledge warning" menu/button found in the GUI, an additional "acknowledge warning and delete job" button/menu would make sense to me, given you can acknowledge warnings under three different tabs in five different places, making it not so much of a little thing.

All hope is not lost though. You can acknowledge and delete in one go by deleting a job from the queue, although that's not without some irony given there's no way to delete a job from the queue without also acknowledging the warning it created.

It's all perspective I guess..... and of course it's your software and up to you. All the work is appreciated anyway. Cheers. :)

[raymondjpg]

Latest version of mkvextract.exe 9.8.0 throws an error on some (not all) mkvs in MeGUI. Reverted to backup (v9.7.1) which still works OK.

I am no expert, but running version 9.8.0 at the command prompt on one of the "problem" mkvs gives "error in the matroska file structure...Resyncing to the next level 1 element". Seems 9.8.0 doesn't like some older mkvs. The new version seemed to work OK in MeGUI on newer mkvs that I had created using recent version of MKVToolNix GUI.

If I am right in my conclusions, will all future versions of mkvextract.exe have this same difficulty with older mkvs?

[Midzuki]

Latest version of mkvextract.exe 9.8.0 throws an error on some (not all) mkvs in MeGUI. Reverted to backup (v9.7.1) which still works OK.

I am no expert, but running version 9.8.0 at the command prompt on one of the "problem" mkvs gives "error in the matroska file structure...Resyncing to the next level 1 element". Seems 9.8.0 doesn't like some older mkvs. The new version seemed to work OK in MeGUI on newer mkvs that I had created using recent version of MKVToolNix GUI.

If I am right in my conclusions, will all future versions of mkvextract.exe have this same difficulty with older mkvs?

You should have "defined" your "problematic MKVs".
In other words, an MKVinfo report at least, or a sample file if possible.

[raymondjpg]

You should have "defined" your "problematic MKVs".
In other words, an MKVinfo report at least, or a sample file if possible.
MKVinfo report of one of the "problem" files:

+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 4
|+ Doc type read version: 2
+ Segment, size 1099639116
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4044)
|+ Segment information
| + Timecode scale: 1000000
| + Multiplexing application: libebml v1.3.0 + libmatroska v1.4.1
| + Writing application: mkvmerge v7.0.0 ('Where We Going') 64bit built on Jun 22 2014 08:19:39
| + Duration: 2589.088s (00:43:09.088)
| + Date: Thu Oct 01 02:02:40 2015 UTC
| + Segment UID: 0xea 0x4a 0xd7 0xd1 0x3b 0x3e 0xeb 0x42 0x48 0xf0 0x8a 0x12 0x89 0x65 0x10 0x04
|+ Segment tracks
| + A track
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 1
| + Track type: video
| + Lacing flag: 0
| + MinCache: 1
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 43 (h.264 profile: High @L4.1)
| + Default duration: 41.708ms (23.976 frames/fields per second for a video track)
| + Video track
| + Pixel width: 1280
| + Pixel height: 720
| + Display width: 1280
| + Display height: 720
| + A track
| + Track number: 2 (track ID for mkvmerge & mkvextract: 1)
| + Track UID: 9028823705323146958
| + Track type: audio
| + Codec ID: A_AC3
| + Default duration: 32.000ms (31.250 frames/fields per second for a video track)
| + Language: und
| + Audio track
| + Sampling frequency: 48000
| + Channels: 6
|+ EbmlVoid (size: 1100)
|+ Cluster

[Mosu]

I am no expert, but running version 9.8.0 at the command prompt on one of the "problem" mkvs gives "error in the matroska file structure...Resyncing to the next level 1 element".

That is not an error, it's a warning. If MeGUI treats warnings as something fatal, then that's a bug in MeGUI. The warning is intentional in that it notifies the user of potential loss of data due to corruption.

My guess (!) is that MeGUI treats an exit code of 0 as success and anything else as a fatal error. That's not how mkvextract (and my other tools) work:

Exit code 0 = everything was OK
Exit code 1 = there were non-fatal warnings
Exit code 2 = there was a fatal error
Anything else = there is a bug in the tool, because this should never happen

Situations such as the one mentioned above should generate a warning and have mkvextract exit with exit code 1. MeGUI should treat that as "well, it did something, and the user probably wants to see the warning in question", not as "that did not work at all".

The problem is really two things: your broken file and MeGUI's handling of such a situation (if my guess at what's happening is correct). The old behavior of mkvextract was just wrong; it was lying about how successful it was — it was still encountering the issue and trying to deal with it. It just wasn't signalling this to the calling process (meaning it would exit with exit code 0 even though there was a warning, which is simply wrong). The new behavior is the correct one as it gives the calling tool more information about what actually happened.

[raymondjpg]

Thanks for your explanation. The mkvextract.exe warning message did indeed appear for both v9.8.0 and v9.7.1 when run with the "problem" file at the command prompt, but delivered output as required in both cases. So it looks as if the issue is with MeGUI tolerating the warning in v9.7.1, but not v9.8.0. I'll keep using v9.7.1 until MeGUI updates to tolerate v9.8.0, if indeed that happens in time.

[hubblec4]

Hi Mosu

Short question:
Are there deprecated language codes which you filter and transform, like country codes(gb,tp)?

[Mosu]

Yes, there are:

scr → hvr
scc → srp
mol → rum

[arrgh]

hi
I have a feature request...
with MPC-BE/LAV-Filters /XySubFilter/madVR one can playback 3D-mkv like those produced with MakeMKV;

if for some reasons one needs to remux/rebuild such files one needs to preserve the individual 3D-plane for each subtitle...

one can do this by adding a small tag file (XML format, see appended txt-example) to each individual subtitle stream...

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Tags SYSTEM "matroskatags.dtd">

<Tags>
<Tag>
<Simple>
<Name>3d-plane</Name>
<String>6</String>
</Simple>
</Tag>
</Tags>

http://www.bilder-upload.eu/show.php?file=53958d-1486497309.jpg

it would be easier just to input this, like for example the delay...

Best Regards

[raymondjpg]

The problem is really two things: your broken file and MeGUI's handling of such a situation (if my guess at what's happening is correct). The old behavior of mkvextract was just wrong; it was lying about how successful it was — it was still encountering the issue and trying to deal with it. It just wasn't signalling this to the calling process (meaning it would exit with exit code 0 even though there was a warning, which is simply wrong). The new behavior is the correct one as it gives the calling tool more information about what actually happened.
I have found that mkvextract.exe 9.8 causes MeGui to exit with an error when processing most of the mkv files in my archives. The behaviour is not just confined to the one file I posted details on, which you suggest is "broken".

As a result I have reverted to mkvextract.exe 9.7.1 which does not cause MeGui to exit with an error.

I'm sure that non-technical users would prefer a version of mkvextract.exe that works with MeGui than to know that the new behaviour of mkvextract.exe 9.8 is the correct one.

Ideally I'm sure that non-technical users would prefer to see mkvextract.exe 9.8 working well with all mkv files in MeGui.

[Mosu]

If the file structure is really broken, then exiting with a proper warning is the right course of action. It's really up to MeGUI to handle such cases by not aborting. Like I said, a warning isn't fatal, therefore MeGUI shouldn't treat it as such.

That being said: it's possible that there's a bug in mkvextract: it might show a warning about the file structure in situations where none is warranted. If you can provide me with such a file to test, I'll look into it.

[raymondjpg]

That being said: it's possible that there's a bug in mkvextract: it might show a warning about the file structure in situations where none is warranted. If you can provide me with such a file to test, I'll look into it.
Thank you!

I have uploaded the file I first had problems with, Bones S11E01.

[Mosu]

The file you've uploaded is indeed damaged at the end. The last valid element is located at position 1099639165 with a size of three bytes, meaning the valid content ends at 1099639168. However, the file is 1099639253 bytes long. The difference, 85 bytes, is made up solely of 0 bytes. That's not valid Matroska data. Therefore the warning is indeed valid and not bogus.

The header of that file states that it was written by mkvmerge 7.0.0. I don't know why it wrote such trailing 0 bytes, and neither do I remember a bug regarding such behavior.

I consider mkvextract's current behavior to be correct. Please ask the MeGUI author to treat warnings in mkvextract's execution (= exit code 1) as non-fatal.

[raymondjpg]

The file you've uploaded is indeed damaged at the end. The last valid element is located at position 1099639165 with a size of three bytes, meaning the valid content ends at 1099639168. However, the file is 1099639253 bytes long. The difference, 85 bytes, is made up solely of 0 bytes. That's not valid Matroska data. Therefore the warning is indeed valid and not bogus.

The header of that file states that it was written by mkvmerge 7.0.0. I don't know why it wrote such trailing 0 bytes, and neither do I remember a bug regarding such behavior.

I consider mkvextract's current behavior to be correct. Please ask the MeGUI author to treat warnings in mkvextract's execution (= exit code 1) as non-fatal.
Thank you for looking. I will pass the suggestion on in the MeGUI thread.

[hubblec4]

Yes, there are:

scr → hvr
scc → srp
mol → rum

Many thanks for this info.

[raymondjpg]

I consider mkvextract's current behavior to be correct. Please ask the MeGUI author to treat warnings in mkvextract's execution (= exit code 1) as non-fatal.
The issue has been resolved in MeGUI v2703 without me needing to ask the MeGUI author. mkvextract.exe 9.8 is now working in MeGUI v2703 without error.

Thanks again.

[arrgh]

hi
I have a feature request...
with MPC-BE/LAV-Filters /XySubFilter/madVR one can playback 3D-mkv like those produced with MakeMKV;

if for some reasons one needs to remux/rebuild such files one needs to preserve the individual 3D-plane for each subtitle...

one can do this by adding a small tag file (XML format, see appended txt-example) to each individual subtitle stream...

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Tags SYSTEM "matroskatags.dtd">

<Tags>
<Tag>
<Simple>
<Name>3d-plane</Name>
<String>6</String>
</Simple>
</Tag>
</Tags>

http://www.bilder-upload.eu/show.php?file=53958d-1486497309.jpg

it would be easier just to input this, like for example the delay...

Best Regards

...takes so long to approve even a small txt...

obviously the value "6" is just an example and must be replaced by the correct individual subtitle value

[Mosu]

The issue has been resolved in MeGUI v2703 without me needing to ask the MeGUI author. mkvextract.exe 9.8 is now working in MeGUI v2703 without error.

That's good to hear!

[Mosu]

if for some reasons one needs to remux/rebuild such files one needs to preserve the individual 3D-plane for each subtitle...

If you remux directly from the source Matroska file, then the tags for the track should be kept intact. No need to specify them anew.

[arrgh]

If you remux directly from the source Matroska file, then the tags for the track should be kept intact. No need to specify them anew.

...Mosu,
Sorry, if I might sound harsh, but have you looked lately in the options you provide for subs…?
“language”,.. ”default”,…”forced”,… “delay”,… “stretch”…
But “3d-plane” is not significant…?

I accept it, since I have a work-around and the other 95% do work super-good (don’t get me wrong, I’m happy!), but I think the standardizing process in this respect (handling of 3D-mkv) should be accelerated…

Best Regards
arrgh

[Mosu]

...Mosu,
Sorry, if I might sound harsh, but have you looked lately in the options you provide for subs…?
“language”,.. ”default”,…”forced”,… “delay”,… “stretch”…
But “3d-plane” is not significant…?

"Language", "default", "forced" all correspond to certain track header fields. "delay" and "stretch" affect the timestamp calculation. All of these things are officially supported elements of the Matroska specification.

Your "3d plane" tag is an unofficial tag that some players use to affect something. Big difference.

but I think the standardizing process in this respect (handling of 3D-mkv) should be accelerated…

What's lacking is manpower and people actually knowledgeable and passionate about these things. Regarding 3D video I'm neither. We (as in the Matroska team and the CELLAR working group (https://datatracker.ietf.org/wg/cellar/charter/)) welcome anyone including you to join in the standardization effort (https://www.ietf.org/mailman/listinfo/cellar) that's currently underway. Work on 3D things would most likely be welcome by a lot of people, but it will only get done if people actually step up and do the work. That's how it works with Free/Libre and Open Source software.

[kuchikirukia]

Arrrrgh, it just happened again. Had a power outage and it started remuxing everything muxed since February 8th, and that was a HUUUUUGE list. Thankfully it only screwed one file and was a minor inconvenience for one other since I had to go and fix its UID.

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

[sneaker_ger]

How does that happen? Mosu mentioned something about OS caching but February 8th ...

[kuchikirukia]

How does that happen? Mosu mentioned something about OS caching but February 8th ...

Don't know. I don't even have write cache flushing disabled. I'm only using Windows 10's default write cache.

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.

[ndjamena]

I just remuxed a recorded ts file, there's a section 50 minutes in where it looks like there were problems with the signal, the audio skips on playback and there's some minor pixelation. The ts plays back fine on MPC-HC but upon remuxing with MKVMerge the audio and video after that point in the resulting MKV goes about a second out of sync.

FFMPEG remuxes it fine and its MKV plays back without issue.

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

[Mosu]

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]

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 (https://mkvtoolnix.download/), the Windows installer/portable version & Mac OS DMG (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

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 (https://mkvtoolnix.download/doc/NEWS.md) 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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/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 (https://github.com/mbunkus/mkvtoolnix/issues/1891).

Have fun :)

[Midzuki]

Many :thanks: for yet another update.

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

[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 (https://github.com/mbunkus/mkvtoolnix/wiki/Wrong-frame-rate-displayed). Don't try to play with it unless you know what you're doing as mkvmerge is already doing the right thing.

[ndjamena]

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]

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]

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.


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 (mega:///#!MRAzTaDA!JwYZf8xOEk-LICwW2M16ea6XcfuJomaT5RoZURrbfR0).

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

[Mosu]

MTX is not able to skip the identical frames.

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

[Mosu]

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]

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.