Log in

View Full Version : MKVToolNix v99.0 released


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

Mosu
10th November 2021, 16:11
Not really, no. You can probably approximate it by running your whole source file through "mkvinfo -s", taking all the video key frames & then guess from their timestamps. Problem is, as soon as you have two key frames that are within 1s from each other mkvmerge will not split before the second one as "--split 1s" means "split after a duration of at least 1s has been written". You'll also have to take frame duration into account.

All of that will not be reliable.

Selur
12th November 2021, 23:19
okay, thanks for clearing that up.

Master Yoda
13th November 2021, 15:20
Something I have been curious about and that's the delay option. Already read a number of posts, just asking this to be clear for me.

From my understading when you add a - or + delay to a subtitle the program changes the timestamps, same as if I shifted the times back or forth in subtitle edit. With audio from what I have read, a negative delay the program removes frames from the beginning. I assume it isn't re-encoding, just cutting some frames off. What about a positive delay? Change the timestamp, add blank frames to the beginning or just add a flag to tell the player to start then audio later?

With the audio, does the program do the same with all formats? ie, FLAC, Master Audio, TrueHD, AAC, etc....

Mosu
13th November 2021, 15:38
Positive delays will only be added to the timestamps. No silent (that's what you probably mean by "blank") frames will be generated; for none of the supported codecs. There will simply be no audio content at the start for a certain amount of time.

Different players deal with that differently, some well (by only playing the video at regular speed until the first audio frame is encountered), others not so much (e.g. by playing audio immediately & having the video speed up until both are synchronized again).

vanden
13th November 2021, 15:55
Hello,

I have video and I don't understand how they are muxed..
Transformers Dark of the Moon (2011) MULTi VFF 2160p 10bit 4KLight DOLBY VISION BluRay AC3 5.1 x265-QTZ.mkv

Opened in MPC I have this:
https://i.ibb.co/3kFMXmP/MPCHC1.jpg
Last frames around 2h25min59sec, the sound is perfectly synchronized with the video.

The problem is when I open it with MeGUI/AviSynth script creator (L-SMASH Works) I have this:
https://i.ibb.co/jbRnK2y/MeGUI1.jpg
Last frames 2h27min43sec.771 (224649)!

I then demux the HEVC track and the audio track with gMKVExtractGUI.exe, mux that with mkvtoolnix-gui.exe
https://i.ibb.co/TtCHYpq/g-MKVExtract-GUI.jpg
https://i.ibb.co/8DtGpXm/mkvtoolnix-gui.jpg
Opened in MPC I have this:
https://i.ibb.co/WgwtCvg/MPCHC2.jpg
The sound is shifted and the Last frame is at 2h27min43sec!

How is this hevc track muxed !! ??

tebasuna51
13th November 2021, 23:32
I have video..
Transformers Dark of the Moon (2011) MULTi VFF 2160p 10bit 4KLight DOLBY VISION BluRay AC3 5.1 x265-QTZ.mkv...
Please read the forum rules:
6) No warez, cracks, serials or illegally obtained copyrighted content! Links to content of a questionable nature (e.g. anything you don't own and/or have downloaded), asking for, offering, or asking for help/helping to process such content in any way or form is not tolerated.

We can't help you.

Mosu
14th November 2021, 11:10
Heyo!

The last couple of months have been pretty quiet regarding MKVToolNix as I'm still struggling to find time, motivation & energy for after-hour coding in general and work on MKVToolNix in particular. There are several topics on my TODO list that are rather big & require lots of work, e.g. improving Dolby Vision support further or implementing support for VVC/H.266. I'm therefore glad that some users posted a couple of bug reports & feature requests that turned out to be small enough for me to fix & implement quickly: sometimes such small wins are desperately needed.

But that's probably more than you wanted to know. Anyway, here's a new release with a couple of small improvements.

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

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

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

Version 63.0.0 "Everything" 2021-11-14
New features and enhancements

mkvmerge: AC-3 parser: E-AC-3 with BSID values > 10 and ≤ 15 are recognized now, too. Implements #3211 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3211).
mkvmerge: when using language codes for track selection (e.g. "-a und,en") all tracks that do not have a language property (due to their container not providing one, e.g. AVIs) will be treated as if they did have one set to "und" ("undetermined") as that is the language the track will have in the Matroska file anyway. Before this change it wasn't possible to match such tracks via language codes.
MKVToolNix GUI: only on Windows: when compiled with Qt ≥ 5.14 and < 6 (which is the case for the officially provided binaries) fractional screen scaling will be enabled. This means that the GUI will be scaled appropriately if Windows is set to 125%, 150% or 175% instead of being too small or too large. Implements #3043 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3043).
MKVToolNix GUI: the spinner in the bottom right corner will now be hidden when no jobs are currently running. Implements #3225 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3225).
MKVToolNix GUI: header editor: a new column has been added to the tree view showing the status of the "track enabled" flag. The information is also shown on the track overview page on the right. Implements #3228 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3228).
MKVToolNix GUI: header editor: users can now reorder tracks by dragging & dropping. Implements #3227 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3227).

Bug fixes

mkvmerge: AVI reader: fixed reading AVI files that contain "vprp" video properties header chunks; reading aborted too early. Fixes #3209 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3209).


Have fun! ☺

SeeMoreDigital
14th November 2021, 12:45
Many thanks Mosu....

The 'screen scaling' appears to be working well on my Dell laptop ;)

