– DRAFT –
Media WG meeting

Media Session API

<marcosc> cn: who would like to give us an update?

<marcosc> youen: started writing a PR for setMicrophoneActive etc on issue 312 ... expand it to screen share too. maybe in the future we might be able to support other devices. Will continue to work with folks on that and hopefully get it merged

<marcosc> youen: we need the media session to support muting various devices, but due to a lack of UI, we don't need to support it just yet. We can look at extended parts of the API to mute/unmute devices based on device IDs. This might not be a "V1" thing, maybe we do this as an extension

<marcosc> jib: we might not want to support multiple devices. Similarly for media conferences, there is already good support already in browsers and on keyboards. There is privacy concerns, particularly with multiple cameras or mics, that all of them get muted... not selectively.

<marcosc> ts: that makes sense. There is no strong use cases for this right now

<marcosc> Cn: what would be the expected behavior be if there is a single mute button?

<marcosc> youen: it would toggle all of them. If some track is already muted, then all of them would get muted... they would all be put in sync

<marcosc> jib: so it's like a privacy shield across all of them. All get toggled off or on

<marcosc> cn: we have a number of issues open, and I'm wondering what we need to do to get to CR status?

<marcosc> youen: we need to triage them together with Tommy

<marcosc> cn: that would be great

<marcosc> cn: so yeah, we could look at test coverage too

<marcosc> ts: yeah, it's not entirely clear what we need to do to move everything forward

<marcosc> youen: we need multiple implementations for everything

<marcosc> youen: we might move things to a different spec

mc: we only need that to go to rec, but we can sit in CR indefinitely, and get the IPR commitments
… features not implemented across multiple implementations can be marked as at-risk
… they can be left in CR for a reasonable amount of time
… I'd caution against extension specs, they can become a bit of a mess
… We have a process in place for having things well tested

jan-ivar: GH has milestones, so can have one for CR and one for extensions

mc: whatever process works, so GH milestones can be good

yf: we currently have P1 and P2, a v1 milestone with 14 issues to resolve to get to that milestone

<marcosc> cn: wether we take it through to REC or leave it in CR is a discussion to have in the future. So long as we can show interop

<marcosc> fd: you don't even need an implementation to go to CR for some things

MSE

<marcosc> cn: we've merged the managed media source into the main spec. What's now the process for adding test?

mc: it's for me and jean-jves to bring over tests already written
… two parts: as the spec lands in TR, there's a script that picks it up and adds the interfaces to WPT
… We add additional tests there for the IDL stuff. Then we need to exercise what we can from the API
… It can get more complicated from there. WebDriver will drive pressing buttons to play a video, but because we don't run WPT on real devices, the managed part isn't really testable
… So need to figure out what's testable. Some will need to confirm manually. We'll get as much coverage as we can

<marcosc> cn: I'm planning to re-read what is in the spec.

<marcosc> cn: Matt who used edit the spec is no longer as editor of the spec or as en invited expert, unfortunately. So we are looking for editors potentially for "MSE byte stream format registry" and "WebM byte stream format"

<marcosc> cn: I don't anticipate much work needed on those documents. There is just some small maintenance work on them, so we would love some volunteers to help us out.

<marcosc> fd: on the short term, we need to republish them. To republish, we need an editor who is in the working group.

mc: we could do as chairs, but ideally good to have volunteers

<marcosc> cn: ideally we would love some help. Please let us know.

Media Capabilities

<marcosc> cn: there are two issues (213).... regarding support for dynamic metadata

<marcosc> cn: of various types as described in the issue

<marcosc> Jn: I was asked about this by some folks... I was unsure if the platform gets to pick one or if they are used together. If there are multiple types available, then the platform should pick... but I don't have an answer for exactly how it would work when in combination. The API doesn't support that.

<marcosc> jn: we might need an enhancement (enum) to allow us to support specific combinations

<marcosc> jn: instead of trying to handle them all combined

<marcosc> cn: what about how we deal with the registry

<marcosc> jn: I don't have a good answer for that... specially for non-public metadata types

<marcosc> cn: what's the next steps?

<marcosc> jn: it might be good to reach out to an expert that would know how the combination of metadata would work.

<marcosc> cn: yes, I could write a reply to the issue

