Skip to content

Instantly share code, notes, and snippets.

@voluntas

voluntas/learning-obs-webrtc-whip.md

Last active April 10, 2024 03:17
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save voluntas/06d7f992d78fbddf8061a09a8caf4efb to your computer and use it in GitHub Desktop.
Save voluntas/06d7f992d78fbddf8061a09a8caf4efb to your computer and use it in GitHub Desktop.
Download ZIP
時雨堂 OBS WebRTC/WHIP 入門 (講師資料)
Raw
learning-obs-webrtc-whip.md

時雨堂 OBS WebRTC/WHIP 入門 (講師資料)

これは時雨堂が 2023 年 11 月 21 日 (火) 15:00-17:00 で開催を予定しているオンラインイベント OBS WebRTC/WHIP 入門の 講師用 の資料であり、 参加者用の資料ではありません。

時雨堂 OBS WebRTC/WHIP 入門 オンラインイベント

概要

ChatGPT がある今、学ぼうと思えば好きなだけ学べる時代がきています。 ただ「正しい情報」をなんとなく知っている事はとても重要だと考えています。

進め方

今回の WebRTC WHIP/OBS 入門はざっと説明して、その後、残り時間を利用して、細かく話をしていきます。

資料表示用の画面と iPad を画面共有してホワイトボード的な使い方をしていきます。

お願い

是非 Discord にメモを残していってください。 後から振り返るとき、参加者の皆に有用だと思います。

ライセンス

Creative Commons — 表示 - 非営利 - 改変禁止 4.0 国際 — CC BY-NC-ND 4.0

参考書

参加する前に読んでおくと良い資料と本

WebRTC でよくある間違い

定型文

  • WebRTC はブラウザだけで利用できる
    • WebRTC はプロトコルスタックなので、ブラウザ外でも利用できる
    • むしろ Discord や WhatsApp といった非ウェブアプリで利用されている
  • WebRTC は P2P でしか利用できない
    • WebRTC は P2P だけでなく、クライアント・サーバーモデルでも利用できる
  • WebRTC は P2P だから超低遅延を実現している
    • P2P といっても、いろいろなネットワークを経由して繋がる
    • WebRTC が超低遅延なのは P2P だからではなく、WebRTC プロトコルスタックのおかげ
  • WebRTC は UDP だから超低遅延を実現している
    • インターネットは UDP だろうが TCP だろうが速度一緒なのを忘れている
    • WebRTC が超低遅延なのは UDP だけでなく WebRTC プロトコルスタックのおかげ

WebRTC 入門

WebRTC/WHIP を学ぶための最低限入門

WebRTC はブラウザなどで利用できるコミュニケーションに向けたレイテンシー最優先のプロトコルです。 とにかくコミュニケーションを実現する事を最優先にしているため、そのためには他を犠牲にしてもイイという方針をとっています。

元々は P2P つまり、1:1 の技術だったのですが、サーバー経由で利用する事により複数人数での利用が可能になりました。 今一般的に利用されている会議システムの多くは WebRTC が採用されています。

WebRTC は複雑な技術です。時雨堂では WebRTC 入門を今まで 2 回開いていますが 4-5 時間でなんとか通信の基本的な部分だけをカバーできるという感じです。

今回は WHIP を理解するための WebRTC の知識にしぼってざっくり説明していきます。

SDP

WebRTC はもともと P2P の技術ということは説明しました。そのため 1:1 でやりとりをするために「お互いが利用できる音声や映像のコーデック」や「利用できるプロトコル」を交換する必要があります。

これが SDP というプロトコルです。つまり複雑なプロトコルをやりとりする前にやりとりする複雑なプロトコルです。

DTLS-SRTP (RTP/RTCP)

WebRTC の音声と映像は DTLS-SRTP というプロトコルで常に暗号化されています。

DTLS は暗号データをやりとりするための マスターシークレット を共有するために利用されます。

SRTP というのがマスターシークレットから生成された鍵を利用して暗号化された音声と映像のデータです。

ICE/STUN/TURN

NAPT についてはここで説明はしません

WebRTC はもともと P2P のため、ネットワーク的に繋がらない場合をなんとかする必要があります。 例えば UDP がブロックされている場合などです。

ICE はネットワークをなんとか繋げる仕組みで、 その仕組みを実現するプロトコルが STUN と TURN と覚えて貰えれば大丈夫です。

  • STUN はグローバルからみた自分の IP アドレスを取得するためのプロトコル
  • TURN はグローバルに自分の代理のサーバーを用意して、そこを経由して通信をするためのプロトコル
  • ICE は STUN と TURN を組み合わせてなんとかして P2P を実現する仕組み

シグナリング

シグナリングは WebRTC において SDP を双方向でやりとりする仕組みです。多くの場合は HTTP を利用しています。

Offer と Answer という二つのタイプがあります。やりとりをするためにはどちらか先に Offer を送り、相手は Answer を返す必要があります。

Offer は 自分ができる事 が書いてあり、Answer は 相手を考慮して上で、自分ができること が書いてあります。

Offer に 日本語と英語が話せます、と書いて Answer 側は日本語しか話せないので、では日本語でお願いします。と返すイメージです。

シグナリング、つまり Offer と Answer を最初にやりとりする仕組みは WebRTC では規格化されておらず、これが配信ツールに WebRTC が採用されなかった一番の理由です。これについては後で詳しく説明します。

なぜ WebRTC なのか