tebasuna51
15th November 2021, 00:41
...
mkvmerge: AC-3 parser: E-AC-3 with BSID values > 10 and ≤ 15 are recognized now, too. Implements #3211 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3211)...

Thanks Mosu.

VBB
15th November 2021, 00:57
Thank you!

Perenista
15th November 2021, 16:42
What is going on, this new MKVTOOLNIX version isn't working anymore when I click Start multiplexing. Did it broke? Clicking does nothing.

EDIT: It's fixed now. I had to restart Windows 11. Oddly it wasn't doing anything before that.

Is it here or the program looks smaller? I am using a 4K monitor@30 Hz and 175% (display scale).

SeeMoreDigital
15th November 2021, 17:35
Is it here or the program looks smaller? I am using a 4K monitor@30 Hz and 175% (display scale).
Maybe the following quote is relevant: -

Version 63.0.0 "Everything" 2021-11-14
MKVToolNix GUI: only on Windows: when compiled with Qt ≥ 5.14 and < 6 (which is the case for the officially provided binaries) fractional screen scaling will be enabled.
This means that the GUI will be scaled appropriately if Windows is set to 125%, 150% or 175% instead of being too small or too large. Implements #3043.

Mosu
15th November 2021, 17:36
Is it here or the program looks smaller? I am using a 4K monitor@30 Hz and 175% (display scale).

Yes, the new version enables Qt's support for fractional scaling. Before the update Qt would use a scaling factor of 1 for 100%/125% and 2 for 150%/175%. This is obviously rather bad as the GUI would be too small in 125% and too large for 150%/175%.

Liisachan
15th November 2021, 20:37
How to disable opening a file automatically on startup of mkvtoolnix-gui??? If you mean a popup, automatically opening and telling you about available new versions, you can disable it by the settings.

@Mosu
Thanks a lot for v63. Though that problem was only cosmetic, High-DPI is finally working fine, it seems :)

-Possible, minor usablity enhancements (if it's easy to implement):
a) GUI Muxer: When the "Edit Language" box is opened, e.g. when you hit Alt+L: (1) if you select "Free-form input" say by Alt+F, the editbox below should be auto-focused so you're ready to type whatever immediately; (2) if you select "Individually..." say by Alt+I, "Language" should be auto-focused similarly.
b) Info Tool (GUI): it would be quicker and more convenient if you can just double-click on the item in the Content list — instead of selecting it, right-clicking it, and then selecting "Show hex dump" — to get the same result (showing hex dump). Since it's only one item in the right-click menu and it's not like you can select menu items, IMHO right-clicking to get that mini-popup menu won't be necessary.
(This Info Tool is very nice and education, btw, for studying the the internal. Thanks!)

-A possible technical (not-so-practically-important) issue:
Some 3-letter lang codes accepted in v59 are no longer accepted in v60+ (including the latest version v63). For example bic, bij, blg; of which bic & bij have been deprecated and so it may be justifiable not to accept them; `blg` however is not deprecated according to https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
While such a minor lang tag is seldom if ever used anyway, there may be subtle, more generic issues behind this.


D:\Apps\mkvtoolnix59>mkvmerge -o out.mka --language 0:blg in.ogg
...
Multiplexing took 1 second.

