gregwhitworth: [Summary of 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.
<chcunningham> Makes sense to me
gregwhitworth: So in practice, see comment on GitHub issue, we're converging towards video-[css property]
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.
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 comment on GitHub issue for a summary of questions and answers
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.
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 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.
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
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 a link to the specification (ZIP file).
… Published in 2013.
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> https://www.iso.org/standard/73412.html
<cyril> 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> https://github.com/w3c/media-capabilities/issues/118#issuecomment-526780468
<chcunningham> 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"
gregwhitworth: We've been working with partners on client-side video editing, see Improved client side video editing explainer.
… I don't necessarily think that the Media WG is the right place to discuss this.
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.
Succeeded: s/relecant/relevant/
Maybe present: Barbara, Joey, vi_nguyen