22:01:57 RRSAgent has joined #mediawg 22:01:57 logging to https://www.w3.org/2022/01/11-mediawg-irc 22:01:59 pengliu has joined #mediawg 22:02:04 Zakim has joined #mediawg 22:02:18 Meeting: Media WG / Second Screen WG joint meeting 22:02:20 Agenda: https://www.w3.org/events/meetings/ab178610-074a-4aa2-881e-1af902d3c409 22:05:13 present+ Matt Wolenetz 22:12:59 present+ Chris_Needham, Jer_Noble, Chris_Cunningham, Takumi_Fujimoto, Eric_Carlson, Frank_Liberato, Greg_Freedman, Mark_Watson, Peng_Liu, Theresa_O'Connor 22:13:06 Chair: Chris_Needham, Jer_Noble 22:14:58 scribe+ cpn 22:15:12 jernoble has joined #mediawg 22:15:28 https://github.com/w3c/openscreenprotocol/issues/194 22:15:37 chcunningham has joined #mediawg 22:15:52 mfoltzgoogle has joined #mediawg 22:16:04 Topic: https://github.com/w3c/openscreenprotocol/issues/194 22:16:17 takumif has joined #mediawg 22:16:20 [Remote Playback] Capabilities for HDR rendering and display #194 22:16:44 cpn: two parts within the WG: decode capability detection, and display capability detection 22:17:13 cpn: for display capabilities, there's an open discussion within the CSS WG for how to do so 22:18:05 mark_foltz: OpenScreen Protocol can send media to another device, so needs to be able to determine what media capabilities on the remote device exist to select the correct variant 22:18:36 mark_foltz: one of those capabilities is color, which we added as "color profiles", but would like to align the definitions with Media Capabilities 22:18:36 present+ Francois 22:19:28 mark_foltz: I put up a pull request to use the "color gamut" capability with the same values as exposed through MC. 22:19:36 https://w3c.github.io/media-capabilities/#enumdef-colorgamut 22:19:44 mark_foltz: That pull request has been waiting for feedback from the Media WG before merging. 22:20:11 mark_foltz: The second piece was about the display characteristics of the display. 22:20:33 q+ 22:21:08 ack chcunningham 22:21:40 chcunningham: the displays discussion is mostly settled; HDR was added. Another discussion topic was about TV devices, which is not yet settled. 22:22:22 chcunningham: The last remaining issue is about device-pixel-ration when the video and graphics planes have different capabilities 22:22:23 chcunningham: 22:22:58 Media queries: https://www.w3.org/TR/mediaqueries-5/ 22:24:01 gregwf has joined #mediawg 22:25:00 mfoltzgoogle: the capabilities are going to be used by the UA to decide on whether a specific variant is compatible with the remote device 22:25:18 mfoltzgoogle: there doesn't seem to be a need for more color gamuts than are currently specified in the MC API 22:26:13 q+ 22:26:23 cpn: how is this information exposed to the page? 22:26:35 mfoltzgoogle: for remote playback, this is internal to the UA 22:26:49 mfoltzgoogle: there's a question about whether this is exposed before remote playback is initiated 22:27:32 RRSAgent, draft minutes 22:27:32 I have made the request to generate https://www.w3.org/2022/01/11-mediawg-minutes.html tidoust 22:27:36 jernoble: IIRC remote playback API only sends the current URL being played 22:27:59 ... Is there discussion of extending Remote Playback API to allow multiple sources? 22:29:00 [Right, I don't think that the Remote Playback API actually asks the user agent to only send the current URL being played] 22:30:03 ... if you go to remote a set of sources, do we need to spec how the media queries apply to the remote display and not the local? 22:30:29 mfoltz: i'm not sure i have a good answer. depends on the type of remote device you're sending to 22:31:02 ... once the two sides have negotated what streams to send, do we communicate that back to the sender? and does that get communicated back to the page? 22:31:17 RRSAgent, make logs public 22:31:37 jernoble: an extension is declarative video elements and sources, and enabling the negotation of those 22:31:45 mfoltz: it's worth tracking that 22:32:29 ... I'll ping Chris and others with a PR. If someone sent a discussion in CSS for dynamic range media query, we can look at that 22:32:32 q+ 22:32:38 ... landing both of those should close this 22:32:39 ack jernoble 22:32:51 q+ 22:33:20 Pull request: https://github.com/w3c/openscreenprotocol/pull/225 22:33:28 Matt: For MSE, which may be one of the children in the media element's source list, is that list sent to the remote side during negotiation? 22:33:59 mfoltz: so you have a media element, with an MSE object url in the source list 22:34:15 ... the protocol allows the agent to send a URL of the media source or the demuxed media 22:34:34 ... if the remote agent can understand the object url, the implemtnation could do that, but doesn't seem to fit with how MSE works 22:34:37 q+ 22:34:50 ... Chrome pipes the media fetched in the source buffer to the remote device over the streaming protocol 22:34:56 ack Matt 22:35:44 ... The sending site isn't generally aware. They can use the Remote Playback API to know they're remoting, but they still use MSE to transfer the data 22:36:17 Matt: If there's a changeType that involves capability changes, the required set of capabilities may not be detectable up front 22:36:27 ... unless you transcode the stream to a single type 22:36:49 mfoltz: a session can include multiple stream types, called encodings. the sender gets a full list of capabilities up front 22:37:06 ... if the type of media encoding changes, it knows if it can change to that encoding 22:37:15 ... we may have an issue open on that, but it should be handled 22:37:18 q? 22:38:19 cpn: do you also need the video plane resolution? 22:38:41 mfoltz: yes, one property is the native resolution, what you can display without scaling the video, e.g., the panel resolution 22:39:05 ... then what are the recommended scaled resolutions. you can enumerate preferred resolutions 22:39:42 ... we could look at aligning terminology with CSS. the data is there, but could align 22:40:23 chcunningham: haven't looked at the protocol to know. the concept of getting the native resolution is simple 22:40:36 mfoltz: makes sense to align, but fine either way 22:40:55 chcunningham: you could save words by referencing the CSS spec of a bi-plane device 22:41:00 mfoltz: agree 22:41:20 q? 22:41:23 ack cpn 22:41:33 q- jernoble 22:41:53 https://github.com/w3c/openscreenprotocol/issues/233 22:42:11 Topic: Use the same codec names as the media APIs 22:42:26 mfoltz: want to align what we ask devices with what's in Media Capabilities 22:42:50 ... I don't think there's anything difficult or controversial, but wanted feedback 22:43:16 ... In the GH issue, I tried to track down some of the RFCs, extended MIME types that describe the codec and profiles and config attributes 22:43:35 ... Do we see any difficulty using these strings to enumerate decoding capabilities? 22:43:57 chcunningham: the strings would be my first choice. Same question came up with WebCodecs, and chose to use those strings 22:44:24 ... We made a registry of the strings and the RFCs that define them, to have clear reference 22:44:34 ... the strings aren't perfect, but your best best 22:44:48 ... Some evolution, VP9 didn't describe the profile, but now does 22:45:02 ... Newer strings are more verbose, adding info on bit depth and colour 22:45:20 ... MC API breaks those out separately, so we can support newer and older strings 22:45:40 ... The people who made the strings also made the codec, so happy to defer to them 22:45:59 mfoltz: Is there an issue where enumerating codecs could result in a large number of them? 22:46:15 chcunningham: MC API the site asks the browser 22:46:41 mfoltz: we want to enumerate, depdends on hardware decoder support. could be a desktop with software support for a number of codecs 22:46:49 ... could that result in a large number of strings? 22:47:08 chcunningham: consider the VP9 string, has 10 parts each with 2 or 3 values, so the combination is large 22:47:24 ... with software decoding, can have a big list. so only describe the things that matter 22:47:54 ... VP9 includes things about the stream, not just things for decode 22:48:20 ... need to look at details, but could motivate some cleverness on communicating just the things you care about 22:48:29 ... initially i'd just use the pieces you care about from the strings 22:48:47 mfoltz: we might make it possible for agents to drop information after the profile, or use a wildcard in some way 22:49:00 ... maybe that's not quite as precise, but could be good enough 22:49:12 eric: that probably violates the RFC that this is based on 22:49:32 mfoltz: don't want to go that route unless we need to 22:49:57 ... would be good to have some normative reference to the strings. sounds like webcodecs already did that 22:50:28 webcodecs codec registry https://www.w3.org/TR/webcodecs-codec-registry/ 22:50:30 ... we can probably use that to firm up the codec names to close this issue 22:51:46 Topic: AOB 22:52:01 matt: Origin trial for MSE in Workers is open 22:52:34 ... Also MSE for WebCodecs, currently working on spec and implementations 22:53:17 present+ Mark_Foltz 22:54:09 scribe+ 22:54:15 cpn: I was on an AC call earlier. Question about whether groups have a feeling about whether they would like to hold a physical meeting. I believe that a survey is upcoming. 22:54:40 ... W3C would like to plan logistics if there is a sense that physical meetings are going to be possible. 22:54:55 ... Seems hard to make commitments though. 22:55:26 ... Next meeting will be February 8th, early time Pacific time. If you feel we need an intermediary call, let us know. 22:55:33 RRSagent, draft minutes 22:55:33 I have made the request to generate https://www.w3.org/2022/01/11-mediawg-minutes.html tidoust 22:57:21 i/scribe+ cpn/scribe+ jernoble/ 22:57:31 rrsagent, draft minutes 22:57:31 I have made the request to generate https://www.w3.org/2022/01/11-mediawg-minutes.html cpn