D:\Apps\mkvtoolnix63>mkvmerge -o out.mka --language 0:blg in.ogg
...
Error: 'blg' is not a valid IETF BCP 47/RFC 5646 language tag in '--language 0:blg'.

Mosu
15th November 2021, 21:02
I'll look into implementing your two proposed changes. They both sound reasonable.

About blg: I don't generate the language list from the subtag registry as the information in it is rather incomplete. Instead I use the official sources for the 639-* codes where possible, and Wikipedia for 639-5. I don't care enough to extend this to handle codes that are only present in the subtag registry as well.

`blg` however is not deprecated according to https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

You must have misread, it is very much deprecated:

%%
Type: language
Subtag: blg
Description: Balau
Added: 2009-07-29
Deprecated: 2021-02-20
Preferred-Value: iba

Liisachan
15th November 2021, 21:27
You must have misread, it is very much deprecated:

%%
Type: language
Subtag: blg
Description: Balau
Added: 2009-07-29
Deprecated: 2021-02-20
Preferred-Value: iba

You're right. I was accidentally looking at `blq' (which is not deprecated) instead of `bld`. Everything seems cool after all. Thanks!

Mosu
15th November 2021, 21:30
BTW, after thinking some more about your info tool request I will not implement it after all. Double-clicking in a tree view is a standard action that expands or collapses the node, not just in MKVToolNix, but in a lot of GUIs in general. I don't want to have one special tree view that behaves subtly differently.

Liisachan
15th November 2021, 21:36
Okay. It was just a minor suggestion, nothing really important.

ctl-tx
16th November 2021, 06:17
I've run into a UI issue with the new version. The icons on the sidebar are now outsized and push out of their allotted space. It should be a scaling issue because I run my primary display at 200% scale. Can't see anything at 4K otherwise.
I'll note that moving the window to my secondary display (which is at 100% scale) and restarting it there doesn't resize the outsized icons.

Mosu
16th November 2021, 09:26
Yeah, others have opened an issue (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3229) for it, too. I'll look into it.

Nejiro
16th November 2021, 11:02
Heyo!

improving Dolby Vision support


Thank you so much for your work on this exceptional program ..... about the dolby vision I wanted to know if I have a uhd bluray with dolby vision track I get the single track in dolby vision as with MkeMKV or always two tracks in which the 1080 one concerns the dolby vision? Because when I have bluray uhd with dolby vision I am forced to use MakeMKV to get the track compatible with my player ..... I hope that soon everything can be done with your program that I like much more than MakeMKV.
Thanks

Mosu
16th November 2021, 11:53
At the moment mkvmerge only supports reading single-layer DV when reading from MPEG transport streams (that's what's used on Blu-rays). See the status page (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dolby-Vision-support-status) for more info.

Both dual-layer in a single track as well as dual-layer in two separate tracks are currently not supported when reading from MPEG transport streams. The former will be easier to implement in MKVToolNix and will likely be done at some point, but I cannot give you an ETA on the latter. As you're talking about "two tracks" this means you're talking about dual-layer DV in two separate tracks, the thing currently not supported and without an ETA.

You're going to have to continue using MakeMKV for such discs at the moment.

ctl-tx
16th November 2021, 14:41
Yeah, others have opened an issue (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3229) for it, too. I'll look into it.

Yes, mine looks like that too.

SeeMoreDigital
16th November 2021, 16:35
At the moment mkvmerge only supports reading single-layer DV when reading from MPEG transport streams (that's what's used on Blu-rays). See the status page (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dolby-Vision-support-status) for more info.

Both dual-layer in a single track as well as dual-layer in two separate tracks are currently not supported when reading from MPEG transport streams....Perhaps it's the term 'reading' I find confusing as I've experienced no problems dragging and dropping 2-track Dolby Vision.m2ts files (as used on 4K UHD Blu-ray discs) into mkvmerge and creating 2-track Dolby Vision.mkv muxes. Admittedly, such .mkv contained muxes can't be played correctly, but they can be muxed.

https://i.ibb.co/CPdSNvT/Capture.png

More-over, it's possible to drag and drop these 2-track Dolby Vision.mkv muxes into TSmuxer GUI and generate 'fully compliant' 2-track Dolby Vision.m2ts (AVCHD Folder-set) muxes, which play perfectly in my OPPO UDP-203 hardware media player.

