- From: Francois Daoust <fd@w3.org>
- Date: Wed, 20 Nov 2019 20:29:37 +0100
- To: <public-media-wg@w3.org>
Hi all,
The minutes of yesterday's Media WG call are available at:
https://www.w3.org/2019/11/19-mediawg-minutes.html
... and copied as raw text below.
The group notably resolved to go with "video-" prefixed properties for width, height, resolution, dynamic-range, color-gamut within CSS for media queries regarding bi-plane support.
Thanks,
Francois.
-----
Media WG Call
19 November 2019
[2]Agenda. [3]IRC log.
[2] https://lists.w3.org/Archives/Public/public-media-wg/2019Nov/0002.html
[3] https://www.w3.org/2019/11/19-mediawg-irc
Attendees
Present
Chris Cunningham, Cyril Concolato, Eric Carlson,
Francois Daoust, Garret Singer, Gary Katsevman, Greg
Freedman, Greg Whitworth, Tess O'Connor, Jer Noble, Mark
Foltz, Mounir Lamouri, Joey Parrish, Peng Liu, Vi
Nguyen, Matt Wolenetz, Barbara Hochgesang
Regrets
Chair
Jer Noble
Scribe
Francois
Contents
* [4]Meeting minutes
1. [5]HDR
2. [6]Media Capabilities Issue #136 (aka. DolbyVision)
3. [7]MediaCapabilities and EME detection polyfill
4. [8]ISO/IEC DIS 23091 (aka “Coding Independent Code
Point”)
5. [9]AOB
* [10]Summary of resolutions
Meeting minutes
HDR
gregwhitworth: [Summary of [11]discussions in the CSS WG on 3
options to deal with bi-plane (video/graphics)]
... Basically, the CSS WG came back and noted that they would
prefer the second option with video- prefixes to properties.
[11] https://github.com/w3c/csswg-drafts/issues/4471
<chcunningham> Makes sense to me
gregwhitworth: So in practice, see [12]comment on GitHub issue,
we're converging towards video-[css property]
[12] https://github.com/w3c/csswg-drafts/issues/4471#issuecomment-549178832
jernoble: People really interested were Netflix and Mark in
particular who is not yet on the phone.
GregFreedman: FYI, Mark cannot join today but I'm here. He's
been following the thread, and in general, we agree with the
direction in the thread.
gregwhitworth: Could be useful to agree on the exact set of
properties. width, height, resolution, dynamic-range. Any one
missing? Please make sure to add them!
… I'm going to agenda+ the topic to next CSS WG meeting.
… Probably next week.
jernoble: Let's adopt a resolution that we agree with the
handling of the CSS WG
chcunningham: Just want to clarify the list that Greg gave. Is
color-gamut included?
… Do we want to do that in addition to dynamic-range?
gregwhitworth: I don't have strong feelings about that.
jernoble: I'm just going to read Mark's mind, and say that
he'll want to target both differently.
… Dynamic range is more about brightness level than it is about
color.
gregwhitworth: So I agree that we probably want to add that as
well.
… There's a CSS call tomorrow but the topic won't be on the
agenda. So not until next week or the week after that.
Resolved: Regarding bi-plane support, video- properties for
width, height, resolution, dynamic-range, color-gamut within
CSS for media queries
gregwhitworth: My expectation is that, in the CSS call, we'll
just summarize the options and get agreement that the second
option is indeed the right one. We've done our due diligence.
Media Capabilities Issue #136 (aka. DolbyVision)
jernoble: It looks like there's been some back and forth on the
issue page. Vi, would you be able to give us an update?
vi_nguyen: rdoherty0 brought up that the reference we had is
not enough. Question is "is 2094-10 enough?" or do we need a
new string to handle Dolby extension? See [13]comment on GitHub
issue for a summary of questions and answers
[13] https://github.com/w3c/media-capabilities/issues/136#issuecomment-555697687
vi_nguyen: In practice, Dolby has registered MIME types, so we
don't need a new string.
… The comment lists a couple of other questions and answers.
vi_nguyen: Follow-up question is "is there any point keeping
2094-10 around?". I think we should. It is standardized and
could be useful in the future. But for the perspective of
querying Dolby Vision, we would use the MIME types.
GregFreedman: Speaking from a Netflix perspective, I believe
that's a good approach. Can't say whether we'll need 2094-10.
chcunningham: Example of the VP9 MIME type wich is super long
but doesn't describe metadata. You can associate different
metadata. What we're saying here is that there is a strong
binding between the mime type and the extension.
vi_nguyen: The MIME type will contain a profile, strongly bound
to specific HDR metadata type.
chcunningham: OK, that sounds like a reasonable path forward
then.
… If there is a spec that wouldn't be controversial to
reference that would be great
vi_nguyen: To Chris' point about DolbyVision standardization,
to the best of our knowledge, that is not defined in any
standard for now.
jernoble: Let's give people on GitHub a chance to respond, but
it seems we have agreement.
MediaCapabilities and EME detection polyfill
Joey: We polyfilled the encryption scheme support based on the
key system ID. That's independent of Shaka. Anybody can use it.
… We make some assumptions based on the key system ID.
vi_nguyen: You explained that encryption scheme support is
correlated to key system. Is it correlated to codecs as well?
Say H.264 and VP9?
Joey: In a native implementation of the new API, yes, the
encryption schemes supported may vary per codec. But in the
polyfill, this is dependent only on key system.
… We know that each key system has historically supported one
particular encryption scheme since the very beginning. Most
have added support for additional schemes since, but in the
absence of a native implementation, the polyfill just assumes
the historical scheme for that key system, since that has
always worked and is always a safe guess.
… So for Widevine and PlayReady, we assume "cenc" support, and
for FairPlay, we assume "cbcs-recommended" support.
… Those values are always safe in those contexts.
… The implementation has already been done in Chrome but hasn't
shipped yet. As soon as it's in the editor's draft, the Chrome
team will start the process of landing that feature.
chcunningham: Related to [14]Media Capabilities issue #100.
… Basically a clone of what's in EME
… If no one objects, I would go ahead and prepare a PR once it
lands in the EME spec.
[14] https://github.com/w3c/media-capabilities/issues/100
Joey: At this point, we're at PR review, feedback welcome.
jernoble: Webkit has an update pending too, following
discussion on the PR that Joey talked about
ISO/IEC DIS 23091 (aka “Coding Independent Code Point”)
jernoble: I have received a comment from someone in the MPEG
Working Group who was concerned that the Media Capabilities
spec did not reference the "Coding Independent Code Point". …
It defines terms like chroma or luma, and formulas to do color
conversion and transfer functions.
… Also [tabular]
jernoble: This document contains what looks like normative
language, and it might be convenient to use the exact same
language.
… It does not look like it's a free ISO document though.
Cyril: It is a free document. If you follow the link to the
ITTF web site, you get it for free. Here's [15]a link to the
specification (ZIP file).
… Published in 2013.
[15] https://standards.iso.org/ittf/PubliclyAvailableStandards/c069661_ISO_IEC_23001-8_2016.zip
jernoble: Is the same thing true for all the other parts?
cyril: I don't know.
… The topic was raised in CTA WAVE too.
cyril: When you say that you don't want to go through an ISO
index, in practice, how do you do it? You can ask the player or
you can get a manifest and ask for each of them which one is
supported. In the second case, there is no need to convert.
… In most cases, you'll have to convert though.
… Typically from an integer into a string that you have
specified in the Media Capabilities spec.
jernoble: No point in media capabilities where you're going to
query the details of the audio/video. OK, I'll take that back
on my side.
<jernoble> [16]https://www.iso.org/standard/73412.html
[16] https://www.iso.org/standard/73412.html
<cyril> [17]https://www.itu.int/rec/T-REC-H.273-201612-I/en
[17] https://www.itu.int/rec/T-REC-H.273-201612-I/en
<cyril> "After ISO/IEC 23001-8:2016 was split into three parts
in 2019 and renumbered as ISO/IEC 23091 parts 1, 2 and 3, ITU-T
H.273 remained technically aligned to ISO/IEC 23091-2:2019."
[some discussion on renumbering of ISO standards, the link
Cyril pointed people to is previous version]
<chcunningham> [18]https://github.com/w3c/media-capabilities/
issues/118#issuecomment-526780468
[18] https://github.com/w3c/media-capabilities/issues/118#issuecomment-526780468
<chcunningham> [19]https://github.com/w3c/media-capabilities/
issues/118#issuecomment-529033474
[19] https://github.com/w3c/media-capabilities/issues/118#issuecomment-529033474
<chcunningham> ^^ relevant to discussion of code points
chcunningham: This code point question, I raised this in our
larger discussion around HDR.
… I pasted two comments on IRC that are relevant for this
discussion.
… I recognized this code point could be relevant because the
VP9 codec string is designed to reference it.
… It would be trivial for Chrome to translate. Having said
that, the code points are more robust.
… Mark thought that the more coarse values that we're using are
enough though.
… I don't have strong opinion, just wanted to raise that in the
context of this discussion
jernoble: My understanding of that issue is that it's more for
non VP9 codec strings that don't have this code point
references
… I will take this back to our standards body
cyril: The comment seems to be that Media Capabilities does not
reference "CICP"
AOB
gregwhitworth: We've been working with partners on client-side
video editing, see [20]Improved client side video editing
explainer.
… I don't necessarily think that the Media WG is the right
place to discuss this.
[20] https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/MediaBlob/explainer.md
mounir: How is it related to WebCodecs?
gregwhitworth: Very related. If there is proof that WebCodecs
is coming very fast, then that could probably be used instead.
mounir: We are starting to work on that in Chrome. My
understanding is that video editing is one use case that we're
trying to solve.
… I will put you in touch with people at Google.
chcunningham: There is a WebCodecs weekly meeting tomorrow. I
believe Microsoft, Mozilla are regularly attending.
gregwhitworth: Excellent.
Barbara: Also interest from Intel. Happy to connect you to
people here.
… Riju is taking care of it on our side, typically
mounir: Yes, we seem to be talking to the same people in
different places.
jernoble: Thank you everyone for attending. We'll probably
bounce between the two time slots.
Summary of resolutions
1. [21]Regarding bi-plane support, video- properties for
width, height, resolution, dynamic-range, color-gamut
within CSS for media queries
Received on Wednesday, 20 November 2019 19:29:41 UTC