IRC log of mediawg on 2021-09-14

Timestamps are in UTC.

20:49:51 [RRSAgent]
RRSAgent has joined #mediawg
20:49:51 [RRSAgent]
logging to https://www.w3.org/2021/09/14-mediawg-irc
20:49:53 [Zakim]
Zakim has joined #mediawg
20:50:07 [tidoust]
Meeting: Media WG Teleconference
20:54:37 [MattWolenetz]
MattWolenetz has joined #mediawg
20:58:22 [tidoust]
Agenda: https://github.com/w3c/media-wg/blob/main/meetings/2021-09-14-Media_Working_Group_Teleconference-agenda.md
20:58:55 [MattWolenetz]
present+ MattWolenetz
20:59:36 [tidoust]
present+ Francois_Daoust, Bernard_Aboba, Joey_Parrish
20:59:44 [tidoust]
RRSAgent, make logs public
21:00:59 [gregwf]
gregwf has joined #mediawg
21:02:08 [tidoust]
present+ Cyril_Concolato, Peng_Liu
21:02:09 [cyril]
cyril has joined #mediawg
21:02:40 [pengliu]
pengliu has joined #mediawg
21:03:09 [zacharycava]
zacharycava has joined #mediawg
21:03:21 [tidoust]
present+ Jer_Noble, Gary_Katsevman, Zachary_Cava, Chris_Cunningham, Greg_Freedman
21:04:03 [chcunningham]
chcunningham has joined #mediawg
21:04:16 [cyril]
present+ Cyril_Concolato
21:04:21 [tidoust]
scribe: chcunningham
21:04:36 [jernoble]
jernoble has joined #mediawg
21:04:45 [chcunningham]
present+ Chris Cunningham
21:04:50 [jernoble]
present+ jernoble
21:05:03 [tidoust]
present+ Chris_Needham
21:05:04 [gkatsev]
present+ Gary_Katsevman
21:05:40 [chcunningham]
cpn: focus of today MSE issues
21:06:23 [chcunningham]
... first AOB item: TPAC
21:06:28 [tidoust]
present+ Jan-Ivar_Bruaroey
21:06:37 [tidoust]
present+ Eric_Carlson
21:06:43 [chcunningham]
... media ig planning meetings to assess future direction of web tech for consumer devices
21:06:58 [chcunningham]
... in collab w/ cta wav and others
21:07:14 [chcunningham]
... date: 25 October, more details coming soon
21:07:34 [chcunningham]
... WG members invited to join
21:07:39 [tidoust]
s/cta wav/CTA WAVE/
21:08:10 [chcunningham]
aboba: Also joint meeting w/ WebRTC group
21:08:48 [chcunningham]
... on 26 October
21:08:53 [cpn]
https://www.w3.org/wiki/TPAC/2021/GroupMeetings
21:09:29 [chcunningham]
cpn: today's focus, MSE issues
21:09:39 [chcunningham]
... thank you for cfc replies
21:09:48 [chcunningham]
... resolved: MSE in workers is ready to integrate
21:09:52 [tidoust]
i/cpn: today's focus/Topic: Media Source Extensions
21:10:33 [tidoust]
i/cpn: focus of today/Topic: A couple of media-related joint meetings during TPAC
21:10:49 [chcunningham]
wolenetz: First issue, #184
21:10:56 [chcunningham]
... MSE for WebCodecs
21:11:21 [cpn]
https://github.com/wolenetz/mse-for-webcodecs/blob/main/explainer.md <- Explainer
21:11:32 [tidoust]
i/wolenetz: First issue/Subtopic: MSE for WebCodecs (#184)
21:11:43 [chcunningham]
... looking for authors to try origin trial, and feedback on API
21:11:58 [chcunningham]
... first promise-based MSE API
21:13:01 [chcunningham]
... summary: MSE would take WebCodecs chunks rather than containerized bytestreams
21:13:31 [chcunningham]
... expecting interest from player libraries, hls.js, etc, who could use this to avoid re-muxing
21:14:11 [tidoust]
Subtopic: MSE-in-Workers: {Audio,Video,Text}Track{,List} IDL in HTML need additional DedicatedWorker in Exposed (#28
21:14:11 [tidoust]
0
21:14:11 [tidoust]
)
21:14:33 [tidoust]
RRSAgent, draft minutes
21:14:33 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/09/14-mediawg-minutes.html tidoust
21:14:46 [chcunningham]
... 280 how to expose HTMLMediaElement tracks in worker.
21:15:01 [chcunningham]
... currently, tracks interfaces exposed only in Window
21:15:02 [tidoust]
s/)//
21:15:23 [chcunningham]
... 1) do we need tracks in worker?
21:15:27 [cpn]
q?
21:15:28 [tidoust]
s/(#28/(#280)
21:15:30 [chcunningham]
... 2) if yes, how to update html5 to go about it
21:16:05 [chcunningham]
cpn: changes to html should go to whatwg
21:16:24 [chcunningham]
... question: tracks exist both on HTMLMediaElement and SourceBuffer. What's the difference?
21:16:53 [chcunningham]
wolenetz: w/ SourceBuffer API, you can ask SB what tracks it specifically provides
21:17:03 [tidoust]
s/... 280 how to/wolenetz: 280 how to
21:17:39 [chcunningham]
... note: currently Chromium doesn't expose tracks even in Window
21:18:38 [chcunningham]
jer: Generally, I prefer MSE in worker to be as close to on main thread as possible. To facilitate easier adoption
21:20:10 [chcunningham]
... Probably not a big issue for HTML to expose tracks in Workers
21:20:33 [cpn]
https://github.com/w3c/media-source/issues/277
21:20:38 [chcunningham]
Subtopic: Threading lifetimes
21:21:56 [chcunningham]
wolenetz: what happens to <video> when worker is terminated
21:22:20 [chcunningham]
... do we remove the buffers from <video> that MSE-in-worker was contributing?
21:22:38 [chcunningham]
... or do we let <video> retain what was buffered
21:23:15 [chcunningham]
... also, should <video> get some notification that worker termination occurred
21:24:12 [chcunningham]
... currently, chrome's mse-in-workers drops buffers after worker dies, but not sure if it's right
21:24:49 [chcunningham]
jernoble: I would behave as if source object is removed from <video>. return to empty network state
21:25:15 [chcunningham]
wolenetz: or potentially trigger EOS behavior?
21:25:57 [chcunningham]
jernoble: that sounds more complicated. if source object disappears, most transparent thing is to remove the buffers
21:26:13 [chcunningham]
... could be detected by network state event
21:27:04 [chcunningham]
... similar to how <video> behaves w/ src set to empty string
21:27:32 [chcunningham]
cyrl: can things be downloaded, buffered, then wasted if worker dies?
21:27:40 [chcunningham]
s/cyrl/cyril/
21:28:14 [chcunningham]
wolenetz: yes that could occur, but generally we expect the app to be driving the termination, so just a question about the short period of time following that
21:28:54 [chcunningham]
cyril: fine to remove buffers if it's just for a short period.
21:29:42 [chcunningham]
jernoble: "terminating" the worker would be caused by explicit terminate(), which in theory is only done by the client of the worker
21:30:16 [chcunningham]
cyril: can the app wait to terminate until it's used all the buffer
21:30:19 [chcunningham]
wolenetz: yes
21:31:24 [chcunningham]
cpn: what do we need to spec from interop pov
21:32:05 [chcunningham]
wolenetz: I like Jer's suggestion to detach as much as possible.
21:32:47 [chcunningham]
cpn: can you reuse media element by setting a new src / srcObject?
21:32:51 [chcunningham]
wolenetz: yes
21:33:42 [cpn]
https://github.com/w3c/media-source/issues/275
21:34:25 [chcunningham]
Subtopic: timing of initial HAVE_METADATA transition
21:35:19 [chcunningham]
... currently, HAVE_METADATA is spec'ed to be fired synchronously w/ arrival of init segment
21:35:53 [chcunningham]
... not feasible with workers. any concerns to relax it to be async
21:36:56 [chcunningham]
... specifically, bottom of init segment received algorithm: when all SB's have init segment received = true
21:37:17 [chcunningham]
... set's readyState = HAVE_METADATA
21:37:56 [chcunningham]
jernoble: I think the time where init segment is processed is probably already arbitrary
21:38:49 [chcunningham]
wolenetz: so it's probably ok to do async here as well? not blocking the worker on synchronously setting readyState?
21:38:58 [chcunningham]
jernoble: I agree
21:40:12 [chcunningham]
janivar: might be good to gather data on current browser behavior
21:40:19 [chcunningham]
wolenetz: will do
21:40:49 [chcunningham]
jernoble: do we have a wpt test for this? could use that to track differences
21:41:30 [chcunningham]
wolenetz: test exists, but it's flaky
21:41:59 [chcunningham]
jernoble: for webkit, we issue have_metadata before updated event
21:42:32 [cpn]
https://github.com/w3c/media-source/issues/156
21:42:56 [chcunningham]
Subtopic: Object URLs vs srcObject
21:43:18 [chcunningham]
wolenetz: chromium regrettably doesn't support srcObject yet
21:44:10 [chcunningham]
... the original object URL was "autorevoking"
21:45:00 [chcunningham]
... Chrome changed behavior to let apps explicitly revoke to improve GC ability to collect
21:46:05 [chcunningham]
... for MSE-in-workers, we need to keep object URLs alive long enough to be used by worker (can't immediately revoke).
21:46:47 [chcunningham]
... proposal: for workers, what if we don't revoke until after first use.
21:47:51 [chcunningham]
jernoble: I initially favored keeping the URL, but now I like srcObject. Still, usage of srcObject is very low because of missing support in other UAs
21:49:29 [chcunningham]
wolenetz: we haven't decided how src would work w/ MSE-in-workers yet. so far just looked at using srcObject
21:50:16 [chcunningham]
jernoble: for src url, we could maintain autorevoking behavior on the main thread while behaving differently for use in workers
21:50:42 [cpn]
https://github.com/w3c/media-source/issues/28
21:51:54 [chcunningham]
janivar: I'm supportive of srcObject. Firefox hasn't implemented it yet.
21:56:24 [chcunningham]
jernoble: it seems simpler to create object in worker, do attachment on main thread, and have spec language say <video> informs the MSE-in-worker that they're now attached
21:56:54 [chcunningham]
... vs earlier proposals that considered creating src url in main thread
21:57:40 [chcunningham]
janivar: beware, as you "transfer" objects, the typical language is that the source-side is "detached"
21:57:44 [chcunningham]
q+
21:58:43 [chcunningham]
wolenetz: Up next I'll be addressed Mark Watsons PR comments and taking a look at specter mitigations
21:59:06 [chcunningham]
cpn: to confirm, for workers, we've aligned on srcObject for attachment?
21:59:11 [chcunningham]
wolenetz: correct
21:59:54 [chcunningham]
jernoble: something to consider, should <source> elements have srcObject attribute?
22:00:13 [chcunningham]
Topic: next meeting
22:00:31 [chcunningham]
cpn: scheduled for end of october. do we need anything sooner?
22:00:49 [chcunningham]
cyril: I'd like an earlier session to discuss bytestream issues
22:01:26 [chcunningham]
jer: how about same time in two weeks?
22:01:33 [chcunningham]
q-
22:02:55 [chcunningham]
cyril: in the meantime, please add your thoughts to the GH issues
22:04:02 [tidoust]
RRSAgent, draft minuntes
22:04:02 [RRSAgent]
I'm logging. I don't understand 'draft minuntes', tidoust. Try /msg RRSAgent help
22:04:07 [tidoust]
RRSAgent, draft minutes
22:04:07 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/09/14-mediawg-minutes.html tidoust
22:04:30 [MattWolenetz]
s/specter/Spectre/
22:06:40 [tidoust]
Chair: Chris, Jer
22:06:44 [tidoust]
RRSAgent, draft minutes
22:06:44 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/09/14-mediawg-minutes.html tidoust