IRC log of mediawg on 2024-04-16

Timestamps are in UTC.

20:53:20 [RRSAgent]
RRSAgent has joined #mediawg
20:53:25 [RRSAgent]
logging to https://www.w3.org/2024/04/16-mediawg-irc
20:53:27 [Zakim]
Zakim has joined #mediawg
20:56:11 [tidoust]
tidoust has joined #mediawg
21:00:26 [tidoust]
RRSAgent, draft minutes
21:00:28 [RRSAgent]
I have made the request to generate https://www.w3.org/2024/04/16-mediawg-minutes.html tidoust
21:01:07 [tidoust]
RRSAgent, make logs public
21:01:33 [tidoust]
Meeting: Media WG monthly call
21:01:39 [tidoust]
Agenda: https://github.com/w3c/media-wg/blob/main/meetings/2024-04-16-Media_Working_Group_Teleconference-agenda.md
21:01:54 [cpn]
scribe+ cpn
21:02:04 [tidoust]
Present+ Francois_Daoust, Chris_Needham, Minji_Kim, Gabriel_Brito
21:02:46 [tidoust]
present+ Joey_Parrish
21:02:51 [gabrielbrito]
gabrielbrito has joined #mediawg
21:03:10 [tidoust]
present+ Eugene_Zemtsov
21:04:37 [tidoust]
present+ Greg_Freedman
21:05:00 [cpn]
Regrets: Marcos_Caceres
21:05:02 [tidoust]
Chair: Chris
21:06:22 [tidoust]
scribe+ tidoust
21:07:22 [tidoust]
Topic: WebCodecs - Expose in VideoFrameMetadata some fields from VideoFrameCallbackMetadata
21:07:34 [tidoust]
-> https://github.com/w3c/webcodecs/issues/601 #601
21:08:02 [tidoust]
eugene: A bunch of timestamps are considered to be added to the VideoFrameMetadata registry.
21:08:25 [tidoust]
... It's not clear to me if this VideoFrameMetadata is going to be that much useful.
21:08:59 [tidoust]
... Unless we give all this metadata to encoders/decoders and over the network, all the timestamps will be lost very quickly.
21:09:20 [tidoust]
... And that means that app developers will need to manage that metadata themselves (copy, send over the network)
21:09:32 [tidoust]
... We're not helping them that much, burden is on them.
21:10:05 [tidoust]
... At this point, I would like to hear the opinion of the WG if we even need this VideoFrameMetadata registry.
21:10:20 [tidoust]
... Any user for it, given that metadata is very likely to be lost quickly anyway?
21:10:42 [tidoust]
... One use case is that this could be used to surface some settings of the video pipeline.
21:10:55 [tidoust]
... But I don't know if there's any real need for this.
21:11:08 [tidoust]
... We could get rid of the registry altogether.
21:11:28 [tidoust]
cpn: I think we need Youenn for this discussion.
21:11:54 [tidoust]
... The original issue suggests a couple of RTC-related timestamps. I don't have more details than what he says there.
21:12:10 [tidoust]
... I'm trying to recall what motivated us to introduce that in the first place.
21:12:25 [tidoust]
... Face detection metadata in RTC scenarios, perhaps?
21:12:55 [tidoust]
Eugene: You're right. I had forgotten about it. That's a valid use case.
21:13:23 [tidoust]
cpn: The difficulty with that one is that we haven't progressed it. I don't think we have a defined registry entry for this.
21:13:58 [tidoust]
Eugene: Exactly, it's been 2-3 years that WebCodecs has been implemented by a couple of implementers and there have been 0 entries to that registry, which suggests it is not really useful.
21:14:25 [tidoust]
cpn: Specific question on captureTime and receiveTime and so on. I don't have strong opinion on this.
21:14:37 [tidoust]
Eugene: I agree we need Youenn for this. I'll ping him on the GitHub issue.
21:15:06 [tidoust]
cpn: Yes, maybe let's pick up on some of the WebRTC people, e.g., Bernard could perhaps talk about the face detection aspects.
21:15:20 [tidoust]
... I agree with you otherwise that we can remove if it's unnecessary.
21:15:46 [tidoust]
... You said something interesting here: WebCodecs is starting to stabilize.
21:16:08 [tidoust]
... That makes me wonder about criteria to get to Candidate Recommendation so that we can secure IPR commitments from everybody.
21:16:17 [tidoust]
... Do you still have editors meetings?
21:16:57 [tidoust]
Eugene: Yes, we do, and there are outstanding updates, related to enabling people to implement their own SVC mode.
21:17:05 [tidoust]
... That's more or less the state of affairs.
21:17:34 [tidoust]
cpn: I would perhaps suggest that, once those have made progress, we can define that as the feature scope for transition to Candidate Recommendation.
21:18:05 [tidoust]
... Goal is to progress the spec along the Recommendation track. A CR Snapshot transition gives everybody the possibility to exclude essential claims.
21:18:37 [tidoust]
... The snapshot becomes a stable spec that can be referenced, while we continue to progress the spec, e.g., focusing on the tests.
21:18:55 [tidoust]
... Also need horizontal reviews.
21:19:05 [tidoust]
Eugene: We should do the reviews, indeed.
21:20:15 [tidoust]
cpn: That's something I'd like to progress for WebCodecs. Whether we do that in a WG meeting or in an Editors call, I don't yet know. Anyway, my ask to the editors is: is the features scope ok or are there additional features that need to be added still?
21:20:38 [tidoust]
Eugene: I'll create a GitHub issue so that we can discuss among editors.
21:20:59 [tidoust]
Topic: Proposal: Pause iframe media when not rendered
21:21:16 [tidoust]
-> https://github.com/whatwg/html/issues/10208 Proposal: pause iframe media when not rendered
21:22:13 [tidoust]
gabrielbrito: I work for Microsoft. We have this proposal for a new Permission policy to pause a media by iframes which are not currently rendered.
21:22:42 [tidoust]
... The iframe could have some resources associated with it, destroying and re-creating them could take time and lead to subpar experiences.
21:23:10 [tidoust]
... The interaction between the permission policy and the HTMLMediaElement makes the Media WG a good place to discuss.
21:23:30 [tidoust]
... One scenario: the iframe is rendered on the screen, it plays media, and then it becomes non rendered. What should we do?
21:23:56 [tidoust]
... Other scenario: the iframe has just been created but is still not rendered, the web site attempts to play media in the iframe (not rendered).
21:24:44 [tidoust]
... Idea is to make things work as if the web page does not have autoplay permission for the second scenario.
21:25:11 [tidoust]
... For the first one, the web site could treat this as if the user had paused the media. We would fire a "pause" event.
21:25:32 [tidoust]
... When the media gets paused because of the permission policy, it does not resume automatically when the iframe gets rendered again.
21:25:43 [tidoust]
... Either the website or the user would need to call "play" again.
21:25:57 [tidoust]
... I wanted to get feedback from you regarding this proposal.
21:26:05 [tidoust]
present+ Bernard_Aboba
21:26:34 [tidoust]
... non rendered means "display: none" for the time being.
21:26:43 [tidoust]
?1: This would default to allowed?
21:27:01 [tidoust]
gabrielbrito: It would default to "allowed" so that we don't change the current behavior.
21:27:44 [tidoust]
... This proposal interfaces with a lot of other APIs. Also interaction with the Web Audio API which we've started to discuss in the context of the Audio WG.
21:28:42 [tidoust]
cpn: From an end user perspective, what issue is this addressing?
21:29:16 [tidoust]
gabrielbrito: We're aiming at scenario where performances would be compromised, e.g., if we had to destroy a whole subtree.
21:29:29 [tidoust]
... Mostly related to performance from an end-user point of view.
21:30:25 [tidoust]
... In the GitHub issue I created, someone suggested re-creating the iframe (or detaching/re-attaching) but we think it could lead to performance issue due to the need to re-create things from scratch.
21:30:51 [tidoust]
?1: In the case where web developers depend on user agents help.
21:31:00 [tidoust]
... Do you have web developers asking for this?
21:31:14 [tidoust]
gabrielbrito: We do.
21:31:34 [tidoust]
cpn: It would be interesting to have other perspectives from other browser vendors, unfortunately not around today.
21:31:53 [tidoust]
... I see that Marcos commented on the issue. I don't know if it's a naming issue.
21:32:37 [tidoust]
?1: I think this one is about the fact that the proposal is only talking about "display: none" whereas there are other ways to make iframes invisible.
21:33:30 [tidoust]
gabrielbrito: I may raise issues on standards positions repositories to get feedback from Webkit and Gecko.
21:34:13 [tidoust]
cpn: Yes, also happy to arrange a session with them.
21:35:48 [tidoust]
gabrielbrito: Wondering where to join a meeting from the HTML group
21:36:27 [tidoust]
tidoust: I don't think they have meetings in the way that we do here. More asynchronous mode through GitHub issues.
21:36:59 [tidoust]
Topic: Encrypted Media Extensions (EME) layering
21:37:33 [tidoust]
cpn: This is something I'm here to ask your help and advice.
21:37:57 [tidoust]
... To give you some context, we're currently working on the EME spec and it's currently using an older version of ReSpec tooling.
21:38:05 [tidoust]
... I'm trying to update things.
21:38:36 [tidoust]
... This is throwing a number of errors, for example related to terms defined in HTML but not exported by HTML.
21:39:10 [tidoust]
... There's an open pull request against the HTML spec.
21:39:25 [tidoust]
... Anne asks how the layering works with EME.
21:39:37 [tidoust]
... I'm not sure that's been attempted in practice.
21:39:53 [tidoust]
... Part of landing this HTML change means that we need to go back to Anne with some thoughts on the layering.
21:40:30 [tidoust]
... A couple of things, covered in separated issues: EME defines "valid MIME type" (both EME and Media Capabilities have their own definitions)
21:41:34 [gabrielbrito]
gabrielbrito has joined #mediawg
21:41:34 [tidoust]
... Following issues in respective repositories, the idea would be to use the MIME Sniff algorithm and then use some additional algorithm steps to determine whether the MIME type is acceptable.
21:41:55 [tidoust]
... There's a bit of work to update the specs and remove this concept of "Valid MIME type".
21:42:12 [tidoust]
... Slide shows what EME says at the moment.
21:42:32 [tidoust]
... Similar definition in Media Capabilities.
21:43:00 [tidoust]
... Some slight differences, but the idea is to move from defining validity in this way to a more algorithmic approach.
21:43:41 [tidoust]
... The other part of the issue is figuring the interaction points between the specs and the dependencies.
21:44:02 [tidoust]
... In a few places, EME is extending HTML in multiple ways.
21:44:09 [tidoust]
... Some examples listed here.
21:44:38 [tidoust]
... e.g., to reset some internal state. Or patching of HTML behavior in the EME spec.
21:44:57 [tidoust]
... I'd like to ask your advice on the recommended approach.
21:45:11 [tidoust]
... I'm unsure what the guidance should be.
21:46:04 [tidoust]
?1: This feels like monkey-patching at a distance. There are going to be steps in the HTML spec for you're going to say "also do that".
21:47:20 [tidoust]
cpn: Do you know if there's a recommended approach? In a way, the EME is self-contained. Are there hooks that we can put in place?
21:47:38 [tidoust]
?1: My main experience is working on Document Picture-in-Picture.
21:48:11 [tidoust]
... Lots of places where it patches e.g., navigation specs. "after step 2 in navigation, do this and that..."
21:48:24 [tidoust]
... Goal is to merge them upstream once the spec matures.
21:49:06 [tidoust]
Bernard: I've heard EME is essentially bringing another codec. Do you need this deep integration or not if you consider that it's a new codec?
21:49:34 [tidoust]
joey: That seems like a valid question.
21:50:32 [tidoust]
... Not clear what HTML editors want here.
21:50:46 [tidoust]
cpn: I'm not here to propose making a lot of changes if we don't need to.
21:51:06 [tidoust]
joey: I think we're just missing some exports for the time being.
21:51:38 [tidoust]
cpn: We may get back to say that we think that the way we've made it is clear enough.
21:51:52 [tidoust]
joey: Yes, I'm happy to address something concrete.
21:52:34 [cpn]
cpn has joined #mediawg
21:53:19 [cpn]
Francois: This kind if issue also affects MSE. In Respec we can force referencing a non-exported term.
21:54:07 [tidoust]
-> https://www.w3.org/TR/presentation-api/#terminology Example of "internal" terms referenced by the Presentation API
21:55:14 [tidoust]
Bernard: I would separate the Respec issue, which I would consider editorial, from the layering discussion.
21:56:20 [tidoust]
cpn: Once HDCP detection is merged, I can go and run some editorial updates on the way to First Public Working Draft.
21:57:38 [tidoust]
... Thanks for the feedback. I'll continue to do the editorial bits and respond to the issue to ask for more detailed feedback.
21:57:53 [tidoust]
s/?1/Tommy/g
21:58:18 [tidoust]
Topic: Next meeting
21:58:36 [tidoust]
cpn: Next meeting should be on May 14th
21:59:59 [tidoust]
RRSAgent, draft minutes
22:00:00 [RRSAgent]
I have made the request to generate https://www.w3.org/2024/04/16-mediawg-minutes.html tidoust