Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
P2P ではじめる WebRTC のつまづきどころ
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
tnoho
July 24, 2025
Technology
480
1
Share
P2P ではじめる WebRTC のつまづきどころ
久々に WebRTC で普通に P2P をしてみようと思ったらつまづいてしまった共有です。
VibeCoding で WebRTC をやりたい人向けです。
tnoho
July 24, 2025
More Decks by tnoho
See All by tnoho
WebRTC と Rust と8K 60fps
tnoho
2
2.2k
WebRTC と AI の組み合わせ
tnoho
0
970
WebRTC の映像を Python から自由に加工する sora-python-sdk の仕組み
tnoho
0
2k
Other Decks in Technology
See All in Technology
AI時代に、 データアナリストがデータエンジニアに異動して
jackojacko_
0
760
[Scram Fest Niigata2026]Quality as Code〜AIにQAの思考を再現させる試み〜
masamiyajiri
1
310
AI時代に越境し、 組織を変えるQAスキルの正体 / QA Skills for Transforming an Organization
mii3king
5
4.3k
(きっとたぶん)人材育成や教育のような何かの話
sejima
0
720
みんなの考えた最強のデータ基盤アーキテクチャ'26前期〜前夜祭〜ルーキーズ_資料_遠藤な
endonanana
0
310
オライリーイベント登壇資料「鉄リサイクル・産廃業界におけるAI技術実応用のカタチ」
takarasawa_
0
390
10サービス以上のメール到達率改善を地道に継続的に進めている話 / Continue to improve email delivery rates across multiple services
yamaguchitk333
6
1.6k
ボトムアップの改善の火を灯し続けろ!〜支援現場で学んだ、消えないための3つの打ち手〜 / 20260509 Kazuki Mori
shift_evolve
PRO
2
660
Oracle AI Database@AWS:サービス概要のご紹介
oracle4engineer
PRO
4
2.5k
【関西製造業祭り2026春】現場を変える技術はここまで来た〜世界最大の製造業見本市から持って帰ってきたもの〜
tanakaseiya
0
130
AI時代の品質はテストプロセスの作り直し #scrumniigata
kyonmm
PRO
4
1.5k
サイボウズ、プラットフォームエンジニアリング始めるってよ ― プラットフォームチームの事業貢献と組織アラインメントの強化
ueokande
0
100
Featured
See All Featured
A designer walks into a library…
pauljervisheath
211
24k
Between Models and Reality
mayunak
3
280
KATA
mclloyd
PRO
35
15k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
55k
We Have a Design System, Now What?
morganepeng
55
8.1k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
270
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
2
800
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
450
Music & Morning Musume
bryan
47
7.2k
Into the Great Unknown - MozCon
thekraken
41
2.5k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
560
From π to Pie charts
rasagy
0
180
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