13:59:56 RRSAgent has joined #mediawg 13:59:56 logging to https://www.w3.org/2022/04/12-mediawg-irc 14:00:00 Zakim has joined #mediawg 14:02:11 Meeting: Media WG monthly call 14:02:20 Chair: Chris_Needham 14:02:24 Agenda: https://github.com/w3c/media-wg/blob/main/meetings/2022-04-12-Media_Working_Group_Teleconference-agenda.md 14:02:36 present+ 14:02:45 present+ Francois_Daoust, Chris_Needham, Matt_Wolenetz, Chris_Cunningham, Bernard_Aboba 14:05:53 present+ Johannes_Kron 14:06:37 scribe+ cpn 14:07:05 Topic: Retrieving RTCRtpCodecCapability from MediaCapabilities when queried for webrtc (#185) 14:07:12 https://github.com/w3c/media-capabilities/issues/185 14:07:31 Bernard: Have got to the bottom of it for real codecs, h.264, not sure what the objective is 14:08:01 ... Some things expressed such as FEC, redundant audio, isn't really a codec but expressed as such in MC API 14:08:54 Chris_Cunningham: I don't have a strong opinion. The goal is to go from a getCapabilities call to a setCapabilities call 14:08:59 ... Would you use setCapabilities for this? 14:09:31 Bernard: You would put in the retransmissions and FEC, if you don't include them you don't get any robustness 14:09:51 ... Doesn't need to be covered in MC API though. It gives more information than what you had in getCapabilities 14:10:04 ... Is it a helper, or a replacement for getCapabilities? A question of scope 14:10:29 Chris_Cunningham: Not too opinionated. On this point, maybe it depends how ugly it makes the API 14:10:54 ... If we can hide the complexity by using different mime type strings, so we don't need to add more dictionary attributes, I'm willing to go ahead with it 14:11:37 Bernard: For some of the robustness things, use FEC on a particular stream, weird things like payload types, your ideas make sense. Let's see if we can fit it in or if it gets too ugly 14:11:53 ... Fundamental question is scope: are we trying to get rid of getCapabilities? 14:12:26 Chris_Cunningham: The initial view was not to replace getCapabilities. Having performance information was valuable, so happy to pursue to the extent WebRTC wants us to 14:12:56 Bernard: I agree on that initial view of the scope 14:13:25 Chris_Cunningham: On real vs fake codecs, in the GH issue, on setting clock rate and SDP format, are those OK? 14:13:45 Bernard: Seem reasonable, although audio DTMF is weird 14:14:37 Johannes: I'm thinking the same, intent wasn't to deprecate the other API, but add the ability to query for smoothness and power efficiency, so what you say sounds good to me 14:15:06 Chris_Cunningham: Trying to figure out the spec steps 14:15:24 Johannes: Bernard and Harald may want to weigh in, but it looks ok to me 14:15:41 Bernard: We have a WebRTC WG meeting coming up where we can go into these things 14:15:49 ... Important to confirm the scope 14:16:22 Johannes: If there's a simple path to fit into MC API, that would be good, but don't want to push it 14:16:55 Bernard: Width and height may be ok, but FEC in h.264 (is that power efficient or smooth), would it make sense in the API? 14:17:04 Johannes: Doesn't seem like it to me 14:17:34 Bernard: April 26 14:18:19 Topic: Should width, height, etc be required or optional in VideoConfiguration? (#192) 14:18:29 -> https://github.com/w3c/media-capabilities/issues/192 Issue #192 14:19:15 Bernard: Scalability mode is a static thing, enabled or not. Or maybe software encoder can only do low resolutions. So AV1 might not report scalability mode 14:19:47 ... WebRTC just returns that scalablityMode is always supported, but you could lose it depending on resolution and available hardware 14:20:11 ... What width and height should be put in? We decided width and height with all the scalability modes there 14:20:21 Johannes: Is that the combined value? 14:20:33 Present+ Nigel_Megitt 14:20:54 Bernard: You'd look at the resolution with all combined, all temporal and spatial layers, that would tell you if scalability is available at highest resolution 14:21:05 ... You could put in a lower resolution to see where the boundary is 14:21:22 Chris_Cunningham: So you could check for fallback support 14:21:45 Bernard: WebRTC doesn't have the control WebCodecs has where you can request hardware or software 14:22:02 ... But think we know the right answer. Did we conclude bitrate doesn't matter? 14:22:26 Chris_Cunningham: It does matter (doesn't matter in Chrome but it should) 14:22:58 Bernard: Different browsers may do different things, so API should allow for that 14:23:12 Chris_Cunningham: It will in Chrome eventually, currently we have a first pass implementation 14:24:16 ... What remains for this issue is to send a PR to clarify the spec text. I can clarify anything else if needed, just let me know 14:24:54 Bernard: I think this is all non-normative. People should be aware that because something doesn't matter now, it may matter later 14:25:18 Chris_Cunningham: In MC API, everything you must have are marked as required, so hints strongly to what authors should do 14:26:01 Chris_Needham: Any other relevant issues we should cover today? 14:26:32 Chris_Cunningham: There was an issue about key system configuration not making sense with WebRTC 14:26:55 ... We should go through all the attributes from that point of view. Johannes has a PR, that's moving along 14:27:00 i/Chris_Cunningham: There was an issue/Topic: MediaDecodingConfiguration type=webrtc must not contain a keySystemConfig (#166) 14:27:06 Johannes: I've taken your suggestions on board 14:27:35 Bernard: Key systems don't make sense as it doesn't support content protection 14:28:42 Chris_Needham: DASH-IF are interest in that, they're running a coordinating activity 14:29:01 Chris_Cunningham: I completed their survey 14:29:36 ... I'm looking for users of WebCodecs with interest in encrypted media. We have some high level use cases, was mentioned in the DASH-IF presentation, but in passing. 14:30:20 ... If people want EME for WebCodecs and my organisation commits to help flesh out the requirements and use it when development, please reach to me, this is exactly the kind of input we are looking for 14:30:53 Bernard: I don't recall people asking for content protection, but they do care about security issues. For example, WebCodecs being used for political meetings 14:31:27 ... What people are worried about is whether people in certain locations are listening to the stream 14:31:53 ... Be clear about the use cases, are they content protection or something different. S-Frame protects against snooping on the wire, which is different 14:32:34 Chris_Needham: My undestanding is DASH-IF are interest in low latency streaming of premium content, hence EME 14:33:20 Topic: Proposed joint meeting with the WebRTC WG 14:33:29 -> https://lists.w3.org/Archives/Public/public-media-wg/2022Apr/0000.html Message from Jer 14:34:10 Chris_Needham: I'll go ahead and confirm the date for that meeting 14:34:36 Topic: Refine srcObject's MediaSourceHandle behavior (#306) 14:34:47 -> https://github.com/w3c/media-source/pull/306 Issue #306 14:34:54 Matt: Wanted to discuss MSE in Worker attachment mechanism using a transferable handle 14:35:22 ... Some things we need to consider, e.g., what to do when an object is currently attached and the app tries to transfer it away or unset and reset it 14:35:53 ... Some scenarios need clarification in the timing. Do we leave it up to implementations? This in the last has led to differences and developer confusion 14:36:18 ... Define timing points when the timing object is detached? Increases implementation complexit 14:36:30 ... Doesn't block my current prototype work, keeping it simple 14:37:12 ... Eventually it will need clarification. Can continue on GitHub? 14:37:22 Chris_Needham: Should we arrange a meeting to discuss earlier? 14:37:45 Matt: Mozilla may be working on implementation, but I'll ask the WG for input 14:38:04 Topic: WebCodecs H.263 registration update 14:38:08 scribe+ tidoust 14:39:16 Chris_Needham: Ongoing thread with Gary Sullivan, an expert on H.263 working on it at ITU. It just seemed to me that there are a lot of questions on the proposal. 14:39:29 ... I'm wondering what to do next to help move it forward. 14:40:07 ... I think it needs somebody with a greater level of expertise than I have. The proposal that we have is based around the implementation that whatever FFmpeg currently does. 14:40:33 ... But there's a lot more complexity involved because of the different features in the codecs. 14:41:22 ... We would be minting new codec string definitions that I worry may overlap existing definitions. I'm not sure that there is a definition that covers all possibilities. 14:41:47 ... Should we get everyone in a call to solve this? Seek input from ITU group that works on H.263? 14:42:25 Chris_Cunningham: My next step, naively, would be to turn the email points into a GitHub issue so that the original author can see that feedback and respond to it. 14:42:45 ... If that avenue turns out to be too complex or too slow, happy to jump on a call! 14:43:16 Chris_Needham: OK, no need to do that yourself, I'll follow this up. 14:44:08 Topic: Horizontal review status 14:45:12 Chris_Needham: FPWD on Autoplay Policy Detection. Within a short period of time, that should trigger horizontal reviews for accessibility, internationalization, privacy, security, etc. Some steps on our hands such as preparing answers to questionnaires. 14:45:23 ... I'd like to get all of the horizontal reviews for that spec underway. 14:45:38 ... This led me to reviewing where we are with horizontal reviews more generally. 14:45:56 ... It seems that there are a number of reviews that we've not requested yet that we should really do. 14:46:34 ... For example, for WebCodecs, we completed the TAG review, the privacy review. There's also accessibility and internationalization. 14:46:41 ... Security as well? 14:46:49 Chris_Cunningham: We did security already. 14:47:24 Chris_Needham: For accessibility and internationalization, if we don't think there are impact, our self assessment should be straightforward. I would suggest that we do those before too long. 14:47:33 ... Should I just file GitHub issues for those? 14:47:39 Chris_Cunningham: Sounds great. 14:48:21 Chris_Needham: For MSE, I'm wondering what the approach is here. We're extending a Recommendation here. Are the reviews on the delta? 14:48:47 Matt_Wolenetz: Did the TAG review for MSE in workers. No Security and Privacy sections for now. 14:49:35 ... Not all horizontal reviews were in place at the time. It's best to be aware of v1 issues if any, even if implementations are already done. 14:49:52 Chris_Needham: Looking more broadly, the same comment applies to most other specs. 14:50:07 ... For example, we may have done the privacy review on specs but not accessibility. 14:50:54 Francois: The reviews don't need to be done by the spec editors, can be done by other types of participants in the group 14:51:17 ... The self analysis is just a starting point 14:52:35 ACTION: Chris_Needham to file relevant horizontal review issues across spec repos 14:53:05 Topic: AOB 14:53:21 -> https://github.com/w3c/webvtt/issues/503 WebVTT #503 Behavior with controls, particularly non-native controls, overlap 14:53:36 Nigel: I wanted to alert you about an issue raised on WebVTT but not directly related to WebVTT. 14:53:54 ... This is about how to present subtitles or captions when non-native controls are on the video element. 14:54:22 ... Styling of controls is a bit tricky. Quite a lot of discussions on that ticket. 14:54:49 ... Main outcome is that aligning any sort of rendering with video elements is quite difficult. 14:55:14 ... The goal is to de-conflict subtitles/captions and video elements. 14:55:33 Chris_Needham: Is there a solution proposal for this? 14:56:03 Nigel: There is a specific proposal for one part of it related to a WebVTT algorithm, but there isn't a proposal for general de-confliction. 14:57:11 Chris_Needham: In these meetings in the past, we often recognized that we have the right people in the room to discuss impacts to video elements. I cannot speak on behalf of others, but my feeling is that it would be ok to explore that. 14:58:03 ... During rechartering, we've been contacted by the Open UI Community Group. It feels like that would be a good topic with the Open UI CG. 14:58:22 s/a good topic/a good topic for a joint meeting/ 14:58:44 ... Should we try to set something up soon? 14:59:16 Nigel: No particular timescale. It's a real world problem for sure and we'd like to solve it as soon as possible. 15:00:11 s/Topic: AOB/Topic: Behavior with native/non-native controls for video elements/ 15:04:18 i|Topic: WebCodecs H.263|helpful link for context on the MSE srcObject question that needs wider input: https://github.com/w3c/media-source/pull/306#pullrequestreview-928290232| 15:04:26 RRSAgent, draft minutes 15:04:26 I have made the request to generate https://www.w3.org/2022/04/12-mediawg-minutes.html tidoust 15:06:28 RRSAgent, make logs public 16:36:36 Zakim has left #mediawg