- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Tue, 30 Jan 2024 18:01:19 +0000
- To: public-webrtc-logs@w3.org
> What is the right place to discuss the Media Session proposal? > > See [w3c/mediasession#312](https://github.com/w3c/mediasession/pull/312), [w3c/mediasession#307](https://github.com/w3c/mediasession/issues/307), [w3c/mediasession#279](https://github.com/w3c/mediasession/issues/279) and [w3c/mediasession#278](https://github.com/w3c/mediasession/issues/278). > > When we discussed this particular topic, one idea was to add a member to [MediaSessionActionDetails](https://w3c.github.io/mediasession/#dictdef-mediasessionactiondetails), like a deviceId. But it was unclear whether it was useful enough in the short term to work on it. Filing an issue in MediaSession repo might be a good idea to keep track of this. > > Similarly, we might want to add a state to MediaSessionActionDetails (to know whether action is about muting or unmuting). I'll probably work on this once the basic PRs are all landed. Thanks. I left a couple of comments in some of the issues. I think a solution based on MediaStreamTrack directly would be more suitable for the VC use cases, since applications already have access to the tracks they are playing. Using media session (provided it is augmented to properly support the use case) would require getting the device ID from the MediaStreamTrack, then separately looking up and/or maintaining the right state/objects and filtering events based on the device ID and associating all that to the MediaStreamTracks. -- GitHub Notification of comment by guidou Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/982#issuecomment-1917598319 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 30 January 2024 18:01:23 UTC