IRC log of mediawg on 2022-03-08

Timestamps are in UTC.

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