WebRTCを試すときにオッサンが映り続ける問題に対処する - Qiita
はじめに WebRTCを使ったアプリを作る際に、切っても切れないのがカメラ映像の取得です。ノート型のPCで作業したりすると、延々と自分の顔を見続けなければなりません。そこで、自分の顔の替わりに好きな動画をメディアストリームとして流すサンプルを作って見ました。 仕組み 動画ファイルの変換 ユーザにローカルの動画ファイルを指定してもらう（ファイル選択 or ドラッグ＆ドロップ） FileオブジェクトからURLを生成 (window.URL.createObjectURLを利用） それをVideoタグで再生 継続的にCanvasタグに転写 (window.requestAnimationFrameを利用） CanvasタグからMediaStreamを取り出す (Canvas.captureStreamを利用） 音声ファイルの変換 ユーザにローカルの音声ファイルを指定してもらう（ファイル選択 or
WebRTCプラットフォーム tokboxのopentokを調べてみた(3) 通信経路編 - Qiita
今回は 前回は利用料金の考え方について整理しました。今回は裏側の通信経路について、推測交えて整理してみます。 勝手な思い込み opentokが利用しているSFUでは、ユーザからみて上りの通信経路を1本に減らすことができます。なので、全体の通信経路も減ると思い込んでいました。opentokは全ての組み合わせを基準とした利用料金なので、SFUで減らした分の通信経路の差分で儲けているのだろう、と思い込んでいました。ところが、実際はそんな単純なものでは無いようです。 Peer-to-Peer(P2P) の場合 4人が直接P2P接続していると、片方向ずつ数えると、12本の通信経路があることになります。 SFUの場合 4人でSFUを使った場合、ユーザーから見ると上り1本＋下り3本での4本。4人なら16本になります。 あれ！？ P2Pの場合より通信経路が増えています。冷静に考えれば当たり前ですが、ope
WebRTCプラットフォーム tokboxのopentokを調べてみた(1) 基礎編 - Qiita
はじめに WebRTCを実際にサービスで使おうとすると、シグナリングやNAT越え、さらにiOS対応や複数人での通話の負荷など、考えなければならないことが多々出てきます。それを解決するプラットフォームやサービスとして、例えば次のようなものがあります。 Skyway (by NTTコミュニケーションズ) opentok (by tokbox) Skylink (by Temasys) この中で最も利用事例が多い有償サービスであるopentokについて、今更ながら調べてみました。今回は基礎編として、公開情報から基本的な内容をまとめます。 対応しているクライアント環境 出典： tokbox.com/platform Windows/Macの Chrome, Firefox WindowsのIEはプラグインを提供 AndroidのChrome, Firefox iOSネイティブ向けSDK (iOS
Mac版Chromeで、Firewallが越えられない話 - Qiita
はじめに WebRTCでFirewall/NATを越えて通信するために、TURNと呼ばれる仕組みを使います。80/TCPや443/TCPしか通さないFirewall越しでも、TURN over TCP を使えば、壁を越えて通信することができます。 これでめでたしめでたし、だと思っていたのですが、自社内でFirewallを越えられないケースがありました。その1つケースでどうやら原因が判明したので、ここにまとめておきます。 TURN over TCP を利用するには TURN over TCP が利用できるのは、今のところ Chrome だけのようです。Firefoxでは（私の知る限り）まだ利用できません。こちらのNYのイベントの資料の22,23ページでも、Firefoxでは上手く動かないと記述されています。 TURN over TCP を使うためには、PeerConnectionを生成する際
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
