これは一部時雨堂製品の宣伝記事になっています
前提
- 著者は OBS に関してはまったくの初心者
- WebRTC に関しては商用の WebRTC SFU を 1 から開発、販売している会社を経営している
- WHIP については WebRTC のシグナリング規格 WHIP と WHEP について をどうぞ
まとめ
- OBS の WHIP の方向性は良い
- それ以外の WHIP 実装は正直いまいち
- クローズドソースの WHIP 実装が増えるの良くない流れだとおもう
OBS WHIP とは
凄く簡単に言うと OBS から WebRTC で直接配信できるようになる仕組み。
こんな感じの遅延でブラウザなどへの配信が可能になる。
OBS WHIP の現状
2023 年 4 月の時点でメインラインへのマージを待っている状況。
Add WebRTC (WHIP) output support by kc5nra · Pull Request #7926 · obsproject/obs-studio
WHIP 対応機能
- WHIP エンドポイント URL の設定
- H.264 と AV1 による配信機能
- OBS は現時点で AV1 の配信は HWA が必須
- WHIP 最新ドラフトへの追従
- Location による WHIP リソース URL の取得
- 切断時 WHIP リソース URL へ DELETE によるリソースの解放
- Authentication ヘッダーによる Bearer Token を利用した認証機能
WHIP 未対応機能
- サイマルキャスト
- FIR や PLI による全画面要求への対応
- TURN 全般
- TURN-UDP
- TURN-TCP
- TURN-TLS
- Trickle ICE
- WHIP リソース URL への PATCH で実現
- VP8 や VP9 への対応
- VP9 は HWA が多いので対応してほしい
- VP8 は見捨ててイイと思う
- SSE 拡張
- SSE を使った通知
- 必要性をあまり感じない
雑感
WHIP 自体はシンプルだし良い流れだと思う。対抗の WHEP も WHIP とほぼ同様の仕様になったことで、整理も進んでいきそう。ただ、結局シグナリングの仕様を決めたから、そのシグナリングの仕様を守るかどうかは実装者依存なのでかなり難しい。
事実 OBS も全部を実装しているわけではない。サイマルキャストとか TURN とかはまだ実装されていない。
OBS は多くのユーザーが利用しており、さらに OSS ということで、貢献することで問題点を解決できる。ただ企業が提供しているソフトウェアの個別対応をしていくとなると、昔の SIP の独自実装に追従していく感じがする。
結局シグナリングの仕様を決めたことにより、OBS のようなメジャーソフトウェアは嬉しくなるが、それ以外の配信ソフトウェア対応でメーカーの負担はより大きくなりそうだなぁというお気持ちがある。
結局シンプルな仕様を維持されることはなく、だんだんと拡張されたり独自仕様が増えてきたりして、疲れていく流れが見えてしまい、悲しい気持ちになる。
OBS WHIP を試したい場合
これは宣伝です
時雨堂 の WebRTC SFU Sora を無料で検証できるサービス。
月 2000 分までは利用可能。
OBS で配信する を見ながら試せる。
Discussion