18:00:38 RRSAgent has joined #mediawg 18:00:42 logging to https://www.w3.org/2024/09/26-mediawg-irc 18:00:42 Zakim has joined #mediawg 18:00:49 RRSAgent, make logs public 18:01:56 Meeting: Media WG - TPAC 2024 - Day 1/2 18:03:22 cpn has joined #mediawg 18:03:30 Present+ Chris_Needham 18:03:39 Agenda: https://github.com/w3c/media-wg/wiki/TPAC-2024 18:03:58 JohnRiv has joined #mediawg 18:04:27 nigel has joined #mediawg 18:04:49 present+ 18:05:14 Present+ Nigel_Megitt 18:06:01 present+ Francois_Daoust 18:07:50 sprang has joined #mediawg 18:07:53 hta has joined #mediawg 18:07:54 padenot has joined #mediawg 18:07:58 present+ 18:08:02 markw has joined #mediawg 18:08:06 wschi has joined #mediawg 18:08:08 jernoble has joined #mediawg 18:08:19 present+ Wolfgang Schildbach (observing) 18:08:25 xhwang has joined #mediawg 18:08:37 felipc has joined #mediawg 18:08:38 present+ Jer Noble 18:08:47 mjwilson has joined #mediawg 18:08:47 hta has joined #mediawg 18:09:55 Sun has joined #mediawg 18:10:21 scribe+ 18:10:28 Topic: Media WG introduction 18:10:47 cpn: We're building on the media foundations developed in former groups. 18:11:08 ... Goal is to improve the overall media playback experience on the web. 18:11:15 ... Beyond media playback with WebCodecs. 18:11:41 ... Current charter runs until May 2025. Marcos and I co-chair. François is our team contact. 18:12:16 cyril has joined #mediawg 18:12:23 Marcos has joined #mediawg 18:12:26 cpn: Looking at publication status of our specs, there's a mix bag of maturity levels and implementation levels. 18:12:38 present+ 18:12:38 ... We want to help drive interoperability. 18:12:43 present+ 18:12:50 present+ Xiaohan Wang 18:13:14 ... We'll talk about each spec in term. To progress them, for specs that are at WD, question is what needs to be done to move to CR. 18:14:28 ... Re. Media Playback Quality, the decision was to migrate this to HTML. It used to be part of MSE, then moved to a separate spec. We have not yet done the work to migrate the spec to WHATWG. We may discuss when is the right time to do that. There are a number of open issues against the spec to look at perhaps here before we migrate. 18:15:58 Marcos: In parallel among chairs and team contact, we've been looking at the specs and low-hanging fruits that we could address to help progress things forward. 18:16:39 ... Things that can help spec editors maintain the quality of their specs. 18:17:00 cpn: Some of the specs were authored with older versions of the spec authoring tools. We refreshed some of them, it took some time. 18:17:20 Marcos: That also helped uncover some things such as eventing models that are wrong. 18:17:57 ... There is machinery available to help detect that in parallel steps properly queue tasks before they resolve promises or fire events. 18:18:53 Anssi: Do you have a pipeline of new stuff coming into your group for the next cycle? For example, for Picture-in-Picture, there is Document Picture-in-Picture. 18:19:14 felipc6 has joined #mediawg 18:19:25 cpn: Discussed in the past. Document Picture-in-Picture being not focused on media in parallel, we felt that the Media WG would not be the right home for it. 18:19:38 q+ 18:19:50 ... In terms of other incubations, there are none that I'm aware of that with plans to adopt in the WG. 18:19:53 eric_carlson has joined #mediawg 18:20:26 markafoltz has joined #mediawg 18:20:32 Present+ Mark_Foltz 18:21:05 present+ eric_carlson 18:21:09 Marcos: The other part that we looked into is test coverage. We found that one of thems had funny test coverage that did not match the spec. I think that was Media Capabilities. The tests have weird steps on MIME interpretation that affect interoperability. 18:21:29 ... Some open issues got filed years ago by Boris. 18:21:35 ... Quite fun to read over. 18:21:50 anssik has joined #mediawg 18:22:21 Present+ Anssi_Kostiainen 18:22:28 Marcos: The main point being that, if you're a spec editor, you're also responsible for making sure that things that get merged in specs have corresponding tests. 18:22:47 ... Make sure that's all good. If you need a hand or are unsure, I'm happy to review things. 18:22:51 q? 18:22:55 q- 18:24:21 cpn: Picture-in-Picture has shipped in at least two engines, and has not really changed in a long time. There are a bunch of open issues. What we need here is help from editors to move these things over. Issues seem somewhat easily resolvable. 18:24:28 greg_f has joined #mediawg 18:25:01 ... The spec is in Working Draft state, and there's no real reason why it would be stuck at that level. I'd really want us to move forward. 18:25:37 dana has joined #mediawg 18:25:42 ... Horizontal reviews: accessibility and TAG reviews were done. We haven't done internationalization, privacy and security reviews. Any objection for us to initiate those? 18:26:06 ... Help wanted to complete the relevant preliminary questionnaires. 18:26:29 q? 18:26:31 louay has joined #mediawg 18:26:38 q+ 18:26:44 present+ Louay_Bassbouss 18:26:50 present+ 18:26:54 present+ 18:26:57 ... Current editor is François Beaufort 18:27:09 ack markafoltz 18:27:23 markafoltz: Is there an issue open to finish the Privacy and Security considerations? 18:27:34 cpn: We can create one if it's missing. 18:27:53 ... What I've done is creating a tracking issue for CR requirements as a whole 18:28:05 eugene has joined #mediawg 18:28:13 okin has joined #mediawg 18:28:29 present+ Eugene Zemtsov 18:29:20 Marcos: With the issues that are still open, the work is probably to check what implementations currently do, and adjust the spec with that. 18:30:05 cpn: For Autoplay Policy Detection. Alastor has done a great job at getting horizontal reviews. 18:30:15 ... There are a couple of privacy related feedback that need addressing. 18:30:26 ... We have a single implementation for now. 18:30:45 ... My question is around the level of interest for moving the spec forward. 18:30:59 q? 18:31:07 ... There was a lot of discussion on what the spec currently says. 18:31:45 jernoble: WebKit is supportive of the API. No time to work on implementation yet. To be honest, I had forgotten about it. No particular objection on the design. 18:32:10 cpn: The main open issue is on whether the API result should be binding or indicative? 18:32:32 jernoble: Was the issue opened before we switched to a sync API? 18:32:35 cpn: I think that was after. 18:32:47 ... Having more implementation experience with that would help. 18:33:21 jernoble: In the time since this was discussed, WebKit moved from requiring a user event to using a transient activation status of the document. 18:33:41 ... The answer will depend on when you ask the question since the API is sync. 18:34:00 ... We may have found a way around having to answer this question accordingly. 18:34:37 cpn: For Media Playback Quality, one thing I noticed is that we don't have great tests for it. I don't know how interoperable this is in practical terms. 18:35:31 ... We heard in the IG on Monday is that CTA WAVE has designed a testing framework with capturing cameras that can be used to detect actual rendered frames in a video. 18:35:48 ... It makes me wonder whether we can leverage some of this to create more useful tests. 18:36:16 ... We'll come back to the interoperability issues if we have time during the WebRTC discussion. 18:36:41 bernard: Also added a discussion on "corruption" in the agenda of the joint meeting. 18:36:55 subtopic: Media Capabilities 18:37:04 cpn: A number of open pull requests. 18:37:39 ... Anne commented that we had a concept of valid MIME type which wasn't properly defined. We re-worked the spec to make use of algorithms defined in MIME Sniff instead. 18:37:48 ... In doing so, we managed to simplify the specs quite a bit. 18:37:58 ... Bernard, I'd like your review on this. 18:38:26 ... It references RFCs for registration requirements. 18:38:48 ... I propose changing these to reference the IANA registries itself. 18:39:09 Bernard: We're going to close the RTP payload registry. We'll only keep the MIME type registry. 18:39:31 hta: It turned out that it was a badly maintained part of the overall MIME type registry. 18:39:45 Bernard: Right, just reference the main MIME type registry. 18:39:53 cpn: OK, I'll update the pull request. 18:40:01 ... Then I think it's good to merge. Thank you! 18:40:14 q+ 18:40:20 i/cpn: For Autoplay Policy Detection/subtopic: Autoplay Policy Detection 18:40:30 subtopic: Media Capabilities 18:41:50 i/cpn: OK, I'll update the pull request./ACTION: cpn to update the Media Capabilities PR to refer to the main MIME type registry 18:42:00 s/subtopic: Media Capabilities// 18:42:23 i/cpn: Picture-in-Picture has shipped/subtopic: Picture-in-Picture 18:42:33 RRSAgent, draft minute 18:42:33 I'm logging. I don't understand 'draft minute', tidoust. Try /msg RRSAgent help 18:42:35 RRSAgent, draft minutes 18:42:36 I have made the request to generate https://www.w3.org/2024/09/26-mediawg-minutes.html tidoust 18:43:01 q? 18:43:07 cpn: On Media Capabilities, ability to detect Dolby HDR support 18:43:49 Timo: The proposal is that, at the moment, the spec has 3 enum values. They are not sufficient to identify all cases, including Dolby Vision support. 18:44:21 ... Last year, we discussed the possibility of turning the enum into a registry. Both approaches would work with us. 18:44:35 ... Any comment and feedback on how to proceed and hopefully move to the next step? 18:44:48 jernoble: Is there a public spec we can point to? 18:45:05 Timo: Yes. There is enough information out there. 18:45:15 jernoble: That was a problem previously. 18:45:28 Timo: We also put a lot of resources into providing a test suite to the community. 18:46:05 cpn: What Media Capabilities is to report on the abilities to decode a stream. Not really in scope is display and rendering capabilities. 18:46:30 ... Does the Dolby Vision metadata need to be paired with some rendering capabilities? 18:46:39 ... Does a yes answer imply some rendering capabilities? 18:47:30 jernoble: What is the goal that apps would want from an answer? 18:47:56 ... Second question on rendering is what we punted to to CSS. 18:48:30 Timo: You could argue that there's still value in going to Dolby pipeline even if you're on SDR. 18:48:46 jernoble: Yes, but that's what you get from CSS already. 18:49:05 q+ 18:49:13 q+ 18:49:15 ... I'm curious what use cases are left unsupported, between CSS reporting these capabilities and Media Capabilities providing decode capabilities. 18:49:33 Timo: Will circle that with colleagues. 18:49:50 jernoble: It would be good to have that argumentation written down. 18:50:43 jernoble: I'm not saying that we shouldn't add those, but I'm curious about missing ones from Media Capabilities which I'm hearing might exist. 18:51:15 Timo: I guess we want to know what kind of homework you'd like us to do. 18:51:40 markafoltz: Understanding the pipeline model would be great. Where you see the information coming from, API and CSS. 18:52:03 ... If CSS says display is SDR but you still want to use Dolby Vision, do you need to know something else? 18:52:30 Timo: I guess it's a choice at this point because you then don't necessarily need Dolby Vision, but you may still want to use it. 18:52:41 cpn: I don't know that we completed everything on the CSS front. 18:52:59 q? 18:53:15 ... We talked about the possibility to query the video rendering plane capabilities independent of the graphics rendering plane. 18:53:52 ... What we didn't complete is [missed]. 18:54:18 jernoble: I don't remember there being different resolution for the video plane and the content plane. Certainly for colos support. 18:54:23 s/colos/color 18:54:25 q+ 18:54:43 cpn: I think that may be the case for some TV devices for which the video resolution may be higher than for content. 18:54:55 ack markafolts 18:54:55 ack markafoltz 18:55:02 ack wschi 18:55:02 ack xhwang 18:55:58 xhwang: I have some experience with Dolby Vision in browsers. My understanding is that there is a certification process. We basically ask the OS in Chromium. I'm trying to see whether the browser needs to have these capabilities or whether it can delegate to the OS. 18:56:15 ... Instead of browsers making a decision, that may be more a OS decision. 18:56:21 wschi: That makes sense to me. 18:56:29 xhwang: More a passthrough. 18:56:55 jernoble: In WebKit, it's the responsibility of the underlying OS as well, not the browser. 18:57:28 kota has joined #mediawg 18:57:29 i/cpn: For Media Playback Quality/subtopic: Media Playback Quality 18:58:09 xhwang: My understanding is that certification covers both decoding and rendering. 18:58:49 cpn: Is there a concern that answering the decoding question tells you something about the display? 18:59:15 xhwang: Fingerprinting? Possibly. 18:59:39 jernoble: The problem arises if you tie the answer to the display the browsing window is tied to. 19:00:11 ... The answer is supposedly immutable. Regardless of the current device context. 19:00:43 q? 19:01:01 jean-yves: On some low-end level, there can still be cases where it tries to reserve a decoder and falls back, so response can change. 19:01:17 dana has joined #mediawg 19:01:24 handellm has joined #mediawg 19:01:34 sprang has joined #mediawg 19:02:08 greg_f: For video playback dynamic range of protected content, I have been done that it's key system dependent. Some browsers implement multiple key systems, and whether a stream can be decoded and rendered depends on the pipeline you use. 19:02:42 jernoble: Was it a technical limitations where some CDM cannot support HDR or a policy limitation? 19:02:47 xhwang: I think it's mostly technical. 19:03:05 jernoble: Is the solution to say "no" to HDR for such streams then? 19:03:58 xhwang: That particular key system pipeline is implemented using a different pipeling altogether. 19:04:44 jernoble: I'm suggesting that if the CSS media query is unusable, then we should that problem down to media queries as bug report. That would solve the problem that people are seeing. Really, it's a problem of the EME pipeline. 19:05:41 padenot: In some instances, you need a particular combination of hardware and driver. If everything says yes and the provider is happy of the level of protection, you might get HDR bits. But all of these moving pieces need to agree. 19:06:20 xhwang: Do we still have an issue with clear Dolby support? 19:06:45 jernoble: We'd move away from Greg's question, specifically targeting protected video pipelines. 19:07:32 wschi: Most browsers do not deal immersive audio in the clear. If you deal with protected audio, then suddenly things work because the pipeline is different. 19:08:27 padenot: There could be an answer that says "in theory, we should be able to play this content", and then a check on the key system. 19:08:34 kazho has joined #mediawg 19:08:58 ... Do we want to integrate, one call / one answer, or are consecutive requests good enough? 19:09:27 markafoltz has joined #mediawg 19:09:27 jernoble: If you, as a user agent, know that the system is capable of displaying HDR, and the app still wants to render SDR? 19:09:31 q+ 19:09:46 padenot: Yes, per policy because the web site feels that it does not have enough protection. 19:10:00 ack g 19:10:07 jernoble: I'm trying to figure out how we would answer this policy question? 19:10:21 ... Is there not a way to ask that question with the EME API already? 19:10:40 xhwang: Level of robustness. 19:10:56 jernoble: In Fairplay, robustness is not really used. 19:11:21 ... Media Capabilities won't give you an answer. You will only know at key exchange step. 19:11:38 ... At least, it seems doable to request. 19:11:43 ... and know. 19:12:04 markafoltz: It seems there is a path already in Media Capabilities to query about clear and protected paths. 19:12:52 ... I don't think that we need to give the right answer all the time, because that may depend on current context. CSS approach is a good approach. Sticking to separating decoding and rendering. 19:12:58 jernoble: Except for audio ;) 19:13:21 xhwang: If content moves from one screen to another, then JS needs to ask again. 19:13:25 jernoble: Yes. 19:13:52 markafoltz: Video may not always be rendered on screen. 19:13:59 padenot: Even in encrypted scenarios? 19:15:05 cpn: Do we need an issue to capture that? Or do you think we'll capture that as part of the overall enum discussion? 19:15:19 markafoltz: Tracking the enum seems good. 19:16:08 cpn: Wondering whether we've come back to not going to a registry for this? 19:16:24 xhwang: Still a proprietary solution. 19:16:59 q+ 19:17:33 scribe+ 19:17:39 Francois: From a Process perspective, not enough to normatively reference, consider whether it comes from an open community, is it stable. Can't easily normatively reference a spec just because it's there 19:17:56 ack markafoltz 19:17:56 ack m 19:17:58 ack greg_f 19:18:16 q+ 19:18:26 greg_f: I'm wondering whether we need a Dolby specific mime type and HDR mime type. 19:18:35 ... I'm wondering whether that's sufficient to have one? 19:18:50 Timo: That was discussed before. I think the MIME type is not enough. 19:19:24 wschi: This is for cases where the MIME type does not specifically say it's Dolby, because it does not explicitly list all sets of metadata that you can use. 19:19:55 xhwang: In what case would applications actually query the HEVC MIME type + HDR Dolby Vision? 19:20:16 wschi: If you want to be backward-compatible, the MIME type has to be the base thing. 19:20:32 eric_carlson: Why not make more than one query with different MIME types then? 19:21:58 wschi: Maybe that is a solution. I think that has some repercussion on how the media needs to be specified. I'm sketchy on the details. 19:23:00 cpn: Looking at other issues. First, thanks for stepping up as editor, Mark. Any specific issue that you feel would be worth discussing? 19:23:27 q? 19:23:42 markafoltz: I only looked at issues we discussed over email, the ones that looked straightforward. 19:23:56 ... I prepared pull requests for some of them. 19:25:06 ... #152 has a PR now, I think. With a side comment that if there is a conflict between the MIME type and the transfer function, it will be reported as "not supported". 19:25:19 ... The PR reflects the current implementation in Chrome. 19:25:35 cpn: I'd like a reviewer from each engine to check whether it matches their implementation. 19:25:44 q? 19:25:54 ack w 19:26:09 tidoust: A corresponding test in WPT could help assess interoperability as well. 19:27:04 markafoltz: For #146, I debated whether this was worth a PR. About splitting the Audio/Video configurations into decoding dictionaries where most properties are shared, with specific properties specifically for decoding. 19:28:27 ... I think the changes should be compatible, but I cannot make a 100% guarantee right now. The meta question is: to move the two specific properties out, is it worth complicating the IDL? 19:28:43 cpn: I guess the proposal is to close this with no action, then. 19:29:05 markafoltz: If we foresee adding a lot of properties, but for two, I'm indeed not sure that's worth it. 19:29:40 ... I did a PR anyway just to see how the result would look. 19:30:06 cpn: The final thing I wanted to talk about is what to do about additional features that have been raised. 19:30:38 ... Whether we want to do work to address those or set a scope for what we consider suitable for a Candidate Recommendation, possibly to be extended in a v2 spec. 19:31:15 ... What I would propose is that we treat it that way. I'm not hearing strong support for capabilities for codec switching for example, so propose to defer. 19:31:48 RRSAgent, draft minutes 19:31:49 I have made the request to generate https://www.w3.org/2024/09/26-mediawg-minutes.html tidoust 19:32:02 markafoltz has joined #mediawg 19:41:31 nigel has joined #mediawg 20:22:18 markafoltz has joined #mediawg 20:22:42 nigel has joined #mediawg 20:39:13 nigel has joined #mediawg 20:48:21 nigel has joined #mediawg 20:53:48 q? 20:59:08 scribe+ cpn 20:59:33 Topic: Media / Web RTC Joint Meeting 20:59:49 markafoltz has joined #mediawg 21:04:22 nigel has joined #mediawg 21:08:52 felipc0 has joined #mediawg 21:20:37 nigel has joined #mediawg 21:23:40 nigel has joined #mediawg 21:24:06 nigel has joined #mediawg 21:24:27 nigel has joined #mediawg 22:24:10 kazho has joined #mediawg 22:59:38 Zakim has left #mediawg 23:01:19 s/subtopic:/topic:/g 23:01:26 RRSAgent, draft minutes 23:01:28 I have made the request to generate https://www.w3.org/2024/09/26-mediawg-minutes.html tidoust 23:16:57 nigel has joined #mediawg 23:29:14 markafoltz has joined #mediawg 23:34:07 sprang has joined #mediawg 23:34:12 Topic: Media Source Extensions 23:34:23 eugene has joined #mediawg 23:35:12 Subtopic: Detachable MediaSource 23:35:22 Jean-Yves: https://github.com/w3c/media-source/issues/357 23:35:42 ... Use cases is loading content for ads. Long latency to resume playback 23:35:51 ... Solution is multiple players, hide one behind the other. It's complex 23:36:03 ... Idea to have a MediaSource, when you create it's marked as detachable 23:36:31 ... When you detach from the HTMLMediaElement, e.g., by setting srcObject to null 23:36:53 ... The buffers attached to the SourceBuffer are deleted, so you can seek to where you were before and start playback 23:37:02 ... Concern about leaking MediaSources 23:37:15 Lei_Zhao has joined #mediawg 23:37:15 ... Currently, most MS are created by URL, and need to be manually revoked 23:37:40 ... Doesn't matter, remove the media element, it gets cleared, only leak small amount of data. But this would mean more data 23:37:50 i|Topic: Media WG introduction|Slideset: https://lists.w3.org/Archives/Public/www-archive/2024Sep/att-0013/Media_WG_Meeting_26_27_Sep_2024.pdf 23:37:56 ... Use the srcObject instead, to track via refcount, etc 23:38:04 xhwang has joined #mediawg 23:38:12 present+ 23:38:28 ... Attach to a MMS, so if out of memory you can flush content. Can't do this with MS 23:38:43 i/cpn: We're building on the media foundations/[slide 6] 23:38:45 ... I believe it's simple to implement 23:38:55 ... Added behind a feature flag, so you can test it 23:39:00 q? 23:39:00 eric_carlson has joined #mediawg 23:39:05 q+ 23:39:15 i/cpn: Looking at publication status of our specs/[slide 7] 23:39:47 nigel has joined #mediawg 23:40:01 nigel has joined #mediawg 23:40:13 Jean-Yves: [ Explains the behaviour ] 23:40:23 mjwilson has joined #mediawg 23:40:34 i/cpn: Picture-in-Picture has shipped/[slide 9] 23:40:36 i/cpn: Picture-in-Picture has shipped/[slide 10] 23:40:47 ... When you go to HAVE_NOTHING in network state, the currentTime is set to zero. If you reattach, you're into fetching and you'd seek to where you were before 23:41:02 i/cpn: For Autoplay Policy Detection/[slide 12] 23:41:24 i/cpn: The main open issue/[slide 13] 23:41:24 Xiaohan: Would implementation require a bigger context switch in the media pipeline? 23:41:44 Jean-Yves: In webkit ended up being a bigger change. The renderer has been torn down 23:42:03 i/cpn: For Media Playback Quality/[slide 15] 23:42:22 rrsagent, draft minutes 23:42:23 I have made the request to generate https://www.w3.org/2024/09/26-mediawg-minutes.html tidoust 23:42:29 ... Could consider suitable to keep the renderer and reuse it later. That's an implementation detail 23:42:39 q? 23:42:44 dana has joined #mediawg 23:43:08 Xiaohan: feedback from content providers? 23:43:46 Jean-Yves: Joey commented how they switch players by hiding. He described the workarounds 23:43:48 i/cpn: A number of open pull requests./[slide 34] 23:44:16 Joey: Wasn't specific to Shaka. Alternatives are to have two video elements and show and hide 23:44:32 ... On platforms without memory to do that, you have to tear down the stack and rebuild it 23:44:35 rahsin5 has joined #mediawg 23:44:52 ... I that situation, a detachable media source may not help as you still don't have memory 23:45:18 ... If you do have more memory, there's no technical limitation meaning you need a detachable MS in the first place. Might be convenient 23:45:54 i/cpn: Looking at other issues./[slide 35] 23:45:58 Jer: Other use case from FOMS, sometimes platforms have random decoder errors, sites workaround by flushing. THey want to avoid re-parsing the media data 23:46:56 Jean-Yves: May need to add ot the proposal that an error doesn't tear down the MS 23:47:22 Chris: Doing on both MS and MMS? 23:47:31 Jer: That's a question to the group. 23:47:41 i|Topic: Media Source Extensions|See -> https://www.w3.org/2024/09/26-webrtc-minutes.html joint meeting minutes 23:47:57 Jean-Yves: If you leak the blob, you can't force it to clear. If that's a conern, having it only on MMS allows you to correct the situation 23:48:09 q? 23:48:28 cyril has joined #mediawg 23:48:41 i|Jean-Yves: https://github.com/w3c/media-source/issues/357|[slide 21] 23:48:48 Joey: I'm fine with it, despite my complaining. Don't think it solves memory pressure 23:48:58 RRSAgent, draft minutes 23:49:00 I have made the request to generate https://www.w3.org/2024/09/26-mediawg-minutes.html tidoust 23:49:12 Jean-Yves: Doesn't aim to solve memory pressure, it's about quickly swapping two sources of content 23:49:28 Joey: This may be less common on newer devices with memory 23:49:47 Jean-Yves: But those wouldn't necessarily update to a newer API 23:50:04 Wolfgang: Any restriction to working with ?? 23:50:31 Jean-Yves: Can't interact with the MS when detached, because it's closed 23:50:37 ... States are closed, open, and ended 23:50:57 ... When detached it's effectively closed 23:51:12 Wolfgang: Can I fill the source buffers when detached? 23:51:35 Jean-Yves: Not having t add a new state simplifies the logic and use of the API 23:51:44 Eric: We could add a detached state 23:52:18 Wolfgang: Useful for ad-insertion case, as it lets you fill the source buffer? 23:52:31 Jer: Not proposing allowing appends to a detached MS 23:52:49 Xiaohan: Memory leaks 23:53:20 Jean-Yves: You have to revoke the URL. In Chrome, WebKit and Blink, it's not revokable 23:53:29 Xiaohan: But only after detach 23:53:58 Jean-Yves: Currently, you create the URL, delete the source attribute in the media element, then revoke the url 23:54:58 ... WOuld be nice to throw at the time to attach the source. But the algorithm is synchronous, so only know on next time around the loop 23:55:45 Chris: Want to see interest 23:55:52 Eric: Get feedback at FOMS 23:56:19 Chris: Upcoming MEIG with WAVE 23:56:52 Greg: I'm in favour of this. Sounds like it would be easier to use. 23:57:16 ... Cases when transitioning from spatial to non-spatil audio wouldn't work, useful there 23:57:37 q? 23:58:19 Subtopic: MSE and Text Tracks 23:58:46 Nigel: This has been raised before. In MSE you can put audio and video in, you can't put text tracks. Seems odd 23:59:05 ... To summarise the discussion from Monday. A few people said they'd like it, nobody said they wouldn't like it 23:59:32 ... The motivation to add it is simplify player code by making text track information buffering same as audio and video 23:59:57 ... One point not resolved, is what payload data format should be used, and what's the rendering model