Meeting minutes
Retrieving RTCRtpCodecCapability from MediaCapabilities when queried for webrtc (#185)
https://
Bernard: Have got to the bottom of it for real codecs, h.264, not sure what the objective is
… Some things expressed such as FEC, redundant audio, isn't really a codec but expressed as such in MC API
Chris Cunningham: I don't have a strong opinion. The goal is to go from a getCapabilities call to a setCapabilities call
… Would you use setCapabilities for this?
Bernard: You would put in the retransmissions and FEC, if you don't include them you don't get any robustness
… Doesn't need to be covered in MC API though. It gives more information than what you had in getCapabilities
… Is it a helper, or a replacement for getCapabilities? A question of scope
Chris Cunningham: Not too opinionated. On this point, maybe it depends how ugly it makes the API
… 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
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
… Fundamental question is scope: are we trying to get rid of getCapabilities?
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
Bernard: I agree on that initial view of the scope
Chris Cunningham: On real vs fake codecs, in the GH issue, on setting clock rate and SDP format, are those OK?
Bernard: Seem reasonable, although audio DTMF is weird
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
Chris Cunningham: Trying to figure out the spec steps
Johannes: Bernard and Harald may want to weigh in, but it looks ok to me
Bernard: We have a WebRTC WG meeting coming up where we can go into these things
… Important to confirm the scope
Johannes: If there's a simple path to fit into MC API, that would be good, but don't want to push it
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?
Johannes: Doesn't seem like it to me
Bernard: April 26
Should width, height, etc be required or optional in VideoConfiguration? (#192)
<tidoust> Issue #192
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
… WebRTC just returns that scalablityMode is always supported, but you could lose it depending on resolution and available hardware
… What width and height should be put in? We decided width and height with all the scalability modes there
Johannes: Is that the combined value?
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
… You could put in a lower resolution to see where the boundary is
Chris Cunningham: So you could check for fallback support
Bernard: WebRTC doesn't have the control WebCodecs has where you can request hardware or software
… But think we know the right answer. Did we conclude bitrate doesn't matter?
Chris Cunningham: It does matter (doesn't matter in Chrome but it should)
Bernard: Different browsers may do different things, so API should allow for that
Chris Cunningham: It will in Chrome eventually, currently we have a first pass implementation
… 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
Bernard: I think this is all non-normative. People should be aware that because something doesn't matter now, it may matter later
Chris Cunningham: In MC API, everything you must have are marked as required, so hints strongly to what authors should do
Chris Needham: Any other relevant issues we should cover today?
MediaDecodingConfiguration type=webrtc must not contain a keySystemConfig (#166)
Chris Cunningham: There was an issue about key system configuration not making sense with WebRTC
… We should go through all the attributes from that point of view. Johannes has a PR, that's moving along
Johannes: I've taken your suggestions on board
Bernard: Key systems don't make sense as it doesn't support content protection
Chris Needham: DASH-IF are interest in that, they're running a coordinating activity
Chris Cunningham: I completed their survey
… 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.
… 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
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
… What people are worried about is whether people in certain locations are listening to the stream
… Be clear about the use cases, are they content protection or something different. S-Frame protects against snooping on the wire, which is different
Chris Needham: My undestanding is DASH-IF are interest in low latency streaming of premium content, hence EME
Proposed joint meeting with the WebRTC WG
<tidoust> Message from Jer
Chris Needham: I'll go ahead and confirm the date for that meeting
Refine srcObject's MediaSourceHandle behavior (#306)
<tidoust> Issue #306
Matt: Wanted to discuss MSE in Worker attachment mechanism using a transferable handle
… 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
… 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
… Define timing points when the timing object is detached? Increases implementation complexit
… Doesn't block my current prototype work, keeping it simple
… Eventually it will need clarification. Can continue on GitHub?
Chris Needham: Should we arrange a meeting to discuss earlier?
Matt: Mozilla may be working on implementation, but I'll ask the WG for input
helpful link for context on the MSE srcObject question that needs wider input: https://
WebCodecs H.263 registration update
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.
… I'm wondering what to do next to help move it forward.
… 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.
… But there's a lot more complexity involved because of the different features in the codecs.
… 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.
… Should we get everyone in a call to solve this? Seek input from ITU group that works on H.263?
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.
… If that avenue turns out to be too complex or too slow, happy to jump on a call!
Chris Needham: OK, no need to do that yourself, I'll follow this up.
Horizontal review status
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.
… I'd like to get all of the horizontal reviews for that spec underway.
… This led me to reviewing where we are with horizontal reviews more generally.
… It seems that there are a number of reviews that we've not requested yet that we should really do.
… For example, for WebCodecs, we completed the TAG review, the privacy review. There's also accessibility and internationalization.
… Security as well?
Chris Cunningham: We did security already.
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.
… Should I just file GitHub issues for those?
Chris Cunningham: Sounds great.
Chris Needham: For MSE, I'm wondering what the approach is here. We're extending a Recommendation here. Are the reviews on the delta?
Matt Wolenetz: Did the TAG review for MSE in workers. No Security and Privacy sections for now.
… 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.
Chris Needham: Looking more broadly, the same comment applies to most other specs.
… For example, we may have done the privacy review on specs but not accessibility.
Francois: The reviews don't need to be done by the spec editors, can be done by other types of participants in the group
… The self analysis is just a starting point
ACTION: Chris Needham to file relevant horizontal review issues across spec repos
Behavior with native/non-native controls for video elements
<nigel> WebVTT #503 Behavior with controls, particularly non-native controls, overlap
Nigel Megitt: I wanted to alert you about an issue raised on WebVTT but not directly related to WebVTT.
… This is about how to present subtitles or captions when non-native controls are on the video element.
… Styling of controls is a bit tricky. Quite a lot of discussions on that ticket.
… Main outcome is that aligning any sort of rendering with video elements is quite difficult.
… The goal is to de-conflict subtitles/captions and video elements.
Chris Needham: Is there a solution proposal for this?
Nigel Megitt: 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.
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.
… During rechartering, we've been contacted by the Open UI Community Group. It feels like that would be a good topic for a joint meeting with the Open UI CG.
… Should we try to set something up soon?
Nigel Megitt: No particular timescale. It's a real world problem for sure and we'd like to solve it as soon as possible.