20:59:06 RRSAgent has joined #mediawg 20:59:10 logging to https://www.w3.org/2025/08/12-mediawg-irc 20:59:10 Zakim has joined #mediawg 20:59:16 Meeting: Media WG 20:59:54 Agenda: https://www.w3.org/events/meetings/6863dee2-9fc2-44dc-af4e-3e8306ae12ae/ 21:04:18 present+ Chris_Needham, Jan-Ivar_Bruaroey, Greg_Freedman, Mark_Foltz 21:04:38 present+ Eugene_Zemtsov 21:05:16 markafoltz has joined #mediawg 21:06:17 present+ Marcos_Caceres 21:06:51 present+ Xiaohan_Wang 21:08:41 marcos has joined #mediawg 21:09:02 scribe+ cpn 21:09:07 Topic: Media Capabilities 21:09:29 Mark: There's a PR to update the definitions of CBR and VBR. Marcos suggested some markup fixes 21:09:53 ... Issue raised by Paul Kerr 21:09:59 Chris: I'm not sure if Paul is still active 21:10:21 Mark: No rush, can wait to next week for feedback 21:10:39 Marcos: I'd suggest just merging 21:10:45 Mark: I'm happy to do that 21:10:56 Chris: Agree. They can comment if they have feedback 21:11:55 Chris: Issue 247, create a v2 spec? 21:12:42 Mark: We have some features that are currently tagged v2, some have work in progress PRs. If we land them in the V1 spec, it may complicate our ability to move the spec forward, if we don't have implementation commitments from multiple vendors 21:13:15 ... The other issue in the agenda, Chris raised but has moved on, and Johannes doesn't have plan to work on it 21:13:27 ... So concern about stretching our timeline 21:13:58 ... I'm not fixed on having level 2 as the only solution, but if there's a way to have features coexist with different implementation status, happy to consider options 21:14:32 Marcos: Normally if we have a spec at CR, or WD, if we want to add features we can add them as long as there's commitment from multiple implementers 21:14:53 ... You're right that a level 2 spec has some overhead, particularly if you keep them in sync. I'd caution strongly against doing that 21:15:06 ... CSS does it, they have very diligent spec writers 21:15:36 ... The way I do it in my specs, is if we have multiple implementers, add to the spec 21:16:10 Jan-Ivar: Mark the feature as at-risk, so it wouldn't block 21:16:46 Marcos: Marking at-risk is a tool we have, not my preferred way. Pushing more aggressively to get a second implementer on board could be good 21:17:05 ... But at-risk is a route we can take, but that doesn't look good 21:17:35 Mark: I didn't check how many features are far enough along to be merged. May be one or two things, just one or two (e.g., the WebRTC issue in the agenda) 21:18:02 ... If we land things that don't have multiple implementers, marking as at-risk, I'm OK 21:18:20 Jan-Ivar: What would the plan be going forward, have one or multiple documents? 21:18:27 Mark: Just one document, so not a level 2 spec 21:18:57 Jan-Ivar: Don't have a strong preference. Marking at-risk would might have the advantage of allow referencing from other specs, so I may bias towards that 21:19:27 Mark: Shall we resolve to do that? 21:19:39 Chris: Any concerns from anyone? 21:19:43 (nothing raised) 21:20:00 markafoltz has joined #mediawg 21:20:50 RESOLVED: We'll maintain Media Capabilities as a single spec and mark features added that don't have multiple implementer commitments as at-risk 21:21:48 Chris: Moving on to Issue 185 21:22:04 s/RESOLVED:/RESOLUTION: 21:22:06 Mark: We might need Youenn for this 21:22:33 ... Should we consider it as part of v1 or as a feature at risk? When I spoke with Johannes, he didn't want to give a timeline to implement 21:22:56 ... As far as the technical merits, needs others to look at it 21:23:20 Jan-Ivar: This adds WebRTC specific capabilities that are compatible with setCodecPreferences and capability APIs in WebRTC 21:23:32 ... I don't see anything troubling from my perspective 21:23:42 ... I also don't see a lot of reviewers who've looked at it yet 21:24:25 ... Harald seems positive, I think we'd welcome this 21:25:07 Mark: Happy to rebase it 21:25:28 Chris: Good idea, there's all the changes around valid MIME type made since this PR was raised 21:26:34 ... You asked a good question, What is the algorithm for setting the audio and video configuration values? 21:26:54 Mark: Yes, needs a mapping from WebRTC capabilities to Media Capabilities 21:27:26 Jan-Ivar: There may be some RTC elements misnamed here 21:27:39 ... I can add a comment 21:27:43 Mark: Makes sense 21:28:21 Chris: Are there any existing implementations? 21:28:46 Mark: No, but could land this if there's a commitment. It's still fuzzy on our side 21:29:29 Chris: Anything else on Media Capabilities? 21:29:31 (nothing) 21:29:39 Topic: TPAC 21:30:58 CN: we are planning to meet in Kobe. We plant to meet with WebRTC. 21:31:26 CN: We are mindful not to overlap with Second Screen WG, Audio WG 21:31:42 CN: we will be putting together the TPAC plan over next few months 21:31:55 TOPIC: Media WG Charter 21:32:37 CN: the slides I'm shower cover the changes to that we are making to various specs 21:33:41 CN: EME got some feedback that we would like to address in spec. 21:34:57 CN: For WebCodecs we've added some text around supported encrypted content. That received feedback that we were adding more DRM via Web Codecs. The request was to mitigate some of the DRM concerns. 21:35:37 CN: There have been issues raised that realtime media and static media had some interop issues 21:36:21 CN: The TAG gave some feedback around what they call the "bargain" that is made between authors and content producers when it comes to encrypted media. 21:37:15 CN: So given this feedback, we need to consider how we respond to interoperability, privacy, royalty free implementations, and access to media 21:38:03 CN: There's a need for better interoperability testing, particularly for EME 21:39:03 CN: There's a PR #570 on the EME spec that suggests some changes/additions to scope and how we will deal with various additions to EME 21:40:31 CN: For access to content, we need to figure out how to better address this... for media codecs, etc. they have licensing implications. We'd ideally would like a royalty free stack, but the market reality is different. We would like to explain the market reality. 21:40:38 Xiaohan: This isn't a new discussion 21:40:49 ... I feel EME has a positive contribution to the web 21:41:02 ... I'm trying not to get into a philosophical discussion again 21:41:23 ... But we can do the security and privacy questionnaire around new things we're adding. We can add text to explain privacy concerns 21:41:51 ... On interoperability, what examples do reviewers have in mind? If they can explain, I can help 21:42:31 ... Royalty free, most implementations aren't royalty free. All browsers support Clearkey, which is royalty free, but it's not secure from a production perspective, so content providers wouldn't want to use that 21:42:51 ... A royalty free implementation with good protection would need a lot of investment 21:43:30 ... Access to media is easy to answer: Access to premium media on the web, Netflix and commercial providers. It's huge improvement to access to media 21:44:22 Marcos: The TAG bargain point, it may require special hardware. The content producers having power to deliver content because of DRM modules, we'd respond to that ... the tradeoff of access to content 21:44:37 ... It costs content producers users, and it costs users if they have to buy new hardware 21:44:51 ... Comes with potential restrictions or privacy issues 21:45:09 ... It's a hard one to answer. People like watching Netflix! 21:45:33 Xiaohan: Most DRM vendoers have software solutions, so hardware not needed. Most users have the option, but maybe not for 4K 21:45:50 ... But if you want the best experience, e.g., in gaming, you need the best hardware 21:46:35 Marcos: Some people may not accept that that's great. But explain the facts. The world didn't fall apart when EME came out 21:46:47 ... There haven't been EME modules doing nefarious things or phoning home 21:47:17 Jan-Ivar: Is the question also more technical, that the software doesn't get access to the digital media, which is the point of EME 21:48:32 ... Hardware specifically needed to restrict access to what can be done with the media? 21:48:44 Chris: I think the question is more about end user considerations 21:49:13 Xiaohan: Also need to address Accessibility? 21:49:37 Chris: Yes, across all our specs 21:51:25 Chris: My thought was to focus on describing the issues related to the specific feature changes we're making 21:51:41 ... We may already have text on accessiblity, need to check 21:52:04 Jan-Ivar: It says not encrypting captions, described audio, transcripts 21:53:01 Xiaohan: AI could provide assistive features. not sure whether to include? 21:54:11 ... Frame scrubbing, trick play, doesn't need to be done in the CDM. There's no feature in the media element, so each content provider does it, e.g., with a huge image carved into smaller ones 21:54:38 ... We're looking at whether we can provide low resolution frames from the CDM. Would be hard to put in the EME spec 21:55:04 ... I can imagine different CDM implementations having different views 21:56:15 ... Having that on the media element layer would be good. Most implementations have the thumbnails or snapshot feature in the player but there's no W3C standard for it, and JS doesn't have a way to access it 21:57:48 Chris: Suggest we start a draft doc, seed with the thoughts we've discussed today and iterate 21:58:52 ... We have the S&P questionnaire to cover privacy issues 21:59:06 ... But how to know what kind of cross-site tracking it might enable? 21:59:41 Xiaohan: As an implementer, we take cross-site tracking seriously. We likely have that already in the spec, and implementation ensures that as well 22:00:09 ... But as it's closed source, some things are hard to provide 22:00:25 Chris: Do any of our incremental changes change the privacy story in any way? 22:00:52 Greg: Any time you add or extend an API you're potentially changing the fingerprinting footprint, e.g., Media Capabilities 22:02:36 ... Does EME get extra scrutiny from that point of view? 22:03:18 Chris: I think reviewers will be looking at all our specs equally, but EME gets more attention perhaps for the other considerations such as access to media 22:03:43 Topic: Media Fragments 22:04:11 Chris: The Media Fragments spec has come up in discussion in CSS, they raised a couple of issues 22:04:23 ... Don't have time today, I'll send email to the list 22:04:30 [adjourned] 22:04:36 rrsagent, draft minutes 22:04:37 I have made the request to generate https://www.w3.org/2025/08/12-mediawg-minutes.html cpn 22:04:46 rrsagent, make log public 22:05:30 i/scribe+ cpn/scribe+ marcos/ 22:05:50 i/Agenda/Chair: Chris, Marcos/ 22:05:54 rrsagent, draft minutes 22:05:55 I have made the request to generate https://www.w3.org/2025/08/12-mediawg-minutes.html cpn 22:06:38 i/Agenda/Regrets: Francois/ 22:06:40 rrsagent, draft minutes 22:06:41 I have made the request to generate https://www.w3.org/2025/08/12-mediawg-minutes.html cpn