9 : 22 MKVのフォント埋め込み

← 前 9‒21 p ｜ ↑ もくじ i ｜ 次 9‒23 n →

MKV埋め込み字幕用フォントのMIME問題

2019年10月20日
記事ID e91020

3行でまとめると…

字幕を作らない・使わない人には関係ない。現在進行中のことで（2019年10月に話題になり対応されつつある事柄）、記事としてまとめられる段階ではないため、前半では、速報メモをそのままアーカイブ。後半では技術的な事柄について簡単にメモ。

速報メモ

問題に気づいたのは2019年9月末。仲間内で検討したり Matroska の開発者に質問したりして、10月初めに暫定的な「推奨」が決まった。「正解」のない難しいジレンマ。

第1報（2019-10-07）
[INFO] MKVにフォントを添付する場合: 新たに生じている問題点と対応（速報）

要約: TTFフォントを添付する場合、メディア型（いわゆるMIME）が font/ になるケースがある。これは2017年に定義されたウェブ標準のメディア型だが、多くのプレーヤーはまだこの型を認識できず、添付フォントがロードされないという不具合（字幕スタイルが壊れる）が生じる。

推奨: 当面、フォントを添付する場合、レガシーのメディア型を明示的に指定。コマンドラインの場合、TTF なら --attachment-mime-type application/x-truetype-font、OTF なら --attachment-mime-type application/vnd.ms-opentype （※注）。GUI の場合、mux前に、そうなっていることを確認する。

（※注） OTF の場合、TTF と同じメディア型 application/x-truetype-font でもロードされるらしい。

補足: (1) 非公式の新しい MPC-HC (clsid2 builds) なら、一定条件下で新しいメディア型の添付フォントもロードされるが、公式の MPC-HC や MPC-BE や古い LAV に依存するプレーヤーでは、現在、字幕が壊れる。次のバージョンから新しいメディア型がサポートされる見通し。 (2) MKVToolNix は、現在、TTF に関してはデフォルトで application/x-truetype-font を使うように設計されていて、本来、明示的に指定する必要はないのだが、一部の環境では、2018年ごろから、意図通りにならないことがある。過渡期の混乱が生じているため、フォントを添付した場合、念のため、システムからそのフォントをアンインストールした状態で添付フォントがロードされるかテストした方がいい。万全を期すなら、フォントがキャッシュされている可能性を考慮し、再起動後にテスト。 (3) 添付ファイルの MIME は、MPC系なら [Shift]+[F10] の Resources タブでも確認できる。 (4) フォントのメディア型の標準化とその背景については、RFC 8081 参照。「どちらでも同じ」なら標準化された新しい型を使うべきだが、現在、プレーヤー側のサポートが追いついていないので、当面は古い MIME を使い続けるのが現実的。自分たちだけでなく Matroska の開発者も同意見。

第2報（2019-10-10）
[INFO] MKVの添付フォント「新仕様」対応状況

***

MPC-BE＝対応完了（世界初！）: 1.5.4.4799 において、font/ttf と font/otf と font/sfnt がサポートされた。コード更新は 2019-10-07、バイナリー公開は 2019-10-08。残りの2タイプについてサポート追加をリクエスト（2019-10-09）。同日1.5.4.4808 において、font/collection と application/font-sfnt も認識されるようになった。2019-10-10 08:30 UTC 現在バイナリー待ち。公開されたら動作確認する。〔追記: 同日午後バイナリー公開、テスト結果＝OK〕

LAV Filters＝TTC以外対応完了: 0.74.1-26 において、font/ttf と font/otf と font/sfnt と application/font-sfnt が認識されるようになった（font/collection は認識されない）。コード更新 2019-10-07、バイナリー公開 2019-10-09。font/collection のサポート追加についてはリクエスト済み。〔追記: 2019-10-14 TTCにも対応。2019-10-15 v0.74.1-28 バイナリー公開、テスト結果＝OK〕

***

MPC-HC（clsid2 build）: 新しい LAV Filters を取り込めば、自動的に同じ更新が反映される。現時点での最新版バイナリー（1.8.8.234）は、上記の LAV の更新より前にビルドされていて、font/ttf などを明示的にサポートしていない。「MPC-HC（非公式）では既に font/ttf などが認識される」と速報に記したが、拡張子が小文字の .ttf などである必要があり、それが .TTF に変わるだけで認識されなくなる…という危ういもの。順当にいけば、次の 1.8.9 では全部ちゃんと認識されるようになる。