WebRTC はレイテンシーを最優先にしてるからです。現在の配信は HLS や MPEG-DASH を利用したプル型の配信が主流です。 これらの配信はレイテンシーが 1 秒以上あります。これは WebRTC での配信と比べると遅いです。

WebRTC は UDP ベースであり、かつ再送制御や輻輳制御を自前で実装しているため、パケロスが発生しても、ネットワークが輻輳しても、TCP 上のプロトコルに比べて、遅延が悪化しづらくなっています。

そのため、超低遅延で映像を配信したいというニッチな要求に応えるには UDP ベースのプロトコルである必要があります。

さらにブラウザで視聴したいとなると、現時点では WebRTC か WebTransport しかありません。

WebRTC と配信ツールの関係

配信ツールでは今まで RTMP が主に使われてきました、ちなみに大きな誤解があるのですが、別に RTMP を使っているから 配信が遅い というものではありません。

問題はパケロスが発生したり、ネットワークが輻輳したタイミングでのリトライが発生するため、配信が遅くなるという事です。これは TCP を利用しており、順番保証と到達保証をしているためです。Head of Line Blocking と呼ばれる状況です。

そもそも配信は HLS や MPEG-DASH を利用した CDN 経由でのプル型モデルを利用しないと大規模への配信が難しいという現状があります。

では、なぜここで WebRTC による配信がでてきたのかというと、ブラウザに向けて低遅延配信を実現するという場合の選択肢がほとんど無いからです。

また昨今の配信事情では、低遅延であれば視聴者との距離が縮まっていきます。これは Twitch などの配信サービスが低遅延配信を推進している理由です。

実際 Amazon IVS も WebRTC ベースのサービスを提供開始しています。

WebRTC を配信ツールに組み込むための課題

課題はシグナリングの規格が決められていないというシンプルなものです。

シグナリングの規格が存在しないことは WebRTC のとても良いことなのですが、 配信ツールとして利用する場合はシグナリングの規格が決まっていないという事は、 配信サービス毎にシグナリングの規格を配信ツールに実装する必要があるという事になります。

そのため配信で利用するためのシグナリングの規格を作る必要がありました。

ちなみに WebRTC のシグナリングの規格を定義しなかったのは政治的な問題が理由です。

シグナリングなどの再標準化も意識的に行いませんでした。 これはすでに SIP やその他の IETF 以外の取り組みで解決されており、非常に政治的な問題になりかねないと考えたからです。最終的には、この空間に加えるべき価値があまりないと感じたのです

https://webrtcforthecurious.com/ja/docs/10-history-of-webrtc/

WHIP について

WHIP は配信ツールのために作られたシグナリングの規格です。

WHIP は WebRTC を P2P で利用する仕組みではないということを理解しておく必要があります。

あくまでクライアントサーバー形式で利用する仕組みです。無理矢理 P2P で利用する事はできますが、その仕組みは現時点では想定されていません。

WHIP は WebRTC で規格が決まっていなかったシグナリングの規格を片方向配信用に定義したものです。

また、WebRTC の SDP ベースのためコーデックに縛られることはありません。 HTTP POST / 201 Created ベースなので、HTTP の認証の仕組みがそのまま利用できます。

sequenceDiagram
  participant OBS as OBS
  participant WE as WHIP Endpoint
  participant MS as Media Server
  participant WS as WHIP Resource
  OBS->>+WE: HTTP POST (SDP Offer)
  WE-->>-OBS: HTTP 201 Created (SDP Answer)
  note over OBS,MS: ICE
  note over OBS,MS: DTLS
  note over OBS,MS: WebRTC 確立
  OBS->>+WS: HTTP DELETE
  WS-->>-OBS: HTTP 200 OK

WHIP エンドポイント

HTTP POST と 201 Created で SDP の Offer/Answer をやりとりする場所です。

Location ヘッダーを利用して、リソースサーバーの URL を提供します。

メディアサーバー

WHIP クライアント、つまり OBS が直接音声や映像を配信する先です。

メディアサーバーとのやりとりは ICE 候補を利用して確立します。 この ICE 候補は SDP に含まれて送られてきます。

WHIP リソース

WHIP リソースは主に終了をするための場所です。この URL に DELETE を送ると配信が終了します。

WHEP について

WHIP が配信のためのシグナリング規格だとするならば、 WHEP は視聴のためのシグナリング規格です。

OBS の WHIP について

OBS の WHIP 実装は libdatachannel と Mbed TLS を利用して実装されています。

OBS 30.0 の時点では音声コーデックは Opus 、映像コーデックは H.264 が利用できます。

WebRTC SFU Sora の OBS WHIP について

Sora の WHIP 実装は OBS に特化しており、すでに全ての機能が利用できます。 さらにまだ OBS には適用されていない AV1 の機能も Sora では利用できます。

Sora は WHIP 専用ではなく、独自のシグナリングも提供しているので、 通常の双方向の会議に、WHIP での画面共有配信なども実現可能です。

  • H.264 サポート
  • WHEP サポート
    • DELETE サポート
  • user-agent ヘッダーによる OBS サポート

WebRTC SFU Sora の OBS WHIP の今後について

今後 OBS に入る予定の機能に常に対応していく予定です。

個人的には TURN-UDP / TURN-TCP に対応すべきだと考えていますが、 libdatachannel が TURN-TCP に対応していないので、かなり厳しいと考えています。

おまけ

時間外の延長戦です

libdatachannel について

libdatachannel は OBS の WebRTC/WHIP に利用されているライブラリです。

MoQT について

MoQT (Media over QUIC Transport) について雑にお話しします。

資料

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment