MKVToolNix v99.0 released

[Inviska]

In general: when you want to include someone else's work in your own package or when you have any question about the licensing of a specific piece of software, you should really contact the authors themselves, in MKVToolNix' case: me. My email address is readily available. Posting on a forum, not waiting for a response and just going ahead without understanding the licensing implications is not the polite thing to do.

Sorry about that. A bug was reported with PureHD tracks and I was enthusiastic to release the new version with a fix, but I should have waited for your reply or emailed you. Sorry.

I've uploaded a new version of the AppImage with MKVToolNix removed.

Thanks a lot for the information about my obligations under the GPLv2 licence. For now I won't bundle MKVToolNix and will see how things progress. If Snaps and FlatPaks start to take off more I might have to include it, in which case I'll follow your instructions so it's done properly.

Again, sorry for uploading the other version without waiting for your response.

[Mosu]

No problem; I'm not mad or something :)

[ripster]

I am putting together a new PC build that will also be used for working with mkvtoolnix. Is there a benefit to using an Intel processor with more cores/threads in that machine with regard to processing times with mkvtoolnix?

I would get a k-processor with at least 4 cores anyhow but there is also the option to go up to 6 or 8 cores and the question whether it makes much of a difference to go for a processor with hyperthreading - seems that hyperthreading increases temperature substantially and due to that it limits maximum stable overclock.

[mkver]

mkvmerge is single-threaded and usually not CPU-bound, so hyperthreading doesn't really matter. The only thing against AMD that I can think of are recent bugs that resulted in crashes, but they seem to have been fixed already and when you buy a new one, you should already get the fix (see here (https://gitlab.com/mbunkus/mkvtoolnix/issues/2589)).

[ripster]

Thanks, what do you mean by not CPU-bound? I take it that single core speed should still play a role but I could use either an AMD or Intel platform?

[mkver]

It is usually bound by the speed of your HDD/SSD and RAM. After all, a lot of the stuff mkvmerge does is "copy data from here to there".

[stax76]

Does mkvextract support long paths on Win 10? First test showed it doesn't, might as well be an issue in staxrip though.

[Selur]

I had written some code which could detect the stretching that worked with some old mkvinfo version, but since I used it last a bunch of stuff must have changed with the output of mkvinfo, so that code doesn't work any more.
So before I start to try to figure out what that code really indented to do and how it would need to be adjusted I wonder:

Is there an 'easy' way to detect whether an mkv contains a, by mkvtoolnix, strechted stream and by how much the stream was stretched (so that one can take the stretch into account when remuxing/reencoding such a file into another container)?

Cu Selur

[sneaker_ger]

There is no one field you can just read. For video tracks you could look into the bitstream (e.g. AVC or HEVC time_scale and num_units_in_ticks). For audio tracks you could see whether the frames overlap or have gaps i.e. if [number of frames]*[duration of one single frame] matches the duration in the container. If you are lucky maybe by reading the DefaultDuration and comparing it to the frame size (if frame sizes for the given codec are constant, and if DefaultDuration is set in the first place). Without track statistic tags this potentially involves a lot of parsing. For subtitles it may be impossible (maybe one can find a pattern in the roundings?).

Are you sure your app was able to do such things?

[Selur]

There is no one field you can just read.
a bunch of fields would have been nice too ;)

Are you sure your app was able to do such things?
Yup, but what it does/did is:
a. get the mkvinfo output
b. for each stream (only audio&video) collect it's raw length and the length in the container
c. compare raw and container size

Cu Selur

[sneaker_ger]

But mkvinfo does not provide "raw length"?

[Selur]

At least not that I'm aware of, from what I know you have to calculate it yourself by parsing the blocks. :)
I hoped there might be some additional (and 'new') data somewhere providing the info, since parsing the whole output is a pain for large files with xy streams. ;)

Cu Selur

[Selur]

For video stream detecting the stretch is easy you could compare the 'Codec's private data: size' and the 'Default duration' for the stream. My guess is this is how MediaInfo reports container vs. stream fps.
Sadly for audio streams (even if the frame size should be constant), you only sometimes have a 'Default duration' info and I haven't seen any 'Codec's private data: size' so far. :/
-> @Mosu: would it be possible to simply keep a single entry per stream which shows how much a streams duration was stretched in case this happens? Or is there some easy way to calculate stretch value?

[sneaker_ger]

A codec's private data doesn't change when stretched.

[Liisachan]

Hi! I'd appreciate any input from anyone.

