Meeting minutes
Agenda bashing
eugene: WebCodecs issues are low priority. One of them should just be resolved. Happy to rearrange the agenda to put them last.
cpn: Managed MediaSource?
marcosc: Not to be discussed in great detail today. Jean-Yves has started to work on a PR. Hopefully, by the next time we meet, we'll have a PR ready for discussion.
cpn: OK, let's review that in detail when there's a PR then
Media Session
cpn: We identified a couple of issues when we prepared the agenda with Marcos.
The freezing in the artwork getter is broken
cpn: Ability to mutate the metadata
marcosc: Problem is that the PR is not addressing the core of the issue. IDL usage issue. As Jan-Ivar points out, we should at least try to make sense of what's been implemented.
… I would be surprised if implementations would do something weird beyond what IDL usually allows.
jernoble: Webkit's implementation should only modify the metadata internally when it's first set. Modifying the object afterwards would have no effect.
marcosc: That makes sense. That may also confuse developers who may think that they have something mutable at hand.
… We need to evaluate whether the PR is backwards compatible with what's been implemented.
… According to Jan-Ivar, Firefox is the only one using a FrozenArray.
cpn: Youenn asks to update the PR according to this feedback in the previous comment.
… and make a new issue for the follow-up stuff.
marcosc: Not clear whether Chun-Min is still going to do something about it because it's been several years since the last comment.
cpn: With Mozilla, I think. Jan-Ivar should be the right point of contact.
Tommy: I haven't checked Chrome's implementation. I would like to get a better state. We need to figure out what other browsers are doing.
marcosc: If you can update the thing thousands of time, that's going to be a problem.
… That thing shouldn't be updatable after it's been set.
Tommy: Setting the metadata to a new object would be the right thing to do, then?
marcosc: Need to evaluate. The core is figuring out what implementations do for the time being. It's a very edgy thing. I don't imaging anybody updating the artwork this way.
cpn: Desired end state: assigning a new object to the metadata. After that, it's all readonly when you read it back through Media Session.
marcosc: I guess.
… Let's look at implementations first, and get back to it.
Tommy: I can evaluate what Chrome is currently doing for sure.
marcosc: I think Youenn tested Chrome about a month ago.
… Larger question for Chrome is whether changing something in that array has some side effect. I very much doubt that's the case, but I could be surprised!
cpn: OK, clear next steps on that.
EME - Allow getStatusForPolicy() to reject the promise with NotSupportedError
Xiaohan: We want a clear signal about the case where platforms can enforce HDCP status but there's no way to know beforehands.
… A lot of DRM systems can do the enforcing already, but do not necessarily expose that to the outside world.
… Previously, there were workaround, testing a key to obtain a license.
marcosc: What is able to disable this particular feature?
… What results in NotSupported error?
Xiaohan: When the platform doesn't know whether it can support this HDCP level or not, it would report this error.
marcosc: Wondering whether it exposes anything from a privacy perspective or not.
Xiaohan: It's typically a limitation of the OS or the device.
… Examples: Old Chromecast devices. Linux as well.
… From a privacy perspective, this API itself has privacy concerns. What's added there does not, I think.
jernoble: Does that kind of confuse the meaning of outputRestricted?
… Mixing of meanings between e.g., iOS and Linux.
Xiaohan: If we have a key with this queried HDCP level, then outputRestricted might be issued. Which is different from cannot play at all.
jernoble: I see.
… What seems to be missing here, there isn't a value in mediakeysession that can tell you "I cannot tell you right now".
… Impossible to say.
Xiaohan: It goes back to the initial spec. The best way for consistency is to reflect things with a key status.
… I agree with you that we cannot represent this with a key status.
jernoble: On those platforms where you can't query ahead of time, do you get good results when you start playback?
Xiaohan: Yes, that's the expectation. If you know in advance that it's not going to work, you should report outputRestricted.
jernoble: The thing I worry about is changing an API to reject when it previously did not. May break things.
Xiaohan: Good news is that Chrome's implementation already rejects because it does not fully respect the original proposal.
marcosc: From an architecture perspective, whenever you return a Promise, you should expect that the Promise may reject.
jernoble: Webkit at least should not have this issue because we don't have to run across that wide variety of hardware.
marcosc: One thing to think about: people may assume something from missing information that is not really implied.
jernoble: I don't think that we implement this API yet. But it's been requested.
… I am fine with the proposal after talking it through.
… I am ok with newly rejecting when you can't satisfy the demand of the API.
cpn: That's good.
cpn: On a side note, we should aim at publishing EME as First Public Working Draft.
Xiaohan: Planning to exchange with Greg this week.
cpn: If there's anything that I can help with on that, let me know.
WebCodecs
Alpha support
eugene: Reports from people trying to decode streams with alpha. Depends on codecs, such as H.265 where alpha is carried as a separate thing.
… From spec point of view, it's possible to encode a frame with alpha. However, for decoding, for cases where alpha channel needs to be carried out separately, it's impossible to support because no place to put this alpha data.
… I'm curious about implementation status and plans in browsers, and if we should think about including alpha channel in decoders as well. It's kind of strange to have an asymetry between encoding and decoding.
… No PR for now.
jernoble: If I remember right, on VP8 and HEVC and AV1, the alpha support is on a separate layer. Similar problem to Dolby Vision. A couple of other proposals where it's a progressive video proposal.
… I do wonder whether there's a more general problem than alpha channel.
… How to pass additional data layers to the decoder.
… So yes, it is a problem.
eugene: Similar problem with SVC, come to think about it. Maybe I need to look into that.
… Small resolution frame, and on top of that, data to make a higher resolution frame.
… HEVC has alpha channel in the same channel, I think.
jernoble: I'm not certain about that. Last I checked a few years ago, that was not the case but ISOBMFF stuff may have changed things.
eugene: OK. Anyway, that's a very good point to look at the broader perspective.
cpn: We already have the alpha side data. Is that WebM specific?
eugene: Yes. More codec specific though, container may vary.
jernoble: I don't know whether you can mix and match codecs within the same container. e.g., HEVC stream with AVC alpha channel.
… The canvas folks are looking into HDR colors and people are going to be willing to use some advanced codecs for that with WebCodecs.
Can we drop the secure context (https) requirement?
eugene: Situation has not changed. Chromium is disinclined to expose new APIS to non secure contexts.
jernoble: not the right person to ask, Youenn would be a better person there.
cpn: I'm wondering whether that's a general thing, or something specific about WebCodecs.
… The person raising this has a pretty valid use case, using security camera, likely on their local network.
eugene: Self-signed certificates and, in Chromium, there is an exception list for websites to be treated as secure contexts even though they're not secure.
… I could link to this.
cpn: I think that's worth doing. Helpful for the person developing some open source project.
eugene: Back to alpha support, next step is to look whether that can be combined with the other scenarios that Jer mentioned.
cpn: It was good to see people at TPAC. Let me know if you have feedback on how to progress things. Next meeting should be November 14.