Meeting minutes
Post TPAC
CN: great to see everyone
CN: Currently catching up after a week off
CN: I've got two things on the agenda today... looking at media capabilities, with a summary of where we are - with a breakup of issues between long term and short term. There was also an MPEG meeting which I'd like to touch on.
Media Capabilities
CN: What we have in the issue tracker is V1 and V2 labels. V1 is what the WG thinks fit into the current spec development cycle. V2 are features that are currently aspirational, but we could include then in the current CR. So I'd like to figure out the relationship between V1 and V2 and what we need to triage.
CN: If we look at the open PRs, we have the V1 labelled. I've prepared a PR for the MIME Types registry - which goes to our main media type registry. There are still references to the RTP - for the registration requirements.
CN: If you are all comfortable with this, I'd like to merge this.
MF: would you like a final review for typos etc.
CN: yes, please.
BA: The RTP references might need updating because we have closed on of the registries.
BA: we are just telling everyone to use the actual MIME Type registries
CN: Should we drop the reference?
BA: I would drop it
CN: What about 6838?
BA: That one is fine... that's the main IANA registry
CN: Great, then I will drop the reference to the RTP registry
CN: There was a suggestion of how we describe variable bit rate and constant bit rate. We should look at if this changes implementations
MF: I'm happy to review it and check if we need implementation feedback
BA: That change seems useful to me from a developer perspective
MF: the details may be codec specific, but can at least look at the text.
CN: I haven't summarized the change. But if folks can have a look, that would be great
CN: For KeySystemAccess...
<cpn4> w3c/
MF: This one copies the decoding query to the EME structure. do we need to set defaults for these or are they provided by EME. We got some feedback already around that already, and it should be ready to land.
CN: this one is about adding WebRTC info to Media Capabilities Info
BA: this currently needs a sync api to do a bunch of things. This is why the PR provides a one shot solution to solve that particular problem.
CN: has anyone implemented this?
AB: Not sure. Not in chrome. We will need to follow up with Youenn
CN: it seems there was some convergence on what was being discussed there.
AB: Eric gave a talk on the Discovery encoder API, and that's what they were more interested in
CN: We can check in with Youenn on this. We should get feedback from other implementers
CN: it also occurs to me that it returns a lot more information. Does this make things worst from a privacy perspective
BA: with web codecs, you can already get all this information you need by hashing a frame
BA: so, this doesn't make things worse. Things are bad, but this doesn't make things worse.
CN: we might need further review from the PING folks
MF: Is this like a new feature that would be added?
CN: yes
MF: I think if we want to try to scope if that's part of v1 or v2, then we should figure out the guidelines for inclusion... like maybe shipping in multiple browsers
AB: it hasn't shipped in any yet
CN: yeah, shipping in one at least and have commitment from another
MF: I can try to get a sense of Chromium interest
CN: yeah, that would be good and maybe leave it as a v2 while we figure that out
CN: Yeah, let's have that discussion - that is what do we mean by v1 / v2, and relationship to publication stages
CN: we could say that v1 is what we take to recommendation stages
CN: we could stabilize the spec around the v1 features, we could incorporate the v2 stuff that we feel is important. tidoust correct me if I'm wrong, but going to CR triggers a patent exclusion period.
TD: yes, that is correct, but you can then publish as many CRs as we want.
MC: I'd caution against aiming for CR unless all issues are resolved. We can have a cutoff to get patent exclusions, then pick another set to do in a year, another CR. Then go to Rec later when ready
MF: Need to look at implementation status too
MC: Chris and I looked at that a bit already. We should look closer
MF: Testability may be challenging, depends on hardware
MC: We can do some of it manually. Check for consistent error behaviour. We found MIME type handling issues
MF: We can test most in a hardware-independent way. But determining smooth / power efficient is hadrware dependent
MC: Good question. Can you get variance between codec support and whether it's power efficient
MF: Tests might care just you get a valid answer
MC: It's up to the WG to make the case for interop. We can draw a line on which are meaningful bits to test, given there may be different results between implementations
MF: We need people to look at which bits to test out more closely
MC: It's a critical part of going to CR, so should start soon
MF: Given my bandwidth, I'd focus on clearing the PR backlog, for things not feature additions, and other V1 issues
… Then I could spend some time on testing
MC: Sounds good
CN: Focus on MIME type for testing?
MC: Important area, as it has repercussions in the query results where you get different results between implementations
… Risk is that implementers implement against the test suite rather than the spec, so we may need to change the spec
… Want to avoid web interop issues. How much breakage are we willing to accept? And what's the strategy for dealing with it?
MF: Is the concern that we're updating the spec to be stricter about MIME types, so implementations might now reject where they didn't before?
MC: Yes, there might be big users of the API might be affected
MF: If it comes to it, Blink has a deprecation process
… Need to make a practical tradeoff
CN: this was the concern that I has with the mine type stuff, as it defers to mime sniff... but we leave a lot to what is means for something to be supported. The interpretation of the parameters are left to the implementation.
MF: we should work to define it as clearly as possible
CN: to draw the scoping question to a conclusion, provided we have implementation and tests we can user that as a basis on the CR. Then we can add more features as a CR... but getting a good spec with the current set of things that we have, that is shown to be interoperable, that would be a good goal.
CN: At TPAC we talked about text tracks... we could defer that to when we talk about MSE, as it might have implication for media capabilities. There was also discussion about audio configuration, but we are a bit short of time today to talk about it.
CN: Same with multiple stream decoding... these are quite a bit of work, so we might defer these as labelled as V2
EME Common Encryption Versioning
EME common encryption versioning
XW: I joined the MPEG meeting. They acknowledged the need to do something compatible
… The group discussed how signalling should actually work. Different ideas, having groups of features
… I didn't see any conclusion from the meeting. Discussion will continue.
… My feeling is we need to follow up to see what they come up with. We may need to update EME for CENC
… They say EME shouldn't be tied to any CENC version, we currently reference v3. That won't work well
… Say EME works with CENC in general then use feature detection for specific features
CN: And no proposal for how the features will be signaled?
XW: May be discussed in future meetings
CN: Need our input to that conversation, or just wait on them?
XW: We can treat sliced headers as an individual feature. We should be compatible with what MPEG comes up with. Not sure on API shape
… If we come up with something, then MPEG does something else, won't work well.
… Not sure if we should design something
… What does the group think?
CN: Cyril mentioned possbility of MIME type parameters
MF: The structure of the MC API is there's a keySystemAccess for EME capabilities. It's a pass-through to EME, looks like good pattern to follow
… If using a codec string, what if it doesn't get passed to keySystemAccess?
XW: We don't support all encryption schemes, we have some feature detection for this use case. If we follow the MIME type thing, CBCS etc would also be in the string
… If we do that, MC API will have the MIME type for the codecs with all these things there. Signal the key system (Widevine etc), then query with MIME type and key system
… Could work I guess. But if you have a MIME type without the key system metadata ...
MF: Is encryption support inherent to the key system impl?
XW: Yes, all has to go to internally the CDM to ask if supported
MF: Could define your own MIME type, set the codec string to whatever
XW: Not a fan of the MIME type parsing in MIME Chromium
MF: Which is why I'm suggesting passing properties instead of relying on MIME types
<xhwang> Can we spend a few minutes on https://
CN: Conclusion, let's wait on the outcome from the November MPEG meetings
EME Specify mixed encrypted/unencrypted content
XW: What's the next step? Do we need to wait on rechartering?
… It's a relatively straightforward spec update
CN: I'd like to see implementer support
XW: From TPAC, seems we have that. I'll ping WebKit and Mozilla folks
Next meeting
CN: November 12, agenda TBC.
[adjourned]