jernoble: A number of people could not make this time slot.
… One suggestion would be to have a cadence with one meeting at a given time, and another meeting at another time to try to please everyone.
jernoble: I'll send a new Doodle with suggestions for next month meetings.
[sounds good to people]
<wolenetz> Sorry folks, technical issues on my side connecting into the audio session.
gregwhitworth: At the F2F, it was resolved to put me as editor for Media Capabilities. Vi, who is also on the call, has been doing a lot of work. We figured it would make more sense to have him as editor of the spec.
… How does that sound?
chcunningham: No objection.
jernoble: And no objection from me either.
Resolved: Add Vi Nguyen as editor to Media Capabilities
Action: jernoble to add Vi as editor of Media Capabilities
hdrSupported - Screen.video or simply Screen?
chcunningham: Lots of discussions. I added a late comment yesterday.
… Basically it starts off with a simple question: screen.video or simply screen?
… Doing a little bit more of reading, and talking with people, I'm going to come down to not doing screen.video and going through screen.
… Arguments are in my final comment.
… The two-plane solution was not really featured from day 1. TV manufacturers doing a very practical choice, but at the end of the day, that's a choice on their part to implement part of the Web platform that works for them.
… screen.video would provide a cover to continue doing so.
… If we force just one plane, then there would be forced to lie. Jon Piesing replied that they would likely expose video capabilities and lie about graphics.
… Images would be eventually downsampled, which wouldn't be very useful. They would waste bandwidth indeed. That's unfortunate, but not immediately unfortunate.
… I don't think that the two-plane problem is the sole problem that prevents TV manufacturers from having HDR graphics support.
… It's a bit difficult to say what the costs are for lying. Support for HDR in graphics may be feature detectable through other means.
… 4K images are not terribly common at the moment. That may change, but that's not an urgent issue.
… This is not to say that they should lie forever. They have other options down the line, including possibly defining a private API. The problem is specific to the TV space.
… This puts the pain in the right spot to make the change.
… Business pressure can help push for changes.
… e.g. to end up with just one plane for graphics and video.
<gregwhitworth> jpiesing's comment: https://github.com/w3c/media-capabilities/issues/135#issuecomment-543047691
chcunningham: Luke Halliwel is mostly on board. Jon Piesing basically objects, pointing out that TV devices are the biggest consumers of media on the Web.
gregwhitworth: Re. Jon's comment on resolution, can we resolve that devicePixelRatio and screen already give you the actual graphics resolution?
chcunningham: Yes, that's already been agreed.
… If you put a 4K image to a 1080p plane, it will be downsampled in the end.
gregwhitworth: We would need to solve both the resolution and the HDR lies at the same time.
… We already have ways to determine which formats should be best served for images, and I don't think the Media Capabilities should solve that.
… If you have the answer for images, then you might have a way to get your two planes.
chcunningham: Yes, that's correct.
gregwhitworth: OK, I would be in support of removing the two plane definition as we have it today.
jernoble: Should we punt this question over to CSS?
chcunningham: I'd be happy to have CSS weigh in. It's a question about the CSS Object Model.
jernoble: Second part is whether we should reconsider making HDR support a CSS property. If we end up with one plane, then we could end up with media queries.
… We'd also get an event for free that fires when the screen's level of HDR support changes.
chcunningham: Media Queries seems to be just as functional in my view.
chcunningham: The Media Capabilities API would still be used to tell what are your decoding support, as well as wide color and color gamut range.
markw: I kind of disagree with chcunningham's analysis, and that we should go to CSS. We tried to get them to comment on HDR for several years without success.
… I don't think that the problem is restricted to TV. Pretty much every HDR device has the issue, with SDR graphics and HDR video.
… Question about whether we think that the Web Platform should accommodate the hardware that exists.
… We've been trying to put TV as a priority in W3C for some years. When we have hardware properties that are specific to TV, they should be exposed. They are not going to change anytime soon.
… Even with greater graphics plane, the plane are not going to be merged anytime soon.
… I absolutely think we need to take this into account and expose it to Web apps.
… How it's exposed, I don't care, but punting it to CSS does not seem a good idea for me.
chcunningham: The laptop use case. There is an open question about compositing HDR video with SDR graphics. Something for CSS to weigh in. But fundamentally different from the 2 plane problem on TV devices
… With the compositing issue, you would still be able to rotate your video, apply overlays, etc.
… There is no disputing that TVs are super important.
… Media Capabilities build on top of canPlayType. TVs haven't followed the standards to start with.
<Zakim> cpn, you wanted to agree with markw
cpn: I wanted to support what Mark has been saying. That's an important class of devices that I'd like us to support to the extent that we can.
… The WAVE project is doing good strides at making sure that user agent implementations that go into TV devices are more capable.
… Nothing more to add, just to voice my support to Mark and Jon's comments.
jernoble: It seems to me that TV manufacturers want some magic to happen. Video element that does not really take part in the DOM model. Is the responsibility of the Media WG to provide an API for TV manufacturers to expose their capabilities precisely?
… We're talking about this narrow issue. There's a larger set of questions that we're ignoring, in that TV manufacturers are using a magic wand to make things happen.
markw: There are two reasons why TV may not have implemented the whole Web platform. One could be lack of development, testing, etc. Here, the CTA WAVE project is pushing in the right direction.
… Second is key hardware differences such as this one, where we have to accommodate them.
… I don't know where the line is with regards to CSS. We can know for sure that HDR/SDR is in the fundamental hardware limitations space.
… Unless we're saying that the Web is only for desktop/laptop hardware
jernoble: and mobile hardware!
… Since we're talking about this. What happens if a page tries to play two video elements with a scrolling CSS?
markw: I don't know the answer. I think most TV have one video pipeline.
jernoble: will video be in css dimensions for width/ height
markw: Yes, I would assume so but I honestly don't know the details here. We could go back to CTA WAVE to check what tests they have.
jernoble: There's a bunch of out-of-band knowledge that an app needs to know to position video correctly. None of that would work with two planes. That's why I'm proposing taking this to CSS.
chcunningham: I support Jer's last comment. Right that there is a bigger question that needs answering.
… The video element's width and height should be the same as what they would appear to be from a DOM perspective
… You mentioned two videos on a page and scrolling. You would need to do some sync between the hole in the page, and the content behind the hole. My guess is that it's not very efficient.
markw: On that scrolling thing, I know that it's been described that you have a transparent layer on top of a video pane. I wouldn't expect that to be exposed to Web apps. That should be transparent for the apps.
… The video will report its dimensions in CSS pixels.
… In terms of CSS WG, I have no problem describing the issue to them and ask for feedback, but I would not punt the issue to them, as it would take too long.
chcunningham: Re. this scenario is not changing anytime soon; the cost pressures are persistent. Maybe we have an opportunity here. We have time.
… [scribe lost chcunningham for a few seconds]
… Even though we may be faced with this two plane scenarios for a number of years, it isn't clear to me that these years will overlap with years where TV will implement HDR graphics.
… When folks like Netflix want to use 4K graphics or HDR graphics, they will be in negotiations with TV manufacturers about requirements to certify their apps.
RichW: How do you separate things out with decode capabilities if you punt that to CSS?
chcunningham: I don't think that we would punt media capabilities as a whole.
… I think we're just talking about the screen capabilities.
… Media capabilities does not say anything on still images
… There are certainly APIs and mechanisms to detect the right supported format and resolution, such as the <picture> element.
markw: chcunningham, you seem to assume that this is a problem, and not a deliberate design choice.
… There's always going to be this huge spread on capabilities given the cost pressure.
chcunningham: I don't disagree with you. I do think that people that are making TV apps won't be using any fancy HDR capabilities while TVs are different.
markw: I still have the problem of having to know whether I can deliver HDR video.
chcunningham: Absolutely, my proposal is to use video.hdrSupported directly.
… which should give you the same thing as CSS.
markw: That's essentially punting the issue to CSS, and my concern is that it may take ages.
chcunningham: You can look at the canvas colorspace proposal, which covers the same hdrSupported idea for the same reason.
… I'm optimistic that we could get CSS to prioritize things.
markw: We're going to need to think a bit more about this simple boolean hanging out of screen.
<chcunningham> canvas usage of Screen.hdrSupported here: https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.md#selecting-the-best-pixelformat-for-the-user-agents-display-device
mounir: We need to wrap up this discussion
<Zakim> cpn, you wanted to mention the lie could be the other way round
cpn: About Richard's comment on decode capabilities, we could make the lie go the other direction.
chcunningham: screen is the natural place to hang it. For decode, it's about things such as tone mapping.
mounir: Regarding CSS, we can propose a change without depending on them.
mounir: Jer and I discussed with Paul whether we can find a solution that would not involve a formal group vote.
… I have been drafting what I call a TAG's dispute. Here in particular, I would like the TAG to update their guidelines.
… All the implementers would be happy to follow the TAG's recommendations, I believe. I think that would be a better resolution path for the Web platform.
… I would file an issue later this week, or perhaps next week, after discussion with Jean-Yves as FOMS next week.
… If people want to see the draft right away, let me know, I'll file that as an issue later on in any case.
jernoble: Mounir, I think you should write down the issue in the Autoplay repo so that we can discuss it there
Mounir: Yes, happy to do that.
chcunningham: Just want to ask about CSS. What is the best path forward to get the attention of CSS owners and have them prioritizing on the HDR problem we discussed?
mounir: Sorry, we're out of time, let's follow up offline.