Mosu
16th November 2021, 19:06
I see your point. For me as the developer it's basically the same thing as I'll have to change a lot both on the output and the input sides in order to support dual-layer in two tracks; that's why I… well… chose to mention the side that doesn't work as it would have to first, which is the input side (reading).

Nejiro
17th November 2021, 10:40
At the moment mkvmerge only supports reading single-layer DV when reading from MPEG transport streams (that's what's used on Blu-rays). See the status page (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dolby-Vision-support-status) for more info.

Both dual-layer in a single track as well as dual-layer in two separate tracks are currently not supported when reading from MPEG transport streams. The former will be easier to implement in MKVToolNix and will likely be done at some point, but I cannot give you an ETA on the latter. As you're talking about "two tracks" this means you're talking about dual-layer DV in two separate tracks, the thing currently not supported and without an ETA.

You're going to have to continue using MakeMKV for such discs at the moment.
I'll post you a mediainfo example of how they are before making the single file with MakeMKV, practically MakeMKV merges these two files and makes a single one in Dolby Vision ....
Thanks

MPEG-H HEVC Video 70360 kbps 2160p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 4:2:0 / 10 bits / 1000nits / HDR10 / BT.2020
MPEG-H HEVC Video 7538 kbps (9.68%) 1080p / 23.976 fps / 16:9 / Main 10 @ Level 5.1 @ High / 4:2:0 / 10 bits / 1000nits / Dolby Vision FEL / BT.2020

Mosu
17th November 2021, 11:21
I know what I would have to do. A couple of smaller details are still somewhat unclear (e.g. what's the semantics of the first two bytes of the UNSPEC62/63 NALUs). It's just that it's quite a huge amount of work that I'm currently not willing to tackle.

quietvoid
17th November 2021, 15:00
I'd also love to help but just don't have the time nor knowledge of the codebase to do it right, it's intimidating to me. :)

In case you want to note it down, 62 are simply prepended by 0x7C01, and 63 by 0x7E01. 63 is then followed by the regular HEVC NALUs.
I don't think there's anything else special about them.

Mosu
17th November 2021, 16:21
Are those fixed values without any further meaning? I know that what follows are regular NALUs, I just haven't found any documentation about the two prefix bytes yet (I don't have the official Dolby Vision specs).

quietvoid
17th November 2021, 17:49
Yea they are fixed.
0x7C01 is supported by the x265 documentation: https://x265.readthedocs.io/en/master/cli.html#cmdoption-dolby-vision-profile

It's also mentioned in the patent (but that's not a spec).
https://i.postimg.cc/qhT27S0M/Untitled.png (https://postimg.cc/qhT27S0M)

As for the enhancement layer NALUs, I don't think there's any spec for it though.
There's a mention in this comment: https://trac.ffmpeg.org/ticket/5688#comment:2

And a thorough explanation here: https://forum.makemkv.com/forum/viewtopic.php?style=11&p=85231&sid=d3ba6d6cc3ec73f7a5fe6a9ecb89c65c#p85231

Mosu
17th November 2021, 18:38
That's great information, thanks. Now all that remains is… the actual work ��

Megalith
18th November 2021, 00:15
...at what point did dragging .txt files into MKVToolNix's Multiplexer no longer automatically generate chapters? I just realized that all of my recent muxes are missing chapters. WTF.

EDIT: Okay, there's clearly a a bug. If you drag a bunch of files with a .txt file in it, the .txt file isn't automatically added to the chapters section. But it is if you drag it separately/individually.

Mosu
18th November 2021, 08:45
Please open an issue for it over on Gitlab. Otherwise chances are I'll forget about it again. Thanks.

von Suppé
20th November 2021, 12:42
Hi Mosu

I demuxed a mkv that holds BL+EL+RPU (like makemkv creates them). Comparing them with MediaInfo, I notice that for the source mkv it says in the video-part
"HDR format: Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible"
Where for the demuxed hevc stream it says
"HDR format: SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible"

Would the "Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU"-part be information that can't be held in the elementary stream? Of course the demuxed .hevc stream holds BL+EL+RPU.

Mosu
20th November 2021, 14:20
The elementary stream can hold that information just fine. mkvextract simply doesn't support it properly yet (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Dolby-Vision-support-status).

quietvoid
20th November 2021, 14:32
MediaInfo is only parsing the container for Dolby Vision, so that's why.
It parses the HDR10+ SEI though.

von Suppé
21st November 2021, 11:20
Thank you both. So, am I right when I say that:

