同じ二つの .mp4、一方はちゃんと処理できて、もう一方はインポートした途端に「非対応」と出る。最初はツールのバグに見えるが、実は「コンテナ」と「コーデック」を同じものと思っているだけだ。この二層は分かれていて、拡張子は外側の層しか言っていない。
.mp4、.mov、.webm、.mkv はコンテナ、音声と映像のトラックを入れる箱を指す。箱の中の映像データが何のコーデックで圧縮されているかは別の話だ。同じ MP4 の箱でも中身は H.264 かもしれないし、H.265 や AV1 かもしれない。WebM なら VP9 か AV1。拡張子は箱の形を言うだけで、中身がいまの環境で開けるものかは言っていない。
| コンテナ（拡張子） | 中にあり得る映像コーデック |
|---|---|
| .mp4 / .mov | H.264、H.265(HEVC)、AV1… |
| .webm | VP8、VP9、AV1 |
| .mkv | ほぼ任意の組み合わせ |
だから「処理できるか」という問いは、拡張子ではなく、中のトラックの本当のコーデック、そしていまのブラウザがそれを復号でき、望む出力コーデックを符号化できるかを問うている。ブラウザが H.264 を復号できるのはよくあるが、H.265 は限らない。H.264 を符号化できても AV1 はとは限らない。これらは互いに独立で、どれか一つでも満たさなければ、その「.mp4」はこの端末では処理できない。
ImgIng の動画圧縮では、インポート後に拡張子を信じず、コンテナ内の本当の音声・映像トラックのコーデックを直接調べる。説明もはっきりしている——MP4、MOV、WebM、MKV はコンテナに過ぎず、中身はいまのブラウザが非対応のコーデックかもしれない、と。この一手は過剰な慎重さではなく、「UI 上はインポート成功、符号化の途中で失敗」を避けるためだ。中に何が入っていて、この端末が処理できるかを先に確かめてから、処理させるかを決める。
AV1 が典型だ。圧縮率は高いが符号化コストが大きく対応も狭いので、ImgIng は実行時の能力検出が通ってから開放する。UA から「たぶん対応」と推測するのではなく、いまの環境が実際に AV1 を符号化できるか探ってから提示する。「ブラウザが対応と表示するのに実際は符号化できない」とは別世界だ。片方は UI の約束が実行で崩れ、もう片方は実行前に確認する。
ここで私の境界を。動画のコーデック自体はブラウザの WebCodecs を通り、私が作ったエンジンではない。私の層はインポート時のトラック検査と能力探索のスケジューリングだ。そこから言えるのは、「同じ MP4 で処理できたりできなかったり」に出くわしたら、ツールを疑う前に二つのファイルの本当の映像コーデックを見ること。多くは一方が H.264、もう一方が H.265 か別物で、端末は前者しか復号できない。
結論は一言。拡張子は箱、コーデックが中身、処理可否は中身と端末が一緒に決める。 ある動画があるツールで処理できるかは、.mp4 か .webm かではなく、中のトラックの本当のコーデックを見て、この端末が復号・符号化できるかを見る。もう一つ硬い条件がある。WebCodecs のローカル変換には HTTPS か localhost の安全なコンテキストが要る。これが無ければ以上のすべては成り立たない。使ったのは ImgIng（imging.ai）。