なぜ WebRTC でハードウェアエンコーダにこだわるのか

V
3 min readMar 17, 2020

--

ブラウザレスで WebRTC を利用できる WebRTC Native Client Momo は様々なハードウェアエンコーダに対応しています。

さらに Intel Media SDK にも対応するために調査したりしています。なぜここまで WebRTC 利用時にハードウェアエンコーダにこだわるのかを書いていきます。

ブラウザはハードウェアエンコーダを利用してくれないことが多い

ChromeBook や Safari は利用してくれますが、ほかはほぼモバイルじゃない限りは利用してくれません。

リアルタイムエンコードはしんどくて重い

WebRTC って遅延をどれだけ減らせるかがキモになります。カメラなどから入ってきた映像を圧縮かけて送るわけです。この圧縮部分が重かったり時間かかったりすると、WebRTC を使っているメリットがありません。

ちょっとでも重くなる=遅くなるに繋がります。

映像を圧縮してるわけですからそれは時間かかるわけです。ただ画質が悪くていいのであれば軽いです。ただ画質がわるいならそもそも映像見なくていいわけです。

キレイにみたい場合は重くなるという当たり前の話です。

4K のリアルタイムエンコードは尋常じゃなく重い

そして 4K の映像を WebRTC で見たい場合って、ソフトウェアエンコーダじゃほぼほぼ無理。CPU が追いつきません。

そのため 4K の映像を配信するためにはハードウェアエンコーダがほぼほぼ必須です。

ハードウェアエンコーダは癖が強い

基本的にはそれぞれに対応していく必要がありますし、CPU 使用率を下げたまま高解像度、高 FPS を維持するのはノウハウの塊です。

やるべきかやらないべきか

ブラウザ以外での WebRTC を利用する場合はハードウェアエンコーダに手を出さないという選択肢はないと思っています。

WebRTC をブラウザ以外で利用しているサービスはハードウェアエンコーダを活用しているところがほとんどです。

Unity 公式の WebRTC ライブラリも NVIDIA のハードウェアエンコーダを採用していますし、Rainway や Parsec というローカルゲームストリーミングサービスでもハードウェアエンコーダを利用する仕組みになっています。

今後 AV1 などが来ることでよりハードウェアエンコーダの重要性は高まってきます。積極的にハードウェアエンコーダ対応へ投資していこうと思っています。

--

--

V
V

No responses yet