1 makemkv writes the DV info in the container metadata
2 when using a DV mkv as input, mkvmerge will keep this DV info during a remux

Mosu
21st November 2021, 13:22
Thank you both. So, am I right when I say that:

1 makemkv writes the DV info in the container metadata
2 when using a DV mkv as input, mkvmerge will keep this DV info during a remux

Yes to both. mkvmerge can handle single-layer & dual-layer-in-same-track DV just fine when reading them from Matroska or MP4 files. It can also handle single-layer from other containers, including MPEG TS/elementary streams. It cannot handle dual-layer-in-different-tracks correctly (with which I mean converting them to dual-layer-in-single-track as the most compatible way to store this wrt. player support) from any of the containers.

leon
21st November 2021, 23:39
Is this a Qt bug?

https://i.imgur.com/NR1wacN.png

Mosu
22nd November 2021, 09:07
Probably?

GAP
25th November 2021, 19:00
What is good setup to convert lossless avi to lossless mkv?

VoodooFX
25th November 2021, 20:19
What is good setup to convert lossless avi to lossless mkv?
Windows 7 is good enough. Then drag & drop that avi to the MKVToolNix window and press start.

Dogway
26th November 2021, 11:59
I have been using an old mkvtoolnix version (8.2.0 from 2015) since then first due to the header compression issue, I tried again 2 years ago and found that mkvextract was demuxing out .avc elementary streams instead of .h264. What's the situation today? I tested latest version and still demuxed .avc streams which MP4Box doesn't work with nor it is an standard, or is it? Any info is welcome.

von Suppé
26th November 2021, 12:20
I tested latest version and still demuxed .avc streams which MP4Box doesn't work with nor it is an standard, or is it?Can't you solve this by changing the extension?

Dogway
26th November 2021, 12:23
Not that I remember. The thing is I don't know how the .avc format came to be since it always was .h264 or .264. I guess this has implications in the elementary stream header.

Mosu
26th November 2021, 15:19
There is no technical difference between what's in .avc/.h264/.264. It's all the same elementary stream format. There is only one elementary stream format; this is the one: a stream of NALUs following the ISO/IEC 14496-10 Annex B byte stream format (same as the ITU-T Rec. H.264 Annex B byte stream format). Furthermore, mkvextract doesn't actually decide on the file name, nor on the extension; it's totally up to the user what to name it. You could use ".chunkybacon" as an extension, it would still be the same elementary stream format.

AVC is the ISO name. H.264 is the ITU-T name. Both standard bodies cooperated on the work for the codec; they just have different names for the very same format & standard.

Snowknight26
27th November 2021, 00:13
Mosu, I uploaded a sample TS file with an MPEG-2 stream that mkvtoolnix doesn't seem to detect. MPEG2Repair shows no corrupt frames/bytes on the original (sample shows one corrupt frame due to it being split from the original at 18M bytes), though ffprobe indicates that at least one frame has an invalid frame dimension of 0x0, yet proceeds to correctly detect all streams. I haven't analyzed the container further but I imagine mkvtoolnix doesn't detect the MPEG-2 stream due to invalid parameters. Are you able to determine the reason mkvtoolnix doesn't detect it? It's not really a huge problem since I can recreate the container with ffmpeg but was curious nevertheless.

Mosu
27th November 2021, 11:26
Sorry, but I don't really want to have to deal with MPEG-2 anymore. I'm not going to look into it.

SEALBoy
1st December 2021, 00:36
Looking for some help.

I am using MKVToolnix GUI to take MKV files and remove prior embedded subtitles & unnecessary audio tracks, and embedding a single external SRT for subtitles. When I do this, it generates a new MKV file. This process can take some time since it is writing several GBs to the HDD.

Does it HAVE to duplicate the video stream into a new MKV file? Is it not possible to simply remove the embedded subtitles and audio tracks and add in the SRT subtitles I want into the existing file without rewriting it into a new file? Can this be done using the GUI?

Mosu
1st December 2021, 10:12
It does have to do it this way, yes, as all frames of all tracks are interleaved by their timestamps. This means that all frames of video, audio & subtitle tracks that should be played at timestamp X are located closely together in the file. Conversely this means that the frames of a single track (no matter its type) are distributed all over the file. Taking out those frames isn't possible, and putting others into their place (or rather: where they should be located according to their timestamps) doesn't work either.