Meeting minutes
Add "usable-in-future" to MediaKeyStatus (#451)
jernoble: A couple of "OK" in comments. Anything to discuss?
Xiaohan_Wang: Originally filed the issue.
… I see Greg and Joey agree. We just brought it to see if there is consensus, then we can work on actual text
jernoble: Additional status field that represents a "future" state, right?
Xiaohan_Wang: Correct.
… Only "usable" or "expired" could be used and don't apply this status
jernoble: No objection heard. I think we can go ahead
Handling hardware context reset (#473)
Xiaohan_Wang: For certain hardware based CDM systems, if the device enters suspend/resume, or if the user switches monitors, e.g. from one graphics card to another, the hardware context for the session would be lost.
… In some cases, media playback will fail.
… In Windows, the system will throw a special HResult status.
… The current spec does not explain how to expose this. Application rely on workarounds.
… These kind of errors are not real errors, just "normal" workflow for users.
… If we retry, it should work.
… No standard way to detect this case though.
… I'm proposing to specify this process.
… One aspect is MediaElement, firing a waitingForKey event while playback stalls.
… Another aspect is on the EME side, to change the closed attribute. The closed promise does not return any parameter, so no way to know why the session got closed.
… Idea is to return a reason.
… Equipped with that, the application would know what happened and would be able to deal with it.
… Same thing, looking to achieve consensus here.
jernoble: How is this different to having all the key statuses set to expired?
Xiaohan_Wang: expiration is misleading. The whole CDM set has been reset. In this case, the CDM will lose all its state, so it won't even know which keys it had.
… The EME stack of the browser would have to remember all the key IDs that the EME session had before the hardware context reset happened.
… That doesn't fit this case very well, and more work for implementations.
jernoble: For context, Webkit already keeps a cache of key ids
jernoble: From an ecosystem point of view, introducing a new status won't get a lot of adoption, especially if it essentially just happens on Windows.
Xiaohan_Wang: I think the special media foundation error is Windows specific, but the hardware scenario is common to multiple platforms.
… If I'm new to this and implement a JS player, why should I know that if all key IDs are expired, then we're in the hardware context reset case?
… Session closed vs. all session keys expired. In both cases, we need to update the EME spec to explain what needs to happen in such a scenario.
… My point of adding a status is that it would make things super clear.
… I talked with people who did not realize that the session could be closed in such ways.
jya_: Adding to what Jer said, the error is transparent. Why can't you resume playback once you have re-negotiated your keys?
Xiaohan_Wang: Only the JS can re-negotiate the keys currently.
… While the license is there, the media element can resume the playback.
jya_: You should be able to totally hide that this error happened, and have the user agent do things under the hoods and resume playback later on.
Xiaohan_Wang: For normal video playback, all the playback is happening on the client. User or JS won't see anything.
… In this case, there must be network traffic going to JavaScript.
… On the media element, the current proposal is to add a "waitingForKey" event. Other than that, there is no error. Then, if the JS re-negotiates some license, then then media element can resume the playback automatically.
… Some JS players can also tear down everything and restart everything, but that will add some latency.
… JS can also add a play button. Multiple ways to do it, the goal is to have a clear way to signal that this happens to the JS.
JoeyParrish: Jean-Yves, the source of confusion may be that all network communications need to go through the application. There is no way to re-negotiate the licenses without involving the application.
… To Jer's point about re-using expired, I can see the desire not to introduce new things to solve this problem.
… But if the CDM can close itself, it can't hurt to have an enum to say why it closed itself. Certainly in Shaka Player, we would change behavior when we see expired statuses.
… Also "expired" is confusing for developers.
jernoble: Clarifying question, do we have a list of reasons why a CDM can close itself?
JoeyParrish: That doesn't exist today. Right now, the spec says that the CDM can close itself, it doesn't say why.
… There's a Promise<void> for now.
… This proposal would return a Promise<Reason>
gregfreedman: Joey clarified what I wanted to say. Nothing added to EME on top of the reason why the closed happens. More information about whether things got closed by the application or by the CDM. And if by the CDM, why?
Xiaohan_Wang: We kind of talked about possible enum values last time as well. HARDWARE_CONTEXT_RESET. Also one for application reason when the session is closed by the application.
… And a third one for the CDM.
jernoble: I don't hear any objection to this idea, so it seems reasonable to prepare a PR for this, so that we can discuss with concrete text in front of us.
… Does that sound reasonable?
[Plenty of silence heard]
Triage MSE/EME issues
<mounir> https://github.com/w3c/encrypted-media/issues
mounir: We could either start with MSE/EME. EME should go fast because the charter is very specific about what we may be doing.
… I see some already marked as v2.
JoeyParrish: These are all relatively new, probably in the last month or so. 17 issues without milestones, the rest qualified as "backlog"
mounir: Where backlog means not taken care of, right?
JoeyParrish: Correct.
mounir: I'm happy with that. I suggest we review issues without milestones
EME issue #468
JoeyParrish: Issue #468 seems to be more a broken TV than an issue with the spec.
… This seems more to be a question, hence the "question" tag
EME issue #466
mounir: Issue #466 seems to be more an issue about the spec
JoeyParrish: Not sure I understand and what would need to be done to clarify this in the spec.
… Should this go to v2 or backlog?
mounir: Seems either a bug or a clarification
… I wonder whether other specs mention behavior after unload time
Xiaohan_Wang: I know that we're already handling this in Chromium. We'll just reject the promise.
EME issue #464
mounir: Any input on that one?
JoeyParrish: Do we know for Widevine and Fairplay?
Xiaohan_Wang: I'll have to check.
jernoble: It's... complicated. Even within the system CDM family, you have a wide range of keys available.
JoeyParrish: Perhaps we need some type of editorial note that there is some variation on the length of acceptable keys.
… Should we keep questions/bugs together, flagged as v2?
mounir: I expect that the critical matter is new features that have to match the charter.
JoeyParrish: Then I would suggest that such issues that should have us add some text to the spec, we put a v2 milestone to them, and then see later on whether we want to put them to the backlog
EME issue #461
mounir: Issue #461 seems to be editorial in nature.
jernoble: I would make a generic recommendation to add a bug label, so that we can look at them offline afterwards. And then use a "v2bugs" milestone for instance.
EME issue #460
Xiaohan_Wang: Issue #460 seems to be clarification
mounir: OK, I'll use the "bug" label too
EME issues #453, #452
mounir: Just a WebIDL update
… Same for #452
EME issue #450
JoeyParrish: Actually matches an issue against Shaka Player. In short, there is no good way to figure that out. I suggest putting it to the backlog, but will look into it.
EME issues #449
JoeyParrish: #449 is a feature request, but in the backlog, not something we're planning to work on. It involves multiple CDMs working simultaneously, which seems a bit exotic.
EME issues #448 and #447
mounir: #448 and #447 are spec comments / IDL. I will add the bug labels. Right now, v2, but this can be adjusted as needed.
Xiaohan_Wang: Right, not familiar with strings and enums.
EME issue #443
JoeyParrish: #443 is more a question
EME issue #442
mounir: #442 seems to be a new feature request.
JoeyParrish: Right, if it were v2, we should discuss.
jernoble: Isn't that a case where update will fail?
JoeyParrish: Potentially, you might have one key that is usable and another one that is not.
Xiaohan_Wang: Similar to scenarios we discussed. When update is called, maybe the key is usable but then becomes unusable later on
mounir: should we move that to backlog?
JoeyParrish: Sounds good
EME issue #440
JoeyParrish: Recurring conversation. We probably want to tweak the spec.
EME issue #438
JoeyParrish: I think #438 is "bug" and v2.
EME issue #433
mounir: bug and v2
MSE issues
mounir: Moving on to MSE.
mattwolenetz_: There is a v2BugFixes milestone already
mounir: 76 issues without milestone
mattwolenetz_: I want to make sure that I have the input from my co-editor.
… I see Mark dropped from the call.
… I expect the bulk of triaging to happen offline.
… MSE in workers feature is the main priority for now, because we expect that to be the bulk of v2. That should soon land.
… We can look at other issues later on.
mounir: Some of the other issues are rather old and could be closed rather quickly.
… We may want to do MSE triaging at the end of next call.
mattwolenetz_: I would support doing triaging of MSE issues in next call
mounir: Yes, we need to get down to ~20 issues. 76 is too much to go over them in a call.
Next calls
mounir: The day after our next call, there will be a joint meeting with Timed Text and the Media & Entertainment IG. I recommend everyone to attend that call. I would like to get feedback on the API for TextTrack enhancements.
[meeting adjourned]