21:52:43 RRSAgent has joined #mediawg 21:52:43 logging to https://www.w3.org/2022/03/08-mediawg-irc 21:52:49 Zakim has joined #mediawg 21:52:57 RRSAgent, make logs public 21:53:17 Meeting: Media WG monthly teleconference 21:53:42 Agenda: https://github.com/w3c/media-wg/blob/main/meetings/2022-03-08-Media_Working_Group_Teleconference-agenda.md 21:54:40 alwu has joined #mediawg 21:54:59 MattWolenetz has joined #mediawg 21:58:21 present+ 22:01:01 gregwf has joined #mediawg 22:01:19 present+ Chris_Needham, Alastor_Wu, Eric_Carlson, Jer_Noble, Peng_Liu 22:01:23 peng has joined #mediawg 22:01:27 present+ Francois_Daoust 22:01:34 present+ Cyril_Concolato 22:01:55 chair: Jer_Noble, Chris_Needham 22:02:08 present+ Greg_Freedman 22:06:32 present+ Frank_Liberato, Steve_Becker, Sushanth_Rajasankar 22:06:50 jernoble has joined #mediawg 22:07:03 cyril has joined #mediawg 22:07:30 Topic: Autoplay Policy Detection Discussion 22:07:46 Topic: "srcobject" draft specification for using MSE in workers 22:08:20 Issue 26 of Autoplay API: CFC 22:08:47 chrisn: No objections to the CFC 22:08:57 https://github.com/w3c/autoplay/issues/23 22:09:07 Issue 23 of Autoplay API: Preventing sites from proprtyng users on Autoplay 22:09:20 SteveBeckerMSFT has joined #mediawg 22:10:07 sushanth: Not sure the goal of this proposal; the current proposal would prevent MS from requesting from the user whether the user would like to allow autoplay 22:11:04 sushanth: The existing proposal allows the site to know that autoplay was blocked 22:11:12 sushanth: would like to know more about the proposal 22:11:48 alwu: web developers are struggling with how to detect autoplay 22:12:02 * this proposal is different than the play() promise exposed by the media element 22:12:38 ... The current technique web developers use is to play an array of very small videos/images to detect what is available to play 22:12:49 ... so the goal of the api is to improve that situation 22:13:03 sushanth: a website that wants to respect autoplay would add an explicit play button 22:13:19 ... but the reality today is to trick users into allowing media playback 22:13:38 ... So the feedback we get from users is to keep those sites from doing so 22:14:28 alwu: from my understanding, the problem with sites is a bad way of detecting 22:15:02 sushanth: if sites wanted to give the users a choice, they would have already. 22:15:12 q+ frank 22:15:54 ack frank 22:16:08 frank: it sounds like there's two concerns: 22:16:25 ... 1. the UA needs to make a decision about whether to allow autoplay, muted play, or otherwise 22:16:50 ... 2. how can websites respond to what the UA is going to do, and how is this different than the existing play() mechanism 22:17:26 scribe+ 22:17:48 jernoble: are you thinking you'd always show a popup, or only for a subset of sites, asking whether to autoplay 22:18:14 ... the current implementation of autoplay block is static, and the query would be called on every website 22:18:26 ... which would lead to a popup checkbox on each site 22:18:35 ... that's a justification for current behaviour 22:18:59 sushanth: what if a browser draws its own UI over the video before the play promise resolves? 22:19:08 ... e.g., allow playback to proceed on a double-click 22:19:26 ... concern is that this proposal prevents delaying the response 22:19:44 jernoble: frank's question, how should a well-behaved site respond? 22:20:25 ... if user has declared it doesn't want autoplaying content with audio, blocks the ability of the page to do the right thing 22:20:40 ... suspect this won't be a per-element request, generally "is this page allowed to play" 22:20:54 ... that would block all elements on the page 22:21:27 ... if a sensitive user agent wanted to implement what you describe, they could report that autoplay is allowed, then block the play promise 22:21:44 sushanth: would there then be W3C tests that would make a browser that did that non-compliant? 22:21:58 jernoble: haven't thought about that, interested in others views on that 22:22:45 ... as an implementer, i wouldn't want to be constrained to a specific behaviour through implementing the autoplay API 22:23:22 ... i don't think there's any "must" in the spec to say that you must not block play 22:23:36 ... share your concerns about blocking novel ways to deal with annoying behaviour 22:24:11 sushanth: maybe this is autoplay behaviour rather than policy, for sites that want to customise UI based on user preference? 22:24:48 jernoble: sounds reasonable to me, could be done through a note in the spec. the response from the API is informative, not binding on what happens when you call play() 22:24:57 frank: I'm behind it not being binding 22:25:35 jernoble: suggest taking back to the issue, get input from others, so we have something site developers are happy with 22:25:55 chrisn: any particular questions for site developers 22:26:05 present+ Jean-Yves_Avenard, Bernard_Aboba 22:26:27 jernoble: frank's second question, if the answer you get is only informative, is that enough for the experiences you want to create? 22:26:48 sushanth: next issue is exposing more fingerprinting surface 22:26:50 https://github.com/w3c/autoplay/issues/24 22:27:36 ... querying the API you know the document activation is true, so it exposes the user's preference setting, a unique way of tracking the user 22:28:33 jernoble: is your risk scenario that the UA exposes a single preference for autoplay, or are you interested in per-site settings 22:29:05 sushanth: worried about exposing something about the user. people who are more technically advanced could change the setting 22:29:07 liberato has joined #mediawg 22:29:23 ... in either case it maps directly to a setting 22:30:05 alastor: feels more implementation specific. we don't enforce that the result should surface the setting, e.g., browser activation, different result across frames, or other mechanism to block autoplay 22:30:22 ... the result and setting can have a relationship, but how much depends on implementation 22:30:46 sushanth: agree that being in a frame you can't read out into the document. not so concerned about that aspect 22:31:03 ... in future it may be possible to read that out and then leak information about a user 22:31:15 jernoble: have you thought about what a mitigation might be? 22:31:49 sushanth: the nature of the API seems to expose a preference, so not sure how to have the API without preference 22:32:19 jernoble: IIUC the current behaviour of the play promise is an indirect mapping, it also uses the document interaction status? 22:32:40 sushanth: yes. with the new API it removes the decoding piece 22:33:39 jernoble: from PING point of view, just because there are existing ways to surface information, that doesn't excuse new APIs 22:33:46 ... this doesn't seem to be a net increase 22:33:58 ... the existing play promise would allow you to detect the same information 22:34:20 ... the only mitigation would be to not expose the autoplay policy at all, or always the exact same response 22:35:04 ... if you always answer the same thing, user's can't complain what happens, as you're keeping the user's setting a secret 22:36:11 jernoble: from a webkit point of view, you could cc Tess, who's in the PING group, see if she has any mitigation suggestions 22:36:53 frank: mitigation seems difficult, you could wait for a timeupdate and then know. interested in mitigation, sad if there's not a good answer 22:37:20 sushraja has joined #mediawg 22:37:43 jernoble: the timeupdate issue, it would make all custom playback controls impossible 22:37:57 ... hard job to mitigate privacy concerns in all cases for media 22:39:21 chrisn: are the privacy concerns significant that we shouldn't expose this API? 22:40:40 sushanth: as long as the response can be faked and doesn't expose a user setting we should be fine. concern about being non-compliant 22:41:01 chrisn: alastor, so we could propose text along those lines, and get PING review? 22:41:08 alastor: sure 22:41:17 https://github.com/w3c/autoplay/issues/25 22:41:43 sushanth: I think we've covered this issue, it's a preference, not required for compliance, so I think we're ok 22:42:27 MSE srcObject topic: https://github.com/w3c/media-source/issues/175#issuecomment-1042395368 22:42:30 Topic: MSE srcObject 22:43:18 matt: last September we heard back from the WG and the Mozilla that attaching a srcObject would be preferable to object URL 22:43:35 ... have public feedback that they're getting metrics improvements 22:43:48 ... for doing the srcObject attachment, some flexibility on how to specify 22:44:20 ... to enable MSE in workers, I proposed having a handle object be constructable in a worker context, object is transferable, then can be assigned to the media elemnent srcObject 22:44:57 ... would need update the attachment instructions to prevent an object from worker context 22:45:09 ... don't want to precluding using a srcObject from a main thread MediaSource 22:45:27 ... the idea is generate the handle object where the MediaSource is then transfter to the media element 22:46:12 ... alternative is a lot more complex. allowing creation in a worker with transfer would allow this to happen faster 22:46:28 https://github.com/mozilla/standards-positions/issues/547 22:46:32 ... want feedback from you, Jer. Got positive feedback on the Mozilla request for position 22:46:51 alwu_ has joined #mediawg 22:46:52 ... want to make sure I'm not going in the wrong direction without your feedback 22:47:14 jernoble: apologies for not responding. I've come around on createObjectUrl vs srcObject 22:47:26 ... should have an explicit object with ref-count that can be transferred across boundaries 22:47:30 ... simplest possible implemntation 22:47:58 ... the easiest from both UA and client perspective, I think you're on the right track 22:48:04 matt: that's helpful, thank you 22:48:28 ... I've heard from origin trial participants, when is this coming, and to other user agents? be good to be able to give some indication 22:48:46 jernoble: issues around making things available off main thread, so it'll be a while to implement 22:48:58 ... any other feedback? 22:49:33 chrisn: any input from player libraries such as dashjs? 22:49:53 matt: have input from Shaka player. It's a major change to enable in worker and transfer 22:50:05 ... some players already do this, so it makes their work more performant 22:50:21 ... i've heard positive feedback, not sure they'll immediately take this in 22:50:32 ... support from other UAs would help this feature 22:51:41 Topic: Media Capabilities 22:51:59 cconcolato: created a test page for media capabilities: https://cconcolato.github.io/media-mime-support/mediacapabilities.html 22:52:29 Topic: TPAC 2022 22:53:09 chrisn: possible face to face meeting for TPAC 2022 22:53:11 ... https://github.com/w3c/media-wg/issues/35 22:53:11 scribe+ 22:53:51 cpn: WG Chairs have been asked to fill in a survey; about the interest within the WG in meeting F2F, for logistics reasons 22:54:29 ... From my own perspective; don't know if travel will be possible. However, there are issues which would be better discussed in person 22:54:53 ... If you are able to respond, please give a response on that issue w.r.t. your interest in meeting in person 22:55:33 ... Depending on responses we may schedule on a hybrid in-person/virtual meeting, or a virtual one 22:56:07 cyril: I didn't know how to respond because there is no agenda yet; if the question was narrowly about covid-related reasons, I could answer today 22:56:29 cpn: I would say answer based on your ability to travel generally, under the assumption that the agenda would be relevant to you 22:56:45 cyril: Mile high video was great this year 22:57:13 Bernard: there has been some discussion of limiting time for WG meetings to a single hour; having an all day meeting would be a greater motivation 22:58:01 cpn: That's true and I've raised that same point. The question is whether it would be valuable to have face-to-face breakouts and bring those results back to the whole WG. 22:58:33 cpn: If we limit the discussions to only the whole WG, I agree it constrains the usefulness of meeting in person 22:59:12 cpn: please do leave a response on that issue and we'll use that as input to respond to the W3C 22:59:22 Topic: WebCodecs Registration CFC 23:00:05 cpn: The CFC for creating a registry for WebCodecs had only a single response, which Is a difficult answer to interpret 23:00:25 ... if you feel strongly one way or another, please respond; without it, we'll proceed assuming there is consensus. 23:01:05 Bernard: Are we confirmed that the April meeting will cover Media Capabilities? 23:01:19 cpn: That depends on the availability of chrisc, 23:01:31 Bernard: If we start on a slide deck, that will trigger discussion 23:02:15 RRSAgent, draft minutes 23:02:15 I have made the request to generate https://www.w3.org/2022/03/08-mediawg-minutes.html tidoust 23:06:38 s/prevent an object from/prevent a MSE objectURL from/ 23:07:28 s/Topic: "srcobject" draft specification for using MSE in workers// 23:08:04 i/Topic: Autoplay Policy Detection Discussion/scribe+ jernoble 23:08:07 RRSAgent, draft minutes 23:08:07 I have made the request to generate https://www.w3.org/2022/03/08-mediawg-minutes.html tidoust