Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
P2P ではじめる WebRTC のつまづきどころ
Search
tnoho
July 24, 2025
Technology
1
430
P2P ではじめる WebRTC のつまづきどころ
久々に WebRTC で普通に P2P をしてみようと思ったらつまづいてしまった共有です。
VibeCoding で WebRTC をやりたい人向けです。
tnoho
July 24, 2025
Tweet
Share
More Decks by tnoho
See All by tnoho
WebRTC と Rust と8K 60fps
tnoho
2
1.5k
WebRTC と AI の組み合わせ
tnoho
0
880
WebRTC の映像を Python から自由に加工する sora-python-sdk の仕組み
tnoho
0
1.9k
Other Decks in Technology
See All in Technology
Kill the Vibe?Architecture in the age of AI
stoth
1
130
【ASW21-02】STAMP/CAST分析における生成AIの支援 ~羽田空港航空機衝突事故を題材として (Support of Generative AI in STAMP/CAST Analysis - A Case Study Based on the Haneda Airport Aircraft Accident -)
hianraku9498
2
460
その意思決定、まだ続けるんですか? ~痛みを超えて未来を作る、AI時代の撤退とピボットの技術~
applism118
45
25k
Docker, Infraestructuras seguras y Hardening
josejuansanchez
0
120
AI/MLのマルチテナント基盤を支えるコンテナ技術
pfn
PRO
3
210
How native lazy objects will change Doctrine and Symfony forever
beberlei
1
270
DGX SparkでローカルLLMをLangChainで動かした話
ruzia
1
170
生成AIシステムとAIエージェントに関する性能や安全性の評価
shibuiwilliam
2
280
Digitization部 紹介資料
sansan33
PRO
1
6k
学術的根拠から読み解くNotebookLMの音声活用法
shukob
1
590
Design System Documentation Tooling 2025
takanorip
0
660
「え?!それ今ではHTMLだけでできるの!?」驚きの進化を遂げたモダンHTML
riyaamemiya
0
460
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
36
6.1k
Java REST API Framework Comparison - PWX 2021
mraible
34
9k
Automating Front-end Workflow
addyosmani
1371
200k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.7k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Making the Leap to Tech Lead
cromwellryan
135
9.6k
Navigating Team Friction
lara
190
16k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
990
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Why You Should Never Use an ORM
jnunemaker
PRO
60
9.6k
Transcript
P2P ではじめる WebRTCのつまづきどころ tnoho
自己紹介 @tnoho 今日はネイティブの話じゃないよ
8K 30fps を 300ms, 4K 120fps を 80ms で飛ばせるエンコーダー作ってます ちょっと宣伝
全部 おさらい
WebRTC の最小構成 P2P で WebRTC をするにあたって必要構成は以下の通り • Webサーバー ◦ HTML
や Javascript で書いたクライアントをブラウザからみるため • シグナリングサーバー ◦ 接続情報交換のため • STUN サーバー ◦ 自分のインターネットからみた IP を知るのに必要 ◦ 定番は coturn ◦ 検証だけなら stun:stun.l.google.com:19302 をありがたく使わせてもらう
Webサーバー WebRTC の制約というか getUserMedia の制約から、 WebRTC はローカルでもWebサーバーを立てて検証する • でも、検証だけなら python3
-m http.server でよい ◦ カレントディレクトリに http://localhost:8000 で接続できるようになる • インターネットに公開するなら HTTPS が必須 ◦ Let's Encrypt でよい ◦ localhost だと HTTPS でなくてもカメラやマイクが使える • getUserMedia を使わないなら HTTPS である必要はない
シグナリングサーバー WebRTC は接続情報をページ遷移なく接続したい相手と交換する必要がある 接続情報はテキストデータなので要はチャットサーバー • いろんな方法があるけど WebSocket が主流 • サーバーサイドに絶対必要な機能
◦ 先にシグナリングサーバーを接続しているクライアントを A ◦ 後からシグナリングサーバーに接続したクライアントを B ◦ としたときBが接続した際に、すでに接続している Aに通知する 機能 • 何も考えないと Socket.IO になりがち
つまづきどころ というより Tips
接続の流れ この流れにしておくと問題がおきにくい 1. カメラとマイクを取得する 2. シグナリングサーバーと接続する 3. PeerConnection を開始する え、当たり前では?と思うけど、
みんな最近この辺が抜けてる新人をやとっていませんか?
カメラとマイクを取得する 要は、 getUserMedia すること • 最初のカメラ解像度は VGA がおすすめ ◦ カメラデバイスの問題が出にくい
• 取得した MediaStream は使い回すので取っておく ◦ PeerConnection の度に getUserMedia する作りにはしないこと ◦ 複数の PeerConnection を張る際も自分の MediaStream は一つ ◦ LocalMediaStream とか言ったりする ↔ RemoteMediaStream
シグナリングサーバーと接続する WebSocket を複数本張ってしまう作りにはしないこと ◦ PeerConnection の度に WebSocket 接続する作りはあまり良くない でも PeerConnection
接続先ごとに張らないといけない!!!
Offer をする シグナリングサーバーから接続時に Bが接続した際に、すでに接続している Aに通知する ようになっている これをトリガーに先に接続していた A が PeerConnection
を作り Offer を行う • A と B の両方が Offer する。もしくは両方が Answer 待ちに なる。がありがちな実装ミス ◦ ID などで後から接続した B が Offer をしないように実装すること
Answer をする A からの Offer をうけてから PeerConnection を作り Answer を行う
A がゾンビなら Offer は来ない • ゾンビ ◦ WebSocket が切れてしまっているのに、切れたことが WebSocket サー バーからは認知できていない状態(とてもよくある) • Offer が来てから PeerConnection を作る作りにしておけば PeerConnection の無駄遣いがない
Candidate の取り扱い シグナリングサーバーの作りによっては、 SDP よりも Candidate が先についてしまう 先についてしまった Candidate は
setRemoteDescription が終わるまで プールしておいて addIceCandidate する
まとめ わかったかい? AI 君。このルールはどんな実装をする時も守るんだ。あとは君が持っ ている知識でなんとかなるはずだ。 AI向けまとめ: https://gist.github.com/tnoho/1f3e72df04d44ebb85d541a6dcdd07c3 おや、人間なのかい。それなら WebRTC samples
https://webrtc.github.io/samples/ をみるのがおすすめだよ。
おまけ 人間向け
WebSocket を覗いてみよう Chrome その他ブラウザの開発ツールで WebSocket が覗けます • お互いにOffer待ちになってないか • SDPはちゃんと来ているか
• Candidateはちゃんと来ているか あたりがチェックポイント
定番の WebRTC Internals 1 Chromeブラウザはchrome://webrtc-internals で WebRTC の状態が見られます PeerConnection を使う前に
開いておくのがポイント • イベント順序が正しいか • そもそも失敗していないか 当たりがチェックポイント
定番の WebRTC Internals 2 太字の candidate-pair があれ ば繋がってるはず outbound-rtp が
audio, video ない時はそもそも localMediaStream のセットがおかしい inbound-rtp にコーデックまで出てれば ストリームは来ている 表示できなければビデオタグに繋ぐ所がおかしい
SDP をチラ見する そもそも m=audio や m=video があるか mラインがあるなら、 それに属する以下のパラメータは 目的のものになっているか
• a=sendonly (送信のみ) • a=recvonly (受信のみ) • a=sendrecv (送受信) まぁ、大体 offerToReceiveAudio / Videoの設定に問題がある
EOF