00:00:09 -> https://github.com/w3c/webcodecs/issues/198 Emit metadata (SPS,VUI,SEI,...) during decoding #198 00:00:33 DanS: with our metadata proposal, the way to do it is relatively clear, the question is really platform support 00:00:54 Subtopic: w3c/webcodecs #371 AudioEncoderConfig.latencyMode (or similar) extension 00:01:01 q+ 00:01:07 youenn has joined #mediawg 00:01:17 -> https://github.com/w3c/webcodecs/issues/371 AudioEncoderConfig.latencyMode (or similar) #371 00:01:31 -> https://github.com/w3c/webcodecs/issues/405 Fixed audio chunk size support #405 00:01:42 tguilbert: these 2 issues may be the same issue 00:01:47 paul: indeed, probably overlap 00:02:13 ... it's mostly something we need to do 00:02:53 ... in terms of codecs it will apply to: most codecs are fixed-size frame, but OPUS, @@@ and FLAC (not adapted to real-time) 00:03:04 ... adding it to OPUS registry would work 00:03:19 Bernard: 405 is adding ptime - doesn't need to be codec specific? 00:03:30 Issue 405 is about ptime... should be for all codecs, no? 00:03:40 tguilbert: if we expose latency mode on audio encoder, the meaning may differ across codecs 00:03:57 Bernard: Question about "latency mode": for video, the knob doesn't seem to make much difference in latency... 00:04:01 q? 00:04:02 ... so a per-codec setting might be better than a generic low-latency/high-quality toggle 00:04:14 Subtopic: w3c/webcodecs #270 Support per-frame QP configuration by VideoEncoder extension 00:04:30 -> https://github.com/w3c/webcodecs/issues/270 Support per-frame QP configuration by VideoEncoder #270 00:04:41 nigel has joined #mediawg 00:04:56 eugene: QP tends to be codec specific 00:05:27 ... the advice we're getting from people working with codecs is to not try to use a common denominator approach 00:05:37 ... they want finegrained controls to tune this 00:05:52 ... so we're working towards a codec specific approach via settings in the registry 00:05:58 q? 00:06:35 ack ber 00:06:44 Bernard: the cool thing about per-frame QP is that it can have an impact on congestion control 00:07:07 ... re latency mode - I've been playing with it on the video side, when I set it to "quality", it doesn't seem to make any difference in latency 00:07:22 ... and it generates fewer keyframes, which improve the transport latency 00:07:26 ... is that intended? 00:07:48 eugene: this is implementation specific, it's hard to tell without more details on the encoder 00:08:02 ... the API is not trying to be creative, it reflects the knobs from the encoder 00:08:21 ... please send me links to your code sample and I'll take a look 00:08:33 ... it's not the intended behavior 00:08:35 q? 00:08:43 q- 00:09:32 Topic: Wrap up 00:09:42 CPN: who are the relevant WGs we need to coordinate with? 00:10:06 Bernard: I had missed the XR folks in my list 00:11:05 Dom: For the architecure we need the WGs more than IGs 00:11:11 present+ Kenaku_Komatsu 00:11:30 ... For the media pipeline, not sure WHATWG stream is needed to be involved in the architecture 00:11:31 i/For the/scribenick: cpn/ 00:11:53 Bernard: WHATWG streams are a black box, difficult to see how much latency is contributed 00:11:53 rrsagent, draft minutes 00:11:53 I have made the request to generate https://www.w3.org/2022/09/16-mediawg-minutes.html kaz 00:12:21 Dom: As we go through this and collaborate on code samples, some issues may need to be surfaced to WHATWG streams 00:12:32 present+ Youenn_Fablet 00:12:37 ... Who do we need at the table to design the pipeline? 00:12:58 ... Suggest doing it iteratively, then convince people to contribute to it 00:13:06 present+ Eric_Carlson 00:13:21 present+ David_Singer 00:13:26 ... Let's start with those already here, then when we find pieces we don't understand in depths, reach out to the relevant groups 00:14:07 ... Workshop with several components. It's an interesting idea to run a workshop. Once we have an initial architecture, we'll know who to invite 00:14:24 ... So suggest starting small and iterate. Once we get stuck, extend the conversation 00:14:59 ... The real question is to find people committed to look at it. May be harder to find than people willing to work on the solutions 00:15:11 ... Who'd be willing to drive it? 00:15:12 q+ 00:15:22 Bernard: I'm one person, but don't know all the pieces 00:15:32 Peter: I volunteer, for the parts I know about 00:15:47 Bernard: Would be helpful to have sample code that illustrate problem points 00:16:20 ... We have some in WebCodecs, spend time developing samples. Particularly encourage the AR/VR people to try out WebCodecs 00:16:34 ... What kinds of sample could would be illustrative? 00:17:05 Dom: I think we should take the use cases and identify integration points. Some may not be possible, and what would it take to make them possible would be an outcome? 00:17:39 ChrisN: Where to host the repo? 00:17:56 Dom: Something like media-pipeline-architecture under w3c github 00:18:24 Bernard: IETF have hackathons, could that be a useful thing? Does w3c do that? 00:18:49 Dom: If we have sponsors and a time and place, it's possible. I have less experience with virtual hackathons 00:18:59 ... Could be investigated as part of the workshop idea 00:19:32 Cullen: An IETF hackathon could be welcome. Agree with Dom, virtual hackathons haven't been so successful compared to having people in the room 00:20:08 q+ 00:20:14 ... Next IETF is London in October. They'd be happy if we showed up to hack there 00:20:20 ack peter 00:20:21 ack p 00:20:22 ack kaz 00:20:47 s/October/November/ 00:20:56 kaz: Web of things wg has been holding plugfests, with @@@ to help separate remote collaboration 00:21:05 s/@@@/SoftEther VPN/ 00:21:14 ack k 00:21:35 CPN: we've done a few ad-hob joint meetings between our 2 groups 00:21:45 ... when should we plan our next? 00:22:34 Dom: How long would it need to do some initial work to bring to that meeting? 00:22:52 Bernard: Depends on the topic. A month or two for sample code. 00:23:04 Dom: So perhaps end of October 00:23:12 Bernard: Aligns with IETF 00:23:20 rrsagent, draft minutes 00:23:20 I have made the request to generate https://www.w3.org/2022/09/16-mediawg-minutes.html kaz 00:23:56 Bernard Aboba: Present 00:24:16 Will has joined #mediawg 00:24:20 present+ Bernard_Aboba 00:24:23 [adjourned] 00:24:24 present+ Eric Carlson 00:24:25 rrsagent, draft minutes 00:24:25 I have made the request to generate https://www.w3.org/2022/09/16-mediawg-minutes.html kaz 00:24:37 bneedham has left #mediawg 00:32:34 q+ 00:32:42 q= 00:32:44 q- 00:56:49 nigel has joined #mediawg 01:01:17 nigel has joined #mediawg 01:03:25 hfujisawa has left #mediawg 01:03:30 nigel has joined #mediawg 01:11:13 nigel_ has joined #mediawg 02:45:31 miseydl has joined #mediawg 04:12:23 Zakim has left #mediawg 04:27:20 eeeps has joined #mediawg 20:58:55 RRSAgent has joined #mediawg 20:58:55 logging to https://www.w3.org/2022/09/16-mediawg-irc 20:59:01 Zakim has joined #mediawg 20:59:03 nigel has joined #mediawg 20:59:08 Meeting: Media WG 20:59:23 Chair: Chris_Needham 21:00:04 miseydl has joined #mediawg 21:00:29 miseydl_ has joined #mediawg 21:01:16 present+ Matt_Wolenetz 21:01:20 Present+ Dan_Sanders, Hiroshi_Kajihata, Francois_Daoust, Peter_Thatcher, Eric_Carlson, Tuukka_Toivonnen 21:01:42 ken has joined #mediawg 21:02:03 +present 21:02:14 present+ Xiaohan_Wang, Michael_Seydl, Hiroshi_Kajihata, Greg_Freedman, Alastor_Wu 21:02:33 Present+ 21:02:47 eugene has joined #mediawg 21:03:22 present+ 21:03:28 present+ 21:03:29 present+ 21:03:33 present+ Eugene_Zemtsov 21:03:39 tguilbert has joined #mediawg 21:03:44 present+ 21:03:47 present+ Thomas_Guilbert 21:03:47 present+ 21:03:57 Bernard_Aboba has joined #mediawg 21:03:58 present+ 21:04:00 youenn has joined #mediawg 21:04:06 Chris_Lemmons has joined #mediawg 21:04:10 eric-carlson has joined #mediawg 21:04:27 +Observing. :) 21:04:36 present+ Eric Carlson 21:04:38 peter has joined #mediawg 21:04:50 present+ Peter Thatcher 21:05:44 plh has joined #mediawg 21:06:12 tovep has joined #mediawg 21:07:21 jernoble has joined #mediawg 21:07:30 present+ Jer Noble 21:08:15 present+ Tove_Petersson 21:08:30 Xiaohan_Wang has joined #mediawg 21:08:46 scribe: tidoust 21:08:52 Agenda: https://www.w3.org/events/meetings/25bfcb9a-473c-48da-b44c-9bca49e39be7 21:08:57 Topic: Agenda bashing 21:09:06 cpn: [reviewing the agenda] 21:09:36 ... Re. WebCodecs, some follow-up to yesterday's discussion with WebRTC WG. 21:10:23 ... Then Autoplay Policy Detection, Media session issues and session capture and an introduction on Document Picture in Picture API. 21:10:31 ... Suggestions to changes/additions? 21:10:36 igarashi__ has joined #mediawg 21:10:48 present+ Tatsuya_Igarashi 21:11:36 [some discussion on switching agenda topics to accommodate early flights back] 21:14:26 Topic: Media WG Introduction 21:14:49 cpn: Mission is to develop media specifications to improve media support on the web. 21:15:10 ... Looking at an overview of the specs as they stand. 21:15:38 ... MSE v2, we're at WD. Question is then: what do we think we need to publish a CR? 21:16:16 ... For EME v2, we made a number of updates, but they are in an ED. I'd like to get a sense of where we are towards publishing a FPWD. 21:16:45 ... Media Capabilities is pretty mature. It is not on the agenda but it would be interested to understand the blockers towards publication as CR. 21:16:57 Slideset: https://lists.w3.org/Archives/Public/www-archive/2022Sep/att-0011/Media_WG_Meeting_16_Sep_2022.pdf 21:17:02 [slide 7] 21:17:18 ... Media Playback Quality is complete but we agreed to integrate that into HTML and we need someone who can help do that. 21:17:38 ... Autoplay Policy Detection was published as FPWD. We probably want to initiate horizontal reviews. 21:18:13 ... WebCodecs, some question on publishing the registry as a real W3C Registry now that there is such a track, instead of as a draft Note. 21:18:37 ... For both Media Session and Picture-in-Picture, some of these are implemented and deployed. What are the steps to progress these to CR? 21:19:02 ... Picture-in-Picture is more complete in its scope, Media Session more open following recent discussions on presentation actions. 21:19:31 Topic: Media Source Extensions v2 21:19:34 [slide 8] 21:19:56 Matt_Wolenetz: Approximately 20 issues to go through but we won't have time to go through all of them. 21:20:00 ghurlbot has joined #mediawg 21:20:07 Repository: w3c/media-source 21:20:29 ... Two goals here today: present the current status. 1) What changed since the Recommendation. 2) Get some feedback on priorities for v2. 21:20:53 ... If you're interested in any of these features, please reach out directly to me or through the GitHub repository, I'm interested! 21:21:13 #100 21:21:18 https://github.com/w3c/media-source/labels/TPAC-2022-discussion 21:21:27 ghurlbot, this is w3c/media-source 21:21:27 tidoust, OK 21:21:35 dezell has joined #mediawg 21:21:36 #100 21:21:39 https://github.com/w3c/media-source/issues/100 -> Issue 100 Have appendBuffer and remove return promise. (jyavenard) TPAC-2022-discussion 21:21:41 present+ 21:22:20 Matt_Wolenetz: Since Rec, we landed one major feature: changeType. It's been used for a lot of different things. AV1/VP9 switching for instance. 21:22:35 ... Without user visible pauses. 21:22:52 ... Second feature: MSE in workers is in the specification. One question to answer today. 21:23:18 ... We had to unship the feature due to backward incompatibility issues with other MSE features. 21:23:36 dsinger has joined #mediawg 21:23:44 ... The issue tracker lists a number of features that could be considered for v2. 21:23:55 Matt_Wolenetz: Back to issue 100. 21:24:31 ... Have appendBuffer and remove return promise. That seems pretty obvious to me. 21:24:43 ... If you see blockers, speak up now or comment on the issue tracker. 21:24:59 i/Matt_/Subtopic: Issue #100 21:24:59 Matt_Wolenetz: Next one is #232 21:25:00 https://github.com/w3c/media-source/issues/232 -> Issue 232 Define a preemptive eviction MSE API for low-memory platforms (wolenetz) feature request, TPAC-2022-discussion 21:25:02 Subtopic: Issue #232 21:25:38 Matt_Wolenetz: What a conforming implementation might do with regards to picking up ranges for buffer eviction. 21:25:40 nigel has joined #mediawg 21:26:21 q? 21:26:23 q+ 21:26:38 ... To my knowledge, the only remaining technical blocker for getting MSE implemented on small device such as iOS is pre-emptive buffer eviction mechanism. 21:27:31 ... ManagedMediaSource and ManagedSourceBuffer could perhaps be used to distinguish cases with pre-emptive eviction from those without. 21:28:12 q? 21:28:21 ack jernoble 21:28:29 nigel has joined #mediawg 21:28:59 jernoble: I was thinking along the same lines, not necessarily about new objects but some configuration objects to switch to a different mode. 21:29:06 nigel has joined #mediawg 21:29:19 ... Whether it's a completely new object or some mode, we can bikeshed a lot but that's eventually the same. 21:29:58 q? 21:30:05 ... There is a little more SF concept. On iOS, they can mark certain memory as purgeable. We certainly don't want to expose memory purging to JS. 21:30:17 ... But we need to do something about it. 21:30:47 Matt_Wolenetz: To be clear, that's not only about iOS, Chrome implementation also could use some low-memory signals we get from the OS. 21:31:08 ... Look forward to working with you on that. That would be super for the ecosystem. 21:31:15 cpn: What needs to happen next? 21:31:45 Matt_Wolenetz: A PR would be a great starting point for a discussion on whether to use new objects or a new mode. 21:31:56 ... External contributions absolutely welcome on this. 21:32:10 Subtopic: Issue #189 21:32:10 https://github.com/w3c/media-source/issues/189 -> Issue 189 Add Support for Media-Encoded Events (tinskip) feature request, question, TPAC-2022-discussion 21:32:25 q+ 21:32:54 Matt_Wolenetz: Discussed extensively at last TPAC. Add support for DataCue exposure of in-band metadata in emsg boxes. 21:33:03 ack cpn 21:33:15 cpn: I think it was TPAC 2019. 21:33:29 ... Since then, we've been very slowly working on the DataCue API. 21:33:53 nigel has joined #mediawg 21:34:01 nigel has joined #mediawg 21:34:15 cyril_ has joined #mediawg 21:34:15 ... Two things: the DataCue API could be entirely separated from MSE. The current approach is to use a VTTCue but it would be good to be able to do that with any kind of cue. 21:34:44 ... Looking at the DataCue implementation that Webkit has, the proposal is that we standardize on that for the API shape. 21:34:59 ... Really, I'm looking for explicit support from implementers. 21:35:06 -> https://github.com/WICG/datacue/blob/main/explainer.md DataCue explainer 21:35:08 nigel has joined #mediawg 21:35:12 ... Separated from that, there's the question of in-band events. 21:35:15 RRSagent, pointer 21:35:15 See https://www.w3.org/2022/09/16-mediawg-irc#T21-35-15 21:35:30 RRSAgent, draft minutes 21:35:30 I have made the request to generate https://www.w3.org/2022/09/16-mediawg-minutes.html dom 21:35:36 ... The browser could extract those and surface them to the application through DataCue. 21:35:48 ... There has been some collaboration with DASH-IF. 21:36:25 ... Constrained devices don't want to have to touch the media twice. The argument I hear is that parsing the container for metadata is not computationally expensive, so could be done through scripts. 21:36:50 ... For more constrained devices, the question still stands. 21:37:19 nigel has joined #mediawg 21:37:29 ... Parsing and exposing through MSE could be a direction. Here as well, I'm looking for explicit support for that. 21:37:52 ... We don't want to figure out the details of how everything works without some initial expression of support. 21:38:17 Matt_Wolenetz: The Chromium implementation for even in-band text has been removed from MSE. 21:38:45 ... If we're going to expose in-band metadata somehow, it would certainly be some non-trivial impementation work. 21:39:06 nigel has joined #mediawg 21:39:46 ... Interactions with timestamps could perhaps trigger weird behavior that need to be looked into if we integrate that in MSE. 21:40:47 cpn: Should I take that as a semi-positive feedback? 21:41:14 Matt_Wolenetz: Sure, it would be good to have external input. It would help speed up specification work. 21:41:22 ... External PRs would be helpful. 21:41:56 cpn: That's where we struggle perhaps. People in DataCue are more from the media container angle, not experts in MSE. 21:42:15 q? 21:42:35 Matt_Wolenetz: If there's a bytestream format that this would be particularly tied with, people could consider looking into that first and pointing out where precisely things need to happen. 21:42:54 Subtopic: MSE v2 feature prioritisation and developer input 21:43:08 dsinger has joined #mediawg 21:43:09 #175 21:43:12 https://github.com/w3c/media-source/issues/175 -> Issue 175 MediaSource in Worker (DanielBaulig) feature request, needs follow-up, TPAC-2022-discussion 21:44:41 Matt_Wolenetz: One issue wasn't caught that since the main thread implementation throws when handle is not available, the MSE in worker feature introduces a backward incompatibility that affects existing products. 21:44:54 Gary: Old version of video.js typically 21:45:16 Matt_Wolenetz: 2 options: restrict that getter visibility to only the dedicated Worker context. 21:45:30 ... Even there we would change it to never throw an exception. 21:45:49 ... The alternative is to return null if it's not supported instead of throwing an exception. 21:45:50 q+ 21:46:10 nigel has joined #mediawg 21:46:22 ack jer 21:46:24 ... We'd have to specify that through text as WebIDL does not allow that to be expressed directly. 21:46:43 nigel has joined #mediawg 21:46:45 jernoble: Do we have an articulated use to be able to access the handle from the main thread? 21:47:03 Matt_Wolenetz: For now, no. But there is something on that table. 21:47:27 +1 to visibility instead of null 21:47:47 jernoble: My vote would be to do the hidden option. If we do have that use case, we can extend it afterwards. 21:48:01 Matt_Wolenetz: Thanks. That helps. 21:48:31 gregwf has joined #mediawg 21:48:33 Matt_Wolenetz: that also includes not throwing an exception 21:48:48 Next, group of issues: (#259, #209, #172, #40, #35) relating to "introspection API". 21:48:49 https://github.com/w3c/media-source/issues/35 -> Issue 35 Report buffer changes in update events (dmlap) feature request, TPAC-2022-discussion 21:48:49 https://github.com/w3c/media-source/issues/209 -> Issue 209 Expose SourceBuffer as an ArrayBuffer (guest271314) feature request, TPAC-2022-discussion 21:48:49 https://github.com/w3c/media-source/issues/259 -> Issue 259 Consider adding support for apps to get metadata about what is currently buffered (wolenetz) TPAC-2022-discussion 21:48:50 https://github.com/w3c/media-wg/issues/35 : TPAC 2022 planning 21:48:50 https://github.com/w3c/media-source/issues/172 -> Issue 172 Consider adding API for app to know how much room is left in the SourceBuffer (wolenetz) feature request, needs author input, needs follow-up, TPAC-2022-discussion 21:48:54 https://github.com/w3c/media-source/issues/40 -> Issue 40 Needs event to notify when sourceBuffer needs more data (stnishimura) feature request, TPAC-2022-discussion 21:49:49 Matt_Wolenetz: A group of 5 issues to come next. First on exposing SourceBuffer as an ArrayBuffer. 21:50:23 ... Both are related. Getting metadata. 21:50:43 ... Better visibility about what is still buffered. 21:51:01 eric-carlson has joined #mediawg 21:51:23 ... These have all received mixed expression of interest. I would like to get better and more explicit expressions of support and details on how these features would be used. 21:51:25 q? 21:51:37 #185, #14 21:51:38 https://github.com/w3c/media-source/issues/14 -> Issue 14 Update SourceBuffer.appendStream() and related algorithms to use ReadableByteStream (wolenetz) feature request, blocked, needs follow-up, TPAC-2022-discussion 21:51:39 https://github.com/w3c/media-source/issues/185 -> Issue 185 Feature Request: Implement appendBuffer(blob) (beaufortfrancois) feature request, TPAC-2022-discussion 21:51:39 https://github.com/w3c/media-wg/pull/14 : Fix broken links in agenda doc 21:52:13 Matt_Wolenetz: Moving to 14, which was cut from the Rec because implementations had not caught up with the spec. 21:52:39 ... Maybe add a readable endpoint so that you can fetch and pipe. 21:52:51 eric-carlson__ has joined #mediawg 21:53:13 cpn: I think that was one that Zach was particularly interested into. 21:53:21 ... We can probably get some input from him. 21:53:51 jernoble: You said this could help with fixing low-memory conditions. Could you expand on them? 21:54:46 Matt_Wolenetz: Trying to recall. Buffer eviction. Previous prototype was around cases where we provide P-frames very infrequently 21:55:47 jernoble: Interesting that we're contemplating giving back control to the user agent whereas the whole motivation for MSE was to take it away from it. 21:56:07 Matt_Wolenetz: OK, I'll follow-up with Zach from Disney on this one 21:56:14 #184 21:56:14 https://github.com/w3c/media-source/issues/184 -> Issue 184 Enable buffering of WebCodecs Encoded Chunks for playback with MSE - aka "MSE for WebCodecs" or "MSE4WC" (AndrewMD5) TPAC-2022-discussion 21:56:58 Matt_Wolenetz: Next one is linked to buffering WebCodecs encoded chunks for playback with MSE. 21:57:05 #302 21:57:05 https://github.com/w3c/media-source/issues/302 -> Pull Request 302 MSE-for-WebCodecs draft feature specification (wolenetz) 21:57:24 ... MSE for WebCodecs was in origin trial in Chromium but interest seems to be relatively low. 21:57:37 q+ 21:57:46 ... If you are very interested by this issue, please speak up, otherwise we'll just remove the feature. 21:58:24 ack cpn 21:58:28 cpn: From WebCodecs, you can receive and decode. If you want to render, you need to integrate a lot of concepts such as buffering. With this feature, would that give a way to hand things over to the user agent? 21:59:07 Matt_Wolenetz: I think DASH.js does transmuxing from MPEG-TS to MP4 and feeds that into MSE. That could simplify things. 21:59:55 q+ 22:00:14 s/DASH.js/HLS.js 22:00:28 ack Bernard_Aboba 22:00:28 ... I didn't get enough support to create a full pipeline and see how that would improve things. 22:01:17 Bernard_Aboba: I actually know some customers of HLS.js that are very interesting in low latency. Would it be useful to reach out to them? 22:01:26 Matt_Wolenetz: Yes, it would be useful to have more active participation. 22:01:27 q? 22:01:50 cpn: We're reaching the end of the allocated time. 22:02:27 Matt_Wolenetz: Yes, there are a bunch of them. Audio PCM support. Main thread SourceObject attachment. Long been asked for. 22:02:50 jernoble: Don't we already have it? I'm pretty sure we have it in Safari. 22:03:07 Matt_Wolenetz: You probably do, and Firefox as well I think, but it's not in the spec. 22:03:25 ... And then a bunch of interoperability issues, mostly around timing. 22:04:03 ... These are lower-complexity issues. 22:04:06 [MediaSource as a valid value for srcObject has been in HTML for quite some time IIRC https://html.spec.whatwg.org/multipage/media.html#media-provider-object ] 22:04:35 cpn: Live stream and playback through unbuffered ranges is something we're interested in at BBC. 22:04:52 ... For those interoperability, we can schedule a future call and go through those. 22:06:36 Topic: Media Session 22:06:41 ghurlbot, this is https://github.com/w3c/mediasession 22:06:41 dom, OK 22:06:44 [slide 14] 22:07:00 #274 22:07:01 https://github.com/w3c/mediasession/issues/274 -> Issue 274 [closed] Should we add slide presentation specific actions? (youennf) 22:07:05 Subtopic: Media Session & WebRTC 22:07:42 #284 22:07:43 https://github.com/w3c/mediasession/issues/284 -> Pull Request 284 [closed] Add presenting slides actions (beaufortfrancois) 22:07:55 eugene_ has joined #mediawg 22:08:07 cpn: We had a call with Media Session editors and WebRTC folks to add slide presentation specific actions. We got agreement to add support for them in Media Session. 22:08:14 youenn: PR merged this morning. 22:08:29 -> https://w3c.github.io/mediacapture-handle/actions/ The Capture-Handle Actions Mechanism 22:08:30 ... Next step is implementation. Other part is reusing in Media Capture Actions. 22:09:06 ... This work should probably be tackled within the WebRTC WG since it owns the Media Capture Handle Actions. 22:09:19 q+ elad 22:09:20 cpn: Media Session only defines the action ids? 22:09:23 youenn: yes. 22:09:26 ack elad 22:09:27 ack elad 22:09:52 elad: More things will be needed. Right now, if you get the event, you don't know whether it got delivered by the user or by a presentation. 22:10:01 ... You don't know what the user intended. 22:10:30 ... That's ok provided the application that receives these events is willing to treat them regardless of where they were issued. 22:10:40 ... I think something needs to be added. 22:11:06 youenn: Yes, but that's still very early and indeed the security model needs to be defined for media capture actions first. 22:11:11 #285 22:11:12 https://github.com/w3c/mediasession/issues/285 -> Issue 285 The active media session might not be the only one being notified of actions (youennf) 22:11:13 eugene has joined #mediawg 22:11:55 youenn: This discussion led us to next issue. There are cases where the media session is not active but you still want to send the actions. 22:12:17 ... A page still needs to be notified. 22:12:24 #287 22:12:25 https://github.com/w3c/mediasession/issues/287 -> Pull Request 287 Introduce the possibility for a source to be tied to a specific media session (youennf) 22:12:45 ... If the source is not tied to a particular media session, we may want to associate it with an active one, 22:13:01 ... The PR is available. I don't think it has been reviewed yet. 22:13:27 Tommy_Steimel: Just to be clear, it does not change the actual API, right? 22:13:34 youenn: That's correct. 22:13:40 ... No implementation change. 22:14:09 Subtopic: Status of AudioFocus API #277 22:14:09 https://github.com/w3c/mediasession/issues/277 -> Issue 277 Status of AudioFocus API (chrisn) 22:14:40 q? 22:14:54 cpn: I noticed that if we define more precisely AudioFocus, we can define more precisely what happens in media session. 22:15:34 youenn: It's a good idea. We should spend time on that. I know that we have some user experiences which are not great. E.g. in iOS when you're mixing audio and microphone for instance. 22:16:03 ... AudioFocus would allow to tune the user experience. I'm hoping that I'm not alone here and that other implementers are interested. 22:16:14 q+ 22:16:19 -> https://github.com/WICG/audio-focus/blob/main/explainer.md AudioFocus API Explainer 22:16:20 Tommy_Steimel: Specifically with Media Session or AudioFocus as standalone? 22:16:54 youenn: The fact that you're suspended and when it happens in iOS would be very cool. It could be tied to Media Session. But just on its own, it's good as well. 22:18:13 ... On iOS, only one application is able to run audio. If a page plays audio and you e.g. switch to Youtube, audio will stop. But the app does not know it got suspended. 22:18:26 ... So it won't know whether it can resume either. 22:18:49 ... It would also allow you to specify applications that can blend well with other applications. 22:19:35 eric-carlson: An example. "I play audio that's fine to mix with others". If you play file based audio, we assume that it cannot be mixed with others. 22:20:01 ... Whereas you may have an app that plays an MP3 audio file when an event occurs and it will interrupt the audio. 22:21:00 padenot: Are we going to send notifications to say something else is attempting to play? Or are we going to fire an event to say you've been interrupted? 22:21:11 q? 22:21:15 ack pa 22:21:24 eric-carlson: That happens at a lower level, we cannot interrupt that. 22:22:02 padenot: I'm trying to remember why previous proposal stalled. 22:22:40 ... Regardless of the technicalities, I would also like to have something like this on the platform. 22:23:16 youenn: Also a problem with audio level on iOS. Mike level is different from audio level. No way for the browser to know which level to use. 22:23:44 elad: Is this purely specific to iOS? 22:23:52 youenn: Also on MacOS. 22:23:58 elad: What about Windows? 22:24:05 [not sure] 22:24:26 scribe+ cpn 22:24:28 Tommy_Steimel: We do some amount of something similar to the AudioFocus API internally. 22:24:32 s/[not sure]/Paul: there is something equivalent on android and windows 22:25:02 ... I don't know of definitive use cases in Chrome that would make use of it. 22:25:29 cpn: It seems that we're looking for someone who could pick up the explainer and progress that. 22:25:50 youenn: I have limited time but willing to look into it. At some point, it was part of the Media Session specification. 22:26:02 ... I can understand why it was there in the first place. 22:26:07 e.g. Windows, https://docs.microsoft.com/en-us/windows/win32/coreaudio/stream-attenuation 22:26:45 ... If it's less premature, it could perhaps be worth re-introducing it in the spec. 22:28:03 -> https://www.w3.org/2021/07/media-wg-charter.html#potential-normative Potential Normative Specifications, includes "Audio Focus API" 22:29:20 [group looking at charter, audio focus is a "potential normative specification" so no problem adopting it in the group if it is believed it is sufficiently mature] 22:29:53 Subtopic: Media Session and Web Audio 22:29:54 Subtopic: Media Session and Web Audio 22:30:07 #244 22:30:08 https://github.com/w3c/mediasession/issues/244 -> Issue 244 Work without an