Meeting minutes
Media Capabilities
Mark: There's a PR to update the definitions of CBR and VBR. Marcos suggested some markup fixes
… Issue raised by Paul Kerr
Chris: I'm not sure if Paul is still active
Mark: No rush, can wait to next week for feedback
Marcos: I'd suggest just merging
Mark: I'm happy to do that
Chris: Agree. They can comment if they have feedback
Chris: Issue 247, create a v2 spec?
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
… The other issue in the agenda, Chris raised but has moved on, and Johannes doesn't have plan to work on it
… So concern about stretching our timeline
… 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
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
… 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
… CSS does it, they have very diligent spec writers
… The way I do it in my specs, is if we have multiple implementers, add to the spec
Jan-Ivar: Mark the feature as at-risk, so it wouldn't block
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
… But at-risk is a route we can take, but that doesn't look good
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)
… If we land things that don't have multiple implementers, marking as at-risk, I'm OK
Jan-Ivar: What would the plan be going forward, have one or multiple documents?
Mark: Just one document, so not a level 2 spec
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
Mark: Shall we resolve to do that?
Chris: Any concerns from anyone?
(nothing raised)
RESOLUTION: We'll maintain Media Capabilities as a single spec and mark features added that don't have multiple implementer commitments as at-risk
Chris: Moving on to Issue 185
Mark: We might need Youenn for this
… 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
… As far as the technical merits, needs others to look at it
Jan-Ivar: This adds WebRTC specific capabilities that are compatible with setCodecPreferences and capability APIs in WebRTC
… I don't see anything troubling from my perspective
… I also don't see a lot of reviewers who've looked at it yet
… Harald seems positive, I think we'd welcome this
Mark: Happy to rebase it
Chris: Good idea, there's all the changes around valid MIME type made since this PR was raised
… You asked a good question, What is the algorithm for setting the audio and video configuration values?
Mark: Yes, needs a mapping from WebRTC capabilities to Media Capabilities
Jan-Ivar: There may be some RTC elements misnamed here
… I can add a comment
Mark: Makes sense
Chris: Are there any existing implementations?
Mark: No, but could land this if there's a commitment. It's still fuzzy on our side
Chris: Anything else on Media Capabilities?
(nothing)
TPAC
CN: we are planning to meet in Kobe. We plant to meet with WebRTC.
CN: We are mindful not to overlap with Second Screen WG, Audio WG
CN: we will be putting together the TPAC plan over next few months
Media WG Charter
CN: the slides I'm shower cover the changes to that we are making to various specs
CN: EME got some feedback that we would like to address in spec.
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.
CN: There have been issues raised that realtime media and static media had some interop issues
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.
CN: So given this feedback, we need to consider how we respond to interoperability, privacy, royalty free implementations, and access to media
CN: There's a need for better interoperability testing, particularly for EME
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
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.
Xiaohan: This isn't a new discussion
… I feel EME has a positive contribution to the web
… I'm trying not to get into a philosophical discussion again
… But we can do the security and privacy questionnaire around new things we're adding. We can add text to explain privacy concerns
… On interoperability, what examples do reviewers have in mind? If they can explain, I can help
… 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
… A royalty free implementation with good protection would need a lot of investment
… 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
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
… It costs content producers users, and it costs users if they have to buy new hardware
… Comes with potential restrictions or privacy issues
… It's a hard one to answer. People like watching Netflix!
Xiaohan: Most DRM vendoers have software solutions, so hardware not needed. Most users have the option, but maybe not for 4K
… But if you want the best experience, e.g., in gaming, you need the best hardware
Marcos: Some people may not accept that that's great. But explain the facts. The world didn't fall apart when EME came out
… There haven't been EME modules doing nefarious things or phoning home
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
… Hardware specifically needed to restrict access to what can be done with the media?
Chris: I think the question is more about end user considerations
Xiaohan: Also need to address Accessibility?
Chris: Yes, across all our specs
Chris: My thought was to focus on describing the issues related to the specific feature changes we're making
… We may already have text on accessiblity, need to check
Jan-Ivar: It says not encrypting captions, described audio, transcripts
Xiaohan: AI could provide assistive features. not sure whether to include?
… 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
… We're looking at whether we can provide low resolution frames from the CDM. Would be hard to put in the EME spec
… I can imagine different CDM implementations having different views
… 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
Chris: Suggest we start a draft doc, seed with the thoughts we've discussed today and iterate
… We have the S&P questionnaire to cover privacy issues
… But how to know what kind of cross-site tracking it might enable?
Xiaohan: As an implementer, we take cross-site tracking seriously. We likely have that already in the spec, and implementation ensures that as well
… But as it's closed source, some things are hard to provide
Chris: Do any of our incremental changes change the privacy story in any way?
Greg: Any time you add or extend an API you're potentially changing the fingerprinting footprint, e.g., Media Capabilities
… Does EME get extra scrutiny from that point of view?
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
Media Fragments
Chris: The Media Fragments spec has come up in discussion in CSS, they raised a couple of issues
… Don't have time today, I'll send email to the list
[adjourned]