がねこまさし

ネイティブでもWebRTCを使おう!―Android/iOSでWebRTC

こんにちは!今回はGoogle I/O 2015の小セッションから、Justin UbertiさんとSam Duttonさんによる、”Video chat for Web, Android and iOS”のお話をお届けします。このセッションではWebRTCを使ってビデオチャットアプリを作る方法について、WebRTCの中の人であるお二人が説明してくれました。

gio_webrtc_beggin

WebRTCはWeb Realtime Communication の略で、Webブラウザ上でカメラやマイクの映像/音声を取得したり、他のブラウザと通信するための技術です。過去のHTML5Experts.jpの記事に解説がありますので、併せてそちらもご覧ください。

セッションの始めに

最初にJastinさんから、今日は Web/Android/iOS のアプリにリアルタイムコミュニケーションを組み込む話をする、との宣言がありました。従来は「Webブラウザで、JavaScriptでできる」という部分がクローズアップされることが多いのですが、今回はあえてWebブラウザ以外の「Androidネイティブアプリ」や「iOSネイティブアプリ」でも使えるということを強調した内容になっています。そう言えばセッションのタイトルも「WebRTC」という言葉は使っていませんでした。

セッションの冒頭では、関連する資料の公開先が案内されました。どちらもGoogle Docs上で共有されています。

余談ですが企業でGoogle Apps for work を使っていてdocs/driveが使えないように機能制限している場合、アカウントにログインした状態では見れません。私も最初は見れなくて、地味にはまりました。

Google I/Oの大きなセッションのビデオは、公式サイトで公開されています。残念ながら本セッションのような小規模セッションのビデオは公開されていませんが、Google I/O 2015のお土産にもらったCardboard用のアプリからGoogle I/Oの様子をVRで見ることが可能です。本セッションの映像もVRでみることができるので、今年のCardboardをお持ちの方はお試しください。

これまでを振り返る

まずはこれまでの経緯を振り返えっての説明がありました。「数年前、Webをリアルタイムコミュニケーションのプラットフォームにしようと考えた」と言います。

  • あらゆるアプリでリアルタイム通信を可能にしたい
  • オーディオ、ビデオ、独自のデータを扱えるようにたい
  • エコシステムを構築するためにオープンなプロトコルを使いたい

gio_webrtc_target

そのために次の点について力を入れたとのことです。

  • 実用になるための高品質
  • 可能な限りPeer-to-Peerで通信
  • End-to-Endの暗号化を提供

gio_webrtc_tech_target

実に野心的なプランで、ここでSamさんが”Crazy Plan!”と突っ込みます。

  • そんなプランに取り組み、WebRTCができあがった
  • しかしその後、モバイルシフトがものすごい勢いで起こった
  • モバイルでは、コミュニケーションアプリに非常に多くの時間を使っている

gio_webrtc_mobile

利用シーンの変化に合わせるため、AndoridとiOSのネイティブアプリでもWebブラウザと同じことができるようにした、との説明がありました。そしてここで、(WebRTC改め)”AndroidiOSWebRTC” と大きく書いたスライドが登場しました。

gio_webrtc_aiwrtc

この通信技術は、Webブラウザだけリアルタイムコミュニケーションではなく、すべてのプラットフォームで使えるリアルタイムコミュニケーション技術だよ、との力強い声明です。

WebRTCの普及については、次のように説明しています。

  • いまや 1.5 billion (15億)を超えるWebRTC対応ブラウザが使われている
  • また 3 billion (30億)を超える回数、WebRTCのアプリがダウンロードされている
  • 現在はWeb, Android, iOS の3つのプラットフォームで使える様になっている

gio_webrtc_3platform

30億回ダウンロードというのはにわかには信じがたいですが、アップデートも含めればそうなるのでしょう。 FacebookのメッセンジャーがWebRTCを使っているという話もあるので、それを含めれば30億回に到達するのかもしれません。

ソースコードの紹介

次に、実際のソースコードの概要について、3つのステップで説明がありました。Webブラウザ、Android、iOSのケースを順番に比較しています。

