最終日!
このPart.2は金曜の記事で、この日はずっと「Media WG」のオブザーバーしてました。
MSE, DataCue and TextTrackCue
- Timed Text WGとのJoint meeting
- スライド
DataCue / TextTrackCue
- https://github.com/WICG/datacue/blob/master/explainer.md
- HLS/DASHなどの再生にあわせて動的にコンテンツを挿入したりしたい
- 広告とか、字幕とか、etc
- メディアのコンテナに含まれるメタデータを、JS側にイベントで知らせたい
- メディア -> JSへのin-bandでデータを流すのがDataCueの目的
- TextTrackCueはその逆方向
- 論点はデータの処理をどこでやるか
- ブラウザ側で余計な処理はすべきではない
- メインスレッドとの行き来はコスト
- メディア側でやるとしても、気付かずにJS側で2重でパースしちゃうこともあるかも
- mp3のid3とかよくある
- WICGのリポジトリでデザインを固めるのでよさそう
- 今の提案は少しスコープが大きいので、より細かいシンプルなケースが必要かも
- コンポーネントも細分化できるはず
- やり取りするデータは何がいいか
- 暗号化の問題はどうなる
- JSON?
- どうせDOMに表示するなら、DOM fragmentsとかでもよいのでは
- 時間がかかる処理でもある
- APIを同期にするか非同期にするか
- 非同期のほうがよさそうではある
- MSEとあわせて考える必要はある?
- デザインによってはMSEのパーサーを使わずにやれるかもしれない
- 概観を示して分離できるものは分離したい
- メタデータについて
- Sourcing In-band Media Resource Tracks from Media Containers into HTML
- Media Fragments URI 1.0 (basic)
- メディアのin-bandにメタデータをそもそも含めるべきか
- ブロードキャストのユースケースでは、in-bandが望ましい
- DASHでは選択可能
- (どのWGで主導すべきかみたいな話)
- 結論: DataCueの検討は進めていく
MSE: vNext
- Media Source Extensionsのnextを考えてる
- Editorを探している
- Netflix, Micorsoft...
- (どうやって仕様を検討しアップデートしていくかみたいな話)
- 別の仕様に分けたくないとか
- 仕様にバージョンをつけるとテストしにくいとか
- MSEでメディアのコンテナを生成するオーバーヘッドを削減したい
- https://discourse.wicg.io/t/proposal-allow-media-source-extensions-to-support-demuxed-and-raw-frames/3730
MSE in Worker
Eviction Policiesについて
- 低レイテンシの配信なのでは、GOPを無限にして遅延を最小化したい
- MSEは全てをバッファリングするので、それができない
- GOP = キーフレームと依存フレームの1かたまりでバッファリングとGCに使われる
- これはそれをなんとかするための提案
- 次のFOMSでプロトタイプの実装をしてみる
- 最新から遅れている場合には先頭にシークしたい
- GOPが無限だとシークできないのでは
- 実装を調べてみる
MSE: issues
Restore auto-revoking behavior of createObjectURL(MediaSource) to revert breaking change introducing memory leaks
- https://github.com/w3c/media-source/issues/156
- 当時の`createObjectURL()`で作成したURLは自動でrevokeされてた
- その後、自動でrevokeするための`createFor()`が追加された
Support playback through unbuffered ranges, and allow app to provide buffered gap tolerance
- https://github.com/w3c/media-source/issues/160
- vNextでは、欠落したデータ(ギャップ)の処理と低遅延のためのEvictionPolicyが求められてる
- ギャップについて
- アプリケーションで把握できるギャップと、不明なギャップがある
- スキップできるギャップもあるはず
- videoはないけどaudioだけはある場合に、videoを待ちたくないかも
- 既存のMSEプレーヤーはだいたいトラックごとにSourceBufferを持ってる
- HTMLの`bufferedRanges`の仕様が変わったので、MSEでも追従したい
- https://html.spec.whatwg.org/#dom-media-buffered
EvictionPolicyについて
- ビデオ再生の終わっても、バッファを持ち続けるのはよくない
- Appleはメモリ使用量にも懸念があると言ってる
- ポリシーの追加は、すでに同様の実装があるappには嬉しくないかも
MSE in Worker
- ServiceWorkerのEditorいわく、APIはできる限りSWに公開できるとよい
- `createObjectURL()`のように許可されないものもあるけど
- Workerから返すデータはobject URL?transferable object?
- SWでMediaSourceを作ってそれをどうmedia要素で描画するのか
- SWで使えるようにすべきかどうかは、SWのグループとも議論が必要
- 将来的にユースケースが生まれるかもしれない vs ユースケースが思い当たらないなら不要
- https://github.com/w3c/media-source/issues/236
JSON/RAW MediaSource Byte Streams
- https://discourse.wicg.io/t/proposal-allow-media-source-extensions-to-support-demuxed-and-raw-frames/3730/3
- 暗号化のプロセスはどうなる?
- テレビみたいなアプリの場合は、寿命が長くなるはず
- RAWデータを再生する方法が必要
- MSEに渡すために、JS側でremuxする・・・?
- コンテナーは、タイムスタンプや初期化データのためにまだ必要だと思う
- MSE自身はコーデックに依存しないようにしたいね
Media Playback Quality
- https://github.com/w3c/media-playback-quality
- Chromeにまだない
- Should MediaPlaybackQuality keep VideoPlaybackQuality backward compatibility
- Don't return a read-only object
- https://github.com/w3c/media-playback-quality/issues/3
- すでにshipされてるブラウザの挙動にあわせるべき
- pollingよりも代わりにイベントを発火するほうがよいかもしれない
- 差分ではなく同じシェイプのディクショナリを通知するほうがわかりやすい
- 結論: 後方互換性を保ちながらイベントでディクショナリで`VideoPlaybackQuality`を通知する
- バックグラウンド時にはどうなる?
- Chromeは賢くて、何もしないようになってる
- 他にフレームがドロップする可能性は?
- 再生開始時
- PinPにしたとき?
- 結論: `corruptedVideoFrames`は消す
- (フレームレートについてのあれこれ)
- 4Kビデオを再生するとき
Media Session
Add "seek to start" and "seek to live" actions
- https://github.com/w3c/mediasession/issues/233
- 複数のライブストリームが連なってる場合に、特定のストリームの先頭、最新に飛びたい
- 現状のMediaSessionは、長さ固定のメディア用
- ハードウェアにあるボタンとのインテグレーションも考慮が必要
- OSで使うことができるアイコンにも制限がある
- 結論: スキップボタンと同じで、将来的にラベルで指定できるようにする
TAG Feedback: of all the potential metadata...?
- https://github.com/w3c/mediasession/issues/191
- `artist`, `title`などのメタデータを選ぶ理由について
- Chromeの実装時は、音楽にフォーカスしていたのでそれを選んだ
- `schema.org`に沿うほうがよさそうな気がする
- TAGがこれをよしとするかはわからない
MediaSessionActionHandler doesn't work for seek operations
- https://github.com/w3c/mediasession/issues/234
- Permissions APIでも同じ問題があったと思う
- 同じ解決方法にすべきだと思う
Picture in Picture
Provide a clear definition of when a UA should display controls in a PiP window
-
- https://github.com/w3c/picture-in-picture/issues/119
- 結論: UAに任せる
- MediaSessionを通して、UIの制御ができるようにしたい
Style restrictions in picture-in-picture mode excludes mirrored video use cases
- https://github.com/w3c/picture-in-picture/issues/167
- 鏡面反射の表示をPinPしたい
- 自分でそれ用のストリームをcanvasに書いてからPinPすればできるよね
- でもパフォーマンスよくないし、サポートされてるべきでは
Add option or method to set Picture-in-PictureWindow to maximum size programmatically
- https://github.com/w3c/picture-in-picture/issues/163
- PinPのサイズは、videoのサイズに追従する
- セキュリティの懸念として、そのようなAPIはよくないと思う
Add a option to go fullscreen from picture in picture window
- https://github.com/w3c/picture-in-picture/issues/166
- 結論: PinPとFullscrennとの兼ね合いについて提案を追記する
Integration with HTML
- https://github.com/w3c/picture-in-picture/issues/156
- HTML側のSpecとの統合
- 筋は通っていると思うが、HTMLの仕様は膨大
- すべてを統合できるわけではない
- JS的なAPI都合もある
- 逆にHTMLMediaElementを別の仕様にできない・・?
- 過去に試みたが実現しなかったらしい
- でもやってやれないことはないと思ってる
- 結論: 改めてmediaをHTMLと分けることを議論してみる
PinP v2について
- videoを表示する以上のことができるようにしたい
- ミュートボタンを置きたいなど、ウィンドウへのカスタマイズが望まれてる
- カスタムcontrolsを最初は考えたが、独自のアイコンを使用できない欠点があった
- DOMの一部をPinPできる?Fullscreenみたいに
- 検討したけどやめた
- サイズ・位置変更の問題があった
- 新たなwindowとすることを検討した
- window間は`postMessage()`でないとコミュニケーションできない
- これは使いにくいと思った
- Presentation APIとも連携が必要かも
- 単にこれを使うのすら難易度が高いけど
- もはや`iframe`を活用するほうがよいかも?
- でもあれは問題も多いし・・
- どちらにせよこの仕様として大きな変化である
- PinPにcanvasをオーバーレイするところからはじめる?
- インタラクションはなしで
- (ここで結論出すの無理じゃね的な話)
Autoplay
- https://github.com/w3c/autoplay
- 昨今のWebでは、音ありでは`autoplay`できないことがしばしば
- 再生が許可されていない場合、`play()`はrejectされる
- 自動再生できる状態かどうかを知るための方法がない
- 実際に`video.src`を用意して`play()`しないといけない
- 自動再生できないなら、字幕付きで音声なしの動画を再生するなどしたい
- ドキュメント単位か、要素単位でやらせるか
- `document.xxx`にenumを返すプロパティを足す案
- `allowed`, `allowed-muted`, `disallowed`, `unknown`
- FirefoxもSafariも、音声の有無に関わらず、自動再生を禁止できる
- 今はuser gestureが必要
Document Level API issue
- https://github.com/w3c/autoplay/issues/7
- 案1: `document`にプロパティを追加
- 明確でシンプル
- だがポリシーと実装が複雑になる
- 案2: 非同期のAPIを追加
- 事前に何もしなくてよい
- より複雑になる
- イベントループのすき間でユーザーアクションがあったら?
- Permissions APIにはイベントがある
- 今日のChromeは、自動再生ポリシーのために多くの手順を踏んでいる
- 設定、アクティビティ、設定値・・
- 自動再生の許可に関係なく、このデータは取得してる
- それでページの表示速度に影響はない
- なんであれDBにアクセスするなら非同期なのでは?
- 非同期だと複数回読み取り(無駄)が発生する可能性もあるよね
- (ここで議論が発散した + 時間切れ)
2日目の感想
まじめなやつ。
- WebRTC WGとは打って変わって、Media WGは当日の議論がメインだった
- そのせいで聞き取るのめっちゃ大変やった
- 初耳なSpecも多くて、全体的に自信がない
- スコープが広いトピックが多くて、これほんとに決まんの?みたいな印象
- めっちゃ議論が盛り上がってるのに1730になった瞬間みんな部屋から消えていった
- 見習いたいこのノリ
そのほか。
- W3C湯呑もらってくるの忘れた・・・
- 博多グルメは水炊きが優勝