- Cloudベースのネットワークやアプリを作ってる
- 同期的なイベント
- 革新的なテクノロジー
- コミュニケーションの進化
- 現状は普及期
- CiscoやAT/T、Facebookなどが使用してきてる
- 使用してるベンダーも増えてる
- Chrome / Firefox / Edge(これからのサポートを表明) / Safari(プラグインを使わないとダメ)
- コスト減
- 価値の付加や利益向上が見込めるフェイズ
- モバイル体験の向上
- コスト削減
- アナリティクス
- コーデック戦争
- ビッグデータの活用
- ソーシャルメディアとの連携
- 動画との連携
- セキュリティ向上
- スマホとの連携
- クラウド活用した開発
- WebRTC
- 新しいアプリやサービス
- エンタープライズ領域での開発モデル
- 現在は4回目のモバイルの領域拡大期
- 例えば、電話によるカスタマーサポートなどの置きかえが可能
- WebRTCに加えて、動画・音声などのリッチメディアのミキシングなど
- 録音
- ストリーミング
- 垂直にスケール
- 水平にスケール
- メディアサーバーでクラスタリング
- エンコードをリアルタイムにしてシェア
- モノリシックアーキテクチャー
- GPUの活用
- safermobility
- 911の代わりに使えるサービス
- 録画などもできるのでよい
- AWS使って、通報する
- Telehealse
- 医者が遠隔で患者の問診ができる
- IoTも同時使用で患者のモニタリング
- Raspberry PIとセンサーを患者につけてそれを記録する
- IoT
- カメラ
- ドローン
- Webでボタンクリックで電話できる
- Virtual PBXの使用
- Audio/Videoカンファレンス
- バーチャルミーティング
- 使用するのはPBXの電話、Android端末、PCなど
- 同時に録画した動画を流したりもできる
- 一例としてホワイトボードの共有もできるサービスなど
- ファイルシェア
- ゲーム
- CDN
- サーバーを介さないネットワーキング
- ブロードキャスティング
- 電話番号が無くせるかもしれない
- FBメッセンジャーの例がある
- AI領域
- コンテキストを読んだ広告
- 声を使ったデータ収集
- 850社が使う
- 26ベンダーがサービスに使う
- メジャーなアプリが使う
- Facebook Messanger
- Hangout
- メジャーブラウザで使えるように
- 28の関係プロダクト
- ScreenHero→Slack
- HTTPを使った挙動がこれになる
- Chrome47でAPIで指定可能に
- Chrome50からデフォルト
- OSSを使ってテストが可能
- 同程度のVP8のビットレートと比べ、15%CPUを使わない
- 480pであればパケットロスなどがない
- 48khz Audio
- コードのリファクタ
- ループバックレイテンシーの軽減
- デバイスを変更するとクラッシュしていた問題の修正
- VP9の採用(Chrome)
- Video画像の画質向上
- Caputure-to-texture / encode-to-textureの採用
- JSのスピーカー選択できる新しいAPI
- Promiseの対応
- プラットフォームごとの最適化
- バグフィックス
- 声と音楽などがミックスされても聞きとりやすく
- デバイス検知
- CPUを使わない
- p2pに使えないデバイスを非対応にできる
- AvAudioSessionをシェアする新しいAPI
- テクスチャパイプライン
- PeerConnection APIのアップデート
- iOS/AndroidでWebRTCをスタンドアローンで
- localとremoteで録画可能に
- Chrome49からフラグなしで使える
- CanvasとVideoタグで録画
- Chrome50から別タブのものをシェアできる
- remoteのオーディオデバイスが使える
- 音を別プロセスに
- ICEとTURNが高速に
- Wifiと携帯回線の簡単な切りかえ
- chrome://webrtc-internalsから使えるように
- 2016 Q1に1.0になる
- 直接コントロールするためのオプジェクトの追加
- 1.0以後にWebRTC NVになる
- ブラウザとアプリとの間のWebRTCはシンプルだった
- 万能なPeerConnectionが問題だった
- なんでもできすぎる
- ObjectModel API
- ortcとWebRTCの統合
- オブジェクトモデルをシンプルに
- 各オブジェクトは1つの仕事
- 各オブジェクトは何ができるか調べられる
- Audioでの1:1の通話
- コールする前に処理
- ペアリングの高速化
- ウォームアップ
- アーリーメディア
- デフォルトSTUN/TURNサーバー
- ブラウザベンダがデフォルトで用意するサーバー
- 種類によって使わないといけないポート数が変わる
- rtcp-mux + BUNDLE では1つにすることができる
- 複数トラック
- 個別にデコード
- 帯域管理が容易
- 複数トラック
- 同一メディアソースから
- 個別にデコード
- 可能であれば帯域管理が容易
- 複数トラック
- 同一メディアソースから
- 個別にデコード付加
- 可能であれば帯域管理が必須
- 少ない帯域、さらに柔軟に
- 1つのPeerConnectionで複数のメディアストリーム
- ブラウザからマルチキャストで送るが、受信できない
- スクリーンキャプチャ
- メディア録画
- DOMでのMedia Capture
- オーディオ出力デバイスAPI
- 異なるストリームを異なるアウトプットへ
- 統計APIに対する識別子
- データチャネル、コーデック、FEC
- ワーカ内で扱えるデータチャネル
- セキュリティ強化
- IPアドレスの収集に4つのレベルができた
- WGなどは開発者からのフィードバックを求めている
- appear.inのテクニカルリーダー
- 40人の会社
- appear.inはインターンがつくった
- 3人の生徒が2週間で最初のデモ作った
- そこから6週間で製品として出した
- ユーザーが使ったフィードバックなどで製品が良くなるから
- Skypeとかでもなんでも
- 何を使ってつくるのが良いのか
- DTLS-SRTPでend-to-endでセキュアにする
- ログイン不要で8人まで無料
- リンクをシェアすれば良いだけ
- どんなテクノロジーを選んだかはユーザーには届かない
- 例えばGoogle Waveがあったけど、使いかたが分からない
- “Knock”とかはユーザーの希望から
- ログインやサインアップを無くす
- イノベーションは最小限に
- ユーザーは”慣れ”が好き
- 新しすぎる仕様などは離脱に繋る
- 17歳の高校生が毎日appear.in使ったりとか
- ノルウェー国内で学生の口コミで爆発的にアクセス増えた
- ビデオは重要だけど、オーディオはミュートにしている
- Text > Audio
- ミートアップ形式
- UIなどについてユーザーインタビュー
- バーベキューで集める
- ターゲットはプライオリティを決める役に立つ
- この技術はプロダクトを変える力がある
- WebRTCはブラウザでも電話でもない
- WebRTCはビデモでもオーディオでもない
- WebRTCのおかげで、appear.inは作れた