21:56:55 RRSAgent has joined #mediawg 21:56:55 logging to https://www.w3.org/2021/03/09-mediawg-irc 21:56:59 Zakim has joined #mediawg 21:57:12 Meeting: Media WG Teleconference 21:57:34 Agenda: https://github.com/w3c/media-wg/blob/master/meetings/2021-03-09-Media_Working_Group_Teleconference-agenda.md 21:57:40 RRSAgent, make logs public 21:58:51 Peng_Liu has joined #mediawg 22:02:13 present+ Francois_Daoust, Eric_Carlson, Greg_Freedman, Peng_Liu, Tess_O_Connor, Gary_Katsevman, Joey_Parrish, Cyril_Concolato, Chris_Cunningham 22:02:41 present+ Chris_Needham 22:03:07 Present+ Tommy_Steimel 22:04:56 Present+ Mounir_Lamouri 22:05:55 chcunningham has joined #mediawg 22:05:58 present+ Jer_Noble 22:05:59 present+ 22:06:10 chair: Jer, Mounir 22:06:51 jernoble has joined #mediawg 22:06:52 scribe: tidoust 22:07:21 Topic: New media actions for the Media Session API 22:07:35 ericc has joined #mediawg 22:07:51 mounir: Jer, I believe you wanted to add "hang up". Same request internally a couple of weeks later. 22:08:07 https://github.com/w3c/mediasession/issues/264 22:08:13 present+ Mark_Watson 22:08:53 tommy: Media session allows web sites to subscribe to actions, e.g. "next track" in a playlist. All actions have been geared to video playback. 22:09:05 ... Considering actions for conersations and WebRTC. 22:09:20 ... Ways to toggle the microphone and camera, and hang up. 22:09:33 q+ 22:09:36 ... Also two actions to get the current state 22:09:59 q- 22:10:08 ericc: "The browser wouldn't know the state the camera/microphone status", what does that mean? 22:10:43 tommy: If you're talking and muted on Hangout, it's still listening to your microphone to tell you you might be muted. 22:10:50 ... hard to tell the difference. 22:11:19 ericc: You're not saying that the camera/microphone is actually active, rather whether the app is using the data or not? 22:11:32 tommy: Right, we couldn't tell without the app telling us. 22:11:35 q+ 22:12:41 ericc: As far as the actions go, with the existing media session actions, let's say there is a media session that registered play/pause and the user hits a hardware key which, if the session was not active would play/pause the media element 22:13:17 ... When there's a media session and there's a play action registered, the action handler gets called, the UA no longer does anything, it's the responsibility of the page to play/pause the media element. 22:13:26 tommy: I believe that's correct for play/pause. 22:14:11 mounir: Play/pause are a special case where the spec allows UA to have a default implementation. Chrome will play/pause things. It is a bit hard however to do "next track". 22:14:33 tommy: We don't have any plan to provide default handlers for the 3 new actions. 22:14:52 mounir: We may be able to do something with "hang up", but we haven't researched that for now. 22:15:43 ericc: The thing that I'm concerned about is the user takes an action which they believe will stop the feed from the camera, and the UA is delegating responsibility for that to the page because there is a media session, and the page can either honor that or not, which seems like a bad thing. 22:16:07 ... A nefarious site could make it look as though the camera had been turned off. 22:16:48 mounir: In my opinion, you already provided the media feed to that page. 22:17:09 ... If you press mute on the app UI, you already need to trust the app. 22:17:28 q? 22:17:30 ... I believe that's the opposite, the app delegates the UI to the UA in this case 22:17:33 ack jernoble 22:17:33 ack jernoble 22:17:48 GregFreedman has joined #mediawg 22:18:01 jernoble: It seems very easy for us, UA, to mute the mike, stop video frames from being delivered, etc. 22:18:35 ... The problem here is that these actions may be interpreted to be part of the UA chrome, so there's a trust issue here. 22:19:28 ... Different UAs may be able to treat this differently. We might just decide that when the mute button is clicked, we'll just mute the audio/video, to err on the side of users expectation rather than page expectation 22:20:37 ericc: To expand upon that a bit, I was thinking about the current affordances that we have in Safari browser chrome, and I was assuming that for play/pause, we would send an action to the media session with a registered handler. That's where the worry is coming from. 22:21:08 ... As long as there is wording in the spec that the UA can have a default action for these actions, which it does even if there is a registered action handler, that should be fine. 22:21:23 tommy: We already do that for play/pause. It makes sense to me to extend it to these actions as well. 22:21:41 mounir: Would you want a default action for all of them? toggle camera/mike, hang up? 22:22:19 jernoble: I believe it will be difficult to hang up a WebRTC session automatically. 22:23:07 mounir: There is a very Chrome specific problem around that. I know it's doable, but it could be a nuclear bomb for the web site which may not be able to revover from it. 22:23:32 ... If we are able to do a default action for hang up, most likely Safari should be able too. 22:23:59 ... Will have to check with Mozilla folks (not around for this call). 22:24:53 ... Conclusion: being able to handle toggle camera/microphone directly by the UA. You will shut down the camera/microphone regardless of what the app is doing with these actions. 22:24:57 jernoble: Correct. 22:25:16 Topic: New Media WG charter 22:25:20 scribe: mounir 22:25:47 tidoust: the current Media WG charter expires at the end of May so it needs to be renewed to continue this work 22:26:00 ... technically, we have to have a new charter by tomorrow as it has to be reviewed 22:26:12 ... I prepared a pull request starting from the current Media WG charter to refresh it 22:26:43 tidoust: there is also a refresh of deliverables list, the main change was to add WebCodecs 22:26:58 ... which was adopted and was already a potential deliverable 22:27:13 ... I dropped the EME feature around persistent usage record as it was dropped 22:27:39 -> https://github.com/w3c/charter-media-wg/pull/13 PR of draft media WG charter 22:28:02 tidoust: I prepared a pull request with these changes and I would like to hear your feedback 22:28:32 tidoust: any feedback that can be shared during the call? 22:29:04 tidoust: I will merge the pull request and kick off the W3C internal review process 22:29:22 tidoust: Please look at it and provide feedback as soon as possible 22:29:43 Topic: Synchronize /TR documents with Editor's Drafts 22:30:11 tidoust: I raised the issue and asked for feedback but didn't here much 22:30:18 ... so I suggest that we adopt this unless we have comments 22:30:32 chcunningham: I'm supportive 22:31:09 tidoust: the group will then process forword with this 22:31:13 scribe: tidoust 22:31:32 Topic: Move WebCodecs to the Media WG 22:31:51 mounir: I sent an email this morning. WebCodecs adopted as a Media WG deliverable. 22:32:18 ... For publication as FPWD, Google made some comments around registries. This holds publication as FPWD but should be merged soon. 22:32:43 https://github.com/w3c/media-capabilities/pull/165 22:32:56 Topic: Define MediaCapabilitiesDecodingInfo.codecSwitchingSupported 22:32:57 Topic: Define a Media Capabilities decoding info - codec switching supported 22:33:04 s/Topic: Define a Media Capabilities decoding info - codec switching supported/ 22:33:39 chcunningham: API for transition: ability to switch from one codec to another via the MSE changeType API. 22:34:02 ... It doesn't have any way to signal its capabilities about changes that are supported. 22:34:17 ... Only way to discover that is the hard way by trying changes. 22:35:17 ... Difference between the clear pipeline and eme playback is needed, addressed in the PR. 22:36:08 ... Feedback I got from Shaka player on the initial design was that it was too complicated. A boolean "can I call changeType in the current context?" seems more useful. 22:37:19 ... For the clear pipeline, that works smoothly. For the EME pipeline, there was never a moment where we were in a situation where a transition was supported and another transition was not. 22:37:58 ... So proposal is true/false in the context of the pipeline, which is either clear/encrypted (key system + robustness) 22:38:30 ... I didn't feel that we really have had feedback from other user agents. I'd like to call out for feedback. 22:38:33 q+ 22:38:56 cpn: Do you have input from Jon Piesing from an embedded browser perspective? 22:39:01 q+ 22:39:11 ... They have rather more constrained pipelines that may warrant special recommendations. 22:39:25 ack jernoble 22:40:17 jernoble: "Can I switch to this new pipeline" or "Can I switch to this new codec within this pipeline?" 22:40:25 chcunningham: The latter. 22:41:11 ... Once you have the key system established, adding/removing media keys may not be possible anymore depending on the user agent. 22:41:22 ... Not a required feature to go from one pipeline to another. 22:41:40 jernoble: Wondering about clear to encrypted scenarios. 22:42:06 chcunningham: I haven't thought about this. If you're doing clear and switching to encrypted today, is there a question there? 22:42:31 jernoble: I'm assuming web citizens may see this new API and be tempted to call it. 22:42:47 chcunningham: I'd be happy to add a clarification. 22:43:28 GregFreedman: We have clear to encrypted scenarios. Clear intro (a.k.a. bumper) and then we switch to encrypted playback. 22:43:39 q+ 22:43:57 ... We're reusing the video element as much as possible. I can't say that we're using changeType today 22:44:23 ... I could see us switching to a trailer at the end of a series in a different codec. 22:44:27 ack GregFreedman 22:45:28 chcunningham: In Chrome, it's not very interesting. That second "changeType" call, if you haven't set up your key system yet, you'll end up doing a pipeline switch. 22:45:45 ... The pipeline you're entering into will be exposed through media capabilities. 22:46:04 GregFreedman: Should we start playing our clear content within the encrypted pipeline? 22:46:43 chcunningham: That would work today. My point is that you're not switching codecs, you're switching pipelines entirely. That's a different thing. 22:47:18 ... The question "Do you support codec switching smoothly when you switch pipelines?" is difficult to answer. 22:48:06 ... Clear to encrypted is a very legitimate thing to do. I guess I wouldn't think this API is the right approach for that. 22:49:00 ... I would do my ad with codec A in the clear, then set up the encrypted pipeline, then call changeType with the new codec and then start appending. 22:49:09 ack gkatsev 22:49:41 gkatsev: In video.js, if we're playing content that has clear and encrypted, we setup the encrypted pipeline before we start playing clear content. 22:50:08 chcunningham: There were definitely some implementation issues within Chrome going between clear and encrypted. 22:50:29 ... The key system configuration in Media Capabilities describes the pipeline to be used. 22:51:13 gkatsev: Having explicitly things is great. 22:52:47 Topic: Announcement 22:52:48 mounir: I'm leaving Chrome at the end of this week, so will step down as co-chair for this group. Francois and Jer are looking for someone to replace me. I may or may not stick around for next call. 22:53:05 jer: Many thanks, Mounir, for the work you've been doing in the group in the past couple of years! 22:53:19 +1 22:54:07 RRSAgent, draft minutes 22:54:07 I have made the request to generate https://www.w3.org/2021/03/09-mediawg-minutes.html tidoust 23:16:15 RRSAgent, bye 23:16:15 I see no action items