Meeting minutes
WebCodecs Extended HE-AAC registration
cpn: We received a letter from the MPEG Audio Coding working group.
… The letter is asking for an adjustment to the AAC WebCodecs registration.
… They would like to add extended HE-AAC.
… The letter contains suggested changes.
… They say that the codec is well supported across browser implementations.
… They ask what next step they should take.
… Dale replied that it looks good, seems supported in Chrome and Safari, perhaps in Firefox too.
… It seems uncontroversial to add this to the registration.
… I suggest we respond that we're happy to add this.
… Is somebody willing to prepare a Pull Request?
Eugene: I can prepare the pull request, no problem.
WebCodecs Guides / Better WebCodecs documentation
Francois: MDN received a proposal from someone writing WebCodecs document, suggesting adding better docs
… WebCodecs needs people to know the API, and MDN people might not be able to review
Will: A contributor started the discussion, volunteering to write about WebCodecs. They maintain webcodecsfundamentals.org
… They're interested to write learning documentation. AFAICT MDN has comprehensive reference docs for WebCodecs, but there are no guides for it
… Which means it's hard for people to learn, using MDN
… 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
… That would be on par with other MDN guide docs
… What we can do from the docs side is editorial review: make sure it's clear and logical sends, and appropriate for the audience
… We can help them integrate into MDN
… But we don't have expert technical knowledge
… So we could benefit a lot from expert help. Initially, helpful to have a look at webcodecsfundamentals.org to see if that looks good
… If that looks promising, review PRs for how you want people to use WebCodecs
Eugene: I just had a look at it, looks relatively high quality
… Dale and I wrote the original docs, so we shouldn't ignore community contribution. Can you me to the PR and discussion?
… I can review for factual correctness, good to accept these contributions
Will: I had a similar concern about whether it's AI generated, but it doesn't appear to be.
Eugene: I'm @djuffin on Github
Chris: He also has some open source libraries, so has hands on experience
Media Source Extensions
cpn: Idea is to go through issues to triage
… [shares list of issues on GitHub]
… Last time we did an issue triage was a while ago.
… Going backward, starting with #371.
cpn: About support for MediaSource in SharedWorker.
Eugene: We had started an exploration a while ago in Chromium. I don't think there's much interest right now to prioritize this.
Jean-Yves: It creates some security challenges.
cpn: Commenting on the issue about the use case.
… I understand that resources to work on MSE are constrained.
… I hope we can progress the spec. We added ManagedMediaSource, that requires more implementations.
cpn: Next one is #370.
cpn: BufferedChangeEvent members should be nullable.
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.
Marcos: There's weird machinery in place for events. It assumes that the attributes and the dictionary members align.
… If you make them optional with default values, you may end up with something that works.
cpn: There's a bunch of related issues, including #345 to define the constructor steps
cpn: From a triage point of view, it feels like something that needs fixing from a spec correctness point of view.
… We should treat it as a v2 milestone rather than punt it to a future version.
Marcos: Is there anything in the constructor that can make anything throw? That's what we need to look at.
cpn: Adding v2 milestones to some of these issues.
cpn: Looking at #369. It seems to need some analysis. There may not be a problem, but we need to figure that out.
cpn: If it's helpful, we can invite more clarification from the people who raised the issue.
cpn: next one is #367
cpn: This is about when you call endOfStream() but there's no end streaming event.
… There's been some follow-up here on whether that's an implementation issue.
Jean-Yves: I don't think a bug was raised.
… 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.
… The streaming state is strictly based on whether you have content to play.
… Your currentTime is in a location where the buffered range indicates that there is no content to play.
… I don't think the end of stream and streaming are related from a logical perspective.
… 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.
… Why would you call that if you plan on adding more data?
… 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.
… I would suggest to close this with nothing to do.
cpn: You're saying that you can call endOfStream() but that does not prevent you from appending?
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.
… You can check the currentTime and the buffered ranges.
… Let's say that you're playing, you stall, because underlying buffered range is empty. Now you call endOfStream(), it's still empty.
… But you still need more data.
cpn: Could you comment to bring the issue to closure, summarizing that we don't think that an update is needed?
Jean-Yves: OK.
cpn: #365 is another end-of-stream related issue.
cpn: The issue is about integration with HTML spec algorithms.
… I ended up raising an issue against the HTML spec.
… If you follow the steps through, you don't know where to return the point to.
… I seem to have assigned that to myself, I'll have a look at some point!
cpn: Moving on to #364.
cpn: Basically, we have things that may be running in parallel and that may be aborted. What should happen in such cases?
… It does feel like there's a bug that would benefit from fixing the spec.
… Anyone inclined to take a look at this?
Jean-Yves: We should add abort range removal after step 2.1.
… Step 5 of the appendBuffer() algorithm says that the steps run asynchronously.
… Step 11 of removeSourceBuffer() is to destroy all resources, so it won't end up in an inconsistent state.
Marcos: Aborting steps that run in parallel should have some linking mechanism. We might not need it.
Jean-Yves: I would expect that these will have been queued serially, so one runs after the other.
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.
cpn: Right, it's just me trying to make sense of the contents.
Jean-Yves: Maybe editors should go over the issues and do their job... That would be me.
… Maybe organize a side meeting to go over those that does not require the whole WG to attend.
cpn: That seems good. I'm happy to facilitate that.
cpn: Last issue I wanted to discuss is #355
cpn: Do we want to suggest a recommended approach?
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.
… At this stage, isTypeSupported lets you define which object you want to test. But Media Capabilities does not have this level of distinction.
… I should open an issue against Media Capabilities.
… It will also tell you whether ManagedMediaSource is supported or not.
cpn: Please raise this issue to continue the discussion.