🍃このブログは移転しました。
3秒後、自動的に移動します・・・。

W3C TPAC 2019 に行ってきたメモ Part.1

Web WebRTC

きたで福岡！

TPACとは、The W3C Technical Plenary and Advisory Committee Meetingsのことで、Webの標準化団体であるW3Cの年会みたいなやつです。

こういうのに参加できるのは大企業の強いとこですよね・・。

今回のTPACは月曜から金曜まであったんですが、その中の木曜と金曜の2日だけ参加しました。

TPAC 2019: Detailed schedule

Part.1は木曜の記事で、終日「Web Real-Time Communications WG」のオブザーバーをやってました。

Links

基本的にはコレを見れば事足りるんですが、まあ現場で聞いて取ったメモ記事ってことでひとつ。
スライドも1日目だけで148Pもあるんでね・・・。

State of the WebRTC WG

  • WebRTC 1.0をfinishしたい
    • it just works
    • 全てのブラウザ・ネットワーク
  • ローレベルのAPI
    • 非圧縮な状態のメディアをさわりたい需要など
  • APIまわり
    • ORTC需要はちょっと落ち着いた感じ
    • かわりにWebTransportとかでてきた

各分野の概観

Media Capture and Streams
WebRTC-PC
WebRTC Identity
  • （みんなどうなってましたっけそれって感じ）
  • 24 open issues
    • 最新のissueが2017...
仕様検討それ自体について
  • HenrikとYouennがEditor
    • Jan-Ivarはアクティブに書かないとのこと
    • AdamとTaylorとDanは前のTPACでチームを去った
  • どうしようね
  • W3Cはボランティア精神によって支えられてます
他
  • Capture from DOM
    • すごく使われてる
    • しかしEditor不在
    • 19 open issues
  • Recorder
    • 同上
  • Stats
他（下火なやつ）
  • Depth
    • 活動なし
  • Audio output devices
    • CR
    • やや使われてる
  • Contnet hints
    • released
  • DSCP
    • 無
  • WebRTC-SVC
  • WebRTC-ICE
他（他のWGと関係が深いもの）
  • WebCodec at Media WG
  • WebTransport
  • Timed Text
  • Media Time Events
  • みんなTPACで裏でWGやってるよね

ここでやりたいこと

  • WebRTC 1.0のfinishが最重要課題
    • すべてのバグ・ブロッカーを解消したい
  • 次いで新しいAPIを模索したい
    • Developerからのフィードバックも
  • 次のネタはrawなメディアとか
  • そういや去年はSimulcastな年だったね

WebRTC Test Status

  • ここ数年でテストの数が増えた
    • というか仕様と実装が増えた
  • 当初、4ブラウザでの互換性は残念な感じだった
    • ここ最近は復調
    • テストを細分化したりした
  • https://dashboard.cosmosoftware.io/wpt/aab8bf00bd40f392c06b88f8afd03a8b03691099/
    • KITEでやってるよ
  • モバイルブラウザもテストしないといけない
  • P2PだけではなくSFUも（というかSimulcastを）
    • ただSFUはみんな実装が違うので画一的にテストできない
    • そのための仕組みをハッカソンで作ってた
    • loopbackサーバーを用意してもらって、KITEでアクセスする
    • Medooze, Janus, Mediasoup
  • IETF Hackathon
    • 毎回新たなベンダーを巻き込んでる
    • 次の106ではIntelを呼んだ

PR for WebRTC-PC

  • TPAC2018からの進捗はよい
    • 31 open issues
  • Simulcast
    • ラベルついてたやつは解消された
    • 実装としては少し問題は残ってる
      • SSRCサポートとか
      • RID/MIDヘッダー拡張のサポートとか
  • WebPlatformTests
    • 年々Greenになってきてる
    • Simulcastのテストがない
  • Simulcastの互換性をどうやって担保するか
    • F2Fでディスカッションするしかなさそう
    • 次のHackathonネタかな

WebRTC-PC issues

reducing audio packet rate while track is disabled
  • https://github.com/w3c/webrtc-pc/issues/1764
  • いわゆるミュート時の挙動
  • `video`は「black frameを送る」 = 画面にそう表示するから
    • 「何も送らない」だと、最後のフレームが残りっぱなしになる
  • 結論: `audio`は「何も送らない」
    • CNもDTXも関係ない
Constrainable properties on remote tracks are under-specified
  • https://github.com/w3c/webrtc-pc/issues/2121
  • リモートのtrackに対するconstraintsについて
  • 現状Chromeでは`width`, `height`, `frameRate`, `aspectRatio`が指定できる
    • ただし仕様にはない
  • `gUM()`側のそれと、WebRTC-PC側のそれが独立しちゃってる
  • 結論: 改めて`getSettings()`のconstraintsを定義しなおす
    • + `applyConstraints()`したら`throw`するようにする
