WebRTCでH.264を使って，異なるデバイス同士を繫げるための話．WebRTCのOffer/Answerで交換するSDPのvideo部分について解説します． IETF標準を使うことで，異なるデバイス同士で繫げる時の問題の切り分けに役立つことがあります．

1. H.264で相互接続
2016/05/17
WebRTC meet up #10
@higed

2. 自己紹介
• Twitter:@higed
• JavaScript/Python
• Node.jsでサーバを書きます
• 最近はSeleniumをやっています
• アーキテクチャやノウハウについて，情報交換できると嬉しいです
• 低レイヤを勉強中です

3. Firefox46 SDP
v=0
o=mozilla...THIS_IS_SDPARTA-46.0.1
6924584915519705408 0 IN IP4 0.0.0.0
m=video 50515 UDP/TLS/RTP/SAVPF 120 126
97
a=fmtp:126 profile-level-id=42e01f;level-
asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-
asymmetry-allowed=1
…
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
話すこと
WebRTC手動シグナリング（SDP+ICE), https://lab.infocom.co.jp/demo/webrtc-hand-signaling-easy.html
• H.264で異なるデバイス同士を相互接続
するための解説
• 相互接続＝異なる機器同士で通信が
できること
• WebRTCのSDPでいうと，media
type=videoの部分にあたります
• 扱わないこと
• audio，STUN，SDPの詳細
media type = video
media format = H.264

4. 何で相互接続の話？
• H.264が共通コーデックになりつつある
• Chrome M52 => H.264
• Firefox 46 => H.264
• MS Edge => H.264/UC
• 先行するFF/Chromeは相互接続に着手
https://bugs.chromium.org/p/chromium/issues/detail?id=543540

5. いつ，困るのか？
• 全てのデバイスが同じ実装のコーデッ
クとは限らない
• ネイティブアプリと繋ぐとき
• 会議をMCU/SFUで録画するとき
• テレビ会議専用端末と繋ぐ
• 標準が切り分けの手がかりになること
がある
MCU/
SFU

6. Videoコーデックは何が決まれば良いの
か• エンコーダ＋Packetizer
→符号とパケットは密結合
• Videoに必要なパラメータ
• コーデック，解像度，
ビットレート，帯域，etc…
• 視聴側能力に合わせる
Video
配信側 視聴側
Video
packetizer
Video
encoder
Send
UDP
Receive
UDP
Video de-
packetizer
Video
decoder
http://www.callstats.io/2015/10/30/error-resilience-
mechanisms-webrtc-video/

7. RFC6184
• ITU-Tと連携したIETFドラフト
• H.264のRTPにおけるフォーマットを規
定する
• SVC/MVCは除く
• Offer/AnswerのSDPを突き合わせると
分かることも https://tools.ietf.org/html/rfc6184
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-
allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-
allowed=1
SDPでやり取りする
media formatが分かる

8. Firefox46 SDP
a=fmtp:126 profile-level-id=42e01f;level-
asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-
asymmetry-allowed=1
profile-leve-id
0x42(66) :profile_idc…BaseLine Profile
0xe0:profile_iop…互換性フラグ
0x1f(31) :level_idc…Level 3.1(1280x720)
→BP@L3.1 でBP，MP，HPで復号可能
• Profile デコーダの能力＋フォーマット
アプリケーションに応じた機能群
・BaseLineProfile:テレビ会議，携帯電話向け
・基本ツール＋エラー耐性
・Iスライス，Pスライス
• Level 画像サイズとビットレート
L1:QCIF，L2:CIF，L3:SDTV，
L4:HDTV，L5:4K，L6:8K
→整数部でサイズを規定

9. Firefox46 SDP
a=fmtp:126 profile-level-id=42e01f;level-
asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-
asymmetry-allowed=1
packetization-mode
• packetization-mode
• ビデオストリームをパケット化する
，NAL(Network Abstraction Layer)の
モードを表す．
• モードに応じてサポートするPayload
Typeは変わる．
asymmetry-allows
1…Offer/Answerで異なるLevelの仕様を許可
packetization-mode
0…(MUST)Single NALモード専用
1…(SHOULD)非インタリーブモード(Single NAL, FU-Aなど)

10. まとめ
• H.264は当面，主要ブラウザにおける共通コーデックとなりそうです
• ネイティブアプリ/サーバもH.264で繋ぐ場合，開発者同士で問題を解決
が必要な場合があります
• 解決するための基準として，IETF標準が役に立つことがあります

11. 参考:Chrome SDP(抜粋)
Chrome canary M52
m=video 54173 UDP/TLS/RTP/SAVPF 100 101 107 116
117 96 97 99 98
a=rtpmap:100 VP8/90000
a=rtpmap:101 VP9/90000
a=rtpmap:107 H264/90000
a=fmtp:107 level-asymmetry-allowed=1;packetization-
mode=1;profile-level-id=42e01f