Currently, when attached via GUI on Windows, a TTF file seems to get --attachment-mime-type application/x-truetype-font by default (*), an OTF gets --attachment-mime-type application/vnd.ms-opentype. On the other hand, RFC 8081 in Feb 2017 (https://tools.ietf.org/html/rfc8081) defined the official Media Types for them, font/ttf and font/otf, respectively, and there is also font/sfnt. My friend who muxes on Mac actually gets "application/font-sfnt" then "font/sfnt" by default for TTF, saying mkvmerge (on Mac) probably updated how it does things. Hence this ongoing debate among our group:
Opinion 1: We should now use the standardized media types (e.g. font/ttf), instead of non-standard wild types such as "application/x-font-ttf".
Opinion 2: We shouldn't. That will confuse many players, and the fonts won't be loaded/used properly.

In the long run, maybe we should start using "font/ttf" sooner or later, but if there is some kind of guideline that says that for maximum interoperability/compatibility one SHOULD keep using "application/x-truetype-font" for TTF in Matroska, perhaps that makes sense too.

@Mosu Do you (or Matroska devs) have any specs/opinions/plans about this matter?

(*) Very early versions of mkvmerge may have used "application/octet-stream", if I check old MKV files muxed in 2003-2004.

[filler56789]

Hi! I'd appreciate any input from anyone.

Currently, when attached via GUI on Windows, a TTF file seems to get --attachment-mime-type application/x-truetype-font by default (*), an OTF gets --attachment-mime-type application/vnd.ms-opentype. On the other hand, RFC 8081 in Feb 2007 (https://tools.ietf.org/html/rfc8081) defined the official Media Types for them, font/ttf and font/otf, respectively, and there is also font/sfnt.

Ouch! :eek:
Fonts never ever should have been defined as "application/something", to begin with. That suxxx as badly as configuring a web server to define a video file as "application/x-oleobject"
~woman facepalming emoji~

In the long run, maybe we should start using "font/ttf" sooner or later

In the long run, SURELY we should start using "font/ttf" sooner or later. The idiocies from the not-very-smart past should be terminated as soon as possible.

[Jamaika]

From my point of view, I don't care what type we use. I was more interested in the possibility of adding ttf to subtitle and then playing. Under the condition that the recipient likes to watch with subtitles. If the ttf size was over 4MB, the movie didn't play on my computer. So what are we discussing?

[Liisachan]

Thanks for the comments.

Ouch! :eek:
Fonts never ever should have been defined as "application/something", to begin with.

Well, Matroska was born around 2003; the official Media Type "application/font-sfnt" was only defined in 2013 (and became obsolete in 2017 when "font/ttf" was defined), thus there was no "correct" choice in the first place between 2003-2013, except maybe generic "application/octet-stream" if anything. It's not like someone did something not-very-smart. Simply there was no "correct" answer at all.

@Jamaika You can use font subsetting so that only the glyphs used in your script will be supported. Say, you have a CJK font (4 MiB) supporting 40,000 glyphs, but you actually use 2,000 glyphs, then your compacted font will be like 0.2 MiB, which you can attach to your MKV instead of the huge original font file.

If we use "font/ttf" now, potentially many existing players won't load the attached TTF files. One example of such players is the last official version of MPC-HC from 2017, perhaps still used by a few people. We geeks can just use a newer (unofficial) MPC-HC for example, but that's something like using ECMAScript 2017 in an webpage simply because "our" nightly builds support it, ignoring normal users with regular browsers who want to enjoy the same page (but will experience problems).

[Jamaika]

Thanks for the comments.
@Jamaika You can use font subsetting so that only the glyphs used in your script will be supported. Say, you have a CJK font (4 MiB) supporting 40,000 glyphs, but you actually use 2,000 glyphs, then your compacted font will be like 0.2 MiB, which you can attach to your MKV instead of the huge original font file.

I don't know how to do it. I haven't seen users do this. There was to be a new version of libass v5.0 with new font tab options. Nothing that I know of. I think the topic has died and it's certainly not Matroska's problem. Anyway, the problem of enabling new features is associated with potential piracy than improving the video world.

About ttf: I read convert everything to otf. There are converters. How many votes so many ideas.

[filler56789]

Well, Matroska was born around 2003; the official Media Type "application/font-sfnt" was only defined in 2013 (and became obsolete in 2017 when "font/ttf" was defined), thus there was no "correct" choice in the first place between 2003-2013, except maybe generic "application/octet-stream" if anything. It's not like someone did something not-very-smart. Simply there was no "correct" options at all.

Well, I didn't say and I didn't mean that the Matroska developers are the ones to blame in this case. I stopped playing around with Web "development" (read: programming) ages ago, when nearly-nobody used font-embedding in HTML pages... and I was too ignorant and lazy to perceive that the "application/something" mime types were not a very-logical thing.

And yes, someone did something that was not-smart-at-all. Namely, the ones who decided that "application/sth" should be the umbrella label for anything that they were too lazy to classify properly... For example, they should have chosen archive/zip, archive/rar, document/pdf, document/msword, document/msexcel, mmedia/mp4, etc, instead of application/zip, application/rar, application/pdf and so on.

[Liisachan]

Let me clarify the context of my original question:

1. A media player that supports softsubbed MKV won't load the attached font files if it doesn't recognize them as fonts. Then styled subs will be broken (shown with some system default fonts), unless the attached fonts are already installed. This is bad!
2. Many programs (splitter, demuxer, etc.) seem to recognize an attached file as a font by checking its MIME type. So, in principle, you want to use an attachment-mime-type that makes every tool happy. But if "application/x-truetype-font" is going to be obsolete soon, we may want to discard backward compatibility.

Thus the original question: what should I type after --attachment-mime-type when attaching a TTF: "font/sfnt" as seen on Mac, "font/ttf" as in RFC, or actually "application/x-truetype-font" after all?

@Jamaika Subsetting is supported by Windows OS itself (https://docs.microsoft.com/en-us/windows/win32/api/fontsub/nf-fontsub-createfontpackage). It's widely used when embedding fonts in general, and there is no license problem unless subsetting is forbidden in fsType in the 'OS/2' table of that font. Since this is off-topic, you can start a new thread and/or PM me if interested.

@filler56789 To use new top-level types ("archive", "document", etc.), you MUST (https://tools.ietf.org/html/rfc6838#section-4.2.7) first define them via RFC, which would be probably time-consuming. But I see your point - e.g. "application/vnd.ms-opentype" looks a bit ugly (why ms- when it's supposed to be an open standard).

[arrgh]

hi
after some significant time, I wanted to check what the timeline might be for the muxing of MVC mkv-files...
here was the last reference to this...:
https://forum.doom9.org/showpost.php?p=1832794&postcount=5078

as can be seen here 3D is still of interest to many people, as also the tsmuxer open source project shows:
https://forum.doom9.org/showthread.php?p=1879321#post1879321

for a Fantasy / SciFi enthusiast 3D is still a topic, even when some people frown on it as on Micro-Plastic...:)

[Mosu]

Thus the original question: what should I type after --attachment-mime-type when attaching a TTF: "font/sfnt" as seen on Mac, "font/ttf" as in RFC, or actually "application/x-truetype-font" after all?

mkvmerge doesn't detect MIME types itself. It uses the widely used "libmagic" from the "file" project. Waaaay back when "libmagic" used to return "application/…" for fonts. Then one day they switched to "font/…". That was sometime in 2011, and it didn't go down well with users (see bug 682 (https://gitlab.com/mbunkus/mkvtoolnix/issues/682)[1]) as their programs weren't ready for "font/…". Therefore I implemented a workaround in mkvmerge in v5.2.0 which manually mapped "font/…" back to "application/…".

However, that was quite a long time ago. I don't think there's a definitive answer at the moment, though, as I'm not aware of any research/comparison of application wrt. them supporting "font/…". We would all benefit from a comprehensive test of all known implementations that support fonts in Matroska; try using both MIME types and create a mapping which implementation support which MIME type.

My gut feeling would be that there are still implementations out there that don't support "font/…", but I don't have any evidence for it.

Edit: Depending on the result I would definitely change MKVToolNix' default back to "font/…"; maybe make it configurable in the GUI for those who'd need backwards compatibility.

[1] Even though GitLab shows that the bug was "opened 4 years ago", that's only the date when I migrated the bug tracker to GitHub (!); the original dates couldn't be kept during that migration. The original bug was filed in 2011.

[Mosu]

Looks like it's time for MKVToolNix v38, which continues the bug-fixing tradition of previous releases.

There's one minor change wrt. packaging: Boost's Operators header library is now required.

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 38.0.0 "The Silent Type" 2019-10-06

New features and enhancements


mkvextract: chapters, tags & cue sheets will now be written to standard output if no file name is given, same as if "-" is given as the file name.
MKVToolNix GUI: job queue: added a new setting in the preferences' "job queue & job status" section that, when enabled, will cause the GUI to remove all output files created by jobs that are either aborted by the user or that end in an error. Implements #2614 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2614).

Bug fixes


all programs: macOS: fixed file access if the file name (including all path components) contains any Unicode character where NFC (Normalization Form Canonical Composed) and NFD (Normalization Form Canonical Decomposed) differ, e.g. German Umlauts. Fixes #2620 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2620).
mkvmerge: when splitting by chapters the user can now split by chapters coming from one of the appended files, too. Fixes #2625 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2625).
mkvmerge: AAC reader: fixed reading codec parameters (channels, sample rate) if a file starts with garbage that includes valid-but-bogus AAC headers. Fixes #2622 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2622).
MKVToolNix GUI: Hebrew was added to the list of often-used languages so that it can be selected by default again. Fixes #2610 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2610).
MKVToolNix GUI: when updating the GUI's settings from v37.0.0 or older, the GUI checks if the list of often-used languages equals the built-in list from v36.0.0. If it does, it will be updated to the built-in list changed in v37.0.0. Fixes #2611 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2611).

Build system changes


Boost's Operators header library is now required.



Have fun :)

[Liisachan]

Mosu: thank you very much for your detailed answer/clarification!
We would all benefit from a comprehensive test of all known implementations that support fonts in Matroska; try using both MIME types and create a mapping which implementation support which MIME type.

Not a comprehensive test, but a few key facts: Do players support an embedded TTF with the FileMimeType "font/" on Windows?

The latest version of MPC-BE (v1.5.3 @ 2019-04-01): NO
The latest (final) official version of MPC-HC (v1.7.13): NO
The latest unofficial version of MPC-HC (clsid2 builds): YES
zoomplayer: NO (according to my friend)

Those players marked NO do support an embedded TTF with the FileMimeType "application/x-truetype-font". So your gut feeling seems correct (e.g. MPC-BE from April 2019 does not support "font/"). I'd say it's still too early to migrate to "font/".

As a side note, it seems that when you mux a file on Mac, "font/sfnt" is used by default for TTF and "application/vnd.ms-opentype" for OTF; which is less than ideal even if one prefers "font/". RFC says, Use of "font/sfnt" is likely to be rare in practice. I.e. if you do use "font/", "font/ttf" should be used for TTF, not "font/sfnt"; and "font/otf" should be used for OTF, not "application/vnd.ms-opentype".

[Aleksoid1978]

Mosu: thank you very much for your detailed answer/clarification!


Not a comprehensive test, but a few key facts: Do players support an embedded TTF with the FileMimeType "font/" on Windows?

The latest version of MPC-BE (v1.5.3 @ 2019-04-01): NO
The latest (final) official version of MPC-HC (v1.7.13): NO
The latest unofficial version of MPC-HC (clsid2 builds): YES
zoomplayer: NO (according to my friend)

Those players marked NO do support an embedded TTF with the FileMimeType "application/x-truetype-font". So your gut feeling seems correct (e.g. MPC-BE from April 2019 does not support "font/"). I'd say it's still too early to migrate to "font/".

As a side note, it seems that when you mux a file on Mac, "font/sfnt" is used by default for TTF and "application/vnd.ms-opentype" for OTF; which is less than ideal even if one prefers "font/". RFC says, Use of "font/sfnt" is likely to be rare in practice. I.e. if you do use "font/", "font/ttf" should be used for TTF, not "font/sfnt"; and "font/otf" should be used for OTF, not "application/vnd.ms-opentype".

Upload short samples with "font/" mime type - i check and add support in MPC-BE.

[nevcairiel]

Not a comprehensive test, but a few key facts: Do players support an embedded TTF with the FileMimeType "font/" on Windows?

The latest version of MPC-BE (v1.5.3 @ 2019-04-01): NO
The latest (final) official version of MPC-HC (v1.7.13): NO
The latest unofficial version of MPC-HC (clsid2 builds): YES
zoomplayer: NO (according to my friend)


To be fair, MPC-HC does not actually support these mimetypes, it just has a fallback to look at the file extension of the attachment if its an unrecognized mimetype, and then accept .ttf and .otf files.
I have, however, added support just now for future versions. Software like ZoomPlayer that also uses LAV Filters should automatically inherit this support once its updated accordingly.

[Mosu]

Thanks!

Not a comprehensive test, but a few key facts: Do players support an embedded TTF with the FileMimeType "font/" on Windows?

The latest version of MPC-BE (v1.5.3 @ 2019-04-01): NO
The latest (final) official version of MPC-HC (v1.7.13): NO
The latest unofficial version of MPC-HC (clsid2 builds): YES
zoomplayer: NO (according to my friend)

Yikes, that's bad — but not entirely unexpected. This is the usual situation in which there is a solution that is "good enough" and where nothing much will change without a lot of (outside) pressure. In this case such pressure might be all applications creating Matroska files only using "font/…". However, that won't fly with users who'll rightfully complain that their newly created files don't work as expected.

Catch 22, once more.

Great to hear that both Aleksoid1978 and nevcairiel will add support for "font/…".

[Liisachan]

Upload short samples with "font/" mime type - i check and add support in MPC-BE.

fonts_embedded.mkv (http://faireal.net/image/public_domain/fonts_embedded.mkv) (268 KiB, 10 sec), testing four different FileMimeType values:
Test1 font/ttf
Test2 font/sfnt
Test3 application/font-sfnt
Test4 font/otf

Ideally, something like this is shown:
http://faireal.net/image/public_domain/fonts_embedded.jpg
Above = hardsubbed
Below = softsubbed <-- check this
(PNG (http://faireal.net/image/public_domain/fonts_embedded.png))

[Aleksoid1978]

fonts_embedded.mkv (http://faireal.net/image/public_domain/fonts_embedded.mkv) (268 KiB, 10 sec), testing four different FileMimeType values:
Test1 font/ttf
Test2 font/sfnt
Test3 application/font-sfnt
Test4 font/otf

Ideally, something like this is shown:
http://faireal.net/image/public_domain/fonts_embedded.jpg
Above = hardsubbed
Below = softsubbed <-- check this
(PNG (http://faireal.net/image/public_domain/fonts_embedded.png))

:)
It is interesting - who and why come up with different names for the same types.
What diff font/sfnt & application/font-sfnt ??

P.S. Do you have spec for new font/ mime types ?

[Liisachan]

:)
It is interesting - who and why come up with different names for the same types.
What diff font/sfnt & application/font-sfnt ??

P.S. Do you have spec for new font/ mime types ?

to the best of my knowledge:
font/ttf & font/otf = the current standard Media Type (https://www.iana.org/assignments/media-types/media-types.xhtml)s for TTF & OTF respectively, defined in 2017 as RFC 8081 (https://tools.ietf.org/html/rfc8081), assigned and listed (https://www.iana.org/assignments/media-types/media-types.xhtml#font) by the IANA
font/sfnt (https://tools.ietf.org/html/rfc8081#section-4.4.1) = abstract type that includes both font/ttf and font/otf
application/font-sfnt (https://www.iana.org/assignments/media-types/application/font-sfnt) = ex-standard (2013-2017), still valid (https://www.iana.org/assignments/media-types/media-types.xhtml#application) as a deprecated alias of font/sfnt

[qyot27]

fonts_embedded.mkv (http://faireal.net/image/public_domain/fonts_embedded.mkv) (268 KiB, 10 sec), testing four different FileMimeType values:
Test1 font/ttf
Test2 font/sfnt
Test3 application/font-sfnt
Test4 font/otf

Ideally, something like this is shown:
http://faireal.net/image/public_domain/fonts_embedded.jpg
Above = hardsubbed
Below = softsubbed <-- check this
(PNG (http://faireal.net/image/public_domain/fonts_embedded.png))

mpv passes all four tests, and it even warns the user about the old MIME type:
[sub/ass] Loading font attachment 'homework smart.TTF' with MIME type application/font-sfnt. Assuming this is a broken Matroska file, which was muxed without setting a correct font MIME type.

[Liisachan]

Since Mosu suggested a comprehensive test about "font/", I'm posting another test clip: fonts_embedded2.mkv (http://faireal.net/image/public_domain/fonts_embedded2.mkv) (329 KiB, 10 sec)
This one is like the first sample, except the three other subtypes will be tested:
Test5 = TTC attached as "font/collection" <-- mkvtoolnix-gui uses "application/x-truetype-font"
Test6 = WOFF attached as "font/woff"
Test7 = WOFF2 attached as "font/woff2"
Test8 = TTF files with extension .xtf are attached with 3 different FileMimeType values (mkvtoolnix-gui uses "application/x-truetype-font").
Test5 is practically important for a few users (esp. in CJK where TTC fonts are common). Test6/7 are only for completeness, not practical atm. Test8 is something different.

The letters in the upper area are hardsubbed. Ideally, softsubs in the lower area should look similar to the hardsubs, like this:
http://faireal.net/image/public_domain/fonts_embedded2.jpg (http://faireal.net/image/public_domain/fonts_embedded2.png)

mkvmerge doesn't detect MIME types itself. It uses the widely used "libmagic" from the "file" project. Waaaay back when "libmagic" used to return "application/…" for fonts. Then one day they switched to "font/…". That was sometime in 2011, and it didn't go down well with users (see bug 682 (https://gitlab.com/mbunkus/mkvtoolnix/issues/682)[1]) as their programs weren't ready for "font/…". Therefore I implemented a workaround in mkvmerge in v5.2.0 which manually mapped "font/…" back to "application/…".

As RFC 8081 pointed out, media types such as "font/ttf" had been non-existent until they were defined in 2017. If someone had started using it in 2011 in a widely used library, what they did was rather questionable, given that technically no one is allowed to use an arbitrary top-level media type, while anyone is allwed to use a subtype x-something privately. Besides, not "font/" but "application/font-sfnt" became the official media type for TTF/OTF in 2013.
It's only after 2017 that one may officially use "font/" when attaching a font file. So I think that this is a relatively new problem, not directly related to what you did in 2011. As for what you did in 2011, it was a correct move imho - refusing then-illegal media types in favor of legal (though unregisterable) x- subtypes.

@qyot27
While mpv seems to be a fantastic player, that warning message is a bit strange. Does it show a similar warning about "application/x-truetype-font"? As a fact, "application/font-sfnt" was the only standard Media Type for TTF/OTF before 2017 and it's still officially valid, so one could argue it's more correct than "application/x-truetype-font". Was mpv from 2016 happy about "application/font-sfnt" while unhappy about "font/ttf"? If so, in a way I'd respect such a rigorous player, though maybe it'd be more elegant to handle older files transparently, esp. when the file in question is technically not broken.

[qyot27]

@qyot27
While mpv seems to be a fantastic player, that warning message is a bit strange. Does it show a similar warning about "application/x-truetype-font"? As a fact, "application/font-sfnt" was the only standard Media Type for TTF/OTF before 2017 and it's still officially valid, so one could argue it's more correct than "application/x-truetype-font". Was mpv from 2016 happy about "application/font-sfnt" while unhappy about "font/ttf"? If so, in a way I'd respect such a rigorous player, though maybe it'd be more elegant to handle older files transparently, esp. when the file in question is technically not broken.

The relevant commit in mpv is f3d2f4c6c2a (from 2017-12-12), which added the font/ top level type to follow RFC8081. The list of font mimetypes it accepts in the subtitle demuxer is (currently, sub/sd_ass.c @ lines 85-92):
"application/x-truetype-font",
"application/vnd.ms-opentype",
"application/x-font-ttf",
"application/x-font", // probably incorrect
"font/collection",
"font/otf",
"font/sfnt",
"font/ttf",
And if it doesn't see the font as one of those, it throws that warning shown before. I'm not sure why it doesn't have "application/font-sfnt" in the list, as there's no indication that it was removed, but because mpv detects fonts based on file extension as well (sub/sd_ass.c @ line 96), Test 3 in the original file worked despite the warning, but the application/font-sfnt .xtf in Test 8 did not. The file extension detection may have simply masked the issue, so there was never any reason to explicitly include application/font-sfnt...maybe?

[Liisachan]

LAV Filters now explicitly support the 3 important now-standard Media Types and 1 standard alias (related code changes (https://git.1f0.de/gitweb?p=ffmpeg.git;a=commitdiff;h=8066ee422778255341277dd50d83ceb5b1f6a4b2)); the binary (https://files.1f0.de/lavf/nightly/) (v0.74.1-26) was tested with MPC and a few MPC-based players (by disabling their internal source filter for Matroska), 100% passing Tests 1-4 and 8 (one-upping mpv in Test 8 ;)). In the LAV Filters thread, I requested the addition of the "font/collection" support.

In retrospect, it would have been convenient if the Matroska specs had, under each AttachedFile, something like "AttachmentType", the value of which could have been 0 (default: unspecified), 1 (cover art), 2 (back cover art), 3 (embedded font), etc. Then, players could simply load everything as font iff AttachmentType=3, and it could reliably show the cover art in MKA even if a lot of images are attached.

[Mosu]

Thank you very much for all the investigative work, Liisachan!

[MrVideo]

I found a minor grammatical error in mkvmerge, as seen in the MKVToolnix GUI error output listing:
However, no headers where found for that track number.
The word "where" describes a physical location. The correct word is: were

[Liisachan]

@qyot27
Perhaps it simply shows that application/font-sfnt (https://www.iana.org/assignments/media-types/application/font-sfnt) was unsuccessful (*). Failure to support it is not a big problem as this type is so rarely used, and it's indirectly supported anyway if the extension is .ttf or .otf (I think). It's impressive that mpv's FileMimeType support was near perfect already 2 years ago.

@Mosu
Real thanks should go to Aleksoid1978 and Nevcairiel :) If ToolNix suddenly starts using the new font types, there may be a lot of confusion. I suggest there be a transitional period, like until the end of 2020 (or whenever you see fit); mkvmerge can output some kind of notices. E.g. if font/ttf is used too early, it could say, "this is a standard type name, but old players may not recognize it", and if application/x-truetype-font is used too late, it could say "you might want to use the newly standardized type names".

(*) meaning, the media type application/font-sfnt, though officially registered, was never commonly used. Most developers, servers, clients, end-users didn't start using it — perhaps they didn't/don't even know it exists — to the point that the same media type had to be re-defined using a more intuitive name, font/sfnt. CSS3 @font-face was still a Working Draft when application/font-woff & application/font-sfnt were registered in early 2013; maybe only a few, experimental and standard-aware parties (like Firefox devs?) were interested in them back then. One may remember that MSIE hadn't recognized application/xhtml+xml for many years even after XHTML 1.1 was standardized.

EDIT:
Now MPC-BE (r4808+) fully supports the 5 mime types: font/sfnt, /ttf, /otf, /collection & application/font-sfnt, passing Tests 1–5 & 8 100%. LAV is also already near-perfect (except font/collection), passing Tests 1–4 & 8 100%.

EDIT2 (2019-10-14):
Now LAV Filters fully support the 5 mime types!!

[saracas]

I cannot for the life of me figure out how to batch edit 300 MKVs using the same steps... I go into MKVtoolnix and copy the command line after setting one up one episode and I get this:

"C:/Program Files/MKVToolNix\mkvmerge.exe" --ui-language en --output ^"W:\SHOWNAME\Season 01\Show.Name.S01E01.DVD ^(1^).mkv^" --audio-tracks 1 --language 0:eng --track-name ^"0:MPEG-2 / 480p / 23.976 fps^" --language 1:jpn --track-name ^"1:Japanese / AC-3 / 2.0 / 448 kbps^" --default-track 1:yes --language 2:eng --track-name 2:English --default-track 2:yes --forced-track 2:yes ^"^(^" ^"W:\SHOWNAME\Season 01\Show.Name.S01E01.DVD.mkv^" ^"^)^" --track-order 0:0,0:1,0:2

How do I make the two directories in there specify all files in those folders? Basically all I am doing is removing english track and setting first subtitle track to forced for all these files.

[Liisachan]

you can try something like this example
test.bat
---
FOR %%f IN (*.mkv) DO (mkvmerge -o "new\%%f" --no-attachments "%%f")
---

EDIT (FIX)
I forgot to quote the last %%f, which doesn't work if a file name has a space, "%%f" should work in such a case too. The example above will transmux every MKV file in the current folder and write new files in the sub-folder "new". --no-attachments is just an example, where attachments will be dropped in newly created MKVs. One can replace this part with what they actually want to do.

[Liisachan]

[GUI] Error status from the previous session persists until explicitly acknowledged, even when no errors occur in the current session. Maybe by design, but could be confusing as follows:

Tested: MKVToolNix v38 on Win7 32-bit

Steps to repro:
1. Start mkvtoolnix-gui.exe, select a source file (e.g. some.avi)
2. Rename "some.avi" to "renamed.avi" behind the back of the GUI
3. On GUI: Start muxing -> the status bar shows [X] 1 error (as the source file is not found)
4. Just close mkvtoolnix-gui, restart it later -> Still [X] 1 error is shown
5. Select "renamed.avi" and mux it into "renamed.mkv" -> Now successful. but...

Expected result:
In most tools (especially command line ones), even if an error occurred in the previous session and an error message was shown, that error will be automatically forgotten if one restarts the tool and do something new. If old errors are remembered, the corresponding old error messages should be shown too, to explain what errors it is talking about.

What happened instead:
GUI still shows [X] 1 error. Job Output inconsistently says "No errors yet".

[Mosu]

In most tools (especially command line ones), even if an error occurred in the previous session and an error message was shown, that error will be automatically forgotten if one restarts the tool and do something new. If old errors are remembered, the corresponding old error messages should be shown too, to explain what errors it is talking about.

And that is the case for MKVToolNix, too. What you failed to realize is that the status bar indicators refer to the jobs known to MKVToolNix, not to what the "job output" tool shows. As soon as that job containing the error is removed, the status bar indicator will go back to 0 errors. In the same spirit, you can right-click on the job & select "View output". A new tab will be opened in the "job output" tool, and that tab will include the error.

On top of all that, the always-visible tab in the "job output" tool is labeled "current job". Of course there aren't any errors in it when you've just opened the GUI as there hasn't been a "current job" yet.

[Mosu]

I found a minor grammatical error in mkvmerge, as seen in the MKVToolnix GUI error output listing:

Thanks, I'll fix it.

[Mosu]

I suggest there be a transitional period, like until the end of 2020 (or whenever you see fit); mkvmerge can output some kind of notices. E.g. if font/ttf is used too early, it could say, "this is a standard type name, but old players may not recognize it", and if application/x-truetype-font is used too late, it could say "you might want to use the newly standardized type names".

I'm hesitant to add a real warning for such things as it would punish those who use the new types on purpose (punish in the sense that none of their jobs using the new font types would be succeeding anymore, and they'd always have to check if it was only due to the font warning or to something actually important). This means I'd have to make the warning configurable, and that's always a lot of work. A note would be fine, of course. Then again, a simple note would probably never be read by most GUI users.

End of 2020 sounds reasonable; maybe even a bit longer.

[stax76]

This means I'd have to make the warning configurable, and that's always a lot of work.

For the GUI aspect there are some ways to reduce the work, run time generated GUI is some work but easier to deal with than older UI toolkits (never worked with QT), generic GUI based on a grid is easier, most effective is just a INI conf file, I've used it this week for my new MediaInfo GUI and it was totally easy to do.

https://postimg.cc/TLkPDKsX

[Mosu]

The problem isn't adding yet another checkbox to the Qt UI. It's the amount of things to do for each such configurable thing:

Add checkbox in preferences dialog (trivial, it's one line in the corresponding .ui file)
Determine keyboard shortcut that isn't used by any other visible control for English & German
Save that setting in the configuration
Add a corresponding command line option to mkvmerge
Add help output for the new command line option
Add documentation in mkvmerge's man page
Implement both the warning as well as having it turned off in mkvmerge
Implement test cases for all three cases (other MIME type, bad MIME type with warning at defaults, bad MIME type with warning turned off)
Update the program & man page translations
Translate all the new content into German
Add a NEWS entry

Nothing about this is hard. It's just tedious & takes time. Nothing about what you've said would reduce the amount of work I'd have to do.

[Liisachan]

@Mosu
My point is, if MKVToolNix started using "font/" suddenly, there could be a lot of confusion. If you have a plan to migrate to the new types, I suggest you advertise in advance that there will be compatibility-breaking changes, so that subbers can make informed decisions. Warning from mkvmerge (CUI, not GUI) is one of the possible things you could do, but if it's not easy, that's fine. There are other things we could do, such as simply posting a short explanation in subtitle-related forums or making a user-friendly font-attachment FAQ page.

Maybe some subbers don't want to migrate to the new types. Technically, RFCs explicitly guarantee that one can freely use private x-tokens such as application/x-truetype-font as long as both parties (in this case muxer and player) agree on it. As such, it will be perfectly fine and standard-compliant (perhaps even recommended) to keep using x- MIME types privately inside Matroska (note: SSA/ASS itself is a private format, not officially standardized). In fact, when font-embedding was first implemented by Haali (as a patch to Gabest's splitter), it was announced in doom9 (https://forum.doom9.org/showthread.php?threadid=72086) that one MUST use application/x-truetype-font.
On the other hand, since Matroska is an open-spec format, where FileMimeType is defined as the MIME type, one may (and perhaps now should) use the registered MIME types. The catch is, doing so will generate MKVs that older players don't understand. In the worst case, subtitles will be unreadable at all. Sometimes the problem will be only stylistic (wrong font faces), though I imagine young typesetters will be upset when that happens (old typesetters know that font-embedding is optional to begin with, e.g. disabled by default in Haali Splitter until like 2007).

Yet another concern is, unless clearly documented (ideally as a footnote to FileMimeType in the official specs on Matroska.org), some of the legacy types might be forgotten quickly and new-generation players in the future won't play old MKVs right. There are actually as many as 10 different MIME Types that may be used for attached fonts. Implementers generally don't know this undocumented, confusing situation. For example, LAV Filters were fixed in v0.74 saying "Fonts embedded in MKVs without a proper mimetype were not being imported" - where it is assumed that the legacy types are the proper mime types. As another example, application/font-sfnt is registered but was/is poorly supported (even by mpv).
End users (including myself) are even more clueless. I only noticed this problem recently, though the top-level type "font" was registered in 2017. Imho, it could be helpful if mkvmerge warns when "problematic" MIME types are specified. But like you said, some of the "problematic" types are actually "good" (officially registered) ones, and there is no fool-safe solution to this dilemma. That said, there are a few end-users who happened to use new types such as application/font-sfnt simply because their tool chains had been updated that way, even though they wouldn't have used such poorly-supported types if warned about them.

I'd say, a warning like "font/ttf may cause problems. This is not an error. It's fine if you know what you're doing" wouldn't be "punishment". Seeing that, 1% of the users would be cool, like "yeah, I know why this warning is shown. This is a difficult problem and I see mkvmerge is trying to be helpful" and 99% of the users would be like "did I do something wrong? I'll have to check about this" - both would be good. In the second case, ideally they will do some search and will be like "I now understand the problem. I tested several players. I'll use font/ttf" - or they'll be like "I now understand the problem. I'll keep using x-types". Both options sound fine to me. Let them make an informed decision about their own files :)

As for the error status of GUI, it's ok if it's by design. I just wanted to point out that it could be confusing when one uses GUI as a one-time front end, and not as a batch-job front end.

~~PS~~
About the status bar message on GUI, I'd think two minor text changes might be helpful.
1) In the main manu: "Job queue" -> "Job queue/log"
2) In the context menu: "Show job queue" -> "Show job queue/log"

Unfamiliar with this GUI, one may assume the queue is empty in the example I described above (the same status bar says "Jobs to execute = 0, 0, 0", certainly looking like the queue is empty). This may be just me, but intuitively, one has no reason to look into the "Job queue" when an error is reported. But if the context menu item says "Show job queue/log" when "error(s)" is right-clicked, it'll be immediately clear where to look.

[mood]

In the last continuous build 38.0.0-revision-028, how can I disable the dark theme?? the new GUI is mess up, I'm using windows 7 x86

with same configuration settings, the dark theme GUI size change turn it a mess up


38.0.0-revision-028

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

38.0.0-revision-019

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

[kuchikirukia]

Sort of an odd request, but when setting mkvtoolnix to split by chapters, would it be possible to have a period as a valid separator along with the comma? Since I use the numpad to enter chapter numbers, it would make it far easier to enter 2.3.5.6 than reach all the way over for the comma. (I generally sit at an angle to my desk with the keyboard almost out of reach when I don't have it in my lap for typing, and just making a stab for the comma will usually end up with me hitting "m" or ".")

Any of /*-+ would also work. i.e. 2+3+5+6

[filler56789]

I agree with mood, the "dark theme" thing suxxx.
At least there should be an option to turn it off.