アクティブに開発が続いているプレーヤーなら、1～2カ月以内に、新標準に対応可能になるだろう。良いことだが、そうなると、今度は作成ツール側で「フォントを添付するとき、新標準の font/ メディア型を使おうかな…」となるのは必然。この変更を急ぎ過ぎると「新規作成した MKV が古いプレーヤーでは意図通りに再生されない」という混乱を招く。状況の背景・詳細については後日あらためて解説するが、今回の協調更新の趣旨は「新仕様のファイルが来ても再生できるように、先回りして準備」。「旧仕様の添付フォントのサポートをやめる」ということではない。「動画作成側がコマンドラインから明示的に新仕様を使う」または「作成ツールの添付フォント処理のデフォルトが変わる」のどちらかが起きない限り、当面、エンドユーザーには何の影響も生じない。

何らかの理由で古いプレーヤーを使い続けた場合、今から数年以内に「それまでは問題なかった字幕のフォントスタイルが正しく表示されないケース」が起こり得る。特殊な文字だと、最悪、表示が□や？や空白になってしまうかもしれない。そうした問題が起きたときには、あわてず、内部の Matroskaスプリッターをオフにして、外部の LAV を試してみよう。そうすれば、元祖 Gabest バージョンの MPC（約10年前）でさえ、新仕様の添付フォントを利用できる！

第3報（2019-10-12）
[INFO] MKV「新仕様」の背景

「壊れてないのに直すな！」という格言がある。フォント埋め込みMKVは、2004年に実験的に実装され、次第にサポートが充実、今ではクロスプラットフォーム（再生側のOSに依存しない形）での相互運用が当たり前。それがなぜ突然「仕様変更」なのか。古いプレーヤーが新しいMKVに対応できなくなり、未来のプレーヤーが古いMKVに対応できなくなるかもしれないのに…。

問題が生じた背景は、次の通り。

  1. MKV/MKA には、任意のファイルを添付可能（カバーアート、歌詞テキスト、字幕用フォント…）。この柔軟な仕様は、メールの添付ファイルやウェブサーバーのレスポンスヘッダと同様の仕組みで実現されている。鍵となるのは、ファイルのフォーマットを表す識別子（MIME Type）。text/css とか image/png といった識別子を見たことある方は多いだろう。MIME Type は、文脈によっては Media Type とも呼ばれる（以下「メディア型」）。
  2. 従来、フォントを表すメディア型は、公式には存在しなかった。必要なかった。日常的に不特定多数の間で、いろいろな形式のフォント・ファイルを送受信することはなかったので。フォント配布サイトでは ZIPなどで圧縮して配布するのが一般的だし、TTFなどを生でダウンロードさせるにしても、送受信の双方がどういうファイルをやりとりしているか認識しているので、バイナリー・ファイル一般を表す application/octet-stream などで一応間に合っていた。
  3. 2013～17年ごろ CSS3 @font-face が標準化され、状況は急変。ブラウザにバックグランドでフォントをダウンロードさせ、特定フォントを使ってウェブページを表示させることが一般化した。ダウンロードさせるフォーマットも ttf/eot/woff などバラバラ。ブラウザから見ると「漠然と application/octet-stream と言われ、ダウンロードしてみたら未対応の形式だった」となれば時間の無駄だし、ページの表示も遅れ、帯域も浪費され、エンドユーザーから見ても迷惑。従って、フォーマットごとにフォントのメディア型を標準化する必要が生じ、多少の混乱もあったが、2017年には font/ttf や font/woff などの新しい型が公式に定義された。
  4. Matroska ではファイルのメディア型を使うので、型の標準が変わると、新旧2パターンのファイルが作成され得る。国際的に登録されている型が突然変わることはまずないが、フォントの場合、もともと公式な型がなかった→公式な型を新規定義という経緯から、予期せぬ問題が生じた。

