21:01:05 RRSAgent has joined #mediawg 21:01:09 logging to https://www.w3.org/2026/03/10-mediawg-irc 21:01:10 Zakim has joined #mediawg 21:01:43 Meeting: Media WG 21:02:06 Agenda: https://www.w3.org/events/meetings/c9ec8dca-c745-49c6-b2b4-d635e6ecdbbb/20260310T140000/ 21:03:12 Present+ Chris Needham, Will Bamberg, Francois_Daoust, Marcos_Caceres, Mark Foltz, Eugene_Zemtsov 21:03:18 Chair: Chris, Marcos 21:03:21 scribe+ cpn 21:03:35 Mark_Foltz has joined #mediawg 21:03:51 present+ Jer Noble 21:03:52 Present+ 21:05:08 scribe+ tidoust 21:05:22 present+ Gabriel Brito 21:05:31 Topic: WebCodecs Extended HE-AAC registration 21:05:33 present+ Jean-Yves Avenard 21:05:55 Marcos has joined #mediawg 21:06:01 cpn: We received a letter from the MPEG Audio Coding working group. 21:06:23 ... The letter is asking for an adjustment to the AAC WebCodecs registration. 21:06:35 ... They would like to add extended HE-AAC. 21:06:48 ... The letter contains suggested changes. 21:07:04 ... They say that the codec is well supported across browser implementations. 21:07:17 ... They ask what next step they should take. 21:07:48 ... Dale replied that it looks good, seems supported in Chrome and Safari, perhaps in Firefox too. 21:07:57 ... It seems uncontroversial to add this to the registration. 21:09:13 ... I suggest we respond that we're happy to add this. 21:09:22 ... Is somebody willing to prepare a Pull Request? 21:09:54 Eugene: I can prepare the pull request, no problem. 21:10:08 Topic: WebCodecs Guides / Better WebCodecs documentation 21:10:40 present+ Scott Kidder, Jordan Bayles 21:11:05 Francois: MDN received a proposal from someone writing WebCodecs document, suggesting adding better docs 21:11:27 ... WebCodecs needs people to know the API, and MDN people might not be able to review 21:12:37 Will: A contributor started the discussion, volunteering to write about WebCodecs. They maintain webcodecsfundamentals.org 21:13:04 ... They're interested to write learning documentation. AFAICT MDN has comprehensive reference docs for WebCodecs, but there are no guides for it 21:13:14 ... Which means it's hard for people to learn, using MDN 21:13:46 ... It looks good, they listed a set of pages they're thinking of writing. Might be ambitious, so could ask them to prioritise and intro and conceptual basics 21:13:54 ... That would be on par with other MDN guide docs 21:14:16 ... What we can do from the docs side is editorial review: make sure it's clear and logical sends, and appropriate for the audience 21:14:28 ... We can help them integrate into MDN 21:14:38 ... But we don't have expert technical knowledge 21:15:06 ... So we could benefit a lot from expert help. Initially, helpful to have a look at webcodecsfundamentals.org to see if that looks good 21:15:31 ... If that looks promising, review PRs for how you want people to use WebCodecs 21:16:14 Eugene: I just had a look at it, looks relatively high quality 21:16:52 ... Dale and I wrote the original docs, so we shouldn't ignore community contribution. Can you me to the PR and discussion? 21:17:06 ... I can review for factual correctness, good to accept these contributions 21:17:36 Will: I had a similar concern about whether it's AI generated, but it doesn't appear to be. 21:18:08 Eugene: I'm @djuffin on Github 21:19:06 Chris: He also has some open source libraries, so has hands on experience 21:19:33 Topic: Media Source Extensions 21:20:44 cpn: Idea is to go through issues to triage 21:21:36 ... [shares list of issues on GitHub] 21:21:57 ... Last time we did an issue triage was a while ago. 21:22:19 ... Going backward, starting with #371. 21:22:49 -> https://github.com/w3c/media-source/issues/371 21:23:07 ... About support for MediaSource in SharedWorker. 21:23:51 Eugene: We had started an exploration a while ago in Chromium. I don't think there's much interest right now to prioritize this. 21:24:03 Jean-Yves: It creates some security challenges. 21:25:37 cpn: Commenting on the issue about the use case. 21:25:55 ... I understand that resources to work on MSE are constrained. 21:26:28 ... I hope we can progress the spec. We added ManagedMediaSource, that requires more implementations. 21:26:41 cpn: Next one is #370. 21:26:45 -> https://github.com/w3c/media-source/issues/370 21:27:22 ... BufferedChangeEvent members should be nullable. 21:27:58 Jean-Yves: Marcos made me make the entire constructor optional. I don't know if it makes sense to have an event without any of its content. 21:28:58 Marcos: There's weird machinery in place for events. It assumes that the attributes and the dictionary members align. 21:29:41 ... If you make them optional with default values, you may end up with something that works. 21:30:03 cpn: There's a bunch of related issues, including #345 to define the constructor steps 21:30:07 -> https://github.com/w3c/media-source/issues/345 21:30:37 ... From a triage point of view, it feels like something that needs fixing from a spec correctness point of view. 21:30:57 ... We should treat it as a v2 milestone rather than punt it to a future version. 21:31:51 Marcos: Is there anything in the constructor that can make anything throw? That's what we need to look at. 21:32:40 cpn: Adding v2 milestones to some of these issues. 21:34:17 cpn: Looking at #369. It seems to need some analysis. There may not be a problem, but we need to figure that out. 21:34:18 -> https://github.com/w3c/media-source/issues/369 21:34:35 ... If it's helpful, we can invite more clarification from the people who raised the issue. 21:35:14 cpn: next one is #367 21:35:17 -> https://github.com/w3c/media-source/issues/367 21:35:49 ... This is about when you call endOfStream() but there's no end streaming event. 21:36:17 ... There's been some follow-up here on whether that's an implementation issue. 21:36:25 Jean-Yves: I don't think a bug was raised. 21:37:01 ... You just indicated that you don't plan on adding more data. Say you have a gap, that video will stall regardless because you're not going to add any more data. 21:37:30 ... The streaming state is strictly based on whether you have content to play. 21:37:51 ... Your currentTime is in a location where the buffered range indicates that there is no content to play. 21:38:11 ... I don't think the end of stream and streaming are related from a logical perspective. 21:39:18 ... The problem is that the ended state is not a final one. The end of stream is just a hint that you don't plan on adding more data. 21:39:30 ... Why would you call that if you plan on adding more data? 21:40:28 ... If the buffered range has been cleared after you've reached the end of stream and you seek back to the beginning, I would expect to have a need more data event fired. 21:40:40 ... I would suggest to close this with nothing to do. 21:41:00 cpn: You're saying that you can call endOfStream() but that does not prevent you from appending? 21:41:34 Jean-Yves: That's correct, it changes the status to ended, but if you call append again, it will switch back to open. The ended state can be reached multiple times. 21:42:07 ... You can check the currentTime and the buffered ranges. 21:43:03 ... Let's say that you're playing, you stall, because underlying buffered range is empty. Now you call endOfStream(), it's still empty. 21:43:10 ... But you still need more data. 21:43:55 cpn: Could you comment to bring the issue to closure, summarizing that we don't think that an update is needed? 21:43:59 Jean-Yves: OK. 21:44:37 cpn: #365 is another end-of-stream related issue. 21:44:47 -> https://github.com/w3c/media-source/issues/365 21:45:34 ... The issue is about integration with HTML spec algorithms. 21:45:54 ... I ended up raising an issue against the HTML spec. 21:46:26 ... If you follow the steps through, you don't know where to return the point to. 21:46:43 ... I seem to have assigned that to myself, I'll have a look at some point! 21:47:22 cpn: Moving on to #364. 21:47:26 -> https://github.com/w3c/media-source/issues/364 21:48:32 ... Basically, we have things that may be running in parallel and that may be aborted. What should happen in such cases? 21:49:04 ... It does feel like there's a bug that would benefit from fixing the spec. 21:49:16 ... Anyone inclined to take a look at this? 21:51:36 Jean-Yves: We should add abort range removal after step 2.1. 21:52:56 ... Step 5 of the appendBuffer() algorithm says that the steps run asynchronously. 21:53:35 ... Step 11 of removeSourceBuffer() is to destroy all resources, so it won't end up in an inconsistent state. 21:54:14 Marcos: Aborting steps that run in parallel should have some linking mechanism. We might not need it. 21:54:36 Jean-Yves: I would expect that these will have been queued serially, so one runs after the other. 21:55:25 Marcos: Avoiding stomping on each other is what we need to check. But maybe that hasn't triggered any interoperability issue and we don't need to rewrite things differently. 21:55:37 cpn: Right, it's just me trying to make sense of the contents. 21:56:53 Jean-Yves: Maybe editors should go over the issues and do their job... That would be me. 21:57:17 ... Maybe organize a side meeting to go over those that does not require the whole WG to attend. 21:57:36 cpn: That seems good. I'm happy to facilitate that. 21:58:14 cpn: Last issue I wanted to discuss is #355 21:58:21 -> https://github.com/w3c/media-source/issues/355 21:58:57 ... Do we want to suggest a recommended approach? 21:59:54 Jean-Yves: If you query with Media Capabilities on iOS, answer will be no, because there's no support for MediaSource. If you query through ManagedMediaSource, answer will be yes. 22:00:47 ... At this stage, isTypeSupported lets you define which object you want to test. But Media Capabilities does not have this level of distinction. 22:00:58 ... I should open an issue against Media Capabilities. 22:01:35 ... It will also tell you whether ManagedMediaSource is supported or not. 22:02:02 cpn: Please raise this issue to continue the discussion. 22:02:37 RRSAgent, draft minutes 22:02:38 I have made the request to generate https://www.w3.org/2026/03/10-mediawg-minutes.html tidoust 22:02:53 RRSAgent, make logs public