MKVToolNix v24.0.0 released

[Mosu]

Right! But the TrackNumber (like EBML variable-sized integer) can't be zero, because Tracknumbers start at 1, right?

That's correct, at least from the point of view of the specification. It states that the track number must not be 0. However, from a purely technical point of view, there's nothing preventing someone from creating a file with a track number of 0. That would still require one byte in the Block/SimpleBlock structures, though (value 0x80).

@mkver
Would you do this? I think your English is better.

I've just filed this issue (https://github.com/Matroska-Org/matroska-specification/issues/213).

[mkver]

TrackNumber can't be zero because the spec don't allow zero as a TrackNumber ("But the TrackNumber [..] can't be zero, because Tracknumbers start at 1" is circular reasoning); the size encoded in an EBML variable-sized integer can be zero (although the coded EBML variable sized integer can't be). You can even encode a size of zero in an EBML integer with 8 octets.

[psychoboust]

Hello,
a question about TrueHD and AC3 Core.

Do you think we will get one day the availabilty to have a truehd and ac3 core in the same track (like m2ts) or this feature will never be added to the mkv spec ?

Thks a lot for your work

[nevcairiel]

Do you think we will get one day the availabilty to have a truehd and ac3 core in the same track (like m2ts) or this feature will never be added to the mkv spec ?

This "feature" is not useful for MKV.

If you want it to be able to re-create a m2ts with a combined track later, it still wouldn't help you, since you need a m2ts muxer that can write the additional metadata required to clearly split these two tracks - and if it can do that, it would also be able to just take a truehd and ac3 track separately and combine them.

[Mosu]

Do you think we will get one day the availabilty to have a truehd and ac3 core in the same track (like m2ts) or this feature will never be added to the mkv spec ?

No. The only reason for having both in the same track is so that existing players that support the older AC-3 but not the newer TrueHD can still play the track by only using the AC-3 and skipping over everything else. It's a hack for a hacky format.

This is not a concern for Matroska. If the player does support Matroska, then it's highly likely that it'll be able to do somewhat smart track selection already based on the CodecIDs it supports.

[psychoboust]

This "feature" is not useful for MKV.

If you want it to be able to re-create a m2ts with a combined track later, it still wouldn't help you, since you need a m2ts muxer that can write the additional metadata required to clearly split these two tracks - and if it can do that, it would also be able to just take a truehd and ac3 track separately and combine them.

There won't be space gain ?
1 TrueHD track + 1 AC3 track = 1 TrueHD + Core Track ?

Because for DTS HD
1 DTSHD track + 1 DTS track is different from only one DTSHD+Core track (because it always include the core)[maybe I already have my answer : does TrueHD track can exist without core unlike DTS HD ?]

My question is really about the size of the final mkv file (not player support ;-))

Thks !

[Mosu]

TrueHD+AC-3 is not comparable to DTSHD+its core. Two completely different things. Why? Because you can decode TrueHD without AC-3 and AC-3 without TrueHD. However, you cannot decode the DTS HD extension without its core (!). Therefore both TrueHD and AC-3 form their own logical track, they can be used without each other just fine, you don't have to keep them together. With DTS you can separate the core from the HD extension, but then you can only decode the core part, but not the HD-only part.

[psychoboust]

ok, if understand :
a TrueHD + AC3 in the same track from a m2ts should have the same size comparing to a mkv with (the same) 2 tracks (1 TrueHd and 1 Ac3) because Truehd doesn't share information with AC3.

True ?

So we should not call AC3 as Core in TrueHD when in the same track in m2ts file ?

If so, I understand why there is no interest supporting this "feature"

[Mosu]

One could say that the AC-3 part is a lossy representation of the same content that the TrueHD part is a lossless representation of, and that both parts are independent of each other. Of course that's quite a mouthful to say; hence people usually just calling it something else. But yes, calling the AC-3 part a "core" is a misnomer in my opinion.

[psychoboust]

Thanks for your feedback.

I made a simple test with EAC3TO

eac3to.exe "dolby_ATMOS_amaze_lossless-DWEU_.track_4352.thd" acore.ac3 -core
TrueHD/AC3 (Atmos), 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
Extracting AC3 stream...
Creating file "acore.ac3"...

eac3to334>eac3to.exe hd_dts_animated_logo_lossless-DWEU.track_4352.dtshd acore.dts -core
DTS Master Audio, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
Extracting DTS core...
Creating file "acore.dts"...

Even this software tell that AC3 is "embedded" and a different "stream" unlike the DTS which is called "Core"

And to answer my question, if you convert a m2ts to a mkv, TrueHD+AC3 track will have the same size than 1 TrueHD track + 1 AC3 Track. Which is not the case for DTSHD (which can't be separated from its core)

So I Agree, This "feature" is not useful for MKV.

Thks again for your time.

[hubblec4]

Hi Mosu

I have a question about: Split parts by timestamps

The split-times must be ordered? Or can I use something like this:

0s-100s,+600s-700s,+200s-300s

Is MTX so smart to connect different periods of time that are not ordered.

[Mosu]

They have to be sorted as mkvmerge doesn't sort them itself.

[hubblec4]

They have to be sorted as mkvmerge doesn't sort them itself.

It is important NOT to ordered the parts.
The new mkv should be created by this order of the parts.

[Mosu]

Edit: I'm clearly too tired to think clearly about this and not write total rubbish.

mkvmerge processing input once, from start to finish. It cannot jump backwards in time. Therefore the split points you've written will result in an error message during parsing the command line parameters.

[hubblec4]

:-) I saw your first answer, it confused me.

I thought me that this ends up in an error message.
But is it a big work that such split-codes working?

[Mosu]

Yes, huuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuge amount of work. It would involve pretty much rewriting all input, all output modules of mkvmerge as well as the muxer core logic. I can safely say that'll never happen.

[hubblec4]

OK, no hurry next week is good for me :-)

[Arm3nian]

I don't understand how to use a basic function. I add 4 different files, each 25s long, and get a single file which is 25s long. The file has 4 video and 4 audio streams in it. How do I get them to play one after another?

Is it possible to do what I'm trying, or do I have to encode the 4 files into 1.

[hubblec4]

What kind of files, mkv's?

When you like to join files then use "Append to an existing source" option when you load the second file...

[Arm3nian]

That worked, thanks. I was adding all 4 files at the same time.

[Mosu]

Well, hello everyone!

The holidays are always a nice time for coding as the world seems to turn just a tad slower than usual and people are that tiny bit more relaxed. I took the opportunity to work on my backlog and fix quite a number of bugs in mkvmerge. I've also removed those options and features that I had deprecated a year ago.

Another huge change was the near complete rewrite of mkvinfo's internals. The goal is to include its GUI into MKVToolNix GUI in the next release. It won't be a 1:1 copy; instead, the new GUI will have more features. A result is that the output generated by the command-line utility has changed in several ways. See the corresponding NEWS entry below for more details.

An important change for package maintainers is the new requirement for the "cmark" library. Fedora/CentOS/openSUSE already contain the necessary package ("cmark-devel"), whereas Debian/Ubuntu don't just yet (there's the "cmark" package, but that only contains the binary, whereas MKVToolNix needs the library & header files).

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

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

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

# Version 20.0.0 "I Am The Sun" 2018-01-15

## Important notes

Feature removal: several deprecated features have been removed:
mkvmerge: the deprecated options `--identify-verbose` (and its counterpart `-I`), `--identify-for-gui`, `--identify-for-mmg` and `--identification-format verbose-text`
all command line tools: support for the deprecated, old, proprietary format used for option files
all command line tools: support for passing command line options via the deprecated environment variables `MKVTOOLNIX_OPTIONS`, `MKVEXTRACT_OPTIONS`, `MKVINFO_OPTIONS`, `MKVMERGE_OPTIONS` and `MKVPROPEDIT_OPTIONS`

mkvinfo: most of its code was re-written in order to lay the groundwork for including its functionality in MKVToolNix GUI but with more features than the existing mkvinfo GUI. The result is that a lot of its output has been changed slightly while keeping the basic layout. Changes include but aren't limited to:
Several element names are a bit clearer (e.g. `Maximum cache` instead of `MaxCache`).
All timestamps and durations are now output as nanoseconds in formatted form (e.g. `01:23:45.67890123`). All additional formats (e.g. floating point numbers output in seconds or milliseconds) were removed.
Element names for chapters and tags are now translated if a translation is available.
Elements located in wrong positions within the Matroska document are handled better.

While mkvinfo's output is mostly kept very stable, it is not designed to be parsed by other utilities. Even though I've tried hard to cram all changes and cleanups into this version, additional changes may be made in the next couple of releases depending on user feedback and bug reports.

## New features and enhancements

mkvmerge: AVC/h.264 packetizer (framed): access unit delimiter NALUs will now be removed. Implements #2173 (https://github.com/mbunkus/mkvtoolnix/issues/2173).

## Bug fixes


mkvmerge: AVC/h.264 parser: when fixing the bitstream timing information mkvmerge will now use exact representations of the desired field duration if possible. For example, when indicating 50 fields/second `num_units_in_tick` is set to 1 and `time_scale` to 50 instead of 5368709 and 268435456. Part of the fix for #1673 (https://github.com/mbunkus/mkvtoolnix/issues/1673).
mkvmerge: AVC/h.264 parser: mkvmerge no longer assumes that encountering sequence parameter set or picture parameter set NALUs signal the start of a new frame. Fixes #2179 (https://github.com/mbunkus/mkvtoolnix/issues/2179).
mkvmerge: AVC/h.264 packetizer (framed): when mkvmerge is told to fix the bitstream timing information, it will now update all SPS NALUs, not just the ones in the AVCC. Part of the fix for #1673 (https://github.com/mbunkus/mkvtoolnix/issues/1673).
mkvmerge: MPEG TS reader: TS packet payloads will only be treated as PES packets if the payload actually starts with a PES start code. The prior behavior led to wrong timestamps and potentially broken frame data. Fixes #2193 (https://github.com/mbunkus/mkvtoolnix/issues/2193).
mkvmerge: MPEG TS reader: mkvmerge will now drop incomplete PES packets as soon as an error is detected in the transport stream instead of passing the incomplete frame to the packetizer. An error is assumed either if the `transport_error_indicator` flag is set or if the value of the `continuity_counter` header field doesn't match the expected value. Fixes #2181 (https://github.com/mbunkus/mkvtoolnix/issues/2181).
mkvmerge: Opus: when re-muxing Opus from Matroska mkvmerge will now write "block duration" elements for all block groups where a "discard padding" is set, too. Fixes #2188 (https://github.com/mbunkus/mkvtoolnix/issues/2188).
mkvmerge: SRT reader: mkvmerge can now handle SRT files with timestamps without decimal places (e.g. `00:01:15` instead of `00:01:15.000`).
mkvmerge: read buffer I/O class: the class could get out of sync regarding the file position of the underlying file I/O class causing wrong data to be returned on subsequent read operations. One result was that trying to identifying MPLS files that refer to very short M2TS files caused mkvmerge to segfault.
mkvmerge: multiplexer core: if there's a gap in audio timestamps, a new block group/lace will be started for the first frame after each gap. Before the fix the frame after the gap was often stored in the previous block group causing the gap to be in the wrong place: at the end of that block group. Fixes #1700 (https://github.com/mbunkus/mkvtoolnix/issues/1700).
mkvextract: AVC/h.264: if two consecutive IDR frames with the same `idr_pic_id` parameter and no access unit delimiters are found between them, mkvextract will insert an access unit delimiter in order to signal the start of a new access unit. Fixes #1704 (https://github.com/mbunkus/mkvtoolnix/issues/1704).
MKVToolNix GUI: update check dialog: Markdown links will now be converted to clickable links. Fixes #2176 (https://github.com/mbunkus/mkvtoolnix/issues/2176).
build system: fixed a race condition when creating new directories if `rake` is run with `-jN` in newer versions of Ruby/`rake`. Fixes #2194 (https://github.com/mbunkus/mkvtoolnix/issues/2194).

## Build system changes


cmark (https://github.com/commonmark/cmark), the CommonMark parsing and rendering library in C, is now required when building the GUIs.


Have fun :)

mosu

[Selur]

Thanks for the new version and all the work to put into it!
(btw. the title of this thread still neeeds updating, still mentions v19.0)

Cu Selur

[hubblec4]

Many thanks for this new version.

All timestamps and durations are now output as nanoseconds in formatted form (e.g. `01:23:45.67890123`).

You changed the output format only? Or are the values now real nanoseconds?

For example DefaultDuration for a normal Bluray with FPS 24000/1001

old time string: 00:00:00.042
new time string: 00:00:00.042000000
real time string: 00:00:00.041708333

[Mosu]

You changed the output format only? Or are the values now real nanoseconds?

The timestamps are not rounded anymore (before they were often rounded to the nearest millisecond, depending on the format used). In the case of the DefaultDuration header element: that one is stored with ns precision in the file, and therefore it is now output with full precision.

The storage in the files hasn't changed.

[hubblec4]

The timestamps are not rounded anymore (before they were often rounded to the nearest millisecond, depending on the format used). In the case of the DefaultDuration header element: that one is stored with ns precision in the file, and therefore it is now output with full precision.

Very nice to read. But all timestamps which stored with Matroska TimestampScale are still Millisec and filled with "0" up to ns?


The storage in the files hasn't changed.
Ok, logic.

[Mosu]

Very nice to read. But all timestamps which stored with Matroska TimestampScale are still Millisec and filled with "0" up to ns?

Yes. All timestamps are output as ns, no matter which precision was used in the file.

[Snowknight26]

Minor issue with v20:

After muxing something and removing all source files, the destination file is unset. When no destination is specified and there are no source files attached, closing the window shows the following prompt:
https://www.stfcc.org/pics/i/9bf16b8315b0d16ca7c1e96de3467df2.png

[hubblec4]

Hi Mosu

When an mkv has no Statistics Tags, could mkvmerge quickly restore/set new one? Or is it necessary to remux the mkv?

[sneaker_ger]

You want mkvpropedit with --add-track-statistics-tags parameter.


Slightly related:
Does ffmpeg calculate on bytes on compressed or uncompressed bitstream? If it behaves like mkvmerge did until recently maybe uncompressed should get a new tag and the spec gets changed to have the current tag use compressed instead of uncompressed size.

/edit2:
On the other hand, sane people basically only use it for subtitles which are small to begin with. Doesn't really matter. Second tag not important.

[hubblec4]

You want mkvpropedit with --add-track-statistics-tags parameter.

Ah, so simple is that, thanks.

[hubblec4]

Another question.

In the output of the identify JSON there is a field: "minimum_timestamp":0, for some tracks.
Is this a start time of the track, and is this a nanosec value?

[sneaker_ger]

Yes and yes.

[hubblec4]

Yes and yes.

Splendid.

And now:
Mosu, is it possible to get a new field: "maximum_timestamp"?

[Mosu]

No, because that would require parsing the whole file just for identification. I want identification to be fast.

[Mosu]

Minor issue with v20:

Most likely some other setting in one of the controls anywhere in the multiplex job is still set, e.g. the title. Therefore the GUI will ask you that question. You can turn such questions off in the preferences.

[Snowknight26]

Most likely some other setting in one of the controls anywhere in the multiplex job is still set, e.g. the title. Therefore the GUI will ask you that question. You can turn such questions off in the preferences.

If it makes any difference, since it is a regression from v19, here are the reproduction steps:

- Open MKVToolNix
- Click 'Add source files'
- Choose a file to add (I was using a Blu-ray's index.bdmv, selecting a random playlist)
- Click to select the file in the 'Source files' panel
- Press the delete key
- Close MKVToolNix

[hubblec4]

No, because that would require parsing the whole file just for identification. I want identification to be fast.

Ok. I understand.

But when you add Statistics-Tags with mkvpropedit is there a parsing required?
A duration for the video track will be set. Is this duration not an end timestamp?

[Atak_Snajpera]

How to get full info about tracks like in v19
mkvmerge.exe" --identify-verbose "video.mkv"
https://pastebin.com/yUCMqpRC

instead of this
mkvmerge.exe" -i -v "video.mkv"
https://pastebin.com/2XssD1xs

[Mosu]

If it makes any difference, since it is a regression from v19, here are the reproduction steps:

- Open MKVToolNix
- Click 'Add source files'
- Choose a file to add (I was using a Blu-ray's index.bdmv, selecting a random playlist)
- Click to select the file in the 'Source files' panel
- Press the delete key
- Close MKVToolNix

Does this happen with v20 but not v19 for the same file?

[Mosu]

Ok. I understand.

But when you add Statistics-Tags with mkvpropedit is there a parsing required?

Yes. mkvpropedit parses the whole file in that case.

A duration for the video track will be set. Is this duration not an end timestamp?

No, it's the difference between the highest timestamp+its duration and the lowest timestamp.

[Mosu]

How to get full info about tracks like in v19
mkvmerge.exe" --identify-verbose "video.mkv"
https://pastebin.com/yUCMqpRC

Use the JSON identification format:

mkvmerge --identification-format json --identify yourfile.mkv

Also read the announcement again (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/NEWS.md#L905), please.

[Snowknight26]

Does this happen with v20 but not v19 for the same file?

Ah boo, it sure does. So not a regression but not the behavior I expected. Oh well. :P

[hubblec4]

Hi Mosu

Here is a short sample (https://forum.videohelp.com/attachments/44395-1515937462/DefaultDuration20ms_BlockDuration40ms.7z): DVD 25FPS MPEG2

The mkv says for DefautDuration 20ms. All BlockDurations are 40ms.
Is this a bug or why set mkvmerge DefaultDuration to 20ms?

[Mosu]

Possibly a bug, though I'm not sure. I don't want to spend any time on MPEG-2, though.

[mkver]

I actually have already reported such behaviour in my very first bug report (https://github.com/mbunkus/mkvtoolnix/issues/1658). Tl;dr: It is an unintended sideeffect of a fix introduced in MKVToolNix 3.3.

[Inviska]

Mkvinfo v20 now outputs '\n' as the newline character on Windows, while in previous versions it was "\r\n".

Is that an intentional change that's going to stay, or is it a mistake?

[Mosu]

That's not an intentional change. Please file an issue over at Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/); otherwise chances are I'll forget about it again. Thanks.

[Mosu]

I've fixed mkvinfo's behavior. The next release will use \r\n again on Windows.

[Inviska]

I've fixed mkvinfo's behavior. The next release will use \r\n again on Windows.

Thanks for fixing that. One other question; I have an MKVExtract GUI and I'm updating it for the changes in version 17. As far as I can see there's no way to determine from MKVInfo whether a file contains tags or cuesheets. To determine if tags and cuesheets were present I ran mkvextract tags and mkvxtract cuesheets and processed the output.

As of version 17, tags and cuesheets now output to a file, so this won't work. The only way I can see to detect if tags and cuesheets are present would be to output them to a file, read the file and then delete it, which would be a bit messy.

Is there a better way of detecting tags and cuesheets?

[Mosu]

Of course there is: don't use mkvinfo in the first place but "mkvmerge --identification-format json --identify yourfile.mkv" As I've said numerous times. Using mkvinfo for that is the wrong tool.

[Inviska]

Of course there is: don't use mkvinfo in the first place but "mkvmerge --identification-format json --identify yourfile.mkv" As I've said numerous times. Using mkvinfo for that is the wrong tool.

Thanks a lot, that'll make things a lot easier.

I must admit, I never even looked at the mkvmerge documentation and just assumed mkvinfo was the tool to use. I see now I've done things in completely the wrong way. I'll rework it to use mkvmerge rather than mkvinfo.

Thanks again.

[gpower2]

You can check gMKVExtractGUI source code here:
https://sourceforge.net/p/gmkvextractgui/code/HEAD/tree/gMKVToolNix/

Or you can use the .NET DLL "gMKVToolNix.dll" in your application if you want an easy solution to get the mkv info. ;)

Thanks to Mosu, mkvmerge since MKVToolNix v9.1.0 reports all the necessary info for identifying the mkv tracks!

[tormento]

Sometimes happens that a MKV is muxed inserting delays between tracks and/or changing fps.

Is there a way to reverse engineer what happened from the resulting MKV?

I have tried Media Info but there is no sign of it.

[sneaker_ger]

If anything mkvinfo could help.

But of course you need to know what to look for. Better if you just upload samples, command lines and logs if you suspect mkvtoolnix is doing something wrong. Then we can analyze.

About fps also read:
https://gitlab.com/mbunkus/mkvtoolnix/wikis/Wrong-frame-rate-displayed

[tormento]

If anything mkvinfo could help.

But of course you need to know what to look for. Better if you just upload samples, command lines and logs if you suspect mkvtoolnix is doing something wrong. Then we can analyze.

About fps also read:
https://gitlab.com/mbunkus/mkvtoolnix/wikis/Wrong-frame-rate-displayed
I mean intentionally. For example if you have a 23.976 video and 24 "fps" audio from another language or source.

[sneaker_ger]

Changed video fps is not really detectable from the container. Maybe you can find info in the bitstream of original fps (e.g. in H.264 time_scale and num_units_in_ticks - I think MediaInfo even shows this).
Changed audio depends. Sometimes the audio is stretched so that the frames overlap or have gaps. eac3to will detect this if you demux/recode such tracks. If otherwise constant you can compare duration in mkv container with duration of extracted stream.

Very often the mkv container cannot offer you such informations except the duration. Merging video and audio from different sources is more of a trial and error process.

[Sm3n]

Hi,

Today I noticed that I'm no longer able to see any tracks in the mkvextractgui except some chapters or attachement:
https://picload.org/view/ddiapgow/attach.jpg.html
https://picload.org/view/ddiapglr/chapt.jpg.html

Any idea what could be the cause or the reason for this sudden change? Can't say when was the last time I used my "working" extractgui and what change I could make since. Program is uptodate.

thx in advance.

[sneaker_ger]

MKVToolNix 20.0.0 changed output of mkvinfo (among other things). It was already discussed a few posts earlier and also in other threads.

Try gMKVExtractGUI (https://forum.doom9.org/showthread.php?t=170249). It stuck to the recommendations of the MKVToolNix author and thus didn't break with 20.0.0.

[Sm3n]

I have to admit I didn't think to look if it was discussed. Sorry about that. thx so much.

[Inviska]

Of course there is: don't use mkvinfo in the first place but "mkvmerge --identification-format json --identify yourfile.mkv
Sorry to keep bothering you, but am I right in saying that command doesn't show if tags and cuesheets are present in the file?

Muxing the same file with and without tags shows the same output, so there's nothing to indicate the presence of the tags, even thought they are definitely there and can be extracted. Likewise with a cuesheet, I can't see anything that indicates its presence, even though it is there and can be extracted.

[Mosu]

Track statistics tags are indeed not reported, but if other tags are present, then they are reported.

Cuesheets aren't a concept in Matroska. Instead they're a combination of chapters and tags. Both are reported if they're present.

[kuchikirukia]

Ok, if anyone is looking for the missing EVR.DLL, MFPLAT.DLL, MF.DLL, and MFCORE.DLL needed to get mkvtoolnix working, I've uploaded them here: http://s000.tinyupload.com/?file_id=56255835202073920387

So glad I did this. The latest Windows update removed them.

[sierramike]

Hello,
Don't know if this has already been asked, but I noticed that I cannot use mkvtoolnix gui since version 11 on Windows Server 2012 R2 because of missing evr.dll file.
Is there any workaround for this ?
I'm used to RDP on my VM host running Windows Server 2012 R2 to re-package my videos and I'm stuck with version 10 of mkvtoolnix because of this issue.
Thanks for helping!

[Mosu]

See this FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/wikis/DLLs-not-found).

[Sakura-chan]

Thanks very much for the new version... :thanks:

In some short tests I found no problems with the new mkvextract CLI interface. MKVExtractGUI2 and the latest GUI by GPower2 worked without issues, AVStoDVD and StaxRip also worked so far.

Even my hack for using the software under WinXP still works... :D


Cheers
manolito
I also noticed MKVExtractGUI2 breaking with v20. I wasn't aware of gMKVExtractGUI. It blows the old GUI2 out of the water, it even has batches (jobs). Thx.

Is there any intention of adding mkvextract functionality to MKVToolNix? Not asking when, even if it's in 5 years. Now with gMKVExtractGUI providing batches I really can't think of needing more. Just for having everything in one tool?

[clsid]

Qt also supports DirectShow. You can choose between MF and DS.

[gonca]

I'm trying to add
--colour-matrix 0:9 --colour-transfer-characteristics 0:16 --colour-primaries 0:9
to a mkv file
I use the gui and go to Output > Additional Optionsand enter the info
Then I multiplex the file
When I view the output in MediaInfo it doesn't show the colour information
What am I doing wrong?

[sneaker_ger]

Those aren't global options so they should be entered via the "input" tab. Mark the track and at the bottom of its settings you can find the field for track specific extra options. (Hover the mouse for a tool tip.)

If MediaInfo doesn't show check with the Header Editor. (You can also use the Header Editor to add them to mkv files.)

[gonca]

Those aren't global options so they should be entered via the "input" tab. Mark the track and at the bottom of its settings you can find the field for track specific extra options. (Hover the mouse for a tool tip.)

If MediaInfo doesn't show check with the Header Editor. (You can also use the Header Editor to add them to mkv files.)

Thanks
I figured it out a couple of minutes ago
Found the miscellaneous entry under Input
Thanks for the help

[Inviska]

I was testing my software in MacOS when I came across an issue when reading the output from mkvmerge -J and mkvinfo. The issue doesn't occur in Windows or on older MacOS MKVToolNix versions, but starts in MKVToolNix version 14.

I was having some problems with one file on the Mac so I printed the output of mkvmerge -J to a QPlainTextEdit with:

TextExit->insertPlainText(MKVToolNix.readAllStandardOutput());

What I found is that on version 14+ on the Mac some Russian text caused the output to end immediately. Here's the output from mkvmerge -J on MacOS using MKVToolNix v13 (https://www.inviska.com/images/MKVMergeV13.txt), and here's the output using MKVToolNix v14 (https://www.inviska.com/images/MKVMergeV14.txt) and MKVToolNix v20 (https://www.inviska.com/images/MKVMergeV20.txt). Likewise with mkvinfo, here's the output on MacOS using MKVToolNix v13 (https://www.inviska.com/images/MKVInfoV13.txt), and here's the output using MKVToolNix v14 (https://www.inviska.com/images/MKVInfoV14.txt) and MKVToolNix v20 (https://www.inviska.com/images/MKVInfoV20.txt).

When I run mkvmerge and mkvinfo from the terminal the output appears without issues on all Mac versions of MKVToolNix. I'm therefore not sure if it's me being stupid. I'm just confused as to why it works without issues on Windows versions and on MacOS versions up to v13, but not on newer MacOS versions.

[Luke M]

I'm using mkvtoolnix GUI v20.0.0 (for the first time, so be gentle).

When loading multiple MKVs, it appears to show info for each file seperately...is that right? Should it look the same for each file as when loading only one file? Or is the info from multiple files somehow mushed together?

The reason I ask is because when I load a single file, I see different info (specifically, default track flags) than when I load multiple files. So I'm confused. Don't know whether it's a bug or just something I don't understand.

[sneaker_ger]

In track field you see the values for "default" and "forced" as they will be in the output file, not necessarily as they are in the input files. If you put multiple files mkvmerge will often just want to make the first track of a type (video, audio, subtitles) the default.

https://gitlab.com/mbunkus/mkvtoolnix/wikis/Default-and-forced-flags-and-default-yes-no-in-the-GUI

[Luke M]

In track field you see the values for "default" and "forced" as they will be in the output file, not necessarily as they are in the input files. If you put multiple files mkvmerge will often just want to make the first track of a type (video, audio, subtitles) the default.


Thank you. That makes perfect sense.

[Mosu]

I was testing my software in MacOS when I came across an issue when reading the output from mkvmerge -J and mkvinfo. The issue doesn't occur in Windows or on older MacOS MKVToolNix versions, but starts in MKVToolNix version 14.

I cannot reproduce that problem here:

https://www.bunkus.org/pics/mtx-20-macos-russian.png

I also do not really support macOS (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Officially-supported-operating-systems-and-versions); therefore that's as far as I'm willing to investigate.

[arrgh]

...I'm surprised and confused :
also Version 20 does obviously not support the muxing of avc/ssif packages… on the other hand it supports the “interleaved” tag for 3D…

[Mosu]

Well, the latter is simply a flag in the headers. It's trivial to support all values for such a flag. It isn't trivial to add full support for 3D video at the bitstream level.

[arrgh]

ok, understood...
…a cautious question : any plans to support this at some point of time?

[Mosu]

Yes, for the sake of completeness — but if I'm entirely honest, then that feature probably has the lowest priority of all the things that I still want to implement. Mostly because I have zero interest in 3D myself.

[Inviska]

I cannot reproduce that problem here:

https://www.bunkus.org/pics/mtx-20-macos-russian.png

Yes, the problem only occurs when mkvmerge -J is run from a QProccess. I've been trying to identify the cause for ten days, but I don't know why it's happening.

I don't suppose you could read the first post here (https://forum.qt.io/topic/87438/problem-processing-output-from-qprocess) and give your opinion on whether you think it is a Qt issue or an MKVToolNix issue?

If you think it's Qt I can file a bug report, but if you think it's MKVToolNix I'll just work around it by sending the output to a file and reading it from that.

[Mosu]

Yes, the problem only occurs when mkvmerge -J is run from a QProccess. I've been trying to identify the cause for ten days, but I don't know why it's happening.

Try letting mkvmerge redirect its output to a file (mkvmerge --identification-format json --redirect-output whatever.json --identify whatever.mkv) and then read that file. If the file is truncated, then it's likely that environment variables such as LC_ALL, LC_CTYPE, LANG play a part.

Edit: I highly doubt it's a Qt error because MKVToolNix GUI is a Qt program that uses the very same QProcess model for querying mkvmerge's identification output you're trying to implement. In general it definitely works, it just doesn't in your particular program.

[Inviska]

Try letting mkvmerge redirect its output to a file (mkvmerge --identification-format json --redirect-output whatever.json --identify whatever.mkv) and then read that file. If the file is truncated, then it's likely that environment variables such as LC_ALL, LC_CTYPE, LANG play a part.

Thanks for your input. No problems reading the JSON file, and no problems reading the output if I run "cat output.json" in a QProccess. It's an incredibly strange issue that only occurs on MacOS with MKVToolNix 14+. Oh well, I'll admit defeat and go with a workaround for the Mac version.

Thanks again for your advice.

[Perenista]

Following what I wrote here:

https://forum.doom9.org/showthread.php?p=1833334#post1833334

I installed ffmpeg and tried this command:

https://imgur.com/a/i5qY6

Is this correct? Either is taking too much time or it's stuck there.

[BlockABoots]

I have a few episodes in mkv file format that i want to remove the Japanese language audio from but i have noticed if i add the 10 or so files to MKVToolNIX GUI input window it just seems to output 1 large file and not there own separate files, how do i get MKVToolNix to output each files individually?

[Mosu]

Go to the "Preferences" → "Multiplexer" and set "When dropping files" to "Always ask the user". The drop the files & select the appropriate action from the dialog that'll pop up.

[BlockABoots]

Go to the "Preferences" → "Multiplexer" and set "When dropping files" to "Always ask the user". The drop the files & select the appropriate action from the dialog that'll pop up.

Thanks, or though im not sure what option i need to select?

Each file lists...

MPEG-4p10/AVC/h.264
AAC ENG
AAC JPN
SubRip/SRT

Is there a way i can select 'AAC JPN' for removal for all the episode files in 1 go or do i have to click on each episode individually and remove the AAC JPN?

[Mosu]

Well, on the shell (with "bash" or "zsh"; thinks will look differently with "cmd.exe" which I cannot help you with) you could do something like this:

for file in *.mkv ; do
mkvmerge -o "out/$file" -a '!jpn' "$file"
done

If you want to use the GUI, you can use the "enable only certain tracks" feature: in the "preferences" go to "Multiplexer" → "Enabling tracks" and set the controls appropriately.

If you don't get that to work, you can still deselect the Japanese tracks manually.

[BlockABoots]

If you want to use the GUI, you can use the "enable only certain tracks" feature: in the "preferences" go to "Multiplexer" → "Enabling tracks" and set the controls appropriately.

Yes that worked!, had to tick 'Video' and 'Subtitles' and then add 'English (eng)' to the 'selected' window. Then after that all files i added had the 'ACC JPN' line unticked. Thanks

[BlockABoots]

Final question, is there a way to get the program to start 'multiplexing' all the files at once rather than having to click on each header tab and then selecting 'multiplexing'?

[Mosu]

Why don't you have a look in the "Multiplexer" menu?

[BlockABoots]

And this program doesn't alter the quality of the video at all right?

[hubblec4]

And this program doesn't alter the quality of the video at all right?

Right. MKV is a container, not a codec.

[tormento]

Is there a fast and easy way to split a mkv from a wanted position to another wanted position in time?

[Mosu]

That's called "splitting by parts" in MKVToolNix.

[tormento]

That's called "splitting by parts" in MKVToolNix.
I saw now and read the popup with description too.

My mind thought it was only to split in two parts.

Thanks.

[Inviska]

Regarding that problem where the output of mkvmerge -J is truncated after the first Unicode character when running MKVToolNix 14+ from a QProccess on MacOS, it was caused by LANG.

The problem specifically is that on MacOS LANG is not in the list of Qt system environment variables. Running printenv LANG on MacOS returns en_GB.UTF-8, so LANG is set on the system. However, if I print out the list of environment variables returned by the below, LANG isn't present on MacOS, though it is present on Linux.

QProcessEnvironment::systemEnvironment().toStringList().join('\n')

Setting LANG with proccess.setEnvironment(QStringList("LANG=en_GB.UTF-8")) resolves the problem of the output being truncated.

Two questions:

1) A since QProcessEnvironment::systemEnvironment() doesn't report LANG on MacOS there's no way to get the LANG for the system. I was therefore going to set LANG to en_US.UTF-8 on all systems. Would running MKVToolNix in en_US.UTF-8 create any problems on non-English systems?

2) Would you consider it an bug that LANG isn't present in the Qt systemEnvironment() on MacOS? If so I'll file a bug report with Qt.

[Mosu]

1) A since QProcessEnvironment::systemEnvironment() doesn't report LANG on MacOS there's no way to get the LANG for the system. I was therefore going to set LANG to en_US.UTF-8 on all systems. Would running MKVToolNix in en_US.UTF-8 create any problems on non-English systems?

It shouldn't as I don't think anyone would ever run a mac with a non-UTF-8 locale (such as e.g. ISO-8859-15). Don't know if that is even possible.

As UTF-8 is Unicode, output should work regardless of system language and content.

2) Would you consider it an bug that LANG isn't present in the Qt systemEnvironment() on MacOS? If so I'll file a bug report with Qt.

I really couldn't say.

[Ripman]

Thanks for the new version 19 & 20.

Based on your release announcements, we knew that certain options and features would be retired (e.g., text options files, -I).

So I was playing around and using the new -i. If I also use a -v for verbosity — it doesn’t seem to have an effect.

Is there a valid use case for making -i -v kind of like the old -I. I can’t say I ever used the extra info from the old -I (e..g., private codec data).

If that’s something you want to do one day, say as much and I’ll write it up.

[Mosu]

No. The old verbose identification format is gone for good. Use the JSON identification format instead. It contains all the information the verbose format did in a standardized format.

[Mosu]

Hey everyone.

It's time for MKVToolNix v21.0.0. The biggest change is that mkvinfo's GUI portion has been removed. Its functionality is now incorporated into MKVToolNix GUI. I am aware that the functionatliy isn't on par yet, but it will be in time for release v22.0.0.

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

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

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

# Version 21.0.0 "Tardigrades Will Inherit The Earth" 2018-02-24

## New features and enhancements

* mkvmerge: track statistics tags: the `TagDefault` element will not be written anymore as it was always set to the default value `1` anyway. Implements #2202 (https://github.com/mbunkus/mkvtoolnix/issues/2202).
* mkvmerge, MKVToolNix GUI: JSON files can now contain C++-style line comments outside of strings (e.g. something like this: `// this is ignored`). Such comments, even though not part of the official JSON specifications, are now ignored when reading JSON files.
* MKVToolNix GUI: chapter editor: opening a Matroska file without chapters in it will now open the file in an empty chapter editor instead of showing an error message. Implements #2218 (https://github.com/mbunkus/mkvtoolnix/issues/2218).
* MKVToolNix GUI: an "info" tool has been added, replacing the functionality of mkvinfo's GUI. The functionality is not on par yet but will be for release v22. Implements most of the functionality of #2104 (https://github.com/mbunkus/mkvtoolnix/issues/2104).

## Bug fixes

* build system: `configure` was treating `--disable-ubsan` and `--disable-addrsan` the same as `--enable-ubsan` and `--enable-addrsan`. Fixes #2199 (https://github.com/mbunkus/mkvtoolnix/issues/2199).
* build system: an error message is output if a command to execute is not found instead of silently failing.
* build system: in addition to looking for the `gettext` C function and library, `configure` now also verifies the presence of the `msgfmt` program instead of simply relying on it.
* mkvmerge: appending files with additional parts at the same time was broken if more than one additional part was appended (e.g. when appending files from DVDs with something like `'(' VTS_01_1.VOB VTS_01_2.VOB ')' + '(' VTS_02_1.VOB VTS_02_2.VOB ')'`). In such a situation the content from files `VTS_02_1.VOB` and `VTS_02_2.VOB` where laid out in parallel to the content from the earlier files.
* mkvmerge: FLV reader: a single invalid AAC frame was written for AAC audio tracks with codec initialization data longer than five bytes.
* mkvmerge: FLV reader: timestamps will be normalized down to 0. Fixes #2220 (https://github.com/mbunkus/mkvtoolnix/issues/2220).
* mkvmerge: MP4 reader: if an AAC track doesn't contain an AAC-specific decoder configuration in the ESDS portion, then a default decoder configuration will be generated based on the track's header data instead of skipping the track. Fixes #2221 (https://github.com/mbunkus/mkvtoolnix/issues/2221).
* mkvmerge: MP4 reader: fixed reading HEVC/h.265 video tracks if they're stored as Annex B byte streams inside MP4. Fixes #2215 (https://github.com/mbunkus/mkvtoolnix/issues/2215).
* mkvmerge: Ogg Opus reader: mkvmerge will now emit a warning instead of aborting when it encounters an Ogg Opus page with no data in the packet. Fixes #2217 (https://github.com/mbunkus/mkvtoolnix/issues/2217).
* mkvmerge, mkvextract: Matroska parser: fixed a segmentation fault that occurred whenever the first level 1 element after resyncing after an error in the file structure isn't a cluster. Fixes #2211 (https://github.com/mbunkus/mkvtoolnix/issues/2211).
* mkvmerge, MKVToolNix GUI multiplexer & header editor: fixed a crash during file type detection for attachments if MKVToolNix is installed in a path with non-ASCII characters (e.g. German Umlauts). Fixes #2212 (https://github.com/mbunkus/mkvtoolnix/issues/2212).
* mkvinfo: the `--hex-positions` parameter did nothing in summary mode.
* mkvinfo: Windows: line endings will be written as `\r\n` (carriage return & line feed) again instead of just `\n` (line feed).
* mkvpropedit: adding track statistics tags: for tracks with content encoding (compression) mkvpropedit is now accounting the uncompressed number of bytes, not the encoded (compressed) number of bytes. Fixes #2200 (https://github.com/mbunkus/mkvtoolnix/issues/2200).
* MKVToolNix GUI: multiplexer: the subtitle character set can now be set for appended subtitle files, too. Fixes #2214 (https://github.com/mbunkus/mkvtoolnix/issues/2214).
* MKVToolNix GUI: multiplexer: when appending, all tracks appended to disabled tracks will start out disabled, too.

## Build system changes

* mkvinfo: the GUI portion has been removed. mkvinfo is now a pure command-line program again.

Have fun :)