「公式な型がなかったのなら、今までMKVの添付フォントはどうなってたの。どうやって再生互換性が維持されてたの？」という疑問が生じるでしょうが、メディア型の仕様には「x- で始まるサブタイプは、プライベートで自由に使えるよ」という規定があって、
application/x-truetype-font
というプライベート型が、MKV に TTF を埋め込むときの事実標準となっていた（初期の実装において Haali/Gabest が採用した型）。でも Matroska は、誰でも自由に使えるオープンなフォーマット。仕様書で「ファイルのMIME型を指定する」と明記されている。新たにMKVを作るとき「今の公式な型は font/ttf だから、それを使おう」と考える人が出てきても、それを止められない。

結果として、もしプレーヤーが新旧両方のメディア型に対応していないと、未対応型フォントの字幕がデザイン通りに表示されず、困ったことになる。「フォントが違うだけで文字は読める」のなら実用上OKかもしれないが、場合によっては、字幕をオンにしても文字が表示されない。バグ報告・問い合わせが殺到し、多くの人の時間とエネルギーが浪費され、最悪、作成済みのMKVを全部作り直す羽目になる！　大混乱が生じる前に、先手を打って対応しておきたい。

2種類のテスト用ファイルが doom9 の MKVToolNix スレの 2019-10-07/08 にあるので（※1）、MPC系/LAV利用/mpv以外で未対応のプレーヤーを発見したら（ZoomPlayerなどはLAV利用）、そのプレーヤーの開発者に対して、サポート追加を丁重にお願いしてほしい。新形式ファイルの登場による問題で、プレーヤー内部の不具合ではないので、バグ報告ではなく、新形式対応のリクエストという形で。「新形式といっても FileMimeType の文字列が違うだけで中身は同じ」という点を伝えてください。疑問点・問題点・コメントがあれば、上記スレや各プレーヤーのスレに書くと吉。動画作成者は、当面（少なくともプレーヤー側の対応が整うまで）古いメディア型を使い続けるのが無難（速報の「推奨」参照）。趣味で字幕やカラオケを作ってる友達がいたら、このことを教えてあげてください。

※1　テスト内容は、画面上部の文字（ハードサブ）と同じフォントで下の文字（ソフトサブ）を表示できるか。一つ目のサンプルの Test1～4 に合格すれば、そのプレーヤーは実用上ほぼOK。二つ目のサンプルの Test5 に合格すれば TTC 対応もOK。Test8 は「メディア型を本当にサポートしているか、拡張子に基づくその場しのぎのサポートか」を判別するもの。Test6/7 はWOFFサポートを試すものだが、WOFF埋め込みMKVは現在実際には使われていないので、6/7 の結果はどうでもいい（これに通るプレーヤーがあれば神）。

第4報（2019-10-15）
[INFO] MKV「新仕様」対応ほぼ完了

MPC-BE, LAV とも新標準対応のバイナリー（テスト版）が出そろった。内部的に LAV を使う MPC-HC の更新も時間の問題。どのバージョン以降で対応したかは「第2報」参照。MPC-HC (clsid2) の次の正式版リリースは2019年12月以降か（10月3日に 1.8.8 が出たばかりなので。MPC-HC は開発が止まっていて、clsid も積極的な機能追加などはしていない）。

2019-10-16　現在のリリース版において、問題が条件付きで回避されるのは、LAVFilters のうち、2019-03-16 の v0.74 以降（※）。リリースノートに Fixed: Fonts embedded in MKVs without a proper mimetype were not being imported とある（※※）。MPC-HC では、2019-03-17 の v1.8.5 以降に当たる。

（※） ソース変更は 2019-03-15。報告 #261 への対応だった。報告者が提供したサンプルで使われているのは新メディア型ではないが、問題の本質は同じ。レガシーの事実標準と異なる application/octet-stream が使われていて、それにプレーヤーが対応できなかった。

（※※） 何が proper mimetype なのか明確でないことが、問題の核心。

この回避は、拡張子チェックによるものだが、大文字・小文字を区別してしまったため「.ttf なら良くても .TTF では駄目」といった制約あり。さらに .ttc にも対応できない。メディア型の本当のサポートは、2019-10-15 の v0.74.1-28 以降（「第2報」参照）。MPC-HC に関しては対応待ち。

