- From: Francois Daoust <fd@w3.org>
- Date: Thu, 17 Oct 2019 17:19:16 +0200
- To: <public-media-wg@w3.org>
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