WebM を MKV に変換

Matroska は 2002 年に公開された、ほとんど何でも格納できるコンテナで、Google が 2010 年に公開した WebM は、そのコンテナをロイヤリティフリーのコーデックに絞り込んだ制限版です。WebM ファイルをバイナリエディターで開くと、先頭の 4 バイトは Matroska の署名そのものです。

この近さが「WebM から MKV への変換は単なるリネームだ」という説明を生みますが、ファイル構造の話としてはほぼ正しくても、実際にプレーヤーで再生できるかという話としては的を外しています。うまくいかない原因は、たいていコンテナではないからです。

映像は H.264 に、音声は AAC に再符号化されます。入力が何であっても同じです。すべてのフレームが一度画素に戻され、あらためて圧縮されるため、MP4 への変換と同じだけの時間がかかり、同じだけ細部を失います。無料で済むのはコンテナの部分だけです。

これは意図した選択であって、コンテナの制約ではありません。MKV は VP9 も AV1 も FLAC も問題なく保持できます。それでも H.264 で書き出すのは、MKV への変換を求める人がたいていブラウザーではなくメディアプレーヤーへ渡そうとしているからで、WebM でつまずくプレーヤーは、MKV に入った VP9 でも同じようにつまずきます。

「WebM を MKV に」という言葉が本来意味しそうな、圧縮されたストリームをそのまま別のコンテナに移すだけの操作は、実在します。フレームには一切触れず、数秒で終わり、まったく劣化しません。

それはこの変換ではありません。MKVToolNix の mkvmerge や ffmpeg -i input.webm -c copy output.mkv がそれにあたります。あるソフトが VP9 の中身には文句を言わず拡張子だけ .mkv であることを求めているなら、そちらのほうが短時間で終わり、余計な処理時間を使わずに済みます。

Plex や Jellyfin、Emby は、再生ボタンが押されるたびに、ファイルをそのまま渡すか、その場でトランスコードするかを選びます。ダイレクトプレイは無料で瞬時に始まりますが、トランスコードはサーバーの処理能力を継続的に使い、非力な NAS ではそれがカクつきの原因になります。

H.264 と AAC の組み合わせは、ほとんどのクライアントがハードウェアで復号できます。VP9 の WebM をあらかじめ変換しておけば、その負荷を恒久的にサーバーから取り除けます。ライブラリー全体を変換する場面でこそ、バッチ処理とアップロード不要という仕組みの意味が出てきます。

Matroska が評価されているのは、複数の音声トラック、複数の字幕トラック、チャプター、添付ファイルを一つに収められる点です。

この変換ではそのどれも運ばれません。映像トラック一つと音声トラック一つだけが渡されます。字幕を後から一緒にしたいなら、MKVToolNix で既存の MKV にトラックを追加するのが確実で、再符号化を伴わないため数秒で終わります。

MKV への対応は熱心な層の外では薄くなりがちです。ブラウザーでネイティブに再生できるものはなく、スマートテレビのアプリの多くや古いセットトップボックス、Apple のエコシステムは概して受け付けないか、扱いが不安定です。

ここで作られるファイルの中身は H.264 と AAC でどちらのコンテナでも同じなので、コンテナの選択は自由に決められます。何かが特にMKVを求めている場合を除いて、MP4 のほうが安全な既定の選択になります。

解像度の設定は、画面録画のような変則的なサイズの素材で特に役立ちます。メディアサーバーやテレビアプリは標準的な段階を好み、1080p がライブラリーとして扱いやすい大きさです。

画質の設定はもう一つの調整項目です。一度見て終わるものならバランス設定で十分ですが、保管しておくコレクションに入れるなら、すでに二世代目の圧縮であることを踏まえて、高画質を選ぶ価値があります。

ライブラリーは一本ずつ処理するものではありません。最大 100 個の WebM をまとめてドロップすれば、それぞれが個別に進行し、できあがった MKV は ZIP にまとまって戻ってきます。共有サーバーを介さないため、誰かの処理待ちになることもありません。

アップロードがないという点が、これを実用的にしている理由です。百本の録画は数十ギガバイトになり、送信して受け取るだけでも符号化そのものより時間がかかり、無料サービスの一日あたりの上限にも簡単に達してしまいます。