20:58:24 RRSAgent has joined #mediawg 20:58:29 logging to https://www.w3.org/2024/10/08-mediawg-irc 20:58:30 Zakim has joined #mediawg 21:00:38 present+ Chris_Needham, Bernard_Aboba 21:01:48 present+ Greg_Freedman 21:02:02 present+ Xiaohan_Wang 21:02:46 present+ Marcos_Caceres 21:02:53 Chair: Marcos_Caceres, Chris_Needham 21:02:54 markafoltz has joined #mediawg 21:02:58 scribe+ cpn 21:03:16 present+ Francois_Daoust 21:03:28 RRSAgent, make logs public 21:03:38 Meeting: Media WG monthly call 21:03:44 present+ Mark_Foltz 21:03:44 Chair: Chris, Marcos 21:05:26 Marcos has joined #mediawg 21:05:29 xhwang has joined #mediawg 21:05:54 TOPIC: Post TPAC 21:05:59 CN: great to see everyone 21:06:08 CN: Currently catching up after a week off 21:07:25 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. 21:07:35 TOPIC: Media Capabilities 21:09:14 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. 21:10:40 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. 21:10:58 CN: If you are all comfortable with this, I'd like to merge this. 21:11:10 MF: would you like a final review for typos etc. 21:11:19 CN: yes, please. 21:11:48 BA: The RTP references might need updating because we have closed on of the registries. 21:12:12 BA: we are just telling everyone to use the actual MIME Type registries 21:12:31 CN: Should we drop the reference? 21:12:40 BA: I would drop it 21:12:55 CN: What about 6838? 21:13:19 BA: That one is fine... that's the main IANA registry 21:13:45 CN: Great, then I will drop the reference to the RTP registry 21:14:37 CN: There was a suggestion of how we describe variable bit rate and constant bit rate. We should look at if this changes implementations 21:14:54 MF: I'm happy to review it and check if we need implementation feedback 21:15:05 BA: That change seems useful to me from a developer perspective 21:15:35 MF: the details may be codec specific, but can at least look at the text. 21:15:37 https://github.com/w3c/media-capabilities/pull/78 21:16:06 CN: I haven't summarized the change. But if folks can have a look, that would be great 21:16:26 https://github.com/w3c/media-capabilities/pull/107 21:16:32 https://github.com/w3c/media-capabilities/pull/107 21:16:49 CN: For KeySystemAccess... 21:17:07 cpn4 has joined #mediawg 21:17:09 https://github.com/w3c/media-capabilities/pull/107 21:18:04 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. 21:18:24 https://github.com/w3c/media-capabilities/pull/186 21:19:15 CN: this one is about adding WebRTC info to Media Capabilities Info 21:20:08 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. 21:20:19 CN: has anyone implemented this? 21:20:49 AB: Not sure. Not in chrome. We will need to follow up with Youenn 21:21:17 CN: it seems there was some convergence on what was being discussed there. 21:21:47 AB: Eric gave a talk on the Discovery encoder API, and that's what they were more interested in 21:22:37 CN: We can check in with Youenn on this. We should get feedback from other implementers 21:23:18 CN: it also occurs to me that it returns a lot more information. Does this make things worst from a privacy perspective 21:23:45 BA: with web codecs, you can already get all this information you need by hashing a frame 21:24:31 BA: so, this doesn't make things worse. Things are bad, but this doesn't make things worse. 21:24:54 CN: we might need further review from the PING folks 21:25:04 MF: Is this like a new feature that would be added? 21:25:08 CN: yes 21:25:43 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 21:26:01 AB: it hasn't shipped in any yet 21:26:24 CN: yeah, shipping in one at least and have commitment from another 21:26:40 MF: I can try to get a sense of Chromium interest 21:27:01 CN: yeah, that would be good and maybe leave it as a v2 while we figure that out 21:27:34 CN: Yeah, let's have that discussion - that is what do we mean by v1 / v2, and relationship to publication stages 21:27:50 CN: we could say that v1 is what we take to recommendation stages 21:29:18 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. 21:29:38 TD: yes, that is correct, but you can then publish as many CRs as we want. 21:29:50 scribe+ cpn4 21:30:44 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 21:31:27 MF: Need to look at implementation status too 21:31:42 MC: Chris and I looked at that a bit already. We should look closer 21:31:50 MF: Testability may be challenging, depends on hardware 21:32:24 MC: We can do some of it manually. Check for consistent error behaviour. We found MIME type handling issues 21:32:56 MF: We can test most in a hardware-independent way. But determining smooth / power efficient is hadrware dependent 21:33:19 MC: Good question. Can you get variance between codec support and whether it's power efficient 21:33:33 MF: Tests might care just you get a valid answer 21:34:06 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 21:34:23 MF: We need people to look at which bits to test out more closely 21:34:41 MC: It's a critical part of going to CR, so should start soon 21:35:07 MF: Given my bandwidth, I'd focus on clearing the PR backlog, for things not feature additions, and other V1 issues 21:35:14 ... Then I could spend some time on testing 21:35:18 MC: Sounds good 21:35:35 CN: Focus on MIME type for testing? 21:36:03 MC: Important area, as it has repercussions in the query results where you get different results between implementations 21:36:33 ... Risk is that implementers implement against the test suite rather than the spec, so we may need to change the spec 21:37:00 ... Want to avoid web interop issues. How much breakage are we willing to accept? And what's the strategy for dealing with it? 21:37:22 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? 21:37:34 MC: Yes, there might be big users of the API might be affected 21:38:07 MF: If it comes to it, Blink has a deprecation process 21:38:18 ... Need to make a practical tradeoff 21:39:33 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. 21:39:56 MF: we should work to define it as clearly as possible 21:40:38 scribe+ Marcos 21:40:56 RRSAgent, draft minutes 21:40:57 I have made the request to generate https://www.w3.org/2024/10/08-mediawg-minutes.html tidoust 21:41:26 i/TOPIC: Post TPAC/scribe+ Marcos 21:42:02 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. 21:43:36 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. 21:44:09 CN: Same with multiple stream decoding... these are quite a bit of work, so we might defer these as labelled at V2 21:44:15 s/at/as 21:44:38 Topic: EME Common Encryption Versioning 21:44:39 TOPIC: EME common encryption versioning 21:45:25 XW: I joined the MPEG meeting. They acknowledged the need to do something compatible 21:45:51 ... The group discussed how signalling should actually work. Different ideas, having groups of features 21:46:08 ... I didn't see any conclusion from the meeting. Discussion will continue. 21:46:33 ... My feeling is we need to follow up to see what they come up with. We may need to update EME for CENC 21:46:54 ... They say EME shouldn't be tied to any CENC version, we currently reference v3. That won't work well 21:47:11 ... Say EME works with CENC in general then use feature detection for specific features 21:47:30 CN: And no proposal for how the features will be signaled? 21:47:41 XW: May be discussed in future meetings 21:48:15 CN: Need our input to that conversation, or just wait on them? 21:48:51 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 21:49:04 ... If we come up with something, then MPEG does something else, won't work well. 21:49:09 ... Not sure if we should design something 21:49:18 ... What does the group think? 21:50:57 CN: Cyril mentioned possbility of MIME type parameters 21:51:33 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 21:51:46 ... If using a codec string, what if it doesn't get passed to keySystemAccess? 21:52:20 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 21:53:02 ... 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 21:53:21 ... Could work I guess. But if you have a MIME type without the key system metadata ... 21:53:33 MF: Is encryption support inherent to the key system impl? 21:53:46 XW: Yes, all has to go to internally the CDM to ask if supported 21:54:13 MF: Could define your own MIME type, set the codec string to whatever 21:54:27 XW: Not a fan of the MIME type parsing in MIME Chromium 21:54:47 MF: Which is why I'm suggesting passing properties instead of relying on MIME types 21:55:59 Can we spend a few minutes on https://github.com/w3c/encrypted-media/issues/251? I have a quick question. 21:56:32 CN: Conclusion, let's wait on the outcome from the November MPEG meetings 21:56:54 Topic: EME Specify mixed encrypted/unencrypted content 21:57:11 XW: What's the next step? Do we need to wait on rechartering? 21:57:47 ... It's a relatively straightforward spec update 21:58:54 CN: I'd like to see implementer support 21:59:28 XW: From TPAC, seems we have that. I'll ping WebKit and Mozilla folks 21:59:54 markafoltz has joined #mediawg 22:00:13 Topic: Next meeting 22:00:24 CN: November 12, agenda TBC. 22:00:27 [adjourned] 22:00:32 rrsagent, draft minutes 22:00:33 I have made the request to generate https://www.w3.org/2024/10/08-mediawg-minutes.html cpn4 22:00:39 rrsagent, make log public 22:45:25 markafoltz has joined #mediawg 23:27:54 Zakim has left #mediawg