2019-10-18　MPC-BE 1.5.4 (build 4850) beta が正式公開された。MKVの字幕の「新仕様」に対応した。「新仕様」はRFCレベルではメディア型の新しい国際標準だが、旧仕様も依然有効。MKV においては、現時点ではむしろ旧仕様が推奨される。新仕様への移行のタイミングの目安として、MKVToolNix の作者は「2020年末くらいか、もう少し後」とコメントしている。「あと1年半くらいは旧仕様で。その後も互換性重視のユーザーは旧仕様を使い続けてもいい」という感じ。

略語の説明
MPC
メディア・プレーヤー・クラシック。Windows 初期のような古いメディアプレーヤーのインターフェースをあえて使い、中身を超絶的に進化させた Gabest の名作。Matroska が生まれる2003年より前からあり、ほとんど全てのフォーマットに対応していた。しかも Gabest は現在の字幕の事実標準 ASS（アドバンスト・サブ・ステーション）を考え出した。その実装は実験的で、美しくないハックや非効率な面もあったが、ASSに関しては新形式を作り出した神（効率などは後の開発者によって次第に改善された）。
MPC-HC
ホーム・シネマ。開発が止まった MPC を継続・発展させたもの。自前の DirectShow フィルターを実装するのではなく、LAVフィルターを利用している。名前は「ホームシネマ」だが、PCで普通に使えるメディアプレーヤー。公式には開発終了。非公式にメンテが続いているので、まだ現役。
MPC-BE
ブラック・エディション。MPC-HC と似ているが、別の道を歩む。Gabest 流に自前の内部フィルターを使う。今もアクティブに開発が続いている。
LAV
一応「ライブラリー・オーディオ・ビデオ」の略。ffmpeg の「libav」等を DirectShow フィルター化したもの。
MKV/MKA
マトロスカ（マトリョーシカ）ビデオとオーディオ。AVI や MP4 と同様、多目的メディア・コンテナの一種（WebM としてウェブ標準にもなっている）。伝統的に字幕を強力サポート。今でこそ「ハードサブよりソフトサブ」が常識だが、そうなるまでは、長いいばらの道だった（フォント埋め込みも、その1ステップ）。多くの人の努力の積み重ねにより、この環境が作られた。もちろんソフトサブには弱点もある。

実装上の注意点

背景
登録されている型
プライベート型・レガシー型
備考
歴史覚え書き

[1] ASS では、インラインSVGのようにして、\p を使ってグリフ（特定のフォントの文字）を描画できるが、この低水準アプローチは、一般論として実用的なものではなかった。

2021年追記　MKVToolnix仕様変更へ

2021-06-15　【動画作成注意報】MKVToolnix 58 添付フォント型に不具合　更新するなら慎重に

2021年6月13日にリリースされた MKVToolnix v58.0.0 の GUI では、フォント・アタッチメントのMIME型の自動認識が変更された。背景については「MKV埋め込み字幕用フォントのMIME問題」を参照。

注意点:

1. 今回の変更によって、古めのプレーヤーはフォントを正しくロードできなくなり、字幕表示が乱れる。おおむね2019年10月以前のバージョンが影響を受ける（MPC-BE 1.5.4以前、MPC-HC 1.8.8以前、LAV Filters 0.74.1以前）。不特定多数の人（古めのプレーヤーを使っているかもしれない）にファイルを公開する場合、要注意。

2. 技術的問題。標準準拠のための変更なのに、MKVToolnix v58 がデフォで使う MIME-type は標準準拠になっていない。#3137 として開発者にフィードバック済み。

暫定的推奨:

状況がクリアになるまで v58以降への更新をせず、しばらく様子見が吉。

MKVToolnix v58 の GUI を使うと、非標準なファイルが作成され、禍根を残す可能性がある。どうしても58 の GUI を使いたい人は、Preferences | GUI | General Options のUse legacy MIME types for font attachments にチェックを入れると、後方互換になる。状況を把握できていて、自分でコントロールできるなら、更新しても問題ない。

MIMEタイプが標準準拠になること自体は、原則的には良いこと。けれど MKVToolNix 58 は、標準準拠にしたつもりで中途半端になってしまっている。これを開発者が「magicライブラリの仕様」と主張するのか、それとも、標準仕様とずれていることを認めて修正するのか…。

