Meeting minutes
Welcome Marcos as new co-chair
cpn: The Media WG is rechartered for the next two years.
… Change of chair as part of that. Welcome Marcos!
Marcos: Been doing standardization for a number of years. Chair the WebApps WG and WICG.
… Fluent in W3C process.
cpn: I'd like to thank Jer so much for chairing the group over the past few years!
TPAC agenda planning
<cpn> w3c/
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.
… I'd like spec editors to work with the chairs to help us compose the agenda.
… We'll be following up with you via email.
… I'd like that to be pulled together over the next few weeks or so.
… We can spend time on each of the specifications in the group.
… Aside from our own group, we have a joint meeting with WebRTC WG, on Friday afternoon for 2 hours.
… WebRTC people tend to drive the agenda of such meetings, but happy to help as well.
Bernard: Jan-Ivar and I came up with a number of topics today.
… Questions related to use cases: do we know what use cases are? Do we cover the use cases we're aware of?
… We have a use cases document.
… But still un-satisfying.
cpn: We setup a dedicated repo last year on joint topics.
Bernard: That's right, and we did write some code.
… Does not cover all use cases.
… 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.
… I think we have a better perspective on some of the pipeline issues, e.g. with WHATWG Streams.
… The meeting is close than you may think, as people are going to go on holidays soon.
… Some of the questions that came up: ManagedMediaSource and WebTransport or RTDDataChannel as transport.
… Audio and MediaStreamTrackProcessor, whether that works well for audio/video synchronization.
… Third one is setMicrophoneActive and w3c/mediasession#279. Can we add some UA guarantees (might require solving the double mute problem)?
gb, bye
Bernard: Also some questions around color space support.
cpn: I can reach out to Color on the Web CG people. Not sure who is going to be present at TPAC.
Bernard: Each of these topics is a potentially long discussion.
cpn: That seems like a good basis for discussion for the joint meeting.
… 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.
… Happy to take suggestions from editors on that.
eugene: How to integrate external rate control in RTC-based scenarios.
Bernard: This one is a big one. I might be able to find someone for this.
… Possibly Philipp Hancke.
… It might be a joint meeting thing.
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.
… Is it worth allocating time for EME?
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.
<tidoust> s/gregwithworth/gregfreedman/
cpn: For other specs, we'll follow up with the relevant folks.
… If there's anything else that you'd like us to include, let me know.
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.
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.
ManagedMediaSource API
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.
… 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.
… 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.
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?
marcosc: Is that captured in an issue?
Bernard: That came up tangentially.
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.
Bernard: I will raise it.
cpn: This could point at a desire to have something common to MSE, WebTransport, RTCDataChannel.
Bernard: Yes, more about the requirements put on the network.
marcosc: As the name suggests, it's about whether things can be managed or not.
markw: Back to type 1, 2, 3, I can think why people may think that, but it's not type 2 here.
… When it talks about variant selection, is it going to do the selection on my behalf? The answer is no.
… The term "managed" suggests that someone is managing something. If it's not immediately obvious, naming may not be good.
… The API is pretty much independent of the transport.
Bernard: Is there an assumption about sleep state?
markw: That's what we discussed last time. Not the intention from last time's discussion.
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?
markw: To tie things better with networking, you need to go the fetch level, and then to all other the transport APIs to integrate.
… There has to be some benefit for sites for the API to be seen as useful.
cpn: One suggestion was that network operators could be able to charge differently depending on data types.
Bernard: We did dscp marking in WebRTC and that was not such a success.
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.
… 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.
… Other groups such as TAG might spot this when they review the proposal. Should we capture this somewhere?
Bernard: I think the topic of sleep in general has been under-evaluated
marcosc: I think it would really be up to us to find such things, as the TAG would likely rely on us.
cpn: Wondering about next step with this.
… We want to hear back from Mozilla.
marcosc: Have we asked for a standards position from Mozilla?
… Also good to post questions raised here in the issue.
… Before the thread gets too big, it would be good to bring people you may have in mind in.
[People from Mozilla mentioned: Jan-Ivar, Paul Adenot, Randall Jessup, Karl Tomlinson]
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)
marcosc: That's a good point
WebCodecs
Should VideoEncoderConfig cloning remove parameters that are not useful for a given codec?
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.
… The second thing is to file a bug against Chromium to fix the implementation.
… I don't think Youenn would object, since that's what he proposes :)
cpn: Sounds good!
Registries
cpn: I just wanted to bring issues that were perhaps pending on me to resolution.
… 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.
Bernard: Right. ITU specifications, sometimes you have to pay.
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.
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.
… In practice, it's easy to get a copy.
… We were having a similar issue in Payment Requests.
… Chris mentioned a policy for evaluating normative references that somewhat forbids that.
<cpn> w3c/
marcosc: Right, but that's a registry here. I don't see that as a blocker.
cpn: Something that we're going to see happening a bit more frequently.
Francois: The policy was written at a time when registries didn't exist
cpn: The reference was because we were discussing the notion of "stable"
… I'm hearing that there's not necessarily an issue with us having a link to a spec behind a paywall.
marcosc: And it's a human-evaluated list of points that get checked. Not a hard list of requirements.
cpn: OK, I'll prepare a new PR then.