RTCPeerConnectionIceErrorEvent: hostCandidate clarification
  • https://github.com/w3c/webrtc-pc/issues/2230
  • `RTCPeerConnectionIceErrorEvent`が`host`のIP/portを公開しちゃう問題
  • これは隠されるべきでフィルタを適用すべき
    • その場合は、`0.0.0.0:0`になる
    • 型的に空文字列のほうがよいのでは
  • mDNSのnameを使うべき？どのタイミングで？
    • 使わない
  • 結論: IPとportは分ける、IPは`null`ではなく空文字列で
Consider making RTCCertificate throw when serialized when _forStorage_ is false
  • https://github.com/w3c/webrtc-pc/issues/2257
  • `RTCCertificate`を`postMessage()`できちゃう問題
  • デフォルトではできないようにする案が出てる
  • 他にもシリアライズできちゃう情報あるよね
    • DTLSのフィンガープリントとか
  • Origin内ならよい？
    • indexedDBに保存するのとかは問題なさそう
  • 結論: 現状維持 + セキュリティの懸念がある旨をアップデート

Screen Capture issues

Define tab capture
  • https://github.com/w3c/mediacapture-screen-share/issues/60
  • CRブロッカーになってる最後のissue
    • 本当にブロッカーってほどなのこれ？
  • 結論: 仕様の言い回しの問題であり、タブもBrowsing contextとする
  • タブの切り替えはどうする？
    • 実装の問題なのでよしなに

Media Capture issues

Specify a way for WebDriver to add/remove/setup capture devices
Should a devicechange event be fired when the list of devices stays the same
  • https://github.com/w3c/mediacapture-main/issues/565
  • 裏でデバイスを抜き差ししたりして、`devicechange`が複数回発火するときに、さっきと同じ内容だったら
  • 結論: イベントをスキップしてよい
    • 複数回発火する可能性があるケースでは、まとめて最後の1つにする
ResizeMode (crop-and-scale) is underspecified
Is enumerateDevices list order significant?
  • https://github.com/w3c/mediacapture-main/issues/608
  • `enumerateDevices()`の返り値の順番について
  • 現状のmacOSだと
    • システムデフォルトのデバイスがリストの先頭にくる
    • `gUM({ audio: true })`でもシステムデフォルトが使われる
    • システムデフォルトを変えたら、`devicechange`イベントを発火する
  • これを仕様にする？
  • 結論: （時間切れにより明日）

Media Recording issues

Does recording of remote a/v streams always imply re-encoding?
Add replaceTrack method to MediaStream
  • https://github.com/w3c/mediacapture-record/issues/167
  • `MeidaRecorder`に渡した`MeidaStream`を`replaceStream()`したい
  • 案1: `meidaRecorder.replaceStream(stream): Promise;`
    • トラックの数と種類は同じ
  • 案2: `mediaRecorder.replaceTrack(preTrack, newTrack): Promise;`
  • 結論: 案2でよさそう
    • マルチトラックのことは追って検討する

WebRTC-Stats issues

  • issueの数が多すぎるのでかけあしで
  • まず`RTCStatsReport`の実装状況
    • まちまちだね
  • Statsで返ってくる値をどう検証するかも問題
    • Chromeでも`number`かどうかは見てても中身までは見てない
    • Webkitでは簡単なものは見てるのでそれを共有できる
    • WPTでも検証したいはず
  • 現状のstatsは、ユースケースを正しくモデリングできていない
    • `track`ではなく`sender`や`receiver`であるべき
    • そしてsimulcastを考えるとそれも1つではダメ
  • Transceiver用のstatsいる？
    • 案1: 足す
    • 案2: `mid`を`sender`と`receiver`に足す
    • 足してもいいけど、`direction`, `currentDirection`は載せない
  • でもStatsの用途ってデバッグですよね
  • `statsended`イベントと`replaceTrack()`
    • さっきの話で`track`がなくなったら、`replaceTrack()`を検知できないよね
    • `replaceTrack()`すると`onstatsended`が発火することになってる
    • `onstatsended`は廃止
      • `onreplacetrack`足すのはいいけど1.0のスコープか？
      • 追って議論で
  • `track`のStatsをobsoleteすることは決定
  • （ここで時間切れにつき明日へ）

Content-Hints issues

degradationPreference is under-specified
  • https://github.com/w3c/webrtc-pc/issues/2248
  • `degradationPreference`について
  • WPTでもgetter/setterしかテストできてない
    • というかどうやってテストするのコレ
    • 2つvideo表示して見比べるしか無い？
Reduncancy and lack of normative clarity around interaction with constraints
Permanence issues
  • https://github.com/w3c/mst-content-hint/issues/30
  • Content-Hintsは未定なのが多すぎてよくないよね
  • ちゃんと定義されたもののみがAPIとしてshipされるべき
  • ヒント自体は有用だと思う
    • screenshareとか
  • Content-Hintsの進退どうする
    • 結論: すすめるけど、優先度は低くてよい

DSCP

WebRTC-ICE

  • `RTCIceTransport`
    • SDPに依存しないICE単独の実装
  • 方向性はAgree
    • ただし1.0をfinishさせるのが優先だと思う
  • 現状の問題
    • 単一のコネクションしか貼れない
    • PeerConnを作れる数にも限界がある（Chromeだと500とか）
  • 解決策として
  • ICE forking
    • `iceClient1 = iceServer.fork();`
  • `retainLocalCandidate()`
    • 確保したいcandidateだけ残す