(1) カメラ、マイクへのアクセス

Webブラウザの場合

gio_webrtc_camera_web

Webブラウザの場合、getUserMedia()を使って、リアルタイムの映像/音声データをセットでMediaStreamという形で取得できます。取得に成功するとコールバック関数(この例では onStream )に渡されるので、そこで処理します。映像/音声の取得については、こちらの記事もご覧ください。

Androidの場合

gio_webrtc_camera_android

Androidの場合は、カメラの映像とマイクの音声は別々に取得するようです。

  • まずVideoCaptureクラスを使ってVideoSource取得します
  • 次にVideoSouceから、実際の映像であるVideoTrackを取得します
  • VideoTrackが取得できたら、WebRTCで映像/音声を扱うためのMediaStreamクラスの配下に加えます

興味深いのは、MediaStreamのインスタンスはPeerConnectionFactoryから作る、というところでしょうか。Androidの通常の映像処理とは異なり、WebRTC専用クラスということだと思います。
コードの紹介では出てきませんでしたが、マイクからの音声もAudioTrackとして取得してからMediaStreamの配下に追加するのでしょう。

iOSの場合

iOSもAndroidと同じく、VideoCapture → VideoSource → VideoTrack → MediaStream という流れになります。
gio_webrtc_camera_ios

(2) PeerConnectionを使った通信

次は通信です。通信で使うRTCPeerConnectionがWebRTCの肝で、裏で非常にたくさんのことをやっている、との説明がありました。

Webブラウザの場合

gio_webrtc_peer_web

Webブラウザの場合はPeerConnectionのオブジェクトを作るところから始まります。

  • PeerConnecitonのオブジェクトのonaddstreamイベントハンドラに、相手側のメディア(映像/音声)を扱う処理を設定する(この例ではonRemoteStream)
  • PeerConnecitonのオブジェクトにaddStream()で自分のメディア(映像/音声)を教える
  • 通信を始めるための情報であるSDPを、createOffer()を呼び出して生成する
  • SDPが生成されたらコールバックが呼ばれるので(この例ではonCreateSucess)、その中で相手側に送信する

Peer-to-Peer通信を始めるまでの手順をシグナリングと呼びます。シグナリングについてはこちらの記事もご覧ください。

Androidの場合

gio_webrtc_peer_android

Androidも流れは同じです。FactoryでPeerConnectionを生成する際に、observerを指定するのがAndroid流のようですね。PeerConnectionにaddStream()して、createOffer()を呼び出し、生成されたSDPをobserver側のメソッド(この例ではonCreateSucess)で処理しているようです。

iOSの場合

gio_webrtc_peer_ios

流れはAndroidと同様ですが、delegateを使うのがiOS流ということでしょうか。createOffer()で作られたSDPを、delegateのdidCreateSessionDescrition()で処理しているようです。

(3) 表示

最後は動画を表示する部分です。

Webブラウザの場合

gio_webrtc_video_web

おなじみの video タグを使います。 URL.createObjectURL()を使って、MediaStreamをvideoタグで表示できる形に変換します。

Androidの場合

gio_webrtc_video_android

MediaSteamからvideoTrackを取り出し、OpenGLベースのVideoRendererを使って描画する、という流れの様です。OpenGLベースなので描画にGPUを使っていて、CPU負荷が低いのが特徴とのこと。 ソースコードの中にYuvImageRendererとVideoRendererという2種類のRendererが登場していますが、私には役割の違いがよく分かっていません。すみません…。

iOSの場合

gio_webrtc_video_ios

OpenGLベースのRTCEAGLVideoViewというものを使うそうです。VideoTrack.addRenderer()を使うところは、Androidと同じです。

詳細は

Web上に公開されている2つの記事を参考にしてい欲しいとのことでした。(どちらも、WebRTCを使ったビデオチャットサービスを提供している、apper.inのブログ記事です)

AppRTCを使ったデモ

