[minutes] Media WG call - 2019-10-17

Hi all,

The draft minutes of today's Media WG call are available at:
https://www.w3.org/2019/10/17-mediawg-minutes.html

... and copied as raw text below.

Short summary:
- The group resolved to add Vi Nguyen (Microsoft) to the list of editors of the Media Capabilities specification.
- Followed a long discussion on exposing HDR support on screen vs. screen.video in Media Capabilities, not entirely resolved yet.
- Mounir mentioned plan to create a "TAG dispute" issue for the Autoplay API.

Thanks,
Francois.

-----
Media WG call
17 October 2019

   [2]Agenda. [3]IRC log.

      [2] https://lists.w3.org/Archives/Public/public-media-wg/2019Oct/0007.html
      [3] https://www.w3.org/2019/10/17-mediawg-irc

Attendees

   Present
          Chris_Cunningham, Chris_Needham, Eric_Carlson,
          Francois_Beaufort, Francois_Daoust, Garrett_Singer,
          Gary_Katsevman, Greg_Freedman, Greg_Whitworth,
          gregwhitworth, Jer_Noble, jernoble, Joey_Parrish,
          Mark_Watson, mounir, Peng_Liu, Richard_Winterton,
          Rijubrata_Bhaumik, Vi_Nguyen

   Regrets

   Chair
          -

   Scribe
          tidoust

Contents

     * [4]Meeting minutes
         1. [5]Future telecon times
         2. [6]Media Capabilities Editor Changes
         3. [7]Media Capabilities Issue #135
         4. [8]Autoplay API
     * [9]Summary of action items
     * [10]Summary of resolutions

Meeting minutes

Future telecon times

   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.

Media Capabilities Editor Changes

   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

Media Capabilities Issue #135

   [11]hdrSupported - Screen.video or simply Screen?

     [11] https://github.com/w3c/media-capabilities/issues/135

   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: [12]https://github.com/w3c/
   media-capabilities/issues/135#issuecomment-543047691

     [12] 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:
   [13]https://github.com/WICG/canvas-color-space/blob/master/
   CanvasColorSpaceProposal.md#selecting-the-best-pixelformat-for-
   the-user-agents-display-device

     [13] 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.

Autoplay API

   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.

Summary of action items

    1. [14]jernoble to add Vi as editor of Media Capabilities

Summary of resolutions

    1. [15]Add Vi Nguyen as editor to Media Capabilities

Received on Thursday, 17 October 2019 15:19:25 UTC