コードのイメージ
let iceServer = new IceTransport();
iceServer.gather({iceServers: ...});

let localCertificate = ...;

iceServer.onicecandidate = (evt) => {
 if (evt.candidate.type = "srflx") {
   iceServer.retainLocalCandidate(evt.candidate);
   post(evt.candidate, iceServer.localParameters, localCertificate);
 }
};

iceServer.onreceivedcheck = (evt) => {
  let peer = await lookup(evt.hashedRemoteUsernameFragment) // <-- HERE BE THE MAGIC

  let iceClient = iceServer.fork();
  iceClient.start(peer.iceParams);

  let quic = new QuicTransport(iceClient, localCertificate);
};
実装の難易度はどうか
  • IceTransport: 簡単
  • Dtls/SctpTransport: それなりに
  • ICE forking: これがそれなりにきついと思われる
  • ICE forkingしたいのは誰なの？
    • ゲーム系？
    • p2p mesh方面ではないよね
  • 先に進むには少なくとも2つの実装が必要になるけど・・・
    • 誰がやる？
    • みなあんまりやりたそうではないね
  • ユースケースや需要がもっと出てくればやるかも

Feature at risk by Jan-Ivar

riskのポリシー
  • 実装がない x devの興味もない => 消す
  • 実装がない x devの興味はある => 残す or 拡張とする
  • 実装が1つでもある => 拡張とする
feature at risk
  • `rollback`
  • `VoiceActivityDetection`
    • Chromeのみ(しかしbuggy)
    • at risk
  • `OauthCredential`
    • 実装なし
    • at risk
  • `rtcp-mux-policy`: negotiate
  • at risk
  • `pranswer`
  • `priority`
    • at risk
  • `statsended`
    • at risk → remove
  • `getDefaultIceServers()`
    • at risk
  • Removeされるやつおさらい
    • non-multiplexed RTP/RTCP
    • `VoiceActivityDetection`
    • `getSupportedAlgorithms()`
    • `RTCRtpSendParameters.priority`
    • `RTCRtpReceiveParameters.encodings`
    • `RTCRtpEncodingParameters.dtx`
    • `RTCRtpEncodingParameters.ptime & payloadType`
    • `RTCDataChannel.priority`
    • `RTCDataChannelInit.priority`
  • Identityどうする

Developer Feedback Session

from Mészáros
  • NRENsというコミュニティ
  • TURNを使ってる
  • 世界中にNWがあって、各地域にTURNを置いてる
  • なのでマルチテナントTURNがほしい
  • TURNの認証はLongTerm
    • それに代わるものがほしい
  • Time Limited LTC (REST)
    • draft-uberti-behave-turn-rest-00
  • TURN + OAuth
    • RFC7635
from Sean
  • pionの中の人
  • ICEで指定するポートをできるかぎり限定したいケースがある
    • Chromeにはそれ用のオプション（フラグ？）がある
    • Chromeだけではダメ
  • `aIC()` => `sRD()`でつまづく人が多い
  • Datachannel経由でメディアを送るパターンが増えてる(HW acceleratedできるので)
    • SRTPだとこうはいかないらしい
  • SDP mungeせずにコーデック指定したい
from Silvia
  • Developer
  • videoのためのCPUスペックへの要求がキツイ
    • RTXとかの問題？Firefoxでも？
    • わかんない
  • `getStats()`がPromiseベースになって困った
    • 移行ガイドがあるので送るよ
from 8x8 Developer
  • PlanB -> UnifiedPlan移行
    • 影響がでかかった割に、そんなに嬉しいことがなかった
    • SSRC -> MID/RIDも
  • SFUベンダーとして品質向上のためにやれることが少ない
    • videoはFECがあるけど、audioにはない
    • PERCはハマらなかった

この日の感想

まじめなやつ。

  • 議題にあがるIssueは普段から見てるものなので、結論に意外性はあまりなかった
    • ただGitHubで見てるアイコンの中の人や、RFC書いてる人を生で見れたのは謎の感動があった
  • Issueからは感じ取れない空気感がわかる
    • この問題はしばらく解決しそうにないなとか
  • WebRTCに関してはまさにjust worksよなーと思った
    • それも踏まえて、不安定な部分も知った上で、利用する選択をすべき道具である
  • 会議の場は10人くらい + オブザーバーなものの、熱心に議論するのは決まった面々なのだなあ
    • 5人くらいが全世界の開発者が叩くAPIを議論してるっていろんな意味ですごいよな

そのほか。

  • ヒルトンのランチブュッフェぱねぇ最高
  • 飲み物だけでなく無限にケーキとかクッキーがデプロイされてくる
    • しかも1日中！！
  • 朝が早くて0730のバスに乗るのがつらかった
  • 参加記念に湯呑がもらえるらしいｗ

WebRTCは普段からもよく見てるし、せっかくなので明日は他のWGに出ようと思ってます。
Mediaとか、WebApplicationとか？