[sneaker_ger]

Thx.

When flagging H.264 frames from mp4 as discardable is mkvmerge using mp4 container info (is there such info?) or is it parsing the H.264 bitstream? Because I see different results as when reading H.264 ES.

[hubblec4]

Hi Mosu
and many thanks for this new version.

In the ChapterEditor tool, is a button "Open Matroska, WebM- or Chapter files".
But WebM files doesn't contain chapters (says the specs).

[sneaker_ger]

# Version 14.0.0 "Flow" 2017-07-23

## New features and enhancements

* mkvmerge, mkvpropedit, MKVToolNix GUI (chapter editor): added support for
chapters in WebM files that is spec-compliant by removing all tag elements
not supported by the WebM spec. Implements #2002 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2002).

[Mosu]

But WebM files doesn't contain chapters (says the specs).

Chapters in WebM are spec-compliant (https://www.webmproject.org/docs/container/). The valid elements are a subset of all the chapter elements Matroska supports.

[Mosu]

When flagging H.264 frames from mp4 as discardable is mkvmerge using mp4 container info (is there such info?) or is it parsing the H.264 bitstream?

For normal h.264 bitstreams: container information. In the case of MP4 this information is incomplete as the container level doesn't really provide it

In the case of Annex B bitstreams inside MP4: the bitstream information.

[hubblec4]

Chapters in WebM are spec-compliant (https://www.webmproject.org/docs/container/). The valid elements are a subset of all the chapter elements Matroska supports.

Ok, thanks for this link.

[mkver]

For normal h.264 bitstreams: container information. In the case of MP4 this information is incomplete as the container level doesn't really provide it

In the case of Annex B bitstreams inside MP4: the bitstream information.
This is how I proposed it in #2047. But now that I think about it again I think my proposal was based on a misconception: That parsing framed input would be slow. In fact, for an eternity you have already looked at the first byte of every NAL unit in order to discard filler bytes and now AUDs as well. What do you think?

[Mosu]

Not interested. Due to how Matroska works, mkvmerge has to calculate all reference timestamps properly, which basically means treating any h.264 stream the way an Annex B stream is treated (safe for finding the unit boundaries, of course): calculating the frame order etc. The flags in the "simple block" structure such as "key" and "discardable" are only derived from those reference timestamps. And for situations such as simple blocks being disabled the reference timestamps will actually have to be written to the output file (in the block groups).

So no, it's not just looking at the slice type.

[manolito]

Just stumbled upon a weird interaction between TSDoctor and MKVMerge.

The source is a downloaded TS file from the ARTE Mediathek. I used the SD version, but the HD version has the same problem.

The downloaded TS file has a frame rate of 25 fps, it plays without issues. After running it through TSDoctor it still shows 25 fps and plays nicely. But after repacking this TSDoctor fixed TS using MKVMerge GUI the properties change to VFR, and playback shows heavy artifacts.

If I feed MKVMerge with the original downloaded TS without using TSDoctor then the resulting MKV has 25 fps CFR and plays without problems.

I uploaded my results here:
http://www83.zippyshare.com/v/cndrA2sS/file.html


Any idea what is happening here? I tend to believe that MKVMerge is to blame, because when I use FFmpeg to repack the TSDoctor fixed TS file then the resulting MKV does not show any issues.


Cheers
manolito

[Selur]

Looks to me like TSDoctor is not properly adjusting the headers, mkvmerge keeps the messed up headers and delivers vfr, ffmpeg ignores the headers partially and returns cfr. So I would blame TSDoctor and not mkvtoolnix.

[sneaker_ger]

Mkvmerge drops some frames. E.g. frame #16 display/#13 coded, P frame.

[mkver]

Beginning with mkvmerge 20.0 mkvmerge nows uses the information from the continuity counter that the transport stream provides to decide whether a PES packet in the input is corrupted; corrupted PES packets are dropped. ProjectX says that there are some discontinuities in the continuity counter, so this is what's happening here. It also complains a lot about bit errors in packets.
Why do you use tsdoctor at all? What can it do that mkvmerge can't (apart from outputting a transport stream what mkvmerge obviously won't)?
[Edit]: It's actually slightly different to what I said above: There are some packets in your file that look like this:

47 01 00 39 B7 00 FF FF ... FF FF

(... = 178 more 0xFF)
According to the TS header this packet has an adaption field followed by a payload. The B7 (=183) says that the whole rest of the ts packet belongs to said adaption field, i.e. contrary to what has been signalled the packet doesn't even contain a payload. Now the thing is that the continuity counter is only supposed to increase for packets with payload. If one ignores this restriction, then there is no discontinuity in the continuity counter; but if one expects the continuity counter not to increase with such packets, then one has a discontinuity in the continuity counter which leads to the rejection of the entire PES packet.
Now I have to admit that I don't know whether the continuity counter should increment if the header signals the presence of a payload despite there being none (or does a 0 B payload count?) or if it should only increment when there is an actual payload. Anyway, this faulty header information leads to ProjectY's reports of bit errors in the packet; therefore it drops said packets and reports a discontinuity in the continuity counter afterwards. mkvmerge is likely to do something similar.
PS: I'd really liked to know what TSDoctor is supposed to achieve.

[manolito]

I have been using TSDoctor for a long time for video broadcasts in TS containers mainly to repair broadcast glitches and remove padding data. You are probably correct to question its usefulness for non-broadcast streams like downloaded files or ripped files from a BD.

You cannot really compare TSDoctor to ProjectX. ProjectX converts MPEG2 transport streams to program streams, it repairs broadcast glitches and takes care of keeping A/V sync. TSDoctor keeps the transport stream format when repairing the source, and when there was a glitch in the transmission TSDoctor will issue a warning, but it will not repair the stream. The resulting "fixed" stream will still exhibit A/V sync problems (which ProjectX would have repaired).

Still my question remains valid. Why does the TSDoctor fixed TS file work perfectly, but after repacking it to MKV with mkvmerge the resulting MKV is broken? And doing the repacking of the same file to MKV with FFmpeg does not introduce any problems?


Cheers
manolito

[mkver]

1. mkvmerge does also remove padding data by default. And has done this for a very long time. So I don't see a point in using TSDoctor for broadcast streams, too. You yourself said that mkvmerge when fed with the original ts file produces a flawless file.
2. I did not compare ProjectX to TSDoctor; I just said that I used ProjectX to analyze your sample.
3. I don't see that TSDoctor fixed your TS file; the file it created is corrupted as I have explained. And since when does a mediathek use filler data at all? That would be news to me. So why do they exist in the version produced by TSDoctor? Really strange.
4. ffmpeg ignores the continuity counter, therefore it doesn't care about discontinuities in the continuity counter.

[Mosu]

Now I have to admit that I don't know whether the continuity counter should increment if the header signals the presence of a payload despite there being none (or does a 0 B payload count?) or if it should only increment when there is an actual payload. Anyway, this faulty header information leads to ProjectY's reports of bit errors in the packet; therefore it drops said packets and reports a discontinuity in the continuity counter afterwards. mkvmerge is likely to do something similar.
PS: I'd really liked to know what TSDoctor is supposed to achieve.

ISO/IEC 13818-1 (the standard document describing MPEG program and transport streams) has this to say about the continuity_counter:

continuity_counter – The continuity_counter is a 4-bit field incrementing with each Transport Stream packet with the
same PID. The continuity_counter wraps around to 0 after its maximum value. The continuity_counter shall not be
incremented when the adaptation_field_control of the packet equals '00' or '10'.

The lower bit of the two is what signals the presence of data payload, the higher one the presence of the adaptation field. The standard doesn't say anything about the actual number of payload bytes having anything to do with the decision whether or not the continuity_counter should be incremented; and indeed, mkvmerge doesn't base its decision on it either (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/src/input/r_mpeg_ts.cpp#L2025).

That 0xb7 = 0b10110111 indicates: 0b10 = transport_scrambling_control; 11 = adaptation_field_control ( = adaption field present, payload present), 01111 = current continuity_counter. The "payload present" flag is set, therefore the condition mentioned above is not met, meaning the continuity_counter must be increased.

If TSDoctor is writing such header fields but isn't increasing the continuity_counter, then it produces broken files and should not be used until that issue's been fixed.

Still my question remains valid. Why does the TSDoctor fixed TS file work perfectly, but after repacking it to MKV with mkvmerge the resulting MKV is broken?

We've just explained this to you.

And doing the repacking of the same file to MKV with FFmpeg does not introduce any problems?

Just guessing: maybe ffmpeg can recognize such situations and fixes them silently.

[nevcairiel]

FFmpeg reads the continuity counter, and it warns if it mis-matches, but it doesn't automatically drop data.

PS:
Your analyzes is one byte off Mosu, the important header starts at 39, but the conclusion remains the same.

[mkver]

That 0xb7 = 0b10110111 indicates: 0b10 = transport_scrambling_control; 11 = adaptation_field_control ( = adaption field present, payload present), 01111 = current continuity_counter. The "payload present" flag is set, therefore the condition mentioned above is not met, meaning the continuity_counter must be increased.

You are off by 1 B: 0x39 is the header byte containing the information concerning TSC, adaption field, payload and continuity counter. It says that both an adaption field and a payload is there (and no scrambling is used); the 0xb7 is the size of the rest of the adaption field (following 0xb7) and it says that 183 B are this rest. Together with the length field and the 4 bytes of header this is the complete packet.

If TSDoctor is writing such header fields but isn't increasing the continuity_counter, then it produces broken files and should not be used until that issue's been fixed.

TSDoctor is writing packets that contain payload according to the header, but in reality don't contain any payload. For these packets it is incrementing the continuity counter which is in line with the spec and the code you cited. I thought that mkvmerge checks whether a ts packet has any real payload, but if it just checks the header then I actually don't understand why this frame is dropped; because then there is no discontinuity in the continuity counter. Version 19.0 doesn't have any problems with it, so it must be the recent changes to the ts input module.
@Nevcairiel: I have seen ffmpeg outputting error messages that PES packet are incomplete, but I never got an error message (or a warning) informing me of discontinuities in the continuity counter.

[Mosu]

Yes, I was off one byte (oops!), but as Nev said, it doesn't actually change the analysis: the adaptation_field is still 0b11, and therefore the continuity_counter must be incremented.

Version 19.0 doesn't have any problems with it, so it must be the recent changes to the ts input module.

Well, that may very well be, but I'm not really interested in spending time on this. There are three methods described in this thread that don't pose a problem (not using TSDoctor in the first place, using ffmpeg on the file produced by TSDoctor, using an older mkvmerge). If anyone wants to debug mkvmege and propose a fix, I'll gladly apply it, of course.

[Mosu]

Well, I did look into my source code. And yes, this is a bug in mkvmerge. From what I can tell, mkvmerge doesn't update its expectation about what the next continuity_counter is supposed to be if a TS packet doesn't contain payload bytes. The line I've linked to above handles that case correctly, it simply isn't called in that case (and that's likely the issue here). I'll see if I can get it fixed.

[Mosu]

Should be fixed in the latest pre-builds (https://mkvtoolnix.download/windows/pre/).

[mkver]

It is. Except for the tags the output is the same as the one from 19.0.

[manolito]

Thanks Mosu for the quick fix. Works nicely here... :thanks:

And a few words in defense of TSDoctor:

Just for fun I installed a more than 5 year old version (1.2.xxx) of the Doctor and repeated the test. Result was exactly the same. So if you insist that TSDoctor creates broken files then it has been doing this for a very very long time. And so far I am not aware that anyone has ever complained about such broken files.

@mkver
I did not compare ProjectX to TSDoctor; I just said that I used ProjectX to analyze your sample.

I was just a little surprised that you tried using ProjectX at all on this sample. ProjectX does not deal with AVC video and AAC audio.

And if you do not know why anyone uses TSDoctor at all, just download the trial version and throw some corrupted broadcast captures at it. From the first page of the manual:

Cypheros TS-Doctor was designed to scan digital Transport Streams for errors and
correct them in a way that the resulting file(s) will play back without surges, dropouts
or diverging sound and picture on Hardware- or Software-Media players.
Unlike some other tools, TS-Doctor tries to keep the original stream as untouched as
possible during error correction, thus avoiding the creation of additional incompatibilities.


Cheers
manolito

[Mosu]

I didn't say TSDoctor is buggy, I said that if it didn't increase the continuity counter in this case, then it would be buggy. It does increase it, though, and therefore isn't buggy. What it is doing is simply curious: creating TS packets without any payload in it. Such packets could simply be skipped, making the file smaller.

[manolito]

I didn't say TSDoctor is buggy...

No, you didn't, but mkver sure did... ;)

Anyway, this faulty header information...
and
I don't see that TSDoctor fixed your TS file; the file it created is corrupted as I have explained.


Cheers
manolito

[mkver]

It seems that the specs agree with TSDoctor about this after all; but given that the existence of packets falsely claiming to contain payload is very strange to say the least and given that the release mkvmerge version worked with the original file I presume that these packets were created by TSDoctor (maybe because it thinks that some players don't like variable bitrate?). And even if one wants constant bitrate (which is incompatible with the goal of removing filler data) one could do so by inserting packets that not even claim to have a payload.
And yes, I know that ProjectX doesn't really support H.264. But I used it just to check the continuity counters and other things at the transport stream layer and it can do this even with unsupported tracks.
But let's not derail this thread any more. If you want to continue to talk about this, let's do it via PM.

[tormento]

@Mosu

Why doesn't delay work with subs (I am trying with srts). Is it a choice or a limit?

[sneaker_ger]

It should work. Try again. If you can't get it to work provide samples and command-line.

[Mosu]

Why doesn't delay work with subs (I am trying with srts). Is it a choice or a limit?

It works just fine. If you have problems, then please post the actual command line used, like sneaker_ger has said.

[tormento]

It works just fine. If you have problems, then please post the actual command line used, like sneaker_ger has said.

Is there a way to get command line from GUI? I insert streams and delays there.

[ChaosKing]

Yes, look at the menu: Multiplexer -> Show command line (Visualizza linea di comando)

[tormento]

It works just fine. If you have problems, then please post the actual command line used, like sneaker_ger has said.
Tried again. It indeed works. I was mislead from gMKVExtractGUI that doesn't show delay as it does for audio. Is there any way to find srt (sub) delay from muxed mkv?

[nevcairiel]

Subtitles are a sparse stream, which means there really is no inherent "delay". Audio and Video typically always start right at time 0, and any difference here can be considered a "delay".
Subtitles only start when there is actual text to be shown, so any information of how much you delayed it during muxing is essentially lost - because it just gets baked into the timstamps of the subtitles.

[tormento]

Subtitles are a sparse stream, which means there really is no inherent "delay". Audio and Video typically always start right at time 0, and any difference here can be considered a "delay".
Subtitles only start when there is actual text to be shown, so any information of how much you delayed it during muxing is essentially lost - because it just gets baked into the timstamps of the subtitles.

:thanks:

[hubblec4]

Hi Mosu

For long time I don't use an .mtxcfg file, but now I realized I can't open the MTX with the mtxcfg (double-click).
What has changed and what can I do to restore this behavior?

[cherishjoo]

It's a great program!

[Mosu]

@hubble4 Nothing has changed. The installer doesn't set a file association for.mtxcfg. You'll have to do that yourself.

[hubblec4]

I have nothing changed on my system. I remember me to set a "system-path" for the mtxcfg. I override the old files from the new versions zip file.
From version 19 on, my mtxcfg's don't start the MTX.

I will check my system, thanks for your reply.

EDIT: All OK now, it was a path issue.

[hubblec4]

Hi Mosu

After nevcairiel's answer in this thread (https://forum.doom9.org/showthread.php?t=175328) I have one question.
Can MTX cut HEVC material on IDR frames only or also on CRA/BLA frames?

[mkver]

mkvmerge cuts at what it considers to be keyframes (e.g. if you manipulate the keyframe flag of a Matroska SimpleBlock or void the reference fields of a BlockGroup, it thinks that this is a keyframe and allows you to cut the stream at this position). If the source file of the HEVC track is "framed" (Matroska or mp4), then things like the keyframe flags will be reused; if not, mkvmerge will analyze the bitstream and a quick search found this place in the code (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/src/common/hevc_es_parser.cpp#L258) that indicates that a BLA frame without a recovery_point SEI message won't be considered a keyframe.

[hubblec4]

Hi Mosu

I have some questions about mtxcfg file and JSON identify.

In an mtxcfg file exists more then one "type"-object. A "type"-object("type": 22 (for m2ts)) is used for a file and it is the same value like in JSON identify "container_type"
"container": {
"properties": {
"container_type": 22,
"is_providing_timestamps": true
},
"recognized": true,
"supported": true,
"type": "MPEG transport stream"
},
On the other hand, the "type"-object(MPEG transport stream) from this JSON identify sample is not used in mtxcfg, right?

In mtxcfg exists for each track also a "type"-object ("type": 0 for DTS-HD Master Audio) but in JSON identify the "type"-object is a string (video,audio etc).
{
"codec": "DTS-HD Master Audio",
"id": 1,
"properties": {
"audio_channels": 6,
"audio_sampling_frequency": 48000,
"language": "eng",
"number": 4352,
"program_number": 1,
"stream_id": 4352
},
"type": "audio"
},

Is this an issue?
How can I determine the right value for an mtxfcg track "type"-object with info from JSON identify?
Could you add this info?
I know, then are two "type"-objects present. Why exists so many same named objects with different usage?

Best regards hubble

[Perenista]

I tried to add a .sub subtitles to a MKV and MKVTOOLNIX said MicroDVD is not supported. I easily converted into SRT, and then was able to add. Why is this unsupported? Are all .SUB s affected?

[sneaker_ger]

Reason:
https://gitlab.com/mbunkus/mkvtoolnix/issues/77

Often people use .sub/.idx files, those are different from MicroDVD. Then you can just add the .idx file.

[Mosu]

I have some questions about mtxcfg file and JSON identify.

Those two formats don't correlate. The mtxcfg format predates the JSON identification format. The JSON identification format is an official API of MKVToolNix, the mtxcfg format isn't — therefore its values reflect more closely how the GUI's built internally.

On the other hand, the "type"-object(MPEG transport stream) from this JSON identify sample is not used in mtxcfg, right?

That's correct. The GUI uses its internal knowledge for mapping the numerical container type to the string displayed in the "container" column in the multiplexer's "source files" list.

How can I determine the right value for an mtxfcg track "type"-object with info from JSON identify?

The "type" in the mtxcfg for tracks is important as it determines what kind of a track it is: audio, video, subtitles, chapters, tags… The GUI decides which controls to enable/disable based on this value. The values are the ones from "enum Type" in "class Track" (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/src/mkvtoolnix-gui/merge/track.h#L21). Again, this numerical value reflects internal knowledge of the GUI the user shouldn't need to be aware of — and as mtxcfg is considered not to be part of an external API, the GUI uses those internal values there.

I know, then are two "type"-objects present. Why exists so many same named objects with different usage?

Because there are many different kinds of objects that need their type information. External APIs (the JSON identification format) use human-readable strings; internal APIs (the mtxcfg format) often use internal, numerical values as they don't require conversion.

[hubblec4]

Many thanks for this explanation.

I know that mtxcfg is not for normal users but I want support it again in my new cE. The old code still works with version 21/22 but it is too old and missing new MTX functions.

I'm very familiar with the structure of mtxcfg and with JSON identify it is now more easier to build such mtxcfg files.
All the extended functions of cE can then be used in the MTX.


In a JSON identify for an mp4 file there is no chapter track. When I load an mp4 to MTX and save the mtxcfg there is a second chapter track.
Could you add this info to JSON identify?

hubble

[Mosu]

In a JSON identify for an mp4 file there is no chapter track. When I load an mp4 to MTX and save the mtxcfg there is a second chapter track.

Chapters are handled differently in the GUI and in the identification output. In the ID output, there's a separate key called "chapters" on the same level as "tracks", "container" etc. In the GUI that's turned into an entry in the track listing even though it's not a track. Tags are handled the same way.

[hubblec4]

Ah yes, I see the entry for chapters(identify output), but there is only the "num_entries" object. Thats not very helpful.
But mp4-chapter-track has not much mtxcfg-objects and not all are necessary.

[Mosu]

The GUI doesn't use anything more anyway for chapters. What mkvmerge delivers is enough.

[hubblec4]

OK, nice to know. Same for Tags I guess?

[Mosu]

Yes, both types are treated almost identically.

[Mosu]

Hey everyone.

I thought today would be a good day for a new release of MKVToolNix: v22.0.0 is here. Celebrating the official announcement of AV1, this is the first release that contains support for that format as well (still some things to do, though). Other than that the info tool in the GUI has been improved quite a bit.

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

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

Here are the NEWS since the previous release:

# Version 22.0.0 "At The End Of The World" 2018-04-01

## New features and enhancements

* mkvmerge, MKVToolNix GUI multiplexer: AC-3, DTS, TrueHD: added an option for removing/minimizing the dialog normalization gain for all supported types of the mentioned codecs. Implements #1981 (https://gitlab.com/mbunkus/mkvtoolnix/issues/1981).
* mkvmerge: AV1: added support for reading AV1 video from IVF, WebM and Matroska files.
* mkvmerge: FLAC: mkvmerge can now ignore ID3 tags in FLAC files which would otherwise prevent mkvmerge from detecting the file type. Implements #2243 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2243).
* mkvinfo: the size and positions of frames within "SimpleBlock" and "BlockGroup" elements are now shown the same way they're shown for other elements (by adding the `-v -v` and `-z` options).
* MKVToolNix GUI: multiplexer: added options for deriving the track languages from the file name by searching for ISO 639-1/639-2 language codes or language names enclosed in non-word, non-space characters (e.g. "…[ger]…" for German or "…+en+…" for English). Implements #1808 (https://gitlab.com/mbunkus/mkvtoolnix/issues/1808).
* MKVToolNix GUI: info tool: implemented reading all elements in the file after the first cluster. Only top-level elements are shown; child elements are only loaded on demand. Implements the rest of #2104 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2104).
* MKVToolNix GUI: info tool: added a context menu with the option to show a hex dump of the element with the bytes making up the EBML ID and the size portion highlighted in different colors. In-depth highlighting is done for the data in `SimpleBlock` and `Block` elements.
* MKVToolNix GUI: chapter editor: added an option to remove all end timestamps to the "additional modifications" dialog. Implements #2231 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2231).

## Bug fixes

* mkvmerge: MP4 reader: fixed reading the ESDS audio header atom if it is located inside a "wave" atom inside the "stsd" atom.
* mkvmerge: MP4 reader: AAC audio tracks signalling eight channels in the track headers but only seven in the codec-specific configuration will be treated as having eight channels.
* mkvmerge: MPEG TS reader: fixed wrong handling of the continuity counter for TS packets that signal that TS payload is present but where the adaptation field spans the whole TS packet.
* mkvmerge: the 'document type version' and 'document type read version' header fields are now set depending on which elements are actually written, not on which features are active (e.g. if a `SimpleBlock` is never written, then the 'read version' won't be set to 2 anymore). Part of the fix for #2240 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2240).
* mkvmerge: the 'document type version' header field is now set to 4 correctly if any of the version 4 Matroska elements is written. Part of the fix for #2240 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2240).
* mkvinfo: summary mode: the file positions reported for frames in `BlockGroup` elements did not take the bytes used for information such as timestamp, track number flags or lace sizes into account. They were therefore too low.
* mkvpropedit, MKVToolNix GUI header editor: the 'document type version' and 'document type read version' header fields are now updated if elements written by the changes require higher version numbers. Part of the fix for #2240 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2240).
* mkvpropedit, MKVToolNix GUI header editor: mandatory elements can now be deleted if there's a default value for them in the specifications. Fixes #2241 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2241).
* source code: fixed a compilation error on FreeBSD with clang++ 5.0. Fixes #2255 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2255).

## Build system changes

* A compilation database (in the form of a file `compile_commands.json`) can be built automatically if the variable `BUILD_COMPILATION_DATABASE` is set to `yes` (e.g. as `rake BUILD_COMPILATION_DATABASE=yes`).

Have fun :)

[sneaker_ger]

Thx. Some nice new features (mkvinfo hex, language from file name).


* mkvmerge: MP4 reader: AAC audio tracks signalling eight channels in the track headers but only seven in the codec-specific configuration will be treated as having eight channels.
What is the reasoning behind this?



P.S.: You linked to github issue tracker, not gitlab.

[Mosu]

What is the reasoning behind this?

There's shit out there, and ffmpeg does the same in that situation (or at least with that file).

P.S.: You linked to github issue tracker, not gitlab.

Doh! Thanks, fixed, and fixed my NEWS-to-bbcode script, too.

[hubblec4]

Hi Mosu,

While I coding mtxcfg support in cE, I found a strange behavior in MTX. First I thought I do something wrong, but after manually reproducing it occurs also.
I feed MTX with a video stream (m2v) two or three audios (ac3) and subtitles(idx) and for all this files exists "appended files".
When I disable an audio or subtitle stream (all appended streams are disabled and grayed out. OK) and start muxing, MTX shows for all disabled streams an info

No append mapping was given for the file no. 13 ('E:\DVD-mtxcfg\I2_T1\2\AudioFile_82.ac3').
A default mapping of will be used instead.
Please keep that in mind if mkvmerge aborts with an error message regarding invalid '--append-to' options.

Is this info superfluous because the main file/stream and all appended files/streams are not used in the final mkv?

EDIT:
I use this MTX version:
mkvtoolnix-64-bit-22.0.0-build20180401-01724-421bea2a3

[fadedfedor]

Hello, I've been trying to make an mkv with a VP9 video track, Opus audio track, and an srt subtitle. A clicking sound is heard in both channels of the audio track after remuxing. I also tried to forego the srt and make it a webm, and it has the same clicking sound added.

I made a 30 second clip of the Opus track from the remuxed mkv to post as an example, it sounds fine, no clicking. Why would the Opus track sound fine before muxing, and extracted as a clip after muxing, but have an added clicked sound in the mkv or webm container?

[sneaker_ger]

Try:
Open mkv/webm in the Header Editor. Go Audio track -> default duration. Add element: "20000000". Save. Try again in your player (what player are you using?).

[mkver]

What player are you using? And can you upload a sample of the audio track before it was muxed at all?
FYI: There have been multiple (https://trac.ffmpeg.org/ticket/4178) reports (https://gitlab.com/mbunkus/mkvtoolnix/issues/2099) about a strange glitch with regard to opus, but it could never be tracked down, because all those who have complained had already deleted the file that the encoder produced. (And usually they also hadn't had the source files any more to check whether this is a reproducible bug in the opus encoder.) The bug has something to do with the DiscardPadding element that is used to signal the correct, sample accurate length of an opus packet: The packets of lots of codecs usually only have a few possible values for the number of samples they contain; if I am not mistaken then the length of every opus packet is always a multiple of 120 samples/2.5ms so if you want the encoded file to have th esame number of samples you have to trim something at the end and in Matroska this is designed to be signalled by the DiscardPadding element. It is usually only used in the very last packet, but in the samples we are talking about they are all over the place. If you play such a Matroska file with e.g. MPC-HC, the audio is severly distorted (just listen to the Star Trek sample from ffmpeg's bug tracker). Now here are to things you should know: The ogg container (the "native" container for opus) also has a way to signal what the DiscardPadding element signals. And if you extract the opus track from the Matroska file with mkvextract, the ogg muxer built into mkvextract uses this method so that the resulting files still contain this information. But if you play this ogg/opus file with e.g. MPC-HC the audio will sound normal although opusinfo (a file analyzer from the developers of the opus format) complains about the file being invalid. If you extract the file with ffmpeg (ffmpeg -i <Matroska file> -vn -sn -c:a copy output.opus -- this might be adapted if there are several audio tracks), it doesn't signal the information given by the DiscardPadding elements at all (at least not for the packets in the middle of a stream; I don't know about the very last packet where it is completely normal to have a DiscardPadding element). Consequently opusinfo doesn't complain about the extracted file at all any more and they seem to be fine. And maybe extraction with ffmpeg even repaired the file. But notice that ffmpeg's behaviour is actually not spec compliant.
As has been said: We don't really know if mkvmerge messes it up in the first place or if the files output by the opus encoder are garbage or whatnot.
So to cut a long story short: Please upload the samples. And if you know which tool produced them, then please tell which tool it was (including the version number). If you created the files yourself and if you still have the source files, then please try to reproduce the behaviour.

[fadedfedor]

Try:
Open mkv/webm in the Header Editor. Go Audio track -> default duration. Add element: "20000000". Save. Try again in your player (what player are you using?).
Thanks for the reply. I tried this and it did not make a noticeable change, I still hear the clicking / artifacts. I've tried playing it with mpv, MPC-HC and VLC.

What player are you using? And can you upload a sample of the audio track before it was muxed at all?...And if you know which tool produced them, then please tell which tool it was (including the version number). If you created the files yourself and if you still have the source files, then please try to reproduce the behaviour.
Thank you for your reply as well. I wish I understood more of the information that's in your post and the links you provided, and I am trying to. I first encoded it with foobar2000, but it sounded muffled. Then I encoded it with XMedia Recode 3.4.3.0 (latest) and was happy with the result. I still have the audio track, here's a sample of it: https://a.safe.moe/wNs6w3z.opus

[mkver]

opusinfo doesn't complain about the file you uploaded, it sounds right; and it still does when I remux the file with mkvmerge. In other words: I don't see/hear any bug here. Is this really the file that when remuxed with mkvmerge produced these distortions? Or was that the file produced by foobar2000? Or is did you use ffmpeg to extract only a part of the file that when remuxed with mkvmerge triggered the bug? That's not good, because remuxing with ffmpeg may change even the part of the file that is kept.

[fadedfedor]

Yes, that's really from the Opus track that made the distortions when muxed. I deleted the one produced by foobar2000 immediately, maybe I didn't even need to mention it. I made the clip that I uploaded with XMedia Recode from the Opus track not from a remuxed file.

[mkver]

I just took a look at the file you sent me via PM (for others who want to take a look themselves: link (https://a.safe.moe/6Nwew9a.mkv)):
1. The audio frames in both files coincide; it's just that the opus file has a few more of them. (I used ffmpeg's framehash muxer.)
2. The Matroska file (produced be a pretty recent version of libavformat) has DiscardPadding elements in it; more exactly, it has these elements in fixed intervals: at 980ms, 1980ms, 2980ms... The DiscardPadding is equal to 6.5ms -- equal to the CodecDelay. If one would have to join different opus files (each with a CodecDelay of 6.5ms) together, the resulting file would need to have DiscardPadding elements of 6.5ms in the middle. But because of the DiscardPadding elements the actual blocks with DiscardPadding would only have a length of 13.5 ms. In our case: The block after the block at 980ms would have to start at 993.5ms (which would need to be rounded depending on TimestampScale), but it starts at 1s (so there is a gap in the file).
3. Could you upload the exact source files (video and subtitle file) that you used as input in XMedia Recode (besides the opus file you already uploaded)? And can you give the exact settings that you used? (Because of 1. I already know that you did not reencode the opus track again, but I'd like to know the other settings as well.)
4. If I see this correctly, then you didn't really use mkvmerge in the process of creating the defective mkv at all. Is that true? This is further evidence that mkvmerge isn't to blame for this bug.

[fadedfedor]

Thanks for your analysis. I think you misunderstood me somewhere. I did use mkvmerge (MKVToolNix) to make the defective mkv. I only used XMedia Recode to encode the Opus track and to make a small clip of it to upload as a sample. I put a -2200ms delay on the subtitles when muxing, no other settings were changed.
https://a.safe.moe/G4Y6erB.srt
https://a.safe.moe/v7Ag3o1.webm

[mkver]

Ok, so let me rephrase: If I use mkvmerge to mux the webm file, the srt subs and the opus file that you uploaded I am supposed to get a file that has a defect audio track? Because I just did exactly that and the file I got was not defective.

[fadedfedor]

Ok, so let me rephrase: If I use mkvmerge to mux the webm file, the srt subs and the opus file that you uploaded I am supposed to get a file that has a defect audio track? Because I just did exactly that and the file I got was not defective.
You're right, I just did the same thing and the audio sounds fine. I noticed when I load the short clips there are two tags in the webm with the VP9 video. When I load the full VP9 and Opus tracks that those clips were cut from, there are no tags included. Could that have something to do with it?

[mkver]

Can you upload the full opus file? Or at the least the first few megabyte of it (it's important that you don't remux the file, but simply extract the first few MB (with a hex editor, not with a tool like ffmpeg); yes, you will probably have a defect packet at the end, but if there is enough material before it one can nevertheless use it to analyze it).
I'd be very surprised if the tags had anything to do with it. And the approval of attachments is very slow on this forum. If you ever want to upload something, then don't do it as an attachment. Not that I need a screenshot to show me that there are tags. I know it, because ffmpeg adds some tags by default.

[fadedfedor]

You meant the file before it's muxed into mkv that had the added clicking noises, right? Stupid question probably.
I split the file with a hex editor, is the first 3MB split okay? I don't mind uploading the full Opus file either, it's only 33MB.

https://a.safe.moe/0iTR2WZ.opus

[sneaker_ger]

I can hear the popping with the mkv remuxed from that sample.

[mkver]

If you have no problem uploading the whole sample, then please do so. Thanks.
For ease of reading: A = the opus file you just uploaded, B = file A remuxed with mkvmerge, C = file A remuxed with ffmpeg to opus
1. I can confirm that in B the packets at 980ms, 1980ms etc. have a DiscardPadding element. A uses page durations of 1s and the DiscardPadding elements in B are attached to the last frame out of A's pages (if I am not mistaken).
2. opusinfo has two complaints about B: WARNING: Samples with negative granpos in stream 1
WARNING: EOS not set on stream 1 (normal for live streams)
The second warning is an obvious result of the fact that the file is truncated; I don't think the first warning is, but to be sure I'd like to check the whole 33MB file.
What is remarkable is that there are no "WARNING: Sample count ahead of granule (49920>49608) in stream 1" and no "ERROR: stream 1 has interior holes or more than one page of end trimming" messages. (These are the errors that opusinfo outputs if one extracts the track from B to ogg/opus and analyzes the output with opusinfo.)
3. When A is decoded with the reference decoder, it also has this popping in it, but only once at about 970-980ms; B has it more often, because it has DiscardPadding elements every second. Consequently the decoded output of A and B diverge gradually; the difference in length is 138216 = 443*312 samples. 443s = 7m23s, the length of the file is about 7m24s.
If A is decoded with ffmpeg's native decoder then it is quite ok (the native decoder doesn't strip the CodecDelay away, so that the output file is actually 624 samples longer than the output of the reference decoder).
The differing behaviour of the reference decoder and mkvmerge might be due to a bug in the latter.
4. Unfortunately I don't know an analyzer that does for ogg/opus what mkvinfo does for Matroska.
5. Given that A is likely buggy I'd like to know exactly how you created it. In particular I'd like to know if you can reproducibily produce files like A.

[fadedfedor]

33.9MB Opus (https://we4load.com/1L4G)

http://i.cubeupload.com/p8Yh4b.png

I used these settings to create it with XMedia Recode 3.4.3.0. I deleted the source I used shortly after encoding because I listened to some of it and was happy with the result until I muxed it. I just checked and the source is no longer available online either. Almost forgot to mention that the source was 5.1 and I didn't use a downmix matrix.

[mkver]

If your defective opus file is all you've got, then the best thing to do would be to remux said file with ffmpeg: ffmpeg -i RObV6XA0h1k.opus -c copy output.opus. As has been said, this seems to repair it.
If the video is no longer available and you still want to help, you can try a few similar videos from the same website. They presumably use one set of tools for all their videos so that this behaviour may also be triggered by other videos.

[fadedfedor]

Thanks once again. That did seem to repair it and it sounds fine when muxed into an mkv now. That was my first time using ffmpeg. I'm sure I've used a couple programs that utilize it. I really appreciate your detailed analysis. I'll definitely try more videos from that same site.

[mkver]

You have definitely already used ffmpeg: XMedia Recode uses it; in fact, RObV6XA0h1k.opus was created by ffmpeg: Lavc58.17.100 libopus encoded RObV6XA0h1k.opus. Lavc stands for libavcodec, the library ffmpeg provides for de- and encoding. And the first opus file you uploaded (wNs6w3z.opus) was created using libavformat, ffmpeg's muxer and demuxer library.
But anyway, I can now produce such files myself: As has already been mentioned, ffmpeg's native opus decoder doesn't strip the Preskip/CodecDelay away; instead it adapts the timestamps: The first pcm sample has a timestamp of -312 (if the preskip was 312 samples, the default for libopus) on an 48 kHz timescale (or -6.5ms if you prefer) so that the actually valid samples start at zero. Unfortunately the invalid samples with negative timestamps aren't stripped away later either: If you output it to wave, the wave muxer includes the invalid samples in the output file; and if you reencode an opus file again (using ffmpeg's native decoder and the libopus encoder) the output file causes opusinfo to raise a "Samples with negative granpos in stream 1" warning and mkvmerge includes these DiscardPadding elements in the whole file.
So you don't need to try other files from the site again. I'm currently reading the opus in ogg specs to find out which tool is buggy (and whether files like RObV6XA0h1k.opus are actually against the spec (there might be a reason that opusinfo only shows a warning for such files)) and inform the relevant people. I'm already pretty sure that mkvmerge has a bug: If I don't use an opus input, but offset the timestamps manually with -itsoffset -0.05, I get a file where the DiscardPadding is more than the duration of the block without DiscardPadding:

| + Block group
| + Block: track number 1, 1 frame(s), timestamp 00:00:00.940002336
| + Frame with size 3
| + Discard padding: 10000000
| + Block duration: 00:00:00.009999360
| + Block group
| + Block: track number 1, 1 frame(s), timestamp 00:00:00.960001056
| + Frame with size 3
| + Discard padding: 30000000
| + Block duration: 00:00:00.000000000
| + Block group
| + Block: track number 1, 1 frame(s), timestamp 00:00:00.979999776
| + Frame with size 3
| + Discard padding: 50000000
| + Block duration: 00:00:00.000000000
...
| + Block group
| + Block: track number 1, 1 frame(s), timestamp 00:00:01.940000832
| + Frame with size 163
| + Discard padding: 10000000
| + Block duration: 00:00:00.009999360
| + Block group
| + Block: track number 1, 1 frame(s), timestamp 00:00:01.959999552
| + Frame with size 173
| + Discard padding: 30000000
| + Block duration: 00:00:00.000000000
| + Block group
| + Block: track number 1, 1 frame(s), timestamp 00:00:01.979998272
| + Frame with size 166
| + Discard padding: 50000000
| + Block duration: 00:00:00.000000000
...

One more thing: The offset in RObV6XA0h1k.opus (equal to 312 samples, the Preskip of the reference opus encoder) lets me believe that this file has been reencoded from an source that was already opus. Is that so?

[fadedfedor]

One more thing: The offset in RObV6XA0h1k.opus (equal to 312 samples, the Preskip of the reference opus encoder) lets me believe that this file has been reencoded from an source that was already opus. Is that so?
Yes, the source was Opus. It was an odd 5.1 channel file that I've never seen on that site before.

[kuchikirukia]

I've uploaded a transport stream to your ftp that won't mux. The uncut one is 14GB and when mkvtoolnix tries to mux it it will sit there and read it, slowly filling 14GB of RAM, and then output a 120MB mkv that doesn't work.

If you split it with tsmuxer every piece is broken.
mkvtoolnix doesn't report any errors.

[mkver]

This sounds like a file that doesn't contain a single frame that mkvmerge detects as keyframe. Try the "--engage all_i_slices_are_key_frames" option. If this doesn't solve your problem: Can the transport stream actually be played? And does it contain other tracks than the video stream (can the 120 MB come from an audio stream?)?

[Mosu]

That sample is strange. I've only looked into it for a minute, but ffmpeg isn't happy with it either. Running "ffmpeg -i kuchikirukia\ -\ won\'t\ mux.ts -an -c:v copy ffmpeg.h264" produces an empty file; the similar "ffmpeg -i kuchikirukia\ -\ won\'t\ mux.ts -an -c:v copy ffmpeg.mkv" produces a Matroska file with track headers & tags but without any frame.

As to mkvmerge: the option is called ""--engage all_i_slices_are_key_frames" (additional "_" after "key"), BTW. You can mux the file that way. There are I slices every 500ms which will all be marked as key frames.

If I use mkvmerge with "all_i_slices…", extract the h.264 from that and import into an MP4 with MP4Box, then none of the frames are marked as key frames in the MP4 file (the "stss" atom contains an empty table).

If anyone else wants to take a look: I'll leave the file up here (https://mkvtoolnix.download/misc/kuchikirukia%20-%20won%27t%20mux.ts) for a while.

[mkver]

The file has 27 I frames, 27 SPS/PPS combinations (in the same access units as the keyframes), but no IDR frame and no recovery_point SEI messages. In other words: This is exactly the type of file for which said engage option has been introduced.
ffmpeg by default strips everything in front of the very first keyframe away. This behaviour can be overriden with -copyinkf[:stream_specifier]. Btw: It seems that ffmpeg ignores the Matroska keyframe flags: If I copy the file muxed with mkvmerge with the engage option, then the output file doesn't contain any frames flagged as keyframes (and no cues either, of course).

[manolito]

Also played a little bit with this sample, it is definitely quite broken IMO...

TSDoctor has no problems with it, no errors and no warnings. Demuxing or Remuxing always ends up without any video, no matter if you use MKVMerge or FFmpeg.

//EDIT//
Sorry I have to correct myself...
I just found out that Avidemux can remux this clip to MKV just fine (without any reencoding). I was using the ancient version 2.6.8 which still works under Win XP. As far as I can tell the resulting MKV seems to be in sync. Not too bad...
//End Edit//

But...
This clip can very well get transcoded, either to the same format or to a different format. FFmpeg does it, and it is also possible using AviSynth. As the AVS source filter only DSS2Mod worked for me, the three different versions of ffms2 I tried all failed.

Too bad that this clip really makes it impossible to judge audio sync, but I guess this could be repaired one way or another.


Cheers
manolito

[mkver]

Both mkvmerge (with the engage option already mentioned) and ffmpeg (with the copyinkf option; although you won't get an index in this case and the I frames won't have the keyframe flag set) can mux this file with video.
Do you have any reasons to believe there could be audio sync problems? (The sound doesn't consist in dialogue or noises that are caused by things we see onscreen, so we can't detect audio sync with it.)
If you want to repair this clip, you should add recovery_point SEI messages to the I frames: 0606018480 in hex without the start code (00000005 in Matroska, 000001 in an elementary stream/transport stream; but keep in mind that you can't simply add something in Matroska or a transport stream without breaking the container). Maybe mkvmerge could offer an option to include said recovery_points so that one can reprocess further with other tools who want to derive the keyframe condition on their own and don't use the Matroska flag?

[kuchikirukia]

I'm using a version of FFMS2 I pulled from somewhere (i needed the 10 bit hack) and it works to encode it from the start, it just can't seek. Trying to open it with MeGUI's preview just makes it churn endlessly since it tries to open from the middle.
MPC-HC plays it just fine. Audio's in sync and it has no problems seeking anywhere.

[Mosu]

MKVToolNix v23.0.0 is out containing a moderate number of enhancements and bug fixes.

About AV1 support: even though the previous release was the first to support AV1, keep in mind that neither the bitstream format nor the method of storage in MP4, WebM and Matroska has been finalized yet. I've therefore decided to disable AV1 support by default. You have to enable it manually by passing `--engage enable_av1` to mkvmerge. mkvmerge can still identify AV1 without that option, but it'll refuse to multiplex it.

Note further that only supported bitstream format is the one that was active on 2018-05-02.

To my users on Debian and Ubuntu: the layout of my APT repositories was changed in April. You'll have to update your `sources.list` entry accordingly. Read more about that in this blog post (https://www.bunkus.org/blog/2018/04/debian-ubuntu-apt-repository-changes/).

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

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

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

# Version 23.0.0 "The Bride Said No" 2018-05-02

## New features and enhancements

* mkvmerge: input: format detection uses file-extension to improve performance and to give preference when several formats match.
* mkvmerge: AV1: added support for reading AV1 video from Open Bitstream Unit files.
* mkvmerge: AV1: adjusted the code for the AV1 bitstream format changes made up to 2018-05-02 (git revision d14e878).
* mkvmerge: MP4 reader: if a track has an edit list with two identical entries, each spanning the file's duration as given in the movie header atom, then the second entry will now be ignored. Improves the handling of files with bogus data; see #2196 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2196) and #2270 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2270).
* MKVToolNix GUI: multiplexer: added options to only enable tracks of certain types by default. Implements #2271 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2271).
* MKVToolNix GUI: multiplexer: added an option to enable dialog normalization gain removal by default for all audio tracks for which the operation is supported. Implements #2272 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2272).
* MKVToolNix GUI: multiplexer: when deriving track languages from the file names is active and the file name contains the usual season/episode pattern (e.g. "S02E14"), then only the part after the season/episode pattern will be used for detecting the language. Part of the improvements for #2267 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2267).
* MKVToolNix GUI: multiplexer: the regular expression used for deriving track languages from the file names can now be customized in the preferences. Part of the improvements for #2267 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2267).
* MKVToolNix GUI: multiplexer: the user can now customize the list of track languages the GUI recognizes in file names. This list defaults to a handful of common languages instead of the full list of supported languages. Part of the improvements for #2267 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2267).

## Bug fixes

* mkvmerge: MP3 packetizer: removed a memory leak growing linearly with the track's size.
* mkvmerge: VobSub packetizer: whenever a VobSub packet doesn't contain a duration on the container level, mkvmerge will now set it from the duration in the SPU packets. Before it was accidentally setting the SPU-level duration to 0 instead. Fixes #2260 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2260).
* mkvmerge: track statistics tags: if writing the `Date` element is deactivated via `--no-date`, the `_STATISTICS_WRITING_DATE_UTC` isn't written either anymore. Fixes #2286 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2286).
* mkvmerge, mkvextract, mkvpropedit: removed several small, constant-size memory leaks.
* mkvextract: fixed a crash when mkvextract with a non-Matroska file as the source file. Fixes #2281 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2281).
* MKVToolNix GUI: the central area is now scrollable, allowing the GUI to be resized to almost arbitrary sizes. Fixes #2265 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2265).
* MKVToolNix GUI: multiplexer: the "copy file title to destination file name" functionality will now replace everything in the destination file name up to the last period instead of only up to the first period. Fixes #2276 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2276).

## Build system changes

* build system: MKVToolNix now requires a compiler that supports the following features of the C++14 standard: "user-defined literals for `std::string`". For the GNU Compiler Collection (gcc) this means v5.x or newer; for clang it means v3.4 or newer.
* Windows: linking against and installing shared version of the libraries with MXE is now supported by setting `configure`'s `host` triplet accordingly, e.g. `--host=x86_64-w64-mingw32.shared`.

## Other changes

* mkvmerge: AV1: support for AV1 must be activated manually by adding `--engage enable_av1` as the AV1 bitstream specification hasn't been finalized yet.

Have fun :)

[LeMoi]

Thanks, many new features are quite useful and were missing :)

[Snowknight26]

Tiny bug in at least v23:

When adding source files and selecting index.bdmv of a Blu-ray, the "Select file to add" window generally pops up, listing all the scanned playlists. If you select the first scanned file, then 2nd, then first, and so on, the tracks panel's width grows indefinitely, shrinking the scrollbar.

https://www.stfcc.org/pics/i/99bf261a747beca7ee049e5095b9756a_th.png (https://www.stfcc.org/pics/i/99bf261a747beca7ee049e5095b9756a.png)

[zeropc]

is there a way to start a movie from a certain chapter? if not, can this be added?
this would be very neat to skip those millions of logos at the beginning.

[sneaker_ger]

Ordered chapters (http://mod16.org/hurfdurf/?p=8) can virtually "remove" parts you don't want, but only some players support it (e.g. MPC-HC and VLC).

You can also split on chapter marks ("Output" tab) in the GUI to completely get rid of the stuff you don't want. Of course the usual splitting limitations (keyframes, subtitle lines) still apply.
https://mkvtoolnix.download/doc/mkvmerge.html#d4e768

[hubblec4]

@zeropc

If you need more info and help... here is the right place (https://forum.doom9.org/showthread.php?t=169984) for this.

[hubblec4]

Hi Mosu

Can I mux chapters and tags with mkvpropedit in one go to an existing mkv?

[Mosu]

Sure:

mkvpropedit yourfile.mkv --chapters funny-chapters.xml --tags global:serious-tags.xml

[hubblec4]

Wonderful, thanks for this info.

[zeropc]

thanks hubble & sneaker_ger :)

[Sp00kyFox]

I have a problem here with some DVB-T2 captures (mts, HEVC). I usually cut and remux them afterwards with MKVToolnix. but when there are some hiccups during the recording the audio in the resulting MKV gets out of sync. I guess I can't expect that the tool handles corrupt files correctly, but I was wondering if there is any command or option to prevent MKVToolnix from closing the gap. since when playing the original mts file there is still the hiccup but it keeps in sync. here is a sample with said issue:

https://mega.nz/#!Gc4xgBAC!-yRi2YvR31JiZEgdBZu8OhlzwURbOjdH7EROMldPupw

the hiccup occurs around 0:0:14. remux it with MKVToolNix and the result gets desynced. I'd appreciate any help, thanks!

[manolito]

Wow, this is a real bad hickup...

First of all do not spend any money on TSDoctor, it cannot repair the audio sync. Just the opposite with this file, after letting TSDoctor fix it it will not play in sync any longer.

I found 2 methods to keep the remuxed MKV in sync:

The easiest one is AviDemux. Use COPY for audio and video, use MKV as the muxer. In the settings under "Output" there is an option to create more even timestamps in Copy mode. If you tick it then you will get a couple of warnings about skipped frames, but the result also stays in sync.

The other option is FFmpeg, but only if audio is decoded to WAV. You can later reencode it to AAC or AC3. I also had to disable all extra streams including the subs stream. My FFmpeg version is fairly recent, but it could not detect the subs format. This is the FFmpeg command line I used:
ffmpeg.exe -fflags +genpts -y -i "I:\sample.mts" -map 0:0 -c:v:0 copy -aspect:v:0 16:9 -map 0:1 -c:a:0 pcm_s16le -metadata:s:a:0 "language=deu" -map 0:2 -c:a:1 pcm_s16le -metadata:s:a:1 "language=deu" -shortest "I:\sample.mkv"


Good luck
manolito

[mkver]

That sample is weird: Here is a selection of the timestamps that MKVToolNix produces for the video stream:

B frame, track 1, timestamp 00:00:14.683000000, size 5905, adler 0x77fe5115
P frame, track 1, timestamp 00:00:14.723000000, size 7492, adler 0xc9d3a8b1
P frame, track 1, timestamp 00:00:14.823000000, size 39269, adler 0xf81166f8
B frame, track 1, timestamp 00:00:14.783000000, size 17800, adler 0x77f5c510
B frame, track 1, timestamp 00:00:14.763000000, size 7068, adler 0xf5bcdafa
P frame, track 1, timestamp 00:00:14.803000000, size 7392, adler 0xcc7c6691
P frame, track 1, timestamp 00:00:14.903000000, size 41811, adler 0xef1522c7
B frame, track 1, timestamp 00:00:14.863000000, size 17522, adler 0x2947169a
B frame, track 1, timestamp 00:00:14.843000000, size 7354, adler 0x0ca36690
P frame, track 1, timestamp 00:00:14.883000000, size 6775, adler 0xf0114eff
P frame, track 1, timestamp 00:00:14.983000000, duration 00:00:00.080000000, size 40562, adler 0x43f9aea7
B frame, track 1, timestamp 00:00:14.943000000, size 17214, adler 0x4990347a
B frame, track 1, timestamp 00:00:14.923000000, size 6127, adler 0x030cff37
P frame, track 1, timestamp 00:00:14.963000000, size 6162, adler 0x39c8e3f5
P frame, track 1, timestamp 00:00:15.063000000, duration 00:00:02.500000000, size 54072, adler 0x7da33895
P frame, track 1, timestamp 00:00:17.583000000, size 9334, adler 0x88830309
B frame, track 1, timestamp 00:00:17.563000000, size 5986, adler 0xa78fa29b
P frame, track 1, timestamp 00:00:17.603000000, duration 00:00:00.040000000, size 6204, adler 0x05e501b3
P frame, track 1, timestamp 00:00:17.703000000, size 28974, adler 0x589c0d84
B frame, track 1, timestamp 00:00:17.663000000, size 9435, adler 0xd1413b81
B frame, track 1, timestamp 00:00:17.643000000, size 5678, adler 0x9569018e
P frame, track 1, timestamp 00:00:17.683000000, size 5745, adler 0xa2983a9c
P frame, track 1, timestamp 00:00:17.783000000, size 32748, adler 0xaa58c28e
B frame, track 1, timestamp 00:00:17.743000000, size 9003, adler 0x3bfb6ac0
B frame, track 1, timestamp 00:00:17.723000000, size 5656, adler 0x76b9019c
P frame, track 1, timestamp 00:00:17.763000000, size 5459, adler 0x49a19fa5
P frame, track 1, timestamp 00:00:17.863000000, size 32155, adler 0x599cab02
B frame, track 1, timestamp 00:00:17.823000000, size 8498, adler 0xac1282b0
B frame, track 1, timestamp 00:00:17.803000000, size 4970, adler 0x3e389ce3
P frame, track 1, timestamp 00:00:17.843000000, size 5419, adler 0x48907c49
P frame, track 1, timestamp 00:00:17.943000000, size 30719, adler 0xedeeb630
B frame, track 1, timestamp 00:00:17.903000000, size 8410, adler 0xf8d2594f
B frame, track 1, timestamp 00:00:17.883000000, size 5525, adler 0xec7dd765
P frame, track 1, timestamp 00:00:17.923000000, size 5672, adler 0xcee0f180
I frame, track 1, timestamp 00:00:18.023000000, size 52082, adler 0x254477d4
B frame, track 1, timestamp 00:00:17.983000000, size 7646, adler 0x226ebbc3
B frame, track 1, timestamp 00:00:17.963000000, size 5603, adler 0xbd84cf41
P frame, track 1, timestamp 00:00:18.003000000, size 5627, adler 0xf3ec2549
P frame, track 1, timestamp 00:00:18.103000000, duration 00:00:00.040000000, size 34160, adler 0x850647c8
B frame, track 1, timestamp 00:00:18.063000000, size 7740, adler 0x91eaef29
B frame, track 1, timestamp 00:00:18.043000000, size 4781, adler 0xd48d6b83
P frame, track 1, timestamp 00:00:18.083000000, size 4870, adler 0x87604e98
P frame, track 1, timestamp 00:00:18.183000000, size 30475, adler 0x763c5976
P frame, track 1, timestamp 00:00:18.143000000, duration 00:00:00.040000000, size 9822, adler 0xdb050357
B frame, track 1, timestamp 00:00:15.503000000, size 9059, adler 0x148db74b
B frame, track 1, timestamp 00:00:15.483000000, size 4751, adler 0xf4273b64
P frame, track 1, timestamp 00:00:15.523000000, duration 00:00:00.040000000, size 5091, adler 0xff93096a
P frame, track 1, timestamp 00:00:15.623000000, size 32602, adler 0x009a8195
B frame, track 1, timestamp 00:00:15.583000000, size 12851, adler 0xd40500a2
B frame, track 1, timestamp 00:00:15.563000000, size 7913, adler 0xb7f2854e
P frame, track 1, timestamp 00:00:15.603000000, size 8057, adler 0x4a5fd8ed
...
B frame, track 1, timestamp 00:00:17.183000000, size 9020, adler 0x9f776665
B frame, track 1, timestamp 00:00:17.163000000, size 5280, adler 0x1aa6424b
P frame, track 1, timestamp 00:00:17.203000000, size 6087, adler 0x56b9ef41
P frame, track 1, timestamp 00:00:17.303000000, size 32706, adler 0xc4c9c5d4
B frame, track 1, timestamp 00:00:17.263000000, size 8916, adler 0x63451274
B frame, track 1, timestamp 00:00:17.243000000, size 5775, adler 0x53614f69
P frame, track 1, timestamp 00:00:17.283000000, size 5830, adler 0x3bbc415c
P frame, track 1, timestamp 00:00:17.383000000, size 33581, adler 0xe81607af
B frame, track 1, timestamp 00:00:17.343000000, size 9170, adler 0xff80ce50
B frame, track 1, timestamp 00:00:17.323000000, size 5401, adler 0xb95b8c57
P frame, track 1, timestamp 00:00:17.363000000, size 5737, adler 0xd0bb4d6b
P frame, track 1, timestamp 00:00:17.463000000, size 29957, adler 0x8fc5a400
B frame, track 1, timestamp 00:00:17.423000000, size 9846, adler 0xa9862ab8
B frame, track 1, timestamp 00:00:17.403000000, size 6106, adler 0x13f0d4c9
P frame, track 1, timestamp 00:00:17.443000000, size 6747, adler 0xaa1a4085
P frame, track 1, timestamp 00:00:17.543000000, size 28533, adler 0x889598f0
B frame, track 1, timestamp 00:00:17.503000000, size 9428, adler 0x1b643ff4
B frame, track 1, timestamp 00:00:17.483000000, size 6461, adler 0x97dab14f
P frame, track 1, timestamp 00:00:17.523000000, size 6278, adler 0xe8d2403e
P frame, track 1, timestamp 00:00:17.623000000, size 29976, adler 0xa9ac3da5
B frame, track 1, timestamp 00:00:17.583000000, size 9334, adler 0x88830309
B frame, track 1, timestamp 00:00:17.563000000, size 5986, adler 0xa78fa29b
P frame, track 1, timestamp 00:00:17.603000000, size 6204, adler 0x05e501b3
P frame, track 1, timestamp 00:00:17.703000000, size 28974, adler 0x589c0d84
B frame, track 1, timestamp 00:00:17.663000000, size 9435, adler 0xd1413b81
B frame, track 1, timestamp 00:00:17.643000000, size 5678, adler 0x9569018e
P frame, track 1, timestamp 00:00:17.683000000, size 5745, adler 0xa2983a9c
P frame, track 1, timestamp 00:00:17.783000000, size 32748, adler 0xaa58c28e
B frame, track 1, timestamp 00:00:17.743000000, size 9003, adler 0x3bfb6ac0
B frame, track 1, timestamp 00:00:17.723000000, size 5656, adler 0x76b9019c
P frame, track 1, timestamp 00:00:17.763000000, size 5459, adler 0x49a19fa5
P frame, track 1, timestamp 00:00:17.863000000, size 32155, adler 0x599cab02
B frame, track 1, timestamp 00:00:17.823000000, size 8498, adler 0xac1282b0
B frame, track 1, timestamp 00:00:17.803000000, size 4970, adler 0x3e389ce3
P frame, track 1, timestamp 00:00:17.843000000, size 5419, adler 0x48907c49
P frame, track 1, timestamp 00:00:17.943000000, size 30719, adler 0xedeeb630
B frame, track 1, timestamp 00:00:17.903000000, size 8410, adler 0xf8d2594f
B frame, track 1, timestamp 00:00:17.883000000, size 5525, adler 0xec7dd765
P frame, track 1, timestamp 00:00:17.923000000, size 5672, adler 0xcee0f180
I frame, track 1, timestamp 00:00:18.023000000, size 52082, adler 0x254477d4
B frame, track 1, timestamp 00:00:17.983000000, size 7646, adler 0x226ebbc3
B frame, track 1, timestamp 00:00:17.963000000, size 5603, adler 0xbd84cf41
P frame, track 1, timestamp 00:00:18.003000000, size 5627, adler 0xf3ec2549
P frame, track 1, timestamp 00:00:18.103000000, size 34160, adler 0x850647c8
B frame, track 1, timestamp 00:00:18.063000000, size 7740, adler 0x91eaef29
B frame, track 1, timestamp 00:00:18.043000000, size 4781, adler 0xd48d6b83
P frame, track 1, timestamp 00:00:18.083000000, size 4870, adler 0x87604e98
P frame, track 1, timestamp 00:00:18.183000000, size 30475, adler 0x763c5976
B frame, track 1, timestamp 00:00:18.143000000, size 9822, adler 0xdb050357
B frame, track 1, timestamp 00:00:18.123000000, size 4600, adler 0x99a7eafd
P frame, track 1, timestamp 00:00:18.163000000, size 4082, adler 0x55c71256
P frame, track 1, timestamp 00:00:18.263000000, size 31747, adler 0xcf232b6e
B frame, track 1, timestamp 00:00:18.223000000, size 10340, adler 0xfee421db
B frame, track 1, timestamp 00:00:18.203000000, size 4685, adler 0x60391107
P frame, track 1, timestamp 00:00:18.243000000, size 4958, adler 0xdbadafec
P frame, track 1, timestamp 00:00:18.343000000, size 31606, adler 0xb7f4f75d
B frame, track 1, timestamp 00:00:18.303000000, size 10588, adler 0x1a50895d
B frame, track 1, timestamp 00:00:18.283000000, size 5079, adler 0xd794eec5
P frame, track 1, timestamp 00:00:18.323000000, size 4937, adler 0x49596eb3
P frame, track 1, timestamp 00:00:18.423000000, size 31821, adler 0x8064d43e
B frame, track 1, timestamp 00:00:18.383000000, size 9972, adler 0x4cd6611c
B frame, track 1, timestamp 00:00:18.363000000, size 4410, adler 0x4b54aa42
P frame, track 1, timestamp 00:00:18.403000000, size 4407, adler 0xd0ee7f79
P frame, track 1, timestamp 00:00:18.503000000, size 32125, adler 0xfd1484b1
B frame, track 1, timestamp 00:00:18.463000000, size 9686, adler 0xf6e8b772
B frame, track 1, timestamp 00:00:18.443000000, size 4400, adler 0xca9d7802
P frame, track 1, timestamp 00:00:18.483000000, size 4192, adler 0xf00e2d6a
P frame, track 1, timestamp 00:00:18.583000000, size 32390, adler 0x76b8e4d7
B frame, track 1, timestamp 00:00:18.543000000, size 8114, adler 0xf66be2b8
B frame, track 1, timestamp 00:00:18.523000000, size 4325, adler 0xb76fa0c5
P frame, track 1, timestamp 00:00:18.563000000, size 5358, adler 0xb6fc5e37
P frame, track 1, timestamp 00:00:18.663000000, size 31926, adler 0x754efed5
B frame, track 1, timestamp 00:00:18.623000000, size 8209, adler 0xd145cb14
B frame, track 1, timestamp 00:00:18.603000000, size 5177, adler 0x169e1b7d
P frame, track 1, timestamp 00:00:18.643000000, size 5181, adler 0x9929062c
P frame, track 1, timestamp 00:00:18.743000000, size 31480, adler 0x4350e50e
B frame, track 1, timestamp 00:00:18.703000000, size 8789, adler 0x2166ef9d
B frame, track 1, timestamp 00:00:18.683000000, size 5172, adler 0xecd20fca
P frame, track 1, timestamp 00:00:18.723000000, size 5632, adler 0x595dbecf
P frame, track 1, timestamp 00:00:18.823000000, size 30210, adler 0x13a2c4b3
B frame, track 1, timestamp 00:00:18.783000000, size 9503, adler 0x97036215
B frame, track 1, timestamp 00:00:18.763000000, size 6270, adler 0x34992280
P frame, track 1, timestamp 00:00:18.803000000, size 6563, adler 0x61ecc81b
P frame, track 1, timestamp 00:00:18.903000000, size 30006, adler 0xb3e1f7f1
B frame, track 1, timestamp 00:00:18.863000000, size 9644, adler 0xf2369b6b
B frame, track 1, timestamp 00:00:18.843000000, size 6438, adler 0x21dd73b1
P frame, track 1, timestamp 00:00:18.883000000, size 6615, adler 0xa171d824

There are two things of note in there: First, the timestamp of the packet immediately after 15.063 is 17.583, then there are some packets until 18.143 and then we have a packet with timestamp 15.503 diretctly after that. The second jump can't be explained by frame reordering at all. And secondly, after the second jump we have normal video once again -- including packts with the same timestamps and checksums (the adler stuff). Therefore your m2ts file is not only missing some packets (as is normal for a bad transmission), it also has something twice. Analysing the file yields that the blocks 12341248-12842816 and 14700544-15202112 coincide. These 501568 bytes correspond to 2612 1/3 packets. Looking at the above timestamps (or also at the timestamps contained in the first four bytes before the actual 188 bytes transport stream packet) one sees that the first of these blocks should be deleted; but because that would leave an incomplete packet at 12341248 I have only deleted 12341312-12842816. If I feed this to mkvmerge, the A/V sync is good and the hiccup is not so bad any more.
Btw: Using ffmpeg produced a file where the aac tracks used an uncommon format (the A_MS/ACM CodecId and LATM at the bitstream level) and that also had a second error at about 17s. But the snc was fine.

[Sp00kyFox]

yeah, I stumbled upon TS Doctor but I thought I better ask here first. usually there are some free solutions available from the video community. thanks for the heads-up. I only have this problem with some stations. since it is a terrestrial broadcasting I suppose there is a problem with the signal strength and it introduces the occasional packet loss. maybe I should get me a bigger antenna. anyways. many thanks for the help manolito and mkver. I tried Avidemux on the full recording and it worked just fine, awesome.

[VoodooFX]

I remuxed one mp4 video to mkv with mkvtoolnix v23 and noticed that mkv video stutters (skips frames), when mp4 plays properly, there where no warnings or errors in "job output".
Then I tried to remux with Avidemux and got this message:
https://i.imgur.com/l0xHGV3.png

Would be nice to get warning that something wrong with PTS in mkvtoolnix too, or even option to reconstruct PTS.

[Mosu]

mkvmerge used to contain a similar warning if the CTTS atom wasn't present, but it didn't actually check whether or not there were B frames present. This meant that the warning was often shown in error, meaning the CTTS atom not being present was OK as there were no B frames.

Due to how mkvmerge works internally, the container-reading code doesn't have a lot of (if any) knowledge about the bitstreams of the various codecs the container can carry. Therefore analyzing whether or not B frames are present in the MP4 reader would amount to a lot of work and/or a noticeable slowdown in processing speed, neither of which I want.

I therefore decided to remove the warning altogether a couple of releases ago. It won't come back.

[VoodooFX]

That "Question" popup in Avidemux I got almost instantly after opening mp4, so its implementation not so slow. Real slowdown would be need to double check remuxed mkvs for this error.
I hope you reconsider implementing it in future. Thank you.

[Mosu]

In case of a positive hit (CTTS not present but B frames present), the slowdown would indeed be unnoticeable as a B frame is almost certainly encountered right away. The place where the slowdown does hurt and does occur, though, is if the file is valid (CTTS not present and B frames not present either), because in that case mkvmerge would have to parse the whole bitstream in the demuxer to no avail.

No, I won't reconsider. I have a lot of things I actually want to work on that are much more relevant. Your file is something that happens very, very rarely, after all.

[foxyshadis]

I have a problem here with some DVB-T2 captures (mts, HEVC). I usually cut and remux them afterwards with MKVToolnix. but when there are some hiccups during the recording the audio in the resulting MKV gets out of sync. I guess I can't expect that the tool handles corrupt files correctly, but I was wondering if there is any command or option to prevent MKVToolnix from closing the gap. since when playing the original mts file there is still the hiccup but it keeps in sync. here is a sample with said issue:

https://mega.nz/#!Gc4xgBAC!-yRi2YvR31JiZEgdBZu8OhlzwURbOjdH7EROMldPupw

the hiccup occurs around 0:0:14. remux it with MKVToolNix and the result gets desynced. I'd appreciate any help, thanks!

Just curious, but what capture software is this? They're supposed to filter out repeated PTS.

[FishPencil]

Can mkvmerge handle PGS subtitles with some of the subtitles having the forced flag set?

I believe that some studios bundle the forced and nonforced subtitles into one PGS stream and a flag is set for each image to denote its type.

If I multiplex an m2ts with these subtitles included, will the resulting mkv work with the forced ones?

If not, how should this be handled?

[Sp00kyFox]

Just curious, but what capture software is this? They're supposed to filter out repeated PTS.
not any. I'm using a DVB-T2 receiver with PVR feature. it is the Comag SL30T2.

[Mosu]

Can mkvmerge handle PGS subtitles with some of the subtitles having the forced flag set?

mkvmerge doesn't do anything regarding that flag. It simply copies the whole PGS stream as-is.

[manolito]

not any. I'm using a DVB-T2 receiver with PVR feature. it is the Comag SL30T2.

Only few folks here in Germany use USB tuners to capture DVB-T2 directly to the computer. Due to the HEVC format in 1080p @ 50fps this requires a very powerful machine.

For receivers with PVR the users are entirely at the mercy of the manufacturer (or the chipset manufacturer). My XORO HRT 720 seems to have the same chipset as your Comag. The latest firmware update was from June 2017, and it does not look like there will be any more updates in the future. But so far I never had such ugly glitches as you had in my captured files, not even on days when the air is full of low flying choppers (when some foreign high security politician is visiting Angie...)


Cheers
manolito

[Mosu]

Hey.

time for MKVToolNix v24.0.0, a release that's on the smaller side regarding the number of changes: nothing major, a number of smaller bugs squashed, a couple of enhancements.

AV1 support hasn't changed as the bitstream format still hasn't been finalized.

To my users on Debian and Ubuntu: just a friendly reminder that the layout of my APT repositories was changed in April. If you haven't done so, you'll have to update your `sources.list` entry accordingly. Read more about that in this blog post (https://www.bunkus.org/blog/2018/04/debian-ubuntu-apt-repository-changes/).

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

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

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

# Version 24.0.0 "Beyond The Pale" 2018-06-10

## New features and enhancements

* mkvmerge: MP4 reader: improved the detection of edit lists consisting of two identical entries, each spanning the file's duration as given in the movie header atom. The second entry is ignored in such cases. See #2306 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2306).
* mkvmerge: JSON identification: the "display unit" video track property is now reported as `display_unit`. The JSON schema has been bumped to v11 for this change.
* mkvmerge, mkvextract: AVC/h.264: empty NALUs will now be removed.
* mkvextract: VobSub extraction: empty SPU packets will now be dropped during extraction as other tools such as MP4Box cannot handle them correctly. Implements #2293 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2293).

## Bug fixes

* mkvmerge: E-AC-3 parser: fixed determining the number of channels for streams that contain an AC-3 core with dependent E-AC-3 frames. Fixes #2283 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2283).
* mkvmerge: Matroska reader: fixed mkvmerge buffering the whole file if a video track is multiplexed that consists of only one or a few frames. Fixes #2304 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2304).
* mkvmerge: the "display unit" video track property will now be kept if it is set in the source file. Fixes #2317 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2317).
* MKVToolNix GUI: multiplexer: when scanning playlists, all playlists were offered for selection regardless of the value of the "minimum playlist duration" setting. Fixes #2299 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2299).
* MKVToolNix GUI: multiplexer: deriving track languages from file names: the regular sub-expressions for ISO 639-1 codes could match on empty strings, too, causing matches in wrong places and hence no language being recognized in certain situations. Fixes #2298 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2298).
* MKVToolNix GUI: header editor: fixed a crash when saving the file fails (e.g. because it isn't writable). Fixes #2319 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2319).
* MKVToolNix GUI: header editor: the editor was wrongfully claiming that mandatory elements with default values cannot be removed in the "status" text. Fixes #2320 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2320).
* MKVToolNix GUI: preferences: on macOS & Linux the setting "enable copying tracks by their type" wasn't restored on program start. Fixes #2297 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2297).

## Other changes

* Niels Lohmann's JSON library: the bundled version has been updated from v1.1.0 (git revision 54d3cab) to v3.1.1 (git revision g183390c1).
* pugixml library: the bundled version has been updated from v1.8 to v1.9 (git revision e584ea3).

Have fun :)

[hubblec4]

Many thanks for this upgrade and your work.

[Midzuki]

Regression report:

recent versions of MKVtoolnix are unable to mux MLP files correctly.
Version 5.8.0 of MKVmerge did the job well and produced a 28.3 MB .mka from a 26.8 .MLP, whereas MKVmerge 24.0.0 generates a 22.4 MB .mka from the same source.

Sample files: http://www.mediafire.com/file/dpwrgu1z1mtkr1k/MLP-at-44100Hz-Sample.7z/file

[mkver]

In Midzuki's case 7.6 was the last version that worked; the behaviour changed in 7.7.

[SeeMoreDigital]

Regression report:

recent versions of MKVtoolnix are unable to mux MLP files correctly.
Version 5.8.0 of MKVmerge did the job well and produced a 28.3 MB .mka from a 26.8 .MLP, whereas MKVmerge 24.0.0 generates a 22.4 MB .mka from the same source.

Sample files: http://www.mediafire.com/file/dpwrgu1z1mtkr1k/MLP-at-44100Hz-Sample.7z/fileOut of interest... Why don't you re-encode your .mlp contained files to flac?

[Mosu]

recent versions of MKVtoolnix are unable to mux MLP files correctly.

Thanks for the report. But please open an issue on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/). Otherwise chances are I'll forget about it again.

[Midzuki]

Thanks for the report. But please open an issue on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/). Otherwise chances are I'll forget about it again.

Done. And many thanks for answering :thanks:

[v0lt]

@Mosu
In old versions of "mkvinfo.exe" the "--gui" key worked. Now it does not work :(, can I return it?

[Mosu]

mkvinfo's GUI has been removed and replaced by the "info" tool in MKVToolNix GUI. You can start that directly via "mkvtoolnix-gui --info yourfile.mkv".

mkvinfo's GUI won't be coming back.

[arrgh]

Yes, for the sake of completeness — but if I'm entirely honest, then that feature probably has the lowest priority of all the things that I still want to implement. Mostly because I have zero interest in 3D myself.

Hi Mosu
did this feature to mux MVC-mkv move up in the priority list somewhat...?

Thanks

[mike23]

How can I find out with mkvtoolnix what the average video bitrate of a *.mkv video is?

Sometimes tools like MediaInfo do not show this info.
See as sample snapshot here:
http://easycaptures.com/2581037801

But I could imagine that this is possible with mkvtooolnix

[mkver]

Some muxers like mkvmerge (or MakeMKV) add statistcs tags by default that enable MediaInfo to show the average bitrate of the tracks in the file to the user. If these tracks aren't there, MediaInfo simply doesn't know the numbers.
You can use mkvpropedit (a part of MKVToolNix) to add the track statistics tags to your file: mkvpropedit --add-track-statistics-tags <file>

[mike23]

You can use mkvpropedit (a part of MKVToolNix) to add the track statistics tags to your file: mkvpropedit --add-track-statistics-tags <file>

Thank you for the suggestion.

I executed the command (on an existing *.mkv file) just as above and yes the output looks good:

The file is being analyzed.
The file is read in order to create track statistics.
Progress: 100%
The changes are written to the file.
Done.

But when I drag the *.mkv file afterwards onto MediaInfo again then the average bitrate is still NOT shown.

Whats wrong?

BTW: Can I somehow execute the --add-track-statistics-tags operation in the GUI version of mkvpropedit as well?
I found no corresponding checkbox or menu

And finally I wonder if there is a GUI which let me do this without changing the *.mkv file. In other words which analyze the mkv and show me all infos about the used codecs. Unfortunately
mkvtoolnix-gui.exe does not offer this function

[mkver]

You are right. My version of MediaInfo (18.03.1) shows it only in the following way:


Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, RefFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 4 s 160 ms
Bit rate : 8 409 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 50.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.182
Stream size : 4.17 MiB (95%)
Default : Yes
Forced : No
Statistics Tags Issue : mkvpropedit v24.0.0 ('Beyond The Pale') 64-bit 2018-06-16 09:28:36 / Lavf58.13.100
FromStats_BitRate : 11464630
FromStats_Duration : 00:00:03.120000000
FromStats_FrameCount : 150
FromStats_StreamSize : 4471206

Audio
ID : 2
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : A_MPEG/L2
Codec ID/Hint : MP2
Duration : 4 s 166 ms
Bit rate mode : Constant
Bit rate : 256 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Compression mode : Lossy
Delay relative to video : -1 s 46 ms
Stream size : 130 KiB (3%)
Language : German
Default : Yes
Forced : No
Statistics Tags Issue : mkvpropedit v24.0.0 ('Beyond The Pale') 64-bit 2018-06-16 09:28:36 / Lavf58.13.100
FromStats_BitRate : 257542
FromStats_Duration : 00:00:03.984000000
FromStats_FrameCount : 167
FromStats_StreamSize : 128256

It seems that MediaInfo doesn't display the track statistics tags in the usual way if the tags don't seem to have been created during muxing. This even applies to the case when there is a "date" element in the header so that one can check whether the tags are up to date (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Automatic-tag-generation#determining-if-the-tags-are-up-to-date) (ffmpeg/Lavf doesn't write the date element). I'll report this to the MediaInfo developers.

[Mosu]

did this feature to mux MVC-mkv move up in the priority list somewhat...?

No, it didn't.

[v0lt]

mkvinfo's GUI has been removed and replaced by the "info" tool in MKVToolNix GUI. You can start that directly via "mkvtoolnix-gui --info yourfile.mkv".

mkvinfo's GUI won't be coming back.
It's a pity.
Can I run mkvtoolnix-gui.exe with English translation? I need something like the "--ui-language en" key, which was in mkvinfo.exe.

[Mosu]

Can I run mkvtoolnix-gui.exe with English translation? I need something like the "--ui-language en" key, which was in mkvinfo.exe.

That doesn't work at the moment, though I'm not sure why. It certainly was my intention to have that working. I'll look into it.

[Midzuki]

Not a bug report at all, just a *request-for-comments*.

mpv was unable to deal with Matroska files that contain MLP streams. I reported the flaw, and today that flaw has been fixed. I downloaded the latest Windows build of mpv from SourceForge and put it to the test. Now mpv.exe shows the following warning message:

=> mpv PaBailar-580.mka
Playing: PaBailar-580.mka
(+) Audio --aid=1 --alang=spa (*) (mlp 2ch 44100Hz)
[mkv] This is a broken file! Packets with incorrect keyframe flag found. Enabling workaround.
AO: [wasapi] 48000Hz 5.1 6ch float

So my question is: ¿does that warning make any sense? :confused:

[Mosu]

Does that happen with TrueHD files produced by MKVToolNix as well?

[Midzuki]

Does that happen with TrueHD files produced by MKVToolNix as well?

I don't have any sample files with TrueHD audio, so I don't know.

Given that MPlayer (a.k.a. «the real thing») just plays that .MKA file without a complaint, I assume the mpv developers don't know very-well what they're doing :(

[Mosu]

I'm asking about TrueHD as TrueHD and MLP are very similar. Both are two of the few audio codecs (RealAudio being another one) where you cannot start decoding from any packet. Therefore mkvmerge flags only those frames decoding can start from as key frames. Maybe mpv expects that all audio frames are marked as key frames — but that's just conjecture, of course, I don't know mpv's source code.

[SeeMoreDigital]

Unlike Dolby TrueHD audio streams on Blu-ray discs, DVD-Audio discs are essentially PCM streams packed into the .mlp container.

Personally I don't see any benefit of keeping a PCM audio stream within the .mlp container and containing it again within the .mka container. Which is why I've backed up all my DVD-A's to flac.

Sufficed to say, flac can be muxed into the .mka container and the files are smaller than the original .mlp contained files...

[Midzuki]

^ Okay, I found and tested a TrueHD MKA file. Just for the notes, MediaInfo says

Track name : Final Fantasy Advent Children Complete (2009)
Encoded date : UTC 2011-07-05 20:41:36
Writing application : mkvmerge v4.6.0 ('Still Crazy After All These Years') built on Apr 1 2011 21:01:49
Writing library : libebml v1.2.0 + libmatroska v1.1.0

This time mpv didn't display any stupid /misleading message:

=> mpv TrueHD-Sample.mka
Playing: TrueHD-Sample.mka
(+) Audio --aid=1 (*) (truehd 6ch 48000Hz)
File tags:
Title: Final Fantasy Advent Children Complete (2009)
AO: [wasapi] 48000Hz 5.1(side) 6ch s32

So the problem really is in mpv itself, not in MKVmerge (or in FFmpeg). Before I reported that issue, mpv already dealed with containerless .MLP streams, it simply didn't know what to do with MLP audio in a Matroska container.

I was going to tell the mpv people to take a look at our latest comments in this thread, but the admin of mpv's Github locked the issue I filed because it became "too hot" :rolleyes:

[Midzuki]

Unlike Dolby TrueHD audio streams on Blu-ray discs, DVD-Audio discs are essentially PCM streams packed into the .mlp container.

Personally I don't see any benefit of keeping a PCM audio stream within the .mlp container and containing it again within the .mka container. Which is why I've backed up all my DVD-A's to flac.

Sufficed to say, flac can be muxed into the .mka container and the files are smaller than the original .mlp contained files...

You missed the whole point. I should send you to my IgnoreList (again), but I won't. Not yet, at least =)

P.S.: MLP is not a container for uncompressed audio. PCM is not the same as PPCM.

[SeeMoreDigital]

I just don't see the benefit of placing mlp compressed PCM streams within the .mka container!

[mkver]

So the problem really is in mpv itself, not in MKVmerge (or in FFmpeg).
Strange. In my experience ffmpeg wants all audio packets to be flagged as keyframes. When I play a Matroska file created by mkvmerge with video and TrueHD audio and seek in the input file (e.g. ffmpeg -ss 10 -i <mkv file created by mkvmerge> ...) I usually get a "File is broken, keyframes not correctly marked!" error. Given that the index is for the video, the first audio packet received after the seek is probably a non-keyframe. Strangely this doesn't happen without a video track although mkvmerge does not take the keyframe flag into account for creating the cues for files without video track. (Btw: It also doesn't take the clustering into account in this case.)

[Mosu]

"File is broken, keyframes not correctly marked!"

This looks like a bug in ffmpeg to me. libavformat/matroskadec. (https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskadec.c#L3358) seems to assume that the first non-subtitle ( = audio or video) block after a seek-to-keyframe operation must be a key frame. The situation with MLP & TrueHD is, though, that ffmpeg might try to seek to a video key frame and find an audio block first — and that audio block isn't a key frame because it doesn't contain an MLP/TrueHD sync frame.

[foxyshadis]

I just don't see the benefit of placing mlp compressed PCM streams within the .mka container!

Why would you put anything in an mka container? Seeking, standardized tags, chaptering... there are a lot of potential reasons.

MLP is virtually identical to FLAC from a high-level technical standpoint, although it's obviously implemented to suit the constraints of fixed rotational speeds and buffer sizes, as well as often being fixed-bitrate (meaning just stripping padding and re-packetizing it would win you a lot, as well as changing every frame to a keyframe). Plus MLP has no standardized tags or seek tables, so why wouldn't you place it in a container that does?

[SeeMoreDigital]

In today's world (ppcm) mlp is pointless, in or out the .mka container!

Flac offers tagging and image art and far greater software and hardware playback device support.

Sadly I'm yet to find a hardware playback device that supports .mka chapter navigation. Which is why I'm still creating .cue files...

[LeMoi]

I think title of the topic should be changed to meet latest version

[hubblec4]

I think title of the topic should be changed to meet latest version

please read here
https://forum.doom9.org/showthread.php?t=175541

[LeMoi]

Thanks for the info, didn't notice, hope mods can do something :)

[foxyshadis]

Excellent point, done. I'd normally suggest reporting posts when mod action is needed, except avih hasn't been around in a while and Koepi hasn't been around since Longcat was a fresh meme. I should petition to get myself added as a mod on more of the abandoned fora.

[SeeMoreDigital]

Excellent point, done. I'd normally suggest reporting posts when mod action is needed, except avih hasn't been around in a while and Koepi hasn't been around since Longcat was a fresh meme. I should petition to get myself added as a mod on more of the abandoned fora.
Sadly, quite a few moderators are MIA :(

[Masutin]

An issue with splitting. To cut the same duration, counting from the end, at the end of files of different lengths, is there a way to specify a duration (not a timestamp) FROM the end of a file? If not for mkvmerge, for FFmpeg if appropriate.

[Mosu]

Not for mkvmerge, as the file's duration is generally only only after it has been fully muxed.

[Perenista]

Is there a way to turn a video 90 degrees clockwise with MKVToolnix? Or I need to use another software like Sony Vegas and reencode?

[Mosu]

Is there a way to turn a video 90 degrees clockwise with MKVToolnix? Or I need to use another software like Sony Vegas and reencode?

MKVToolNix cannot do this. It's not a video editor/encoder. Additionally there are no provisions for filters/modifications/projections upon display in Matroska either.

[Perenista]

MKVToolNix cannot do this. It's not a video editor/encoder. Additionally there are no provisions for filters/modifications/projections upon display in Matroska either.Hum, what do you mean?

For example, if I wanted to change the display aspect ratio in MKVToolnix I could do that easily. Some videos have a wrong AR, and I usually adjust them by configuring the AR to 4:3, or even 16:9, depending on the case.

Sometimes I use MakeMKV and the extra features are in 3:2 for some odd reason (it only happens with certain discs). Then I use that option to correct the MKV files.

I assumed that since this sort of modification is possible (while mantaining the contents in lossless) I could easily turn the video 90 degrees clockwise without any unnecessary reencode.

The issue with my video is that I recorded using an iPAD Pro 10.5 while not using landscape/portrait properly. So the video looks like this now:

https://imgur.com/a/SkBt9ZZ

Another reason for me to not want to resort to reencode is that I have multiple videos from the iPAD, and once ONE is reencoded you have to do the same for all others, since it's not possible to combine them by using MKVToolnix anymore *.

* At least I don't think this can be done, I remember seeing "the streams don't match" warnings in the past.

I assumed "90 degrees clockwise" was just another random command given to the Matroska just like "change the AR to 4:3, 16:9 or 1.85:1), and the player would only interpret it to adjust accordingly.

Do you guys follow my line of reasoning...?

[Mosu]

Changing the display aspect ratio is basically the only such operation that you can do in Matroska without reencoding the video.

[gpower2]

Hey guys! I have a question for the experts:
A friend of mine was hit by a ransomware and lost a lot of his files. He is interested in a particular mkv file which seems to only have its first bytes encrypted, meaning the mkv header is totally corrupted, yet the track data remain intact.
Is there a way to extract the tracks of that damaged mkv, or recreate the mkv header?

Thanks! :)

[Mosu]

If they know the codec type and order of tracks, they could create a second file with the same track types and track order. Then use a hex editor and combine the track headers (everything before the first cluster) from the second file with the clusters from the encrypted file.

One problem will be CodecPrivate content. This won't be 100% identical in the second file you've created. However, you might get away with additional steps:

Extract the video track from the combined file with "--raw"
Remux that extracted data with mkvmerge

This might work if it's h.264 or h.265 and the SPS/PPS are part of the bitstream as mkvmerge will then be able to re-create the CodecPrivate from the bitstream.

Things get somewhat more complicated with AAC and CodecPrivate. In that case I'd try hard to simply get an audio track to mux with the same stream parameters (number of channels, sample rate, profile) and use the resulting track headers.

After all, they should start making regular backups — the best insurance against data loss of any kind, including crypto ransomware.

[MrVideo]

I assumed that since this sort of modification is possible (while mantaining the contents in lossless) I could easily turn the video 90 degrees clockwise without any unnecessary reencode.
I get the feeling that you do not understand how video works. The video image that is encoded into MPEG-2, H.264 and H.265 (the common codecs that consumers basically use), "scan" from top to bottom, left to right. The aspect ratio is only a "tag" that tells the displaying device how the "pixels" are to be displayed. The decoding of the video is done top to bottom, left to right. Think of the old analog video displays. Same concept, just done with pixels.

The iPad, or any video recording device, does top to bottom, left to right, as if you were holding the recording device landscape. Hence, when you play back your portrait mode video, it looks like you shot it while laying on your side. The only way to "fix" it is to recode it and adding pillar bars on the sides. The vertical resolution is also reduced because the 1920 pixels have to be reduced to 1080 pixels. The horizontal resolution has to be reduced to 607 pixels in order to keep the 9:16 aspect ratio. That is why all these idiots (IMHO) who shoot video with their cell phones result in there being pillar bars of some sort on the left and right. Things are fine if you only view the video on your cell phone, but contribute the video to a TV station and it looks like crap (IMHO). I even harp on my daughter when she sends me vertically shot video.

Sorry, but your video is frack'd.

[mkver]

The only way to "fix" it is to recode it and adding pillar bars on the sides.
There is another way:
1. If your video is H.264, you can add a "Display Orientation SEI message" into the bitstream that contains the information that this video should be turned by 90° when viewed.
2. You can use a container that allows you to rotate the video. mp4 does so (you have to set the right "matrix"), Matroska unfortunately not.
Both these approaches have a downside: They only work on players that take this side-data into account. The second approach seems to work with ffmpeg-based players; the first seems not to do so. (I haven't seen a player that actually honours these SEI values.)

[SeeMoreDigital]

Provide an AVC encoded sample and I'll make it play back at any aspect ratio you like?!

[Mosu]

MKVToolNix v25 has been released. There's a new thread for that (http://forum.doom9.org/showthread.php?p=1846426#post1846426) as I cannot change the title (http://forum.doom9.org/showthread.php?t=175541) of this one anymore — this thread is simply too old. Please head over to the new thread. This one will be closed soonish. Thanks!