20:52:48 RRSAgent has joined #mediawg 20:52:52 logging to https://www.w3.org/2023/07/11-mediawg-irc 20:52:52 Zakim has joined #mediawg 20:54:40 tidoust has joined #mediawg 21:00:30 RRSAgent, draft minutes 21:00:31 I have made the request to generate https://www.w3.org/2023/07/11-mediawg-minutes.html tidoust 21:01:18 RRSAgent, make logs public 21:01:51 Meeting: Media WG meeting 21:01:53 Chair: Chris 21:03:36 Present: Bernard_Aboba, Francois_Daoust, Peter_Thatcher, Joey_Parrish, Sun_Shin, Eugene_Zemtsov, Andy_Estes, Xiaohan_Wang, Chris_Needham, Marcos_Caceres, Greg_Freedman 21:03:59 Agenda: https://github.com/w3c/media-wg/blob/main/meetings/2023-07-11-Media_Working_Group_Teleconference-agenda.md 21:05:07 present+ Mark_Watson, Dale_Curtis 21:05:31 scribe: tidoust 21:05:42 aestes has joined #mediawg 21:05:55 Topic: Welcome Marcos as new co-chair 21:06:12 cpn: The Media WG is rechartered for the next two years. 21:06:22 ... Change of chair as part of that. Welcome Marcos! 21:06:51 Marcos: Been doing standardization for a number of years. Chair the WebApps WG and WICG. 21:07:10 ... Fluent in W3C process. 21:07:33 cpn: I'd like to thank Jer so much for chairing the group over the past few years! 21:08:35 Topic: TPAC agenda planning 21:08:36 https://github.com/w3c/media-wg/issues/40 21:09:15 marcosc has joined #mediawg 21:09:17 cpn: We have the monday afternoon for a dedicated Media WG meeting. That gives us 3.5h of meeting time. I tried to sketch up an agenda. 21:09:47 ... I'd like spec editors to work with the chairs to help us compose the agenda. 21:10:02 ... We'll be following up with you via email. 21:10:14 ... I'd like that to be pulled together over the next few weeks or so. 21:10:51 ... We can spend time on each of the specifications in the group. 21:11:20 ... Aside from our own group, we have a joint meeting with WebRTC WG, on Friday afternoon for 2 hours. 21:11:46 ... WebRTC people tend to drive the agenda of such meetings, but happy to help as well. 21:12:08 Bernard: Jan-Ivar and I came up with a number of topics today. 21:12:42 ... Questions related to use cases: do we know what use cases are? Do we cover the use cases we're aware of? 21:12:56 ... We have a use cases document. 21:13:10 ... But still un-satisfying. 21:13:42 cpn: We setup a dedicated repo last year on joint topics. 21:13:46 Bernard: That's right, and we did write some code. 21:13:53 ... Does not cover all use cases. 21:14:28 ... Example of cloud gaming. Implementing that use case is for a company, not just an exercise. That's what makes these discussions a little bit difficult. 21:14:58 ... I think we have a better perspective on some of the pipeline issues, e.g. with WHATWG Streams. 21:15:21 ... The meeting is close than you may think, as people are going to go on holidays soon. 21:15:54 ... Some of the questions that came up: ManagedMediaSource and WebTransport or RTDDataChannel as transport. 21:16:23 ... Audio and MediaStreamTrackProcessor, whether that works well for audio/video synchronization. 21:16:49 eugene has joined #mediawg 21:17:13 ... Third one is setMicrophoneActive and w3c/mediasession#279. Can we add some UA guarantees (might require solving the double mute problem)? 21:17:13 https://github.com/w3c/mediasession/issues/279 -> Issue 279 Privacy issue: is it a good idea to let webapps lie about camera/mic ON/OFF on a user's lock screen? (jan-ivar) P1, mediacontrol, editorial 21:17:35 gb, bye 21:17:35 gb has left #mediawg 21:18:00 Bernard: Also some questions around color space support. 21:18:21 cpn: I can reach out to Color on the Web CG people. Not sure who is going to be present at TPAC. 21:18:33 Bernard: Each of these topics is a potentially long discussion. 21:18:50 cpn: That seems like a good basis for discussion for the joint meeting. 21:19:24 ... Back to the Media WG, I would expect some time on MSE. If there are WebCodecs issues, we can certainly make time to cover those as well. 21:19:33 ... Happy to take suggestions from editors on that. 21:20:11 eugene: How to integrate custom rate control in RTC-based scenarios. 21:20:38 Bernard: This one is a big one. I might be able to find someone for this. 21:21:04 ... Possibly Philipp Hancke. 21:21:50 ... It might be a joint meeting thing. 21:23:10 cpn: We can also include EME on the TPAC agenda. In principle, I don't feel that there's that much to discuss. It just feels that there's editorial work to be done to update the spec. 21:23:28 ... Is it worth allocating time for EME? 21:24:39 gregwhitworth: I agree it's not worth. We have trouble getting engagement. Outside the 3 of us, we haven't had much feedback. We will finish the tasks that we need to do, but don't think we need to discuss with broader community. 21:25:01 s/gregwithworth/gregfreedman/ 21:25:27 cpn: For other specs, we'll follow up with the relevant folks. 21:25:57 ... If there's anything else that you'd like us to include, let me know. 21:27:09 aestes: Perhaps making progress on the media session coordinator API that we proposed last year. I'm interesting in that. We probably need to gather support from other implementers. 21:27:52 cpn: Interesting. Not in scope of the group for now, but if we can come up with a consensus on it, that would be great. 21:28:17 s/custom rate control/external rate control 21:28:42 Topic: ManagedMediaSource API 21:28:47 https://github.com/w3c/media-source/issues/320 21:29:50 cpn: We had a lot of Q&A last time, on alternative approaches, e.g. is is media specific or more a fetch-type thing? I know Dale left some comment to talk about some aspects that you think might be problematic: privacy, quality, and some concerns on networking. 21:30:43 ... I'd like to have a clearer perspective on how the group views this. I also realize that we don't have input from Mozilla for now. 21:31:18 ... Some of the discussion reminds me of the early MSE discussion where we have type 1 playback and type 3 playback, and this feels like type 2 playback. 21:32:44 Bernard: One of my questions in reading the spec was to undersand the model. How well the model applies to new network technologies? Is this HLS specific? TCP specific? Would it make sense for RTCDataChannel and WebTransport as well? 21:33:01 marcosc: Is that captured in an issue? 21:33:12 Bernard: That came up tangentially. 21:34:03 marcosc: Jean-Yves' presentation was quite focused on 5G technology. It may be worth asking for clarification about whether that would also work well with RTCDataChannel/WebTransport. 21:34:14 Bernard: I will raise it. 21:34:43 cpn: This could point at a desire to have something common to MSE, WebTransport, RTCDataChannel. 21:35:08 Bernard: Yes, more about the requirements put on the network. 21:35:30 marcosc: As the name suggests, it's about whether things can be managed or not. 21:36:07 markw: Back to type 1, 2, 3, I can think why people may think that, but it's not type 2 here. 21:36:37 q? 21:36:49 ... When it talks about variant selection, is it going to do the selection on my behalf? The answer is no. 21:37:17 ... The term "managed" suggests that someone is managing something. If it's not immediately obvious, naming may not be good. 21:37:50 ... The API is pretty much independent of the transport. 21:38:00 Bernard: Is there an assumption about sleep state? 21:38:22 markw: That's what we discussed last time. Not the intention from last time's discussion. 21:39:18 Bernard: You can request outside of the window but that's not great for battery life. Question is is there something that these technologies need to be doing to make it work great? 21:40:05 markw: To tie things better with networking, you need to go the fetch level, and then to all other the transport APIs to integrate. 21:40:22 ... There has to be some benefit for sites for the API to be seen as useful. 21:41:12 cpn: One suggestion was that network operators could be able to charge differently depending on data types. 21:41:47 Bernard: We did dscp marking in WebRTC and that was not such a success. 21:42:20 cpn: The thing that is interesting is that it really is a hint to the site. User agent could reject but experimentation suggests that it's not needed. 21:43:48 ... If it's get seen as a more generically useful API with people starting to use this as a better networking detection feature and start to use with outside of media. 21:44:17 ... Other groups such as TAG might spot this when they review the proposal. Should we capture this somewhere? 21:44:39 Bernard: I think the topic of sleep in general has been under-evaluated 21:45:09 marcosc: I think it would really be up to us to find such things, as the TAG would likely rely on us. 21:45:50 cpn: Wondering about next step with this. 21:46:00 ... We want to hear back from Mozilla. 21:46:09 marcosc: Have we asked for a standards position from Mozilla? 21:46:27 ... Also good to post questions raised here in the issue. 21:47:19 ... Before the thread gets too big, it would be good to bring people you may have in mind in. 21:48:16 [People from Mozilla mentioned: Jan-Ivar, Paul, Randall Jessup, Karl Tomlinson] 21:48:42 Dale: It'd be helpful to update the explainer with resolution of some of the comments in the issue. (I.e., removing language around UA being able to stall out) 21:48:44 s/Paul/Paul Adenot 21:49:31 marcosc: That's a good point 21:50:55 Topic: WebCodecs 21:50:58 Subtopic: Should VideoEncoderConfig cloning remove parameters that are not useful for a given codec? 21:51:01 https://github.com/w3c/webcodecs/issues/681 21:51:48 eugene: From Chromium side, we agree with Youenn. I think we should be cloning the whole configuration (as said in the spec). We should make the spec explicit that everything gets cloned, even if the parameter is not doing anything. 21:52:03 ... The second thing is to file a bug against Chromium to fix the implementation. 21:52:17 ... I don't think Youenn would object, since that's what he proposes :) 21:52:38 cpn: Sounds good! 21:52:48 Subtopic: Registries 21:53:07 cpn: I just wanted to bring issues that were perhaps pending on me to resolution. 21:53:55 ... On the WebCodecs registration itself, the last point of discussion was on whether the registration should have a public specification or not. We left that as "should have", but then you mention possible paywalls. 21:54:22 Bernard: Right. ITU specifications, sometimes you have to pay. 21:55:34 cpn: Should we leave the requirement as it is? Or a requirement that the relevant standard group make the spec available to us on request for possible review. 21:56:41 Bernard: There are a lot of codecs out there. Some are very public. VVC, you can get it for free, but the cut-down version EVC is behind a paywall. 21:57:03 ... In practice, it's easy to get a copy. 21:57:30 ... We were having a similar issue in Payment Requests. 21:58:30 ... Chris mentioned a policy for evaluating normative references that somewhat forbids that. 21:58:41 https://github.com/w3c/webcodecs/pull/693 21:58:48 marcosc: Right, but that's a registry here. I don't see that as a blocker. 21:59:11 cpn: Something that we're going to see happening a bit more frequently. 21:59:26 scribe+ cpn 21:59:44 Francois: The policy was written at a time when registries didn't exist 22:00:20 cpn: The reference was because we were discussing the notion of "stable" 22:00:54 ... I'm hearing that there's not necessarily an issue with us having a link to a spec behind a paywall. 22:01:40 marcosc: And it's a human-evaluated list of points that get checked. Not a hard list of requirements. 22:01:53 cpn: OK, I'll prepare a new PR then. 22:02:03 RRSAgent, draft minutes 22:02:04 I have made the request to generate https://www.w3.org/2023/07/11-mediawg-minutes.html tidoust 22:04:45 RRSAgent, bye 22:04:45 I see no action items