Meeting minutes
Intro
cn: Welcome everyone ... we have a few EME issues to discuss amongst other things. Some TPAC planning.
Joey: do we have more details around the agenda?
cn: not yet... we are building up the agenda at the moment and looking for suggestions
Joey: folks need details before to get permissions to attend so it would be good to have some details
Calls for Consensus
Publication request for WebCodecs VideoFrame Metadata Registry
cn: we had a few "CFC" running. We are interpreting no responses as approval.
cn: For the Publication request for WebCodecs VideoFrame Metadata Registry, it has passed
cn: we have potentially another item to add to that we will come back to
cn: publish EME2 as FPWD is the second. We've done all the items we needed to get to that stage, including the HDCP registry.
cn: third is MSE.. main changes are updated to reflect these are in our working group, updates to the editors, etc. We invite folks to have a look. But we have the formalities to publish out of the way
EME
cn: There's a discussion around the robustness string. If you look at the text in the spec, we have normative requirements in a note. We should move those out of the note. I was wondering why it was drafted like that? It seems it was approved in the original draft. Can we make those notes normative? or edit those things if so their are either
… normative or not
Joey: I don't remember the why, but I can see why it's problematic. I recall there was discussion but we should fix that.
cn: we should discuss how robustness is achieved. How should we spec this/
Xiaohan: respecting it might be hard, because the spec has been around for a long time. We probably want to move some of the text around. Around number 3 is the most controversial... but it leaves a lot of ambiguity. If it's so flexible, then why should it be in the spec. So, the current text doesn't restrict anything.
Joey: this is probably why it was in a note
<cpn> Proposal: Include point 1 as normative in the spec. Include point 3 as a note. Remove point 2 altogether.
cn: next question was around interop. Jer do you have any thoughts?
jn: we don't make any use of robustness, so no opinion
Joey: the previous spec does prevent the user agent from using a higher security level. Greg's point point was that in reality, the hardware DRM will be more secure than the software DRM.
Joey: if one says software DRM or hardware DRM, the developer should be in control. But that would mean changing the semantics of the spec
Xiaohan: it would be good to have some rule in the spec that always use the lowest level that is available. That would require a change in the spec
joey: is there any objections to changing the spec to support something like the above
… if we added that rule, it wouldn't mean a particular user agent would adopt it. We would need to get consensus amongst agents and libraries
Xiaohan: if we change the spec, and we get consensus it will likely take many years.
Joey: so the proposal is if we allow developers to say "use the lowest level available"... I'll update the GitHub issue
cn: there's a follow on issue. We have lots of notes with normative requirements. We need to review all the notes and come back with PRs to fix those things.
cn: after we do the publication, we should kick off wide review. We need to do our own self reviews.
cn: before we ask review from other groups... so we should do that and then kick off wide review
cn: we have made some incremental additions to the spec - but given how much scrutiny the spec got initially, we have a good set of privacy / security review already. So we can focus on the new features and pull everything together
cn: and then we can fill out the questionnaire
cn: then we have a bunch of issues tagged for the V2 milestones
cn: are there other spec modernization things we want to do. Things like how eventing works, using the right task sources, etc. There's v3 milestones soon. We should maybe tackle those at the CR stage
cn: at that point we can produce and implementation report from there. The number of issues is relatively small thankfully. But we really need to get the horizontal review done
cn: I wanted to share that with you as the general plan
cn: we will need people's help to do all this with EME
fd: I added a change log section to eme outlining what's new.
cn: thank you for doing that.
Web Codec
cn: video frame metadata. We have new proposal for background segmentation mask
cn: for example, blurring background... coming from the WebRTC folks
cn: there's an extension to the VideoFrameMetadata dictionary using an image bitmap
cn: unfortunately the person proposing is couldn't join us today
cn: but would love to hear your thoughts. As we own the registry, we need to approve the entry
Eugene: This feature seems useful. ImageBitmap is anything tht can be drawn on a canvas. so that's the only thing they can do, then look at Canvas to see what happened
… It used to be VideoFrame, which was suprising. ImageData may make more sense, for use on Canvas and also the mask values could be accessed directly
… You could query the data for the transparency (background confidence). Right now the only thing you can do is draw to a Canvas and read back
Mark: The exact type exposed to the app depends on what the app wants to do, e.g., incorporate into a WebGPU/GL pipeline
… I'd want to be able to provide feedback on that before incorporating into WebCodecs
Bernard: Similar concerns to Mark and Eugene. Not sure can be implemented in a performant way. It would require multiple copies per VideoFrame which would be a problem
… I like that we're discussing the architectural. It may be early, not sure we have WG consensus in WebRTC, but good to get your expertise here
… What would be needed is high performance
cn: that's a good point about this being an early proposal
Bernard: but it's great that we are discussing this at this early stage
Bernard: I'd want to do it so that there are no memory copies
[ Back to EME, reviewing the commit history, it seems that the use of a "non-normative note" for robustness was done *on purpose*, see: w3c/
TPAC
fd: going quickly back to EME, there was a historical rational as to why those normative statements where in notes
cn: there's only the times we have allocated at this stage. On Monday, the immersive web WG want to meet with us. They are working on the HTML model element, and want to our feedback on how it relates to it being a "media element". It's an architectural question.
cn: there's an number of meetings on the Thursday
cn: we have some slots open on the Thursday for topics we want to advance. We are looking to the editor as to what to cover. We have joint meeting with WebRTC... plus Friday morning. We will be putting forward more agenda topics closer to the date
bernard: Eric wanted to talk about the new encoding apis... that will require some significant amount of time. Eugene anything you would like to cover at TPAC?
Eugene: no suggestions right now
bernard: surround sound is coming up a bit
cn: we might want to spend some time on MSE
cn: Marcos do you have any thoughts on topic for MSE
mc: not right now
cn: it occurs to me that we have managed media source and the worker story... and what's the interop story is around those. There was also a web codecs integration point that we should probably talk about .
cn: I'll leave it for you all to suggest so we can use the time effectively. There's also web codecs and HDR, and integration with web gpu, etc.
cn: in terms of making having a clear agenda, how quickly would folks need that?
cn: for travel plans that is
joey: I don't think it should be an issue to travel etc. but it's good to have agendas ahead of time in case folks need evidence for attendance
cn: that was all I had planned for the agenda
web codecs blocking issues
cn: when should we go through those to move them forward
Eugene: someone needs to step up and do editing work... some of those I could do.
Bernard: which ones are ready for merging... and maybe some can be closed. The editors should propose something
Eugene: we have a label "ready for PR"
Eugene: e.g., 669 is ready for PR
Bernard: some of these ended up on the list because they needed some action
cn: if these need working group time, then please add the agenda label
Bernard: we probably don't need to spend TPAC time on this
cn: I was thinking we should try to cover these sooner in a regular WG meeting
cn: any other topics before we wrap up?
meeting adjourned