WebRTCをトランスコードする知見をまとめてみた

どうも、メテオです。

---

WebRTCをトランスコードする知見をまとめてみた

どうも、メテオです。

最近、バイトでWebRTCのストリームをMPEG2-TSにトランスコードするお仕事をやっています。

その中で色々知見を得たので一部紹介していきます。

なお、今回はRTP周りに関しては長くなるので書きません。

Video

今回、私が業務で扱ったのはH.264です。WebRTCといえばVP8, VP9が主力となってきますが、都合上H.264を扱っていました。

WebRTCのH.264は解像度がかなり変化します。これは配信側によって自動的に変化するもので、仕方がないことです。

解像度が変化することにより、デコード処理も複雑になるため、とても大変でした。

また、WebRTCはパケロスが頻繁に起きます。これはUDPを使っているため防ぎようがありません。個人的にはQUICが早く来て欲しいですが、まだ先のようです。

そのため、WebRTCにはGeneral NACKを使い、落としたパケットを再送するシステムがあります。これを利用することにより、パケットを補間することが出来ます。ただしNACKを飛ばしてパケットが返ってくるまで結構時間がかかるときもありますので、ある程度来ない場合は落とす必要がありそうです。

Audio

音声部分に関してはOpus以外は揺らぎようがありません。

Opusはとても優秀なコーデックで、音楽など高音質を目的としたコーデックであるSILKとスピーチ向けで低音質のCELTの2種類を動的に使い分けます。

普段はHybrid Modeが使われることが多いです。このHybrid Modeとは、8kHz以下の周波数成分はSILK、8kHz以上の周波数成分はCELTで符号化されます。デコーダでは、8kHz以下の周波数成分を単純に0で埋めてIMDCTを行い、SILKの出力に加算することで、音声波形を得ることができます。

また、WebRTCのOpusにはinbound FECが付与されることが多く、前方誤り補正(FEC)を使って、パケットがロスしたときに少しマシになります。

まとめ

文章見る限りだと簡単そうに思われますが、実際にはまだまだやるべきことがたくさんあります。

また、主にWebRTCをトランスコードする上でつらいのはRTPの処理です。ここは素直に頑張っていくしかなさそうです。