リアルタイム会議に関するこちらの最新のブログでは、ビデオに関するインサイトをご紹介していきます。
最新のコーデックを使用したビデオのリアルタイム圧縮について特に言えることですが、中央処理装置（CPU）のコストが深刻な制約となる場合があります。 高解像度、高フレームレートのビデオを CPU 上のソフトウェアで圧縮するのはかなり高性能なコンピュータであっても難しく、一般にモバイルアプリケーションでは対応できません。 このようなコーデックは通常、GPU を搭載しているシステムで実行できます。ただし、最も一般的なのは、シリコンに直接組み込まれているサポートを使用してエンコード処理とデコード処理を行うという方式です。その場合、比較的低出力のモバイルデバイスでも、30fps 以上の高解像度（HD）ビデオのデコードとエンコードが可能です。 つまり、新たなビデオコーデックが普及するかどうかは多くの場合、主要なシリコンベンダーがオンチップでサポートしているかで決まります。
圧縮
圧縮前のビデオは膨大な帯域幅を必要とします。以前ブログで紹介したとおり、1080p30 のビデオストリーム 1 本のビットレートは 1.5 ギガビットにもなります。 このように、ビデオの配信には非常に高レベルでの圧縮が必要です。
画像圧縮、特に非可逆圧縮を使用すると、品質をほとんど損なうことなく 10：1 で圧縮できますが、帯域幅を 15 分の 1 に減らしても、1080p のストリームには 100Mbps が必要となります。 最新のビデオ圧縮では実際のところ、許容できる品質のレベルを維持しながら、1080p30 ストリームを 4Mbps まで圧縮できます。圧縮率は実に 375：1 です。
なぜこのようなことが実現できるかというと、圧縮されたビデオは実際には、圧縮された静止画の連続ではないからです。 リアルタイムで圧縮されたビデオは 2 種類のフレームで構成されています。1 つは I フレーム（Intra-coded frames）で、個別にデコードできる圧縮画像ですが、通常はビデオストリーム内のフレームのごく一部にすぎません。 I フレームはキーフレームとも呼ばれます。
もう 1 つは P フレーム（Predicted frames）です。画像をエンコードするのではなく、現在のフレームとその前のフレームとの変更部分のみを保持します。 現在とその前のフレームとの差分をエンコードするため、差分フレームとも呼ばれます。 ほとんどの場合、2 つのビデオフレームの差分はわずかで、通常は 33 ミリ秒しか違いません。このため、P フレームは実際の画像をエンコードする場合よりもはるかに小さくなります。
このように、ビデオ圧縮は非常に効率的です。 この方法の欠点は、前のフレーム情報に依存しているせいで、パケット損失が発生してフレームをデコードできなくなった場合、それ以降のフレームもすべて影響を受けてしまうことです。 通常これを解決するには、新しい I フレームのリクエストを送信側に送り返す必要があります。 その間にデコーダは、最新の有効なフレームでビデオを停止するか、欠落しているフレームの内容を推測して続行を試みることができますが、これにより奇妙な視覚的な歪みが生じる可能性があります。
コーデック
ハードウェアでのサポートが重要であること、また競争力のあるビデオコーデックの開発には、オーディオコーデックの開発より高いレベルのエンジニアリングの取り組みが必要なことが、ほぼすべてのユースケースで 10 年以上もの間、あるビデオコーデックが独占的であった理由です。そのコーデックが H.264 です。 H.264 は 2004 年に規格化され、幅広いハードウェアでサポートされており、リアルタイム会議などあらゆるビデオユースケースで広く使用されています。
ビデオ会議システムがサポートするコーデックは H.264 だけではありません。 以下で紹介するように、他にも少なくない数のコーデックがリアルタイム会議システムでサポートされています。
H.261、H.263、H.263+ は古いビデオコーデックです。ビットレートが一定の場合、H.264 よりも CPU コストは低いものの、ビデオの品質が低くなります。非常に古いシステムでは、相互運用性のためにこれらを 1 つ以上サポートすることが必要な場合があります。 古いシグナリングプロトコルである H.323 をサポートまたは相互動作するように設計されているシステムでは H.261 のサポートが義務付けられているため、規格に準拠するために H.261 の実装が必要な場合があります。
VP8 と VP9 は、（現在は）Google 社が主導する代替プロトコルです。パテントフリーの設計になっていますが、これが裁判で通用するかについては議論があります。 VP8 は H.264 に代わる競争力のあるプロトコルとして設計されましたが、動作点に関しては柔軟性がかなり劣ります。 VP9 は H.264 よりも優れた設計ですが、H.265 や AV1 ほど高度ではありません。 パテントフリーのビデオコーデックは魅力的です。しかしハードウェアでサポートされておらず、また Google 社以外でパテントフリーのコーデックを支持している主要テクノロジー企業によるサポートは、ブラウザ以外の分野では限られています。ブラウザでは Google Chrome の優位性もあり、一般的に利用されています。
H.265 は、H.264 の後継として設計されましたが、2013 年に規格化されたにもかかわらず、その後の 10 年間でその普及は H.264 よりもはるかに遅れています。 これは技術的な問題ではなく、主に法的または財政的な問題です。H.265 のライセンススケジュールは H.264 よりもはるかに強気で高額です。多くのユースケースでは桁違いの費用がかかり、企業は自社製品のダウンロードごとにライセンス料を支払う余裕がありません。 H.264 と比べ特許の状況がはるかに複雑なので、一部の企業は、H.265 の使用には法的リスクもあると考えています。H.264 には、基本的にすべての特許保有者が属する単一のパテントプールがあるのに対し、H.265 には 3 つの独立したパテントプールがあり、そのいずれにも参加していないベンダーも存在します。 とはいえ、ある程度のオンチップ ハードウェア サポートを備えているので、特定のユースケースには適している場合があります。
最新のコーデックで最も将来有望なのは AV1 です。 H.265 と同様の圧縮率と CPU コストですが、VP9 と同じくパテントフリーの設計になっています。 ただし AV1 は、VP9 と比べ業界全体ではるかに広範な支持を受けて開発が行われました。つまり、より高いレベルで賛同を得ており、著作権使用料無料についても大きく信頼されています。 2018 年に規格化されたばかりなので AV1 の導入はまだ限定的ですが、オンチップ ハードウェア サポートをはじめとしてサポートは拡大しており、最終的に H.264 に取って代わる候補として最も可能性が高いと考えられます。
オーディオの基本を確認
以前の Rob のブログでオーディオの基本を説明し、オーディオコーデックの上位 6 つを比較しているのでご覧ください。
H.264
ビデオをエンコードする際、ほとんどのコーデックでは、フレームをマクロブロック（個々にほぼ独立している処理単位）に分割します。 詳細はここでは説明しませんが、コーデックによってマクロブロックをさらに細分化し、特定の変換や予測を行うこともできます。
マクロブロックと解像度
H.264 のマクロブロックは 16 × 16 の正方形で、256 ピクセルのブロックです（ただし一部の内部操作では、マクロブロックがもっと小さくなったり、細分化されたりすることもあります）。 フレームの境界はマクロブロックの境界で終わる必要があるため、H.264 でエンコードされたビデオのピクセルの幅と高さは 16 の倍数でなければなりません。
マクロブロックは、H.264 では非常に基本的なものです。サポートされる解像度をネゴシエートする際、最大フレームサイズ（max-fs）はピクセルではなく、マクロブロックの合計で表わされます。 H.263 のような以前のコードとは違い、H.264 ではサポートしている解像度と縦横比を受信側が示す必要はありません（機能がありません）。 H.264 の受信側は単にフレームあたりの最大マクロブロック数を単一の数値で表し、その数以下のマクロブロックを含む有効な解像度をデコードしてレンダリングできることになっています。
ここでの問題は、仕様上、送信側が通常と異なる縦横比のビデオを送信することが許可されることです。5 × 1 のような極めて異常な縦横比でも送信される可能性があります。 実際にはほとんどのデコーダでは、ビデオをデコードするために割り当てられているサーフェスには最大の高さと幅が定義されています。極端な解像度はこのサーフェスに収まらない場合もあり、デコードできません。 相互運用性を考慮する実装者は、標準以外の解像度のサポートを通知する何らかの仕組みがない限り、そうした解像度の送信には注意する必要があります。それと同時に、受信する可能性がある妥当な範囲の解像度を受信できるよう、デコーダを比較的強固にすることも追求すべきです。
ビデオ会議では一般的に、テレビの縦横比（16：9）がモニターの縦横比（16：10）よりもサポートされています。 以前のコーデックでは、4：3 の解像度を重視していましたが、 最近のシステムでは、ポートレートビデオなど幅広い縦横比をサポートするようになってきています。 幅広いデバイスから共有されるコンテンツやプレゼンテーションビデオの解像度はさまざまで、これを強力にサポートすることは非常に重要です。また、鮮明で読みやすいテキストを確保するうえで特に重要なのが、元の解像度を可能な限り維持することです。
興味深いことに、一般的な HD 解像度である 1080p（1920 × 1080）は、標準の H.264 ではエンコードできません。高さが 1080 ピクセルなので（16 で割り切れず）マクロブロックに均等に分割できないからです。 したがって、1080p の H.264 コンテンツは 1920 × 1072 または 1920 × 1088 となります。 これはアドバタイジングや送受信の際に重要です。1080p をサポートする実装では、最大 1920 × 1088 のサポートをアドバタイズし、1920 × 1072 または 1920 × 1088 の受信を処理できるようにする必要があります。 送信時の実装は、アドバタイズされた相手側の最大値を超えないようにしなければなりません。つまり、相手側がサポートをアドバタイズした最大値が 1920 × 1072 であれば、1920 × 1088 でなく 1920 × 1072 を送信するようにします。
マクロブロックの最大フレームサイズ（max-fs）を 8100 としてアドバタイズするように実装する場合もあることに注意してください。これは 1080p に必要なマクロブロックのサイズであり、単純な計算（（1920 × 1080）/（16 × 16））で求められます。実際には、この実装ではアドバタイズされた max-fs 値を超える 1920 × 1088 を処理できることが多いのですが、規格に準拠するために 1920 × 1072 で送信する必要があります。
フレームレート
同様に H.264 のネゴシエーションでは、最大フレームレートではなく最大マクロブロック/秒（max-mbps）のネゴシエーションが行われます。 max-fs の縦横比の問題と同じく、高いフレームレートで低い解像度を送信することは送信側の仕様の範囲内であるという特性を持っています。 たとえば 720p は（1280 × 720）/（16 × 16）= 3600 マクロブロックに相当し、30fps の場合は 108000mbps となります。 ただし max-mbps では、60fps 以上で 720 × 576 の解像度、またはさらに高いフレームレートでそれ以下の解像度を送信することも可能です。
縦横比の問題と同様に、実装で任意の高いフレームレートの受信をサポートすることは、実際にはめったにありません。相互運用性を考慮する実装者は、高いフレームレートのサポートを通知する何らかの仕組みがない限り、30fps を超えるフレームレートの送信は避けるべきです。
量子化パラメータ
H.264 ストリームの送信に必要なビットレートに影響する変数は、解像度とフレームレートだけではありません。コーデックは、量子化パラメータ（QP）を使用して、圧縮フレーム自体の忠実度（品質）を変えることもできます。 QP とは、スケーリング行列を導出するのに使用するインデックスです。QP 値が小さいほど、エンコーダはより多くのステップを実行することになるので、元のフレームの詳細が多く保存されます。ただしその分、より多くのビットレートが必要となります。 QP が高いと使用するステップが大きくなり、忠実度の損失が増えますが、同じ解像度のフレームをより少ないビットでエンコードできます。 したがって、QP によってエンコードの品質管理ができると考えることができます。つまり、QP が低いと品質は高くなり、QP が高いと品質は低くなるということです。 QP 値が高いと、明らかな圧縮アーティファクトがフレームに現れ、ぼやけて見えたり、ブロック状に見えたり、歪んで見えたりします。
したがって、エンコーダが特定の最大ビットレートを目標とする場合、実装ではフレームレート、解像度、品質の間で妥協点を見つけなければなりません。 ほとんどの実装では、目標とするビットレートに応じてフレームレートと解像度を設定し、エンコーダが目標品質を達成するのに最適な QP を選択できるようにします。
ただし、多くのキーフレームが必要な場合（たとえばパケット損失により相手側が頻繁にキーフレームリクエストを送信している場合）は、エンコーダは解像度とフレームレートを維持できる程度に高い QP を使用せざるを得ず、ビデオの視認性が低下して、「不均一な」品質の原因となります。エンコーダが低品質な I フレームしか生成できず、次の差分フレームでは QP を下げられるものの、その次のキーフレームでは再び QP を上げざるを得ないからです。 この影響を避けるために、実装では QP の上限の設定をした方がよい場合もあり、フレームを落とす（つまり実効フレームレートを下げる）ことで品質の変動が目立たないようにします。
プロファイル
H.264 規格では、数多くのオプションツールを利用できます。 中には、高い忠実度を達成するために、特定のパラメータに追加のビットを割り当てられるものもありますが、リアルタイムのメディアエンコードで使用されることはほとんどありません。 より適切なのは、特定のビットレートで高い忠実度を可能にするツールですが、CPU コストはかなり高くなります。
これらのツールは、ビデオストリームが一度にエンコードされた後、多数の受信者によってデコードされるユースケース（ストリーミングメディアやディスクメディアなど）では大きな価値がありますが、ビデオ会議の場合は想定が異なります。ビデオ会議では、エンコードはリアルタイムに行われる必要があり、少数の受信者によってのみデコードされるからです。 このような場合、高度なツールをサポートしていない実装が数多く見られます。
H.264 では、これらすべてのツールを個別にネゴシエーションするのではなく、ツールはプロファイルにまとめられていて、各定義済みプロファイルが多数の拡張機能をサポートすることになります。 ビデオ会議に使用される H.264 に主に関係するのは、以下の 3 つのプロファイルです。
- Constrained Baseline：H.264 の最も基本的な形式であり、オプションの拡張機能は一切ありません。 これはビデオ会議で最も一般的にサポートされているプロファイルです。相互運用性を考慮する実装では、他のプロファイルがある場合も、常に H.264 の Constrained Baseline をサポートする必要があります。
- Main：このプロファイルは主に CABAC（Context Adaptive Baseline Arithmetic Coder）のサポートを追加するものです。エンコードの CPU コストが約 50% 増える代わりに、一定の品質でビットレートが約 10% 下がります。 ビデオ会議では、Main プロファイルをサポートする実装が数多くあります。
- High：Main のツールと同様に複数のマクロブロックにまたがるフレーム内予測が可能で、やはり一定の品質でビットレートを下げることができます。ただし、CPU コストはさらに高くなります。 ビデオ会議では、High プロファイルをサポートする実装はほとんどありません。
他にも Baseline プロファイルがあり、一般的に利用されますが、これは実質的には Constrained Baseline プロファイル（CBP）と同じものです。 CBP が定義されたのは、H.264 の Baseline のネゴシエーションが SIP（Session Initiation Protocol）と SDP（Session Description Protocol）で確立されたあとである、という歴史的な理由があります。
スケーラブル ビデオ コーディング（SVC）
H.264 の拡張機能としては、他にもスケーラブル ビデオ コーディング（SVC）があります。 この拡張機能を使用すると、エンコーダは 1 つ以上のサブストリームを含むビデオストリームを生成します。これは、ストリームから特定のパケットをドロップすることで得られます。 エンコードされたストリームが（受信能力が異なる可能性がある）多数の受信者に送信されるユースケースで有益です。スイッチングサーバーで、受信能力の高い受信者にはすべてのパケットを転送し、他の受信者には、SVC ストリームの 1 つ以上のレイヤを破棄してサブストリームの 1 つを低いビットレートで転送できます。
SVC のエンコーディングでは 3 種類のサブストリームが可能です。
- Temporal：各サブレイヤは異なるフレームレートのストリームを表します。 たとえば、前のフレームではなくその前のフレームから 1 つおきにフレームが予測されるようにすることで、30fps のストリームに 15fps のサブレイヤを含めることができます。 したがって、サーバーは何も予測されない 50% のフレームを破棄し、規格に準拠した 15fps のストリームを生成して一部の受信者に送信することができます。 実装が非常に簡単な SVC モードであり、ビデオ会議で最もサポートされています。
- Spatial：各サブレイヤは異なる解像度のストリームを表します。 Temporal の拡張性よりもかなり複雑であり、ビデオ会議ではあまりサポートされていません。
- Quality：忠実度または SNR（信号対雑音比）の拡張性とも呼ばれ、各サブレイヤは同じ解像度とフレームレートであっても、品質が異なります。 一般的には、SVC で最もサポートされていない形式です。
SVC は主に、1 つのソースストリームを複数の受信者に切り替える場合に使用されるため、現在広く実装されているビデオ会議の標準規格ではあまりサポートされていません。独自仕様のビデオ会議ソリューションでより一般的に見られます。
SVC はエンコード処理の効率を低下させるので注意が必要です。たとえば 15fps のサブレイヤを含む 30fps ストリームを SVC でエンコードする場合、同じ解像度で同じく 30fps のストリームを SVC 以外でエンコード処理する場合と同じ品質を維持するためには、わずかに高いビットレートが必要となります。
このように問題が複雑であることから、サイマルキャストでこの問題を解決している実装もあります。つまり、同じストリームの複数の独立したエンコーディングを異なる解像度/フレームレート/品質でスイッチングサーバーに送信することにより、各受信者に最も適切なエンコーディングを転送するという方法です。 その結果、一般的にアップストリーム帯域とエンコードのコストは高くなりますが、各受信者のダウンストリーム帯域が低下し、SVC のサポートに伴う複雑さを回避することができます。
複数のサブストリームのコンテキストでは、SVC を使用しない H.264 は AVC（Advanced Video Coding）と呼ばれて区別されることが多く、H.264 コーデックの正式名称の一部となっています。
パケット化モード
最終的に、H.264 が RTP で送信される場合（後掲のブログを参照）、特定のフレームを複数のパケットに分割する必要があります。Maximum Transmission Unit（MTU）によるネットワーク制限を考慮すると、オーディオとは違って、ビデオフレームが 1 つの RTP パケットに収まることはほとんどないからです。 H.264 では、複数のパケット化モードをサポートしています。 モードの設定は、エンコード処理の一部として行う必要があります。各パケット化モードでは、フレームをそれぞれ特定の方法でエンコードするが必要があるからです。
H.264 には 3 つのパケット化モードがあります。
- 0：最もシンプルなモードで、RTP パケットには単一の NAL ユニット（NALU）しか含めることができません。これは、H.264 の内部構造です。 実装は簡単であり、相互運用性を考慮した実装では、通常はパケット化モード 0 のサポートが必要です。
- 1：このモードでは、複数のパケットに NALU を含めることができ、同じビットレートの場合、一般的にモード 0 よりも圧縮効率がよくなります。 ビデオ会議で最も広く使用されているパケット化モードであり、実装ではパケット化モード 1 を確実にサポートし、ネゴシエーションするよう推奨されています。
- 2：最も複雑なモードです。H.264 を使用したビデオ会議でサポートまたはネゴシエーションされることはほぼありません。
H.264 のライセンス
広く普及している印象がありますが、H.264 は無料で実装したり利用したりできるわけではありません。 H.264 に関連する特許を持つ企業は、MPEG LA という組織の下にパテントプールを設立して H.264 ライセンスに関する規則と料金を設定し、収益を回収して構成員に配分しています。
2010 年、MPEG LA はインターネット経由で送信される H.264 ビデオのライセンスを廃止しました。YouTube などのエンドユーザーの場合は無料ですが、ビデオ会議など他のユースケースではいまだ課金されています。 ただし、1 つの事業体が年間に支払う額の上限が設定されています。2013 年からシスコは openh264 というオープンソースコーデックのプリコンパイル版を利用できるようになりました。シスコは MPEG LA に上限額を支払っているので、商用も含めどのような実装でも無料で統合できます。 だからこそ Firefox などのオープンソースソフトウェア製品で H.264 をサポートできるのですが、そうでもなければライセンス費用の支払いに苦労するでしょう。
注意すべきなのは、openh264 を使用した実装でライセンス料を支払わなくてもすむように、統合する際に特定の手順に従う必要があることです。ライセンス料を支払う必要がないように、手順を遵守するようにしてください。
Webex に関するその他の記事：
About The Author