<marcosc> jn: I'm happy to respond to the issue (213)

<marcosc> cn: the second was related to capability negotiation, that came in with the issue (???)

<marcosc> cn: the current PR doesn't address the privacy issues I don't believe.

<marcosc> ba: you might be right. If you have suggestion to improve it, that would be great

<marcosc> cn: I'm not an RTC expert, but can try

<marcosc> ab: still working with trying to work with PING to address their concerns

<marcosc> ab: but yes, I'm open to guidance here.

<marcosc> ab: there is a lot of software implementations... which may or may not be power efficient. Just we don't differentiate on power efficiency, but it may or may not help address PING's issues

<marcosc> cn: I'll also give this more thoughts

<marcosc> cn: I commented in issue 217... but the feedback seems to questioning our entire approach. We might need to write some words that compare the multiple approaches as a way to address the concerns of PING

<marcosc> ba: there are a lot of consideration when choosing a codec

<marcosc> ba: there are a11y concerns... do browsers have access to that?

<marcosc> jn: the browser is in a better position to make that determination

<marcosc> jn: similarly with device thermals, etc. the user agent is in a better position to make those determinations.

mc: to that point, looking at how we approached managed media source, serves as a good model for addressing these concerns
… the UA and the platform is in a better position to do this, saves all the websites having to create UI, what Jer said

<marcosc> cn: I need to take another look and talk to Mark etc. about all this.

<marcosc> ba: this is a general and larger discussion we should definitely have

<marcosc> cn: that's all for now for media capabilities. I did some triaging there, but we have a lot of open pull requests.

<marcosc> cn: as chairs we can help out with things, but we need experts to continue to move things forward

EME

<marcosc> cn: we've made some progress on the HTTP Version Registry. There is a PR ready to go. It has the criteria and all the relevant specs and versions. The main thing it needs now is on the spec itself. Right now we have an enum, so we need to remove that from the EME spec... we would need to change that to the DOMString instead in the spec (to behave the same as an enum)

<marcosc> gf: I will do that change

<marcosc> cn: do we need a formal call for consensus for publishing the registry?

<marcosc> fd: yes, that would be ideal

<marcosc> cn: when Greg has done the changes, we can move to the Call for Consensus.

<marcosc> fd: we could combine everything into a single CFC

<marcosc> cn: we've got some feedback in issue #522 with security concerns with EME. An attacker could renew a license and get an extended period of service. Has anyone had a look yet and want to discuss?

<marcosc> JP: I've looked into this and reached out to some folks. The relevant folks who understand this have been pinged and waiting to hear back. I'll ask for some clarifications in the bug about some things that were unclear.

<marcosc> Jn: We have shared the report with the relevant teams at Apple. We don't believe WebKit is affected. But it seems. reasonable to change the spec to only allow passing in the cert at creation time.

<marcosc> jp: I also don't see why you would change the cert dynamically after creation. So long as everyone is onboard and it's web compatible, when I'm in favor of the change. I'm still a little bit unclear on some aspects, but it seems like it wouldn't hurt to update the spec

<marcosc> cn: would it be useful to have them (the sec researchers) join a call?

<marcosc> cn: they offered to do that

<marcosc> jp: no objections

<marcosc> jn: it would be great

<marcosc> cn: I'll get back to them and see if we can get them to join in a few weeks

next meeting

<marcosc> cn: next meeting March 12. But we can have another meeting as needed.

<marcosc> cn: there is a W3C breakout day

<marcosc> cn: on that day.

<marcosc> cn: what it does mean is that our time slot overlaps with this time... so we might need to have an alternative time to not clash. We will confirm that nearer the date.

<marcosc> cn: having said that, please propose a session as it's a good way to promote and showcase ideas and make a proposal

https://www.w3.org/2024/03/breakouts-day-2024/

<marcosc> cn: there is GitHub repo

<marcosc> cn: please propose ideas there 👆

https://github.com/w3c/breakouts-day-2024/issues

<marcosc> cn: that's all for today.

<marcosc> jn: I want to pitch an idea for next media. We would like to discuss spatial video. So would like to discuss display and decoding, and where things fall short on the current web platform APIs

<marcosc> cn: would you be interested in maybe presenting that in an related interest group?

<marcosc> jn: yes, perhaps