2026年7月24日、MicrosoftはLinux and Open Sourceブログで、ML Video Codecである MLVC をオープンソース化すると発表しました。コードは github.com/microsoft/mlvc にMITライセンスで公開されており、学習済みの重み、学習スクリプト、各種NPU向けの変換ツールが含まれます。
その裏付けとなる論文 MLVC: Multi-platform Learned Video Codec for Real-World Deployment は、その1か月前にarXivで公開されました。
これは研究室のGPUで一度だけ動かした研究デモではありません。MLVCはMicrosoft Researchが2021年から発表してきたDCVC系列の製品版であり、Microsoftによれば、すでにMicrosoft Teamsのピアツーピア通話で展開が進んでいます。実運用のテレメトリとA/Bテストを伴い、ハードウェアやネットワークが追いつかない場合は従来のコーデックにフォールバックします。
見出しの数字は、きちんと検証するに値するほど大きなものです。この記事が行うのはまさにそれです。数字そのもの、それが実際に測っているもの、リポジトリに本当に入っているもの、そしてこれが今年のストリーミング基盤に影響するのかどうか。
先に短い説明が欲しい方のために、ストリーミング用語集に MLVCとは何か の簡潔な定義を用意しています。
発表された数字
Microsoft自身による比較です。主観品質が同等の場合:
| 解像度 | H.264比のビットレート削減 | H.265比のビットレート削減 |
|---|---|---|
| 360p | 87.8% | 75.5% |
| 540p | 82.7% | 65.4% |
具体的に言い換えたほうが覚えやすいでしょう。H.264で1 Mbpsを要する360p・30fpsの通話が、MLVCではおよそ122 kbpsで済みます。おおむね8分の1のビット数を、リアルタイムで、ノートPCのNPU上で実現しています。
ここからが注意書きです。これがかなり重要です。
これは人間による評点であり、PSNRではない
これらの割合はMOSに基づくもので、人間の視聴者がクリップを採点したITU-T P.910の主観評価試験によるものです。素材はMicrosoftが構築して同じく公開した Video Conferencing Dataset です。つまり、ウェブカメラの前の人物を360pと540pで撮ったものを、目で見て判断した結果ということになります。
同じコーデックを、論文のより広いテストセット上でPSNRによって測ると、BD-rateの利得はむしろ52%前後に落ち着きます。それでも十分に大きな数字ですが、87.8%ではありません。
比較基準は市販で最も弱いH.265
比較対象はIntel Quick Sync上のハードウェアH.265であり、遅いプリセットで丁寧に調整したx265ではありません。会議用の低遅延に縛られたハードウェアエンコーダーは、H.265の実力の上限ではなく下限です。
さらに、論文中にはAV1やVVCとの比較がどこにもありません。著者はその理由を説明しています。VTMとECMは民生ハードウェアでの実装が存在せず、リアルタイムで比較する対象がないため除外した、というものです。研究上の判断としては妥当ですが、現代的なAV1エンコーダーと並べたMLVCを誰もまだ見せていない、ということでもあります。
本当の成果は圧縮率ではなく決定性
ビットレートの数字の陰に埋もれてしまった部分であり、技術的にはこちらのほうが面白い話です。
ニューラルコーデックは、符号化効率という点ではかなり以前から従来型コーデックを上回っていました。それでも実運用に投入できなかったのは、符号化したマシンとは別のマシンで確実に復号できなかったからです。
エントロピー符号化では、エンコーダーとデコーダーが同一の確率を計算する必要があります。同じネットワークをApple Neural EngineとQualcomm Hexagonで実行しても、浮動小数点の結果は一致しません。コンパイラが選ぶカーネルが異なり、演算子の融合の仕方が異なり、丸め方も異なるからです。その結果、ビットストリームは意味のないデータに復号されます。
論文はこれを数値で示しています。制約なしのDCVC-RTは、エンコーダーとデコーダーが同一プラットフォーム上にある場合、BD-rateで約69.6%の改善を示します。プラットフォームをまたぐと、そのBD-rateは無限大になります。要するに映像がまったく復号できない、ということの丁寧な言い方です。
どう解決したか
MLVCは、両端が偶然一致することを当てにするのをやめました。エントロピーモデルのスケールパラメータをhyperprior経由で明示的に伝送し、両端がそれぞれ計算するのではなく、同じ値をビットストリームから読み取るようにしています。
その周辺でも、チームは分岐を生むものをすべて取り除きました。特殊な活性化関数は姿を消し、ReGLUゲーティングを伴うReLUとLeakyReLUに置き換えられています。INT8量子化は完全に見送られました。INT8畳み込みはベンダー間で再現性がなく、旧世代のAppleシリコンではどのみちFP16でシミュレートされるためです。全体がFP16で動作します。
この規律は実際の圧縮性能を犠牲にします。知覚的に学習したDCVC-RTが81.9%のところ、MLVCは75.5%です。Microsoftは自社が所有しないハードウェア上で復号できるコーデックを得るために、BD-rateで約6ポイントを手放しました。
映像を実運用に乗せた経験のある人にとって、これは明らかに正しい取引であり、学習型コーデックがそれを成立させたのは今回が初めてです。
リポジトリに実際に入っているもの
直接見てみる価値があります。リポジトリは発表とは少し違う話を語っているからです。
リポジトリは2026年1月28日に作成され、その後6か月間、ライセンス、README の雛形、Microsoft標準のガバナンス関連ファイル以外は何も入っていませんでした。実際のコードが入ったのは7月22日、「Hello MLVC」というタイトルの単一コミットで、投入したのは論文の筆頭著者であるTanel Pärnamaa氏です。執筆時点でコミット数は8、スター189、フォーク10、タグ付きリリースは皆無です。
つまりこれは一括で投下されたコードであり、公開の場で開発されてきたプロジェクトではありません。批判ではなく、持つべき期待値の話です。オープンな4件のissueはすべて、transformers、jupyterlab、cryptographyに対するDependabotの更新です。これまでに取り込まれた外部からの貢献は、GCC 13以降と新しいClangでC++エントロピーコーダーをビルドできるよう #include <cstdint> をEntropyCoder.hに追加した1行の修正だけです。小さいものですが良い兆候です。Microsoft外の誰かが数日のうちにビルドを試み、Microsoftがそのパッチを取り込んだということですから。
手に入るもの
- 4つのチェックポイント。 パラメータ数1830万のフルMLVCと、540万の軽量版MLVC-Sが、それぞれPSNR最適化版と知覚最適化版で提供されます。知覚版はLPIPSと顔セグメンテーションマスクで学習されており、何のために作られたかがそのまま表れています。
- 学習パイプライン一式。 画像モデルと映像モデルの両方に対応し、YAML設定で制御します。Microsoftは学習データの収集方法も文書化しており、これは多くの公開事例より踏み込んでいます。
- エクスポートツール。 モデルをApple向けCoreML、IntelとOpenVINO向けONNX、Qualcomm向けQNNに、入力サイズ固定で変換します。対応ランタイムはCPUとGPU上のONNX Runtime、ONNX Runtime QNN、OpenVINO、Windows MLです。
- C++によるrANSエントロピーコーダー。
packages/msrtc_ransにPythonバインディング付きで収録され、BD-rate、MS-SSIM、LPIPS、VIF、DeQAを算出するベンチマークツールも含まれます。
入っていないのは、アプリケーションにリンクできるC++コーデックライブラリです。Microsoftは後続のリリースで提供するとしています。現時点で使える表面はPythonであり、インストールにはPython 3.12または3.13とuvが必要です。
フレームレートが実際に落ち着く水準
速度こそがこの話の要なので、解像度の階段が重要になります。論文に記載された符号化スループットは次のとおりです。
| 解像度 | MLVC、Apple M3 Pro | MLVC、3ベンダー平均 | MLVC-S、Apple M3 Pro |
|---|---|---|---|
| 360p | 129.5 fps | 103 fps | 未公表 |
| 540p | 65.7 fps | 49 fps | 未公表 |
| 720p | 33.8 fps | 未公表 | 83.8 fps |
| 1080p | 15.6 fps | 未公表 | 39.5 fps |
復号は全体を通して符号化より数フレーム毎秒だけ遅くなります。Intel Lunar Lakeでの1080pの値は10.5 fpsで、試験された3ベンダーはApple M3およびM4、Intel Lunar Lake、Qualcomm Snapdragon X Eliteです。
率直にまとめるとこうなります。出荷可能な水準は3ベンダーすべてでの540p・30fpsであり、NPU使用率は半分未満です。リアルタイム1080pは軽量モデルで、Appleのみ、片方向でのみ成立します。論文はさらに、1台の端末で1080p以上の符号化と復号を同時に行うことは依然として課題だと述べています。双方向通話が必要とするのは、まさにそれです。
Microsoftのロードマップもこれに沿っています。まず540pの安定化とパケット損失耐性の改善、次に1080pとより広いストリーミング用途です。
これをストリーミングのラダーに入れられない理由
ストリーミングにおいてコーデックの運命を決めるのは、圧縮効率ではありません。デコーダーです。
私たちは HEVCが約束された未来になれなかった経緯 について記事を一本書きました。原因はライセンスと端末対応であって、符号化ツールではありませんでした。AV1が実際の展開で意味を持ち始めたのも、スマートフォンがハードウェアデコーダーを搭載してからのことです。
フォーマットとは重みのこと
MLVCは、この問題のより厳しい版を抱えています。学習済みの重みそのものがフォーマットであるため、MLVCのビットストリーム標準というものが存在しません。あるストリームを復号できるのは、それを符号化したモデルとまったく同じものを保持し、演算を再現できるほど忠実に実行できる端末だけです。
適合性ストリームもなく、MIMEタイプもありません。パッケージングの話もDRMの話もなく、スマートテレビにもセットトップボックスにもブラウザにも再生できるものがありません。CDNは配信できますが、受け取る側に開けるものが何もないのです。
そのコンテンツはあなたのコンテンツではない
印象的な数字は、低解像度の静的なトーキングヘッド映像から得られたものであり、モデルは顔のROIマスクを使って顔で学習されています。スポーツ、フィルムグレイン、速いパン、動きの多い映像こそ従来型コーデックがヒューリスティクスの価値を発揮する場面ですが、論文はそこについて何も主張していません。
むしろ弱点を一つ数値化しています。長期参照の仕組みは急激なシーン切り替えでBD-rateを約2ポイント悪化させ、運用時のシーンカット検出で緩和するとされています。そして映画とは、ほとんどがシーン切り替えの連続です。
そして消費電力を誰も測っていない
これは論文自身が結びに挙げている制約です。リアルタイム性は解決した、だから次の課題は消費電力だ、と著者らは述べています。2時間の映画の全フレームでNPU上のニューラルネットワークを回すことは、バッテリー駆動の端末においては、10年かけて最適化されてきた固定機能デコーダーとはまったく別の話です。
今この技術が意味を持つ領域
両端が自分で管理するコンピューターであり、制約がシリコンではなくネットワークである領域すべてです。
まずはビデオ会議であり、だからこそTeamsが投入先になっています。ほかにも、貧弱な上り回線を使う素材伝送、リモートプロダクション、ドローン、ロボティクス、監視回線、クラウドゲーミングやリモートレンダリングが該当します。Microsoftは発表の中で、ストリーミングやVODと並べてこれらすべてについて協力を明示的に求めており、NPU対応範囲を広げる移植も歓迎するとしています。
最新ハードウェア上でリアルタイムかつピアツーピアのものを作っているなら、今すぐ半日を投じる価値があります。OTTサービスを運営しているなら、まだその時ではありません。
コーデック関係者が本当に警戒すべき点
75%という数字ではありません。傾きです。
Microsoftは、MLVCの符号化効率がモデル容量と学習計算量に応じて向上すると主張しています。ここ数年、ほかのあらゆる機械学習システムがそうであったのと同じようにです。
従来型コーデックは世代あたりおよそ30〜50%改善しますが、1世代には10年近い標準化作業が必要で、その後ハードウェアの普及を数年待ち、さらにパテントプールをめぐる論争が続きます。学習型コーデックが、計算資源を投じるたびに改善し続け、しかもすでにあらゆる機器に載っているNPUで動くのなら、この競争の形そのものが変わります。
ライセンスはMITであり、HEVCを葬ったもう一つの要因を静かに取り除いています。そして、ごく普通の技術課題に落とし込まれます。モデルのバージョンを配布し、コーデックと同じようにネゴシエーションし、相手側が実行できなければフォールバックする、というだけです。
そのどれも今年は起きません。「自分のM3で540pが動く」と「どこかの居間にある5年前のテレビで再生される」の間の隔たりは、これまでどのコーデックも越えるのに15年を要したものと同じです。とはいえ、圧縮技術が論文を読むに値するほど面白くなったのは久しぶりであり、この論文は1時間を割く価値があります。
今後どうすべきか
エンコーディングラダーは何も変える必要がありません。到達範囲のためにH.264を、端末が対応する範囲でHEVCとAV1を配信し続け、次の3つが起きたときに改めて検討してください。
- Apple上のMLVC-Sだけでなく、フルモデルでのリアルタイム1080p。
- 実際に製品へリンクできるC++ライブラリ。
- Microsoft自社製品以外のデコーダーの登場。
興味があればリポジトリをクローンしてみてください。学習パイプラインとクロスプラットフォーム分析は、ニューラルコーデックを世に出すかどうかに関わらず学ぶところがあります。INT8量子化がベンダー間で分岐する理由を扱った付録は、通常であればはるかに長い説明を要する問題を簡潔にまとめています。
よくある質問
MLVCは無料で使えますか?
はい。MicrosoftはMITライセンスで公開しており、モデルのソースコード、学習済みの重み、学習スクリプトが対象です。パテントプールは付随しておらず、これはHEVCとの大きな違いです。
MLVCをスマートテレビやブラウザに配信できますか?
できません。復号にはニューラルネットワークを実行できる端末と、そのストリームを符号化したのとまったく同じモデルが必要です。現時点でMLVCデコーダーを備えたテレビ、セットトップボックス、スマートフォン、ブラウザは存在せず、実装すべきビットストリーム標準もありません。
MLVCは実際どれだけ帯域を削減しますか?
Microsoftは360pにおいて、H.264比で87.8%、ハードウェアH.265比で75.5%のビットレート削減を、ITU-T P.910に基づく人間の視聴者の評価として示しています。より広いテストセットでPSNRによって測ると、削減率は52%前後になります。いずれもビデオ会議コンテンツにおけるハードウェアエンコーダーとの比較です。
MLVCにはどんなハードウェアが必要ですか?
NPUです。MicrosoftはM3とM4のApple Neural Engine、Intel Lunar Lake、Qualcomm Snapdragon X Eliteで検証し、いずれもNPU使用率半分未満でリアルタイム540p・30fpsを達成したとしています。
MLVCはAV1より優れていますか?
その比較は公表されていません。論文はH.264とH.265に対してのみ測定しており、AV1、VVC、ECMは民生ハードウェア実装がなくリアルタイムで比較できないため除外されています。
MLVCとDCVCの違いは何ですか?
DCVCはMicrosoft Researchが2021年から発表してきたニューラルコーデックの系列です。MLVCはその製品版であり、圧縮効率を約6ポイント犠牲にする代わりに、異なるベンダーのNPU上で確実に復号できる能力を得ています。
自社の構成にとって何を意味するか、判断にお困りですか?
コーデックの選択は間違えると高くつきます。しかもコストの大半は、ビットレートではなく、数年後の端末対応とライセンスとして現れます。ストリーミングと放送の専門人材が、コーデック、エンコーディングラダー、配信基盤を大規模に実運用してきた経験をもとに対応します。実際に直面している課題を、そのまま直接ご相談いただけます。