WebRTC SFU と WebRTC Native Client を製品として提供している立場からの H.264 の今後について書いていきます。
メリット
ハードウェアエンコーダを積んでいる端末が多い
WebRTC を利用する場合は映像のエンコードもデコードも必要になることがほとんどです。さらに映像のエンコードは CPU をとても利用するため、ハードウェアエンコーダの存在が重要になります。
消費電力を抑えたり、端末の発熱を考えるとハードウェアエンコーダにオフロードできるのはとても効果的です。
現時点で VP8 や VP9 のハードウェアエンコーダを積んでいる端末は殆どありません。悲しいですがハードウェアエンコーダの世界では H.264 がほぼ唯一の選択肢となります。
iOS の Safari 12.0 で動作する
iOS は消費電力の都合で WebRTC で利用可能なコーデックを H.264 のみに絞りました。そのため iOS の Safari とつなぎたい場合は H.264 を全員が採用する必要があります。
デメリット
WebRTC の H.264 は動きに弱い
これは WebRTC の固有の問題だと認識していますが、ビットレートが低いと動きが圧倒的に弱く、ブロックノイズが出てしまいます。
それに比べて VP8 は動きにも強くとても安定しています。VP8 と H.264 のビットレートを同等にしても明らかに差が出てしまいます。
これは主観だけでなく、お客様からも言われます。
H.264 はリアルタイム利用に大変向いてないのではないか？というのがいろいろ検証して実感しっているのが現状です。
どうしてもきれいに配信するためにはビットレートを高くする必要があります。古いコーデックなのでしょうがないと言われればそうなのですが、どうしても VP8 や VP9 に比べると H.264 の画質の悪さが目立ってしまいます。
これはリアルタイム利用、特有の課題と認識しています。実際 H.264/HLS での配信でそれを感じることは特にありません。
H.264 は RTP の分割の中で更に独自に分割している
WebRTC というか RTP というか UDP の場合は、1 フレームが分割されてくるのがほとんどです。例えば 10Mbps の H.264 の場合の I フレームは相当な数分割されてきます。
VP8 や VP9 の分割はシンプルでいいんですが、H.264 の場合はまずは STAP-A のフレームタイプが結合されて送られてきます。さらに FU-A で分割されてきます。 STAP-A の中に複数のフレームタイプがあるうえ、その中で FU-A というので分割されてている中に IDR が入ります。
RTP でそもそも分割されてくるのをシーケンス番号とマーカーで判断する処理があるにもかかわらず、STAP-A と FU-A で分割されてくるというただの無駄でしかない仕組みがあります。これ本当にひどくて、H.264 だけパーサーや I フレーム判定の処理がめんどくさいです。さらにパケロスした時の FEC でのリカバリー対応とかも H.264 だけ複雑です。
これは H.264 が悪いのではなくRTP に H.264 を乗せるための仕組みが悪いので、H.264 自体は被害者的な感じはありますが、H.264 というコーデックを使わなければこの仕様とは向き合わなくてよかったので本当に耐えられないというのが現状です。正直この処理を外すだけでコードがかなりきれいになるので H.264 をサポートから外したいです、外しませんが。
OpenH264 という存在
ライセンスに関する知識や歴史的経緯については詳しくないので省略します。というかそんな簡単な話ではないと思っています。
Chrome や Firefox で H.264 が WebRTC で利用できているのは OpenH264 という Cisco と Mozilla が協業して出しているオープンソースのおかげです。
H.264 を利用するにはライセンス費用を払う必要があります。それを Cisco がビルドして公開している OpenH264 バイナリを利用すれば、Cisco がその費用を肩代わりしてくれるというものです。
これのおかげで Chrome や Firefox は H.264 を WebRTC で利用することができるようになりました。
ちなみに Safari はそもそも端末搭載の H.264 ハードウェアエンコーダを利用する前提なので OpenH264 は利用していません。
ブラウザで利用するなら Google や Mozilla がいろいろやってくれるので困らないんですが、ブラウザレスで libwebrtc を使う場合は注意が必要です。
OpenH264 を “自分でビルド” してしまうからです。つまり OpenH264 のライセンスを Cisco が払ってくれなくなります。これは要注意です。
自社で公開している WebRTC Native Client では libwebrtc が持っている H264 の機能は使わない仕組みになっています。H.264 が使えるのは Raspberry Pi か macOS だけです、これらはハードウェアエンコーダを利用しています。
ちなみに Intel の QVC では H.264 のライセンスがハード費用に含まれていないので要注意です。
VP8 や VP9 、Opus といったコーデックをメインにしていると、どうしても H.264 には慎重にならざるを得ません。恵まれているだけな気はしていますが。
まとめ
H.264 を WebRTC で使う理由はハードウェアエンコーダ一点だと感じています。それ以外では VP8 を使うのが無難で、少し攻めたければ VP9 を使うというのが良いと思います。
自社製品では VP9 がデフォルトになっています。低ビットレートでも画質が良いのは本当に助かります。パケット数が減るのは CPU にもお財布にも優しいです。
Safari が 12.1 で VP8 に対応することが発表されました。そのため、 H.264 を無理に使う必要はなくなりました。WebRTC において H.264 を使う必要は徐々になくなってくると思います。実際ハードウェアの性能も上がっては来ているので VP8 であれば特に問題ありません。
AV1 とかが来ると話は別だと思いますが、今後どうなるかははコーデックに明るくはないのでこの辺はその道の人におまかせします。
とりあえず自分は H.264 に疲れたので、H.264 から卒業したいです。