実際に動くデモを用意していますとのことで、AppRTCについての紹介がありました。Hight performance, fast call setup, easy to understand and extend の3つを目指しているとのことです。 実際にChromebookとNexus6 を使ったデモが行われました。Nexus6ではエンコード側でもハードウェア(GPU)を使えて、720pのHD動画が快適に送れます。

gio_webrtc_demo1

gio_webrtc_demo2

フロントカメラからバックカメラに切り替えて、観客も映して見せました。

gio_webrtc_demo3

apprtc関連として、次の情報も紹介されていました。

  • apprtcの短縮URLとして、appr.tc が使える
  • ソースコードはgithubで github.com/webrtc
  • ブラウザ側で[i]キーを押すと、統計情報(stats)が表示される

統計情報(stats)を表示しているところ
gio_webrtc_demo_stat2

自分でも試してみましたが、Chromeで表示できる統計情報(stats)はどのような通信が行われているかを知る手掛かりとして、とても興味深いです。

apprtc_stats

つながるためのサーバー側の仕組み

デモの後は、実際の通信がつながるまでの裏側についての解説です。

シグナリングサーバー

Peer-to-Peer通信を始める前にはシグナリングと呼ばれる処理が必要ですが、AppRTCではそのサーバーとデバイスの間の通信にはWebSocketを使っているそうです。(シグナリングについてはこちらをご覧ください)

gio_webrtc_signaling

AppRTCならではの工夫(Smart signaling)として、最初のユーザがシグナリングサーバーに接続した際に、ユーザの接続情報(おそらくSDPのことだと思われます)をサーバー側にキャッシュしているとのこと。2番目のユーザが接続してきたら、サーバーから直ちにキャッシュされた情報を渡すことで、接続までの時間を短縮しているそうです。

リレーサーバー(TURN)

Peer-to-Peerで通信できないケースでは、リレーサーバー(TURNサーバー)が必要です。AppRTCでは次の仕組みを用意しているそうです。
TURNサーバーの役割については、こちらの記事をご覧いただくと参考になると思います。

gio_webrtc_turn

  • Tailbone … オープンソースのGoogle App Engineモジュール(動的にGoogle Compute Engineのインスタンスを起動する仕組みのようです。そのなかのmeshというものが、webrtc関連のように見えます)
  • Coturn server + (Tailboneで起動される)オンデマンドのGoogle Compute Engineインスタンス

これによってすべてのGCEのゾーンでTURNサーバーが動き、世界中で快適に接続できるとのことでした。 ユーザになるべく近いゾーンのTURNサーバーを経由することで、遅延を小さく抑えるようにしているのだと思います。

さまざまな工夫によって「通信が確立するまで500ミリ秒しかかからないよ」と、その短さを強調していました。

gio_webrtc_500ms

最後に、改めて「情報はg.co/webrtcを見てほしい」との紹介のあと、「フィードバックを歓迎します」と締めくくられました。

おまけ

セッション終了後、Justinさんに質問してみました。

  • Q. iOSのSDKでTURN over TCPがProxy設定を見てくれないようですが?
  • A. 先週(5/21)その修正が反映されました。最新のソースで試してください
  • Q. ChromeのBandwidth Estimationで、帯域の上限を指定するにどうすればよいですか?
  • A. SDPのb=ASで指定すれば、その上限は超えません
  • Q. 指定しているのですが効いていないみたいです。2Mbit/secぐらいです
  • A. それはデフォルトの値ですね。指定が間違っていると思うので確認してください

どちらもちょっと間の抜けた質問だったようです。失礼しました…。

Powered byNTT Communications

tag list

アクセシビリティ イベント エンタープライズ デザイン ハイブリッド パフォーマンス ブラウザ プログラミング マークアップ モバイル 海外 高速化 Angular2 AngularJS Chrome Cordova CSS de:code ECMAScript Edge Firefox Google Google I/O 2014 HTML5 Conference 2013 html5j IoT JavaScript Microsoft Mozilla Node.js PhoneGap Polymer React Safari SkyWay TypeScript UI UX W3C W3C仕様 Webアプリ Web Components WebGL WebRTC WebSocket