21:56:15 RRSAgent has joined #mediawg 21:56:19 logging to https://www.w3.org/2023/11/14-mediawg-irc 21:56:19 Zakim has joined #mediawg 21:56:23 RRSAgent, make logs public 21:56:40 Meeting: Media WG monthly call 21:57:00 Agenda: https://github.com/w3c/media-wg/blob/main/meetings/2023-11-14-Media_Working_Group_Teleconference-agenda.md 22:01:27 Present: Chris_Needham, Bernard_Aboba, Jean-Yves_Avenard, Francois_Daoust 22:02:48 Present+ Sun_Shin, Mark_Watson 22:03:54 present+ Andy_Estes 22:04:58 present+ Marcos_Caceres, Sushanth_Rajasankar, Xiaohan_Wang, Thomas_Guilbert 22:05:27 Chair: Chris, Marcos 22:05:50 present+ Dale_Curtis 22:06:12 scribe+ cpn 22:06:40 xhwang has joined #mediawg 22:07:02 marcosc has joined #mediawg 22:07:18 scribe: marcosc 22:07:45 cn: we have a couple of web codec issues we could cover 22:07:58 Topic: Managed Media Source 22:08:07 tguilbert has joined #mediawg 22:08:26 https://github.com/w3c/media-source/pull/329 22:08:30 cn: we have a pull request open to add it 22:09:18 sushraja_MSFT_ has joined #mediawg 22:10:06 cn: question is, is it ready to merge? What's outstanding? Looking at the PR, there have been a lot review and comments. Matt has left a bunch of comments, so we could use this meeting time to look at some of those. We are getting positive signals of support. It might be good land the PR and then do followup. 22:12:21 jya: I went through the comments. A lot of it were playing on semantics, but doesn't have substantive impact. However, it's really up to the player when more data, etc. however, it doesn't make a difference on the implementation level (as implementation will vary). Similarly, the requirements for memory are deliberately vague. 22:12:30 present+ Jer_Noble, Dana_Estra 22:13:12 cn: on that one, Matt is more pointing to the inconsistency about the phrasing which could be addressed or clarified. The note and normative text don't exactly align. 22:15:37 jya: like, how do we know when the system is going to run out of memory and what the exact behavior is going to be. We could say that something is preferred, but we really don't have control of the underlying system because it's not alway possible to know how the underlying system is going to behave. There is also the issue that the original spec, however we've found that the underlying spec is not erroneous. For examples, the eventing model i[CUT] 22:17:31 jya: so I went for the latter, I tried to fix how the eventing is done for MMS, but the rest of the spec needs to be updated. However, the MSE spec is currently, the updates are incorrect. So like, bufferedchanged should really be bufferchange... you do the action, then you queue at task to update attributes, etc. so the whole spec is kinda incorrect 22:17:46 RRSAgent, draft minutes 22:17:48 I have made the request to generate https://www.w3.org/2023/11/14-mediawg-minutes.html tidoust 22:18:08 cn: are you suggesting there is a follow up to address the eventing issues? 22:19:41 jya: yes, Marcos has filed bugs about this also. We also have issues in the WPTests that are inherently racy, that also show some of these problems. We have failures in both Safari and Firefox because they are following the Chrome implementation rather than the spec. We need to address some of those. 22:20:32 jya: there are is quite a bit of followup. Marcos is working on fixing up the spec as much as possible so we can start addressing some of these larger issues with the architecture of the spec itself. 22:20:56 jya: we need to address issues with Timerages too and how the are inconsistently handled 22:21:25 cn: are there places in HTML that use Timerages. 22:22:04 jya: there are also some issues in HTML that we also need to fix. We need to do some cleanup in HTML also. However, I might defer to another spec editor to deal with that. 22:22:51 cn: I'm coming back to Matt's comments. Some of them are about the semantics and precision of the language in the spec. However, it would be good to remove some of the ambiguity that Matt is describing. 22:23:04 jya: I can do another pass and try to address Matt's comments. 22:23:24 jya: I'm not sure what the exactly sure what the process is 22:23:28 q+ 22:24:26 cn: should we merge the PR and address the issues? 22:24:27 present+ Greg_Freedman 22:25:13 jya: I will go through Matt's comments, however, I don't think Matt's comments would change how things are implemented 22:25:24 https://github.com/w3c/media-source/pull/329#discussion_r1385956944 22:25:35 cn: there is one comment that may have an impact ☝️ 22:25:45 jya has joined #mediawg 22:26:13 cn: it's not obvious how an app may distinguish between the time ranges removed by the UA and those changed by script 22:28:06 jya: if you call remove or append, that will generate a change event. The issue that is unaddressed is clarifying a bit more about how the buffer changes and what causes the event to fire. I will clarify that a bit more. 22:28:35 cn: it would be good to get Matt to review this if he has time once this is addressed. 22:28:49 cn: has anyone else got views 22:28:51 q? 22:29:00 ack marcosc 22:29:12 scribe+ cpn 22:29:33 marcos: we have a preference in other groups not to merge things until we have a test suite in place 22:30:05 ... a lot of the issues jya is pointing out is there seems to be mismatch between test and spec 22:30:22 ... so requiring tests before merging helps catch things 22:30:46 ... having a second implementer commitment before merging, otherwise we have a single vendor implementation, which isn't great 22:31:06 ... in other WGs we have a template that points to browser bugs for implementations 22:31:33 ... we should try to minimise bugs as people might start relying on the implementation 22:31:58 ... this may not apply in this particular PR, but something in general for the WG 22:32:40 ... also the quality of the spec text in HTML needs to be fixed 22:34:02 cn: so merge if we have tests plus implementation commitments 22:34:14 marcos: we have tests we can put in 22:35:37 cn: i haven't looked at the test coverage for this yet 22:35:58 marcos: so in parallel with reviewing matt's comments we'll do the tests as well 22:36:58 cn: anything else on this topic? 22:37:10 TOPIC: EME 22:38:13 https://github.com/w3c/encrypted-media/pull/516 22:38:40 cn: thank you Greg on the work you've done thus far. The work to be done on there was to add a registry for the different HTCP versions. 22:39:36 gf: I've ping intel. I think it's hard to get version 1.4, or 2.3... they generally require people to move to a new spec every 18 months so there might not be publicly accessible documents. 22:39:56 cn: they internet archive does have some of the old ones. 22:40:24 cn: they are generally not available anymore. So I can pull out the metadata, and we could have references without URLs. 22:40:57 gf: we should do the best that we can. But we can get the metadata and we can list the transport types in the registry. 22:41:27 cn: is there a core specification? 22:41:47 gf: I'll work on this and get all the references for the transport types 22:42:00 gf: I'll work with you on those. 22:43:57 mw: I don't think it's essential that we spend too much time on this. It's really a question about what that string means to between the content provider and the DRM provider. People can lie about it anyway, so it could fail when DRM decoding actually happens. We are not making any promises about how it would work. 22:44:16 fd: is the meaning is not that important, do we need an actual registry? 22:45:05 mw: we are just kinda describing the intention. However, in terms of having actual normative references, we might not needed because the documents are not available anyway 22:45:10 What is the mechanism for notifying the page when getStatusForPolicy changes? This would be a scenario like the user moving his browser window across monitors. 22:46:12 xi: if we get whatever references we can, but we shouldn't waste too much time on this because they are not publicly available anyway. However, I think the version really does matter. The version can be used by the OS to talk to the hardware. 22:46:33 s/xi/xw 22:48:15 cn: I'll leave it with you Greg to update the PR. I'm wondering if, given what people are Marcos and jya have been doing on the shape of the spec, I wonder if we can make to EME to make it easier to work it. 22:48:47 xw: if you can file bugs on how to modernize it, that would be great 22:49:22 TOPIC: Web Codecs 22:49:36 https://github.com/w3c/webcodecs/issues/558 22:49:49 cn: packet loss 22:51:43 ba: this is a feature we use on native. anyone from chrome have a view on what to do for concealment? 22:51:57 ... something to track whether implemented by anybody, current it isn't 22:52:27 ... it's also odd as FEC doesnt' work across all codecs, not guaranteed the same everywhere 22:53:28 https://github.com/w3c/webcodecs/issues/744 22:53:55 ba: this looks like a test gap, i think we're concluding that Safari's implementation isn't correct and needs a test case 22:54:07 ... so instead of reporting supported = false, it throws 22:54:31 ... i can put together a test, but there may be a more general problem 22:54:40 jya: possibly youenn fixed that 22:55:22 ba: there could be a more general misunderstanding. next step to discuss in thread if the spec text is all we need - there are specific conditions where it should throw. Are those the only conditions, or are there others? 22:55:46 ... so question is what the test should cover, or if the spec text is too narrow and needs clarifying 22:56:21 ... In this case, scalabilityMode is a DOMString, if it were enum it would be valid to throw. so not as cut and dry as the spec indicates 22:57:24 cn: so lets follow up in the issue thread and the test case 22:57:45 Topic: Media Capabilities 22:57:46 https://github.com/w3c/media-capabilities/issues/208 22:58:21 ba: this is a question - if MCAPI shows something is supported, is there a possibity if you set it, you won't get it 22:58:52 ... the SVC modes are almost always software implemented, which will always be there 22:59:05 ... possible you won't be power efficient, but the mode will always be there 22:59:14 ... don't have hardware support for the spatial modes today 22:59:39 ... right now if a mode is advertised in MCAPI you get it 23:00:15 jya: not sure it's true in all hardware though, in FF on some hardware it would pause video until a decoder was available 23:00:31 ... so there was not even a software decoder, only hardware 23:00:43 ba: for h265 there'll only be hardware in Chrome 23:01:14 jya: but with HW decoder, there's no limit on Windows, you can open as many HW h265 decoders as you want 23:01:21 ba: may not be true for the encoder though 23:01:53 ... so the point is you're not guaranteed to get what you ask for in MCAPI, it's possible it won't be there 23:02:12 ... resources could be taken away even if you did get them 23:02:28 ... but from the bug I'm not seeing a problem in the spec 23:02:50 ... anyone have thoughts? 23:03:59 jn: do they want MCAPI to reserve what they request? 23:04:39 ba: not really, it's just the API is optimistic. not suggesting changing the API 23:04:57 jn: without a reservation API it could fail for other reasons 23:05:21 ba: my recommendation is to resolve it by referring to the bug on error messages, without a spec change 23:06:35 RRSAgent, draft minutes 23:06:36 I have made the request to generate https://www.w3.org/2023/11/14-mediawg-minutes.html tidoust 23:06:42 cn: we should organise a session to triage MCAPI issues, we haven't looked at it in a while 23:06:49 [adjourned] 23:06:56 RRSAgent, draft minutes 23:06:58 I have made the request to generate https://www.w3.org/2023/11/14-mediawg-minutes.html cpn