追記: 開発者もこれが不具合であることを認めた。修正されるまで、バージョン57以前を使い続けることをお勧めする。

短期的には、標準準拠に実用上のメリットは何もなく、リスクだけがある（互換性が失われて一部のプレーヤーで字幕が正しく表示されない）。かなりの人々が、当面、明示的にレガシー（後方互換）を使い続けるのではないか。コマンドラインから使えば、MIMEタイプは好きに設定できるし、GUIからでも上述の「レガシーモード」のオプションがある。けれど手動設定が必要。一般ユーザーがデフォのまま操作すると、変なファイルが作成されてしまう可能性がある。一般ユーザー視点では、v57 以前を使い続けるのが、手っ取り早い。

2021-06-18　MKVToolnix（続報）　libｍagic から乗り換えへ

libmagic がフォントのMIME型をおかしくするのは、MKVToolnix史上、少なくとも3度目。最初はまだ font/ が公式に定義されていない時期。独自に font/ を使い、互換性問題が生じた。2回目は2019年ごろ。Mac上で MKV を作ったら、application/font-sfnt というマニアックな型（技術的には間違いではない）を書き込まれ、再び互換性問題。この時点で libmagic に疑いが生じたが、MKVToolnix の作者は「このライブラリは事実標準」と擁護。そして今回（2021年）。主要プレーヤーが標準準拠して1年半たったから、準備そろそろOK？とレガシー対応を廃止したとたん、また libmagic が TTF を font/sfnt という変な型にしつつ（技術的には間違いではない）、OTF をレガシーにするというちぐはぐな挙動。さらに TTC が font/ttf というのは、訳が分からない。

libmagic の返すフォント型がミッション・クリティカルになる場面がほとんどないので、報告されず、放置されているのだろう。字幕制作者は過去のいきさつに懲りて、--attachment-mime-type を明示的に書くようになっているため、MKV でも問題が表面化しにくい。

MKVToolnix の作者もとうとう「これはおかしい」と考え、libｍagic 自体を使わないように変更した。実用上、とりあえず賢明な選択かもしれない。けれど、変更の思わぬ副作用として、フォントとは別の添付ファイル（カバーアートなど）で、分かりにくい互換性問題が生じてくる可能性がある。しばらく添付ファイルのMIME型をよく確認した方がいい。

さいわい主要な動画プレーヤーは、font/sfnt のようなレアな型にも対応しているし、「MIMEを認識できない場合は拡張子をチェックする」という安全策を施した実装もある。自動更新で何も考えずに MKVToolnix 58 にしてしまっても、再生サイドの実害は限定的だろう。

ただ MPC-HC の最後の公式バージョン（clsid2 が引き継ぐ前）を使い続けているユーザーは、内蔵フィルター使用の場合、今後、埋め込みフォントがロードされないケースが増えてくるかもしれない。

2021-07-10　MKVToolnix 59: 依然フォント型が挙動不審　バージョンアップは慎重に

バージョン58では、デフォのMIMEを標準準拠に変更しようとしたものの、結果がおかしかった。最新のバージョン59ではライブラリを一新、標準準拠の対応は改善されたが、今度は、後方互換モードに不具合が生じた模様。具体的に、レガシーの挙動を指示しても、TTCのMIME型がレガシーにならない。

どちらのモードでも、状況によって、一部プレーヤーで字幕の表示がおかしくなる。

コマンドラインからなら型を明示的に指定できるものの、GUIユーザーは、引き続きバージョンアップを控え、バージョン56.1以前を使うのが無難。

当然いつかは標準準拠に移行するべきだが、現時点では、移行しても実際上のメリットがほとんどなく、確実にデメリットがある。「公式」の古いMPC-HCが標準MIMEに対応していない（よってテキスト表示が乱れる）。「非公式」のclsid2版なら大丈夫だが、MPC-BEが sourceforge にあることなどから、意外とMPC-HCもそっちからダウンロードしてしまう人が多いのでは…。

この記事のURL

パブリックドメイン

← 前 9‒21 p ｜ ↑ もくじ i ｜ 次 9‒23 n →
<メールアドレス>
▲
［妖精現実 フェアリアル］ Home h > Articles z > §9 i > 9‒22