きたで福岡!
TPACとは、The W3C Technical Plenary and Advisory Committee Meetingsのことで、Webの標準化団体であるW3Cの年会みたいなやつです。
こういうのに参加できるのは大企業の強いとこですよね・・。
今回のTPACは月曜から金曜まであったんですが、その中の木曜と金曜の2日だけ参加しました。
Part.1は木曜の記事で、終日「Web Real-Time Communications WG」のオブザーバーをやってました。
State of the WebRTC WG
各分野の概観
Media Capture and Streams
- CandidateRecommendation in Oct 17th
- 26 open issues
- ブラウザの実装状況こちら
WebRTC-PC
- CR
- 32 open issues
- 動くけど、完璧ではないよね
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
他(下火なやつ)
他(他のWGと関係が深いもの)
- WebCodec at Media WG
- WebTransport
- Timed Text
- Media Time Events
- みんなTPACで裏でWGやってるよね
ここでやりたいこと
- WebRTC 1.0のfinishが最重要課題
- すべてのバグ・ブロッカーを解消したい
- 次いで新しいAPIを模索したい
- Developerからのフィードバックも
- 次のネタはrawなメディアとか
- そういや去年はSimulcastな年だったね
WebRTC Test Status
PR for WebRTC-PC
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
- https://github.com/w3c/mediacapture-main/issues/554
- WebDriverからデバイスを設定できるようにしたい
- `devicechange`イベントをテストする方法がない
- 結論: あったら嬉しいね
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
- https://github.com/w3c/mediacapture-main/issues/584
- `crop-and-scale`とは具体的にどうすることを指すのか
- 結論: upscaleしないしstretchもしない、黒で埋めたりもしない
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?
- https://github.com/w3c/mediacapture-record/issues/139
- リモートのストリームを録画するために、再エンコが必要なのか?
- 結論: 実装でよしなにスキップできる旨を追記する
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で返ってくる値をどう検証するかも問題
- 現状の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
- https://github.com/w3c/mst-content-hint/issues/28
- `track.contentHint`を設定したあと、それを確認したい
- そのためのAPIがいるのでは
Permanence issues
- https://github.com/w3c/mst-content-hint/issues/30
- Content-Hintsは未定なのが多すぎてよくないよね
- ちゃんと定義されたもののみがAPIとしてshipされるべき
- ヒント自体は有用だと思う
- screenshareとか
- Content-Hintsの進退どうする
- 結論: すすめるけど、優先度は低くてよい
DSCP
- https://w3c.github.io/webrtc-dscp-exp/
- 実装もない
- WebAppからここを設定したいユースケースとは・・?
- 結論: もう少し要件を練るなり情報収集する方向で様子見
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); };
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どうする
- draftをわける
- WebRTC 1.0ではないかもね
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で指定するポートをできるかぎり限定したいケースがある
- `aIC()` => `sRD()`でつまづく人が多い
- Datachannel経由でメディアを送るパターンが増えてる(HW acceleratedできるので)
- SRTPだとこうはいかないらしい
- SDP mungeせずにコーデック指定したい
from Silvia
- Developer
- videoのためのCPUスペックへの要求がキツイ
- RTXとかの問題?Firefoxでも?
- わかんない
- `getStats()`がPromiseベースになって困った
- 移行ガイドがあるので送るよ
この日の感想
まじめなやつ。
- 議題にあがるIssueは普段から見てるものなので、結論に意外性はあまりなかった
- Issueからは感じ取れない空気感がわかる
- この問題はしばらく解決しそうにないなとか
- WebRTCに関してはまさにjust worksよなーと思った
- それも踏まえて、不安定な部分も知った上で、利用する選択をすべき道具である
- 会議の場は10人くらい + オブザーバーなものの、熱心に議論するのは決まった面々なのだなあ
- 5人くらいが全世界の開発者が叩くAPIを議論してるっていろんな意味ですごいよな
そのほか。
- ヒルトンのランチブュッフェぱねぇ最高
- 飲み物だけでなく無限にケーキとかクッキーがデプロイされてくる
- しかも1日中!!
- 朝が早くて0730のバスに乗るのがつらかった
- 参加記念に湯呑がもらえるらしいw
WebRTCは普段からもよく見てるし、せっかくなので明日は他のWGに出ようと思ってます。
Mediaとか、WebApplicationとか?