Meeting minutes
<marcos> CN: there's a lot to cover, charter, quoted exceeded error, etc.
Charter renwal
<cpn> Here's the draft charter https://
FD: charters last a few years, our is expiring at the end of May. We have a few months, but we should decide if we want to add new deliverables.
FD: I personally don't have any suggestions for things to add, but invite others to consider additions to the charter
CN: there's nothing new that I have personally heard of being added
Eugene: There's been talk of things that haven't been added in the past, but now might be an opportunity
<xhwang> Can we have the link to the current draft again? Sorry I probably missed it.
FD: Speech recognition could be a thing we could consider adopting, perhaps, but I believe the plan is for the Audio Working Group to adopt it.
XW: at TPAC we discussed licensing support. We are still debating internally... we are considering EME feature detection and CNC (?) could be a thing to maybe include.
??: We might want to get some representation from other implementers looking at the charter
CN: We should be very specific about the areas we focus on. I remember stuff around CNC feature detection, but I would need to refer to the TPAC minutes.
XW: Google might want to push forward with the licensing proposal, as we have something concrete we would like to propose
<xhwang> continuous key rotation: w3c/
CN: continuous key rotation, transitioning from unencrypted to encrypted content, etc. it might not hurt us to include it in the charter, even if the MPEG stuff is not ready
CN: It's more that if we anticipate starting work on this over the next two years
??: there's nothing really new on the EME, just clarifications for how data is passed around and packets are encrypted \
??: I don't know the legalities around the charter as it relates to EME and the Media WG
CN: It's complicated. We need to focus on particular features as they would related to web codecs and EME. But it would be good to be explicit in the charter.
??: if it in the charter, does that mean the WG need to commit to it?
CN: no, it doesn't commit the WG
??: so yeah, it might be good to include something in the charter around EME and web codecs
FD: There was previous case where we did remove stuff from the charter that we didn't end up working on
FD: for EME stuff, we need to very precise about what we are doing to work on. MSE is in scope though, so we probably don't need add too much. The scope part just needs to be broad enough so that we know what we are going to work on.
XW: I see your point, particularly around EME.
CN: The approach is that it needs to be very explicit around EME. But it may be that the community is more relaxed around it.
XW: I just want to make sure we have enough scope in case something comes up. But we don't have a lot of things to work on right now. Just want to make sure we don't exclude any interesting discussion in the future
MF: for the rechartering, we will need to update a lot of dates for the deliverables. How do we go about updating those?
FD: The editors and implementers would provide some dates. In practice, I sometimes propose some dates. The dates are aspirational, and it would be great if we stick to them. However, we are flexible on the dates.
MF: I can propose some dates
CN: I'm reading the charter, and yes, some of dates are a bit questionable.
CN: We won't be held to these time scales, but we should try to be realistic
Eugen: I edit web codecs, so what dates need to be updated?
CN: so for web codecs, we said we would be in CR at some point last year. So in theory we can look at the issues list and make a guesstimate on how long it will take to resolve those issues
Eugene: I can go through the list and see if I can come up with a guesstimate
CN: under potential normative specs, we've listed anything that goes into out registries and also data queues. We haven't done anything with data queues, but I suspect there's still interest. We should maybe leave that in the new charter.
CN: two next steps. All editors and interested parties not on the call to review the timelines. Also if there are any EME changes, please send a pull request.
<markafoltz> Recommendation track from the W3C Process Document: https://
CN: I think that anything on chartering. FD?
FD: no. But we need to move fairly quickly on this because of the short amount time we have.
Web Codecs
CN: I noticed you put a comment in around orientation into the codec and throw in there is a change in orientation. I haven't looked at the discussion? Is that consistent more reason proposal that Dan had proposed.
DC: I was trying to go with the least breaking change. I was thinking to propose some spec text and see what Paul says
EZ: We don't have precedence for throwing
DC: It does already throw, if frame is closed for example
EZ: But this shuts down the encoder?
DC: The way I propose, it doesn't throw away the entire state, you give a new keyframe to keep going. Resubmit the frame and continue as normal
CN: What's the behaviour today?
DC: There's no orientation data exposed today. We use it internally at composition time
… When we turn on the feature, if there's orientation data, they'll get the data that affects the decoder output in some way
… We want to do the easy thing, not reorientate the video frames themselves, but pass the orientation data
… We could add video config, but that didn't seem to get any interest at the time
EZ: Use case is capturing from a phone, turning it sideways, then the video comes out the wrong way. So it signals to the app to reconfigure the encoder
CN: Sounds like DC's proposal to create a PR we can review makes sense
QuotaExceededError in MSE and WebCodecs
CN: It's proposed to change this across the platform. Is this a safe change to make for WebCodecs and MSE users?
EZ: It's adds two new fields, those are optional. So WebCodecs at first won't populate them. It's a cosmetic change to the spec. UAs will need to make the change in their codebase to throw the right class instance
… It doesn't bring anything useful for us, but if it's a web platform wide refactoring, I don't see a need to object
DC: If it's just a cosmetic change, MSE should be fine - but could be issues if it's observable
EZ: People testing the normal way will be fine. But there are more sophisticated ways to check but IMHO people shouldn't be doing that
CN: I saw they surveyed open source projects in GitHub
DC: Big video sites would notice quickly
CN: So seems we don't need to worry too much
Media Capabilities tests
FD: Mark has created some tests and I've reviewed them
MF: This was a follow up to earlier discussion where we updated the spec to define acceptable and non-acceptable video and audio configs
… Chris added some test cases to understand current browser behaviour and increase coverage
… Those were primarily for the "file" type of encoding and decoding
… There were still gaps with the webrtc use cases
… This PR exercises the same cases for webrtc as for file. The goal is to understand current browser behaviour and then update the spec accordingly
… We need to figure out if the same rules should apply for validating audio and video configs for webrtc and file
… A couple things about the PR. There's a number of test cases that check if a string framerate is possible
… I looked into it. An earlier version of the spec allowed strings, but the current spec doesn't
… Is string still a valid input for browsers? I don't think it is. So we could remove the test cases, as anything not a double should generate an error from the IDL bindings
CN: Motivated by fractional frame rates?
MF: Yes. There's a PR from 2017 changing framerate from double to DOMString, so it could be expressed as a fraction
… Not in current spec, and also not what Chrome does
… If other implementations support strings, could leave it in. Otherwise I can remove the tests
CN: What do current test results show?
MF: Looks like all the browsers pass, so should be safe to remove
… The other comment I have, is after this lands there's a lot of duplication between the test cases
… For maintainability, it makes sense to remove duplication, so I was proposing to create a library of validation test cases, running in different combinations for encoding/decoding and webrtc/file
CN: Makes sense to me
FD: The spec has nuances depending on if it's file or webrtc, e.g., on HDR support
MF: So the things that aren't dependent on the type would be shared
… And the spec might not define what should happen if you ask for HDR in webrtc for example
… I don't think anything blocks landing the PR, once FD's comments are addressed
CN: Depending on the results, we can see if there are spec or test or impl issues
Next meeting
CN: I'm not available on 8 April, should we reschedule?
MC: I'm also not available, at a conference
CN: So suggest putting back a week?
MF: Works for me