Meeting minutes
Survey on registries
Issue #26 Group registries survey
Francois: W3C process isn't good on registries. MSE and EME have accompanying registries
… They've been published as WG notes
… This is a non-normative spec, as a list of things
… Different groups do different things with registries, Rec track may not be a good fit
… Registries need to change once in a while. Looking at changing the process to accommodate registries
… We want feedback from groups
… The GH issue asks a few questions, so I'd like feedback from this group
… You can contribute to the W3C Process CG directly individually
… Is there a need for a CR phase for registries. If the registry is just a table of entries, is it enough to go ahead and skip the CR phase?
ChrisC: If we were to pursue CR for registries, what's the process for updating the registry beyond the lifetime of the group charter?
Francois: The process accommodates that now better than before. When a WG published a doc, we'll keep the WG around in a dormant mode, and the WG can update the document as needed
… If the WG is no longer around, W3C itself can update it on request
ChrisC: It's unclear if you'd need to go to Rec again
Francois: Do we need an easy path to update the Rec? We simplify the process by skipping CR without requiring wide review
… My own feeling is that CR doesn't necessarily need a CR phase
ChrisC: That resonates with me. I anticipate creating a registry for Web Codecs, similar to the MSE byte stream registry
… I don't see a benefit to adding more process
Francois: I'll select the "Registries do not need a CR phase to experimentally validate the Working Draft before requesting AC approval." option
Francois: How should patent policy apply to registries? Should there be a separate track for registries?
ChrisC: I don't have legal experience to answer that. For Google, maybe a lawyer would weigh in on the importants of patent inclusion for registries
Francois: If the group doesn't feel it can give a view, I'll select "no opinion"
Francois: Next, registry definition tables. In some cases the defintions are separate from the table. Or should we prefer to keep them together?
Jer: The EME and MSE examples have a document that points to other documents. Is that what you mean?
Francois: It's more about the definition of the column headers
Jer: I wouldn't want to pull the entire content of the registry into a single document
Francois: You could keep the requirements for the entries in the registry document
… I saw this as about linking to a real rec-track spec with the requirements
Jer: Makes sense to me
Francois: I suggest we wouldn't use this
… If you're all OK, I'll reply to the survey and forward on your questions
Web Codecs call for consensus
Mounir: I want to check in if anyone wants to discuss this
… The CfC is to move Web Codecs to the Media WG
… and make a FPWD
cpn: Do you feel that the incubation phase has achieved the overall goal of shaping the spec?
Mounir: We asked the editors, their feedback is that there would be no expected change. The main use cases: video playback and communication use cases are well understood
… We have less feedback on gaming or advanced audio processing, e.g., Ableton type software
… We anticipate this won't change the API shape significantly
ChrisC: I agree with that. There's a number of open questions in GH, but the skeleton the API with video encoder and decoder are pretty stable
Mounir: I believe Chrome has an origin trial, which is a sign the incubation phase is ending
ChrisC: Below all the codec interfaces is VideoTrackReader. There's an issue to deprecate this in favour of the media stream processing track, a separate spec incubated by the WebRTC WG
… Conceptually its the same, you get audio and video frames. Their API shape was better, you can find out more in the GH issue
Francois: If the CfC passes, I'd like to know what you think about keeping the document in /TR synchronized with the editor's draft. This can now be automated
… Some groups don't like that, but others do. It affects Web Codecs, but also other Media WG deliverables
ChrisC: I support keeping them synchronized
Mounir: Don't we already do that for our other specs?
Francois: I may need to check for a previous resolution
… For MSE and EME we haven't published anything yet under the Media WG
Mounir: It would be good to have a group position instead of doing it per-spec
Jer: We could raise this on a GitHub issue to have the discussion
AOB
Mounir: Anything else for today?
ChrisC: Media Capabilities spec has an issue and PR open to add WebRTC encoding and decoding info
… This has been discussed with the WebRTC WG, they're supportive. I'm supportive
… I'll go ahead and land that PR tomorrow. If anyone has comments on the GH issue, please do so
Mounir: I'm excited to see this. Want to initiate privacy review
ChrisC: I've added security and privacy considerations to Web Codecs spec. As we're gearing up to ship during the summer, I'd encourage all the user agents to raise concerns and give feedback
cpn: Question about Media Capabilities and WAVE project, any further progress?
ChrisC: We last spoke in December, some questions about whether the issue raised about CMAF was really an issue.
cpn: So it's with them to follow up
ChrisC: I'm ready to discuss further on that topic
Jer: The WAVE project is defining a docuemnt the CMAF specs to Media Capabilities. MC offers queries that CMAF can't meet in the format itself
… There's a bitrate field they can't fill out yet. There's some work they'll need to do, and if they find issues that can't be resolved in the mapping document, they can bring to the Media WG
Mounir: Anything else?
[adjourned]