20:45:42 <RRSAgent> RRSAgent has joined #mediawg
20:45:42 <RRSAgent> logging to https://www.w3.org/2020/09/08-mediawg-irc
20:45:46 <Zakim> Zakim has joined #mediawg
20:46:00 <tidoust> RRSAgent, make logs public
20:46:18 <tidoust> Meeting: Media WG call
20:46:43 <tidoust> Agenda: https://github.com/w3c/media-wg/blob/master/meetings/2020-09-08-Media_Working_Group_Teleconference-agenda.md
20:46:48 <tidoust> Chair: Jer, Mounir
20:49:04 <tidoust> scribe: tidoust
20:56:43 <Xiaohan_Wang> Xiaohan_Wang has joined #mediawg
20:58:12 <jernoble> jernoble has joined #mediawg
20:58:24 <gregfreedman> gregfreedman has joined #mediawg
20:59:59 <beccahughes> beccahughes has joined #mediawg
21:00:20 <tidoust> present+ Francois_Daoust, Jer_Noble, Joey_Parrish, Matt_Wolenetz, Xiaohan_Wang, Jean-Yves_Avenard
21:00:22 <cpn> cpn has joined #mediawg
21:01:04 <mattwolenetz_> mattwolenetz_ has joined #mediawg
21:01:17 <mattwolenetz_> present+
21:01:30 <cpn> present+ Chris_Needham
21:01:34 <tidoust> Present+ Greg_Freedman
21:01:50 <mattwolenetz_> present+ Matt_Wolenetz
21:02:20 <hober> hober has left #mediawg
21:02:23 <tidoust> present+ Peng_Liu
21:02:29 <hober> hober has joined #mediawg
21:02:36 <hober> present+
21:02:41 <tidoust> present+ Becca_Hughes
21:05:16 <tidoust> Present+ Gary_Katsevman
21:05:35 <tidoust> Topic: Add "usable-in-future" to MediaKeyStatus
21:05:47 <tidoust> -> https://github.com/w3c/encrypted-media/issues/451 Issue #451
21:06:06 <tidoust> jernoble: A couple of "OK" in comments. Anything to discuss?
21:06:25 <tidoust> Xiaohan_Wang: Originally filed the issue.
21:06:32 <pengliu> pengliu has joined #mediawg
21:06:52 <mounir> present+
21:06:53 <tidoust> ... I see Greg and Joey agree. We just brought it to see if there is consensus, then we can work on actual text
21:07:07 <JoeyParrish> JoeyParrish has joined #mediawg
21:07:16 <tidoust> jernoble: Additional status field that represents a "future" state, right?
21:07:24 <tidoust> Xiaohan_Wang: Correct.
21:07:31 <jernoble> q+
21:07:50 <tidoust> ... Only "usable" or "expired" could be used and don't apply this status
21:08:05 <tidoust> jernoble: No objection heard. I think we can go ahead
21:08:15 <tidoust> Present+ Mark_Watson
21:08:23 <tidoust> Topic: Handling hardware context reset
21:08:33 <tidoust> -> https://github.com/w3c/encrypted-media/issues/473 Issue #473
21:09:13 <tidoust> 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.
21:09:22 <tidoust> ... In some cases, media playback will fail.
21:09:40 <tidoust> ... In Windows, the system will throw a special HResult status.
21:10:05 <tidoust> ... The current spec does not explain how to expose this. Application rely on workarounds.
21:10:20 <tidoust> ... These kind of errors are not real errors, just "normal" workflow for users.
21:10:30 <tidoust> ... If we retry, it should work.
21:10:41 <tidoust> ... No standard way to detect this case though.
21:10:53 <tidoust> ... I'm proposing to specify this process.
21:11:31 <tidoust> ... One aspect is MediaElement, firing a waitingForKey event while playback stalls.
21:12:09 <tidoust> ... 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.
21:12:16 <tidoust> ... Idea is to return a reason.
21:12:17 <jernoble> q+
21:12:33 <jya_> q+
21:12:45 <tidoust> ... Equipped with that, the application would know what happened and would be able to deal with it.
21:12:47 <jernoble> ack jer
21:12:52 <tidoust> ... Same thing, looking to achieve consensus here.
21:13:09 <tidoust> jernoble: How is this different to having all the key statuses set to expired?
21:13:44 <tidoust> 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.
21:14:07 <tidoust> ... 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.
21:14:33 <tidoust> ... That doesn't fit this case very well, and more work for implementations.
21:14:56 <tidoust> jernoble: For context, Webkit already keeps a cache of key ids
21:15:06 <gregfreedman> hand
21:15:20 <JoeyParrish> q+
21:15:39 <tidoust> ... 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.
21:16:07 <tidoust> Xiaohan_Wang: I think the special media foundation error is Windows specific, but the hardware scenario is common to multiple platforms.
21:17:02 <tidoust> ... 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?
21:17:50 <tidoust> ... 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.
21:18:07 <tidoust> ... My point of adding a status is that it would make things super clear.
21:18:17 <jernoble> ack jya_
21:18:24 <tidoust> ... I talked with people who did not realize that the session could be closed in such ways.
21:18:55 <tidoust> jya_: Adding to what Jer said, the error is transparent. Why can't you resume playback once you have re-negotiated your keys?
21:19:10 <tidoust> Xiaohan_Wang: Only the JS can re-negotiate the keys currently.
21:19:34 <tidoust> ... While the license is there, the media element can resume the playback.
21:20:07 <tidoust> 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.
21:20:27 <tidoust> Xiaohan_Wang: For normal video playback, all the playback is happening on the client. User or JS won't see anything.
21:20:43 <tidoust> ... In this case, there must be network traffic going to JavaScript.
21:21:02 <jernoble> q?
21:21:56 <tidoust> ... 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.
21:22:40 <tidoust> ... Some JS players can also tear down everything and restart everything, but that will add some latency.
21:23:05 <jernoble> ack JoeyParrish
21:23:15 <tidoust> ... 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.
21:23:34 <tidoust> present+ Mounir_Lamouri
21:24:14 <tidoust> 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.
21:24:32 <tidoust> ... To Jer's point about re-using expired, I can see the desire not to introduce new things to solve this problem.
21:25:05 <jernoble> q+
21:25:17 <gregfreedman> q+
21:25:20 <tidoust> ... 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.
21:25:32 <jernoble> ack jernoble
21:25:37 <tidoust> ... Also "expired" is confusing for developers.
21:25:56 <tidoust> jernoble: Clarifying question, do we have a list of reasons why a CDM can close itself?
21:26:27 <tidoust> JoeyParrish: That doesn't exist today. Right now, the spec says that the CDM can close itself, it doesn't say why.
21:26:43 <tidoust> ... There's a Promise<void> for now.
21:26:51 <jernoble> ack gregfreedman
21:26:52 <tidoust> ... This proposal would return a Promise<Reason>
21:27:58 <Xiaohan_Wang> q+
21:28:08 <tidoust> 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?
21:28:10 <jernoble> ack Xiaohan_Wang
21:28:51 <tidoust> 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.
21:29:05 <jernoble> q+
21:29:10 <jernoble> ack jernoble
21:29:14 <tidoust> ... And a third one for the CDM.
21:29:45 <tidoust> 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.
21:29:54 <tidoust> ... Does that sound reasonable?
21:30:10 <tidoust> [Plenty of silence heard]
21:30:15 <mattwolenetz_> q+ triaging MSE
21:30:32 <tidoust> Topic: Triage MSE/EME issues
21:30:38 <tidoust> ack triaging
21:31:26 <tidoust> q+ mattwolenetz_
21:31:28 <tidoust> ack MSE
21:31:41 <mounir> https://github.com/w3c/encrypted-media/issues
21:31:57 <tidoust> mounir: We could either start with MSE/EME. EME should go fast because the charter is very specific about what we may be doing.
21:32:07 <tidoust> ... I see some already marked as v2.
21:32:49 <tidoust> JoeyParrish: These are all relatively new, probably in the last month or so. 17 issues without milestones, the rest qualified as "backlog"
21:32:53 <jernoble> https://github.com/w3c/encrypted-media/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone
21:32:59 <tidoust> mounir: Where backlog means not taken care of, right?
21:33:02 <tidoust> JoeyParrish: Correct.
21:33:27 <tidoust> mounir: I'm happy with that.
21:34:01 <mounir> #468
21:34:29 <tidoust> -> https://github.com/w3c/encrypted-media/issues/468 Issue #468
21:34:59 <tidoust> JoeyParrish: Issue #468 seems to be more a broken TV than an issue with the spec.
21:35:16 <tidoust> ... This seems more to be a question, hence the "question" tag
21:35:18 <mounir> #466
21:35:29 <tidoust> -> https://github.com/w3c/encrypted-media/issues/466 Issue #466
21:36:03 <tidoust> mounir: Issue #466 seems to be more an issue about the spec
21:36:20 <tidoust> JoeyParrish: Not sure I understand and what would need to be done to clarify this in the spec.
21:36:29 <tidoust> ... Should this go to v2 or backlog?
21:36:46 <tidoust> mounir: Seems either a bug or a clarification
21:37:00 <Xiaohan_Wang> q+
21:37:11 <mattwolenetz_> q-
21:37:12 <mounir> ack Xiaohan_Wang
21:37:15 <tidoust> ... I wonder whether other specs mention behavior after unload time
21:37:33 <tidoust> Xiaohan_Wang: I know that we're already handling this in Chromium. We'll just reject the promise.
21:37:47 <mounir> #464
21:37:53 <tidoust> -> https://github.com/w3c/encrypted-media/issues/464 Issue #464
21:38:44 <tidoust> mounir: Any input on that one?
21:39:10 <tidoust> JoeyParrish: Do we know for Widevine and Fairplay?
21:39:16 <tidoust> Xiaohan_Wang: I'll have to check.
21:39:44 <tidoust> jernoble: It's... complicated. Even within the system CDM family, you have a wide range of keys available.
21:40:15 <tidoust> JoeyParrish: Perhaps we need some type of editorial note that there is some variation on the length of acceptable keys.
21:41:08 <tidoust> ... Should we keep questions/bugs together, flagged as v2?
21:41:33 <tidoust> mounir: I expect that the critical matter is new features that have to match the charter.
21:42:15 <mounir> #462
21:42:20 <tidoust> 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
21:42:25 <mounir> #461
21:42:33 <tidoust> -> https://github.com/w3c/encrypted-media/issues/462 Issue #462
21:42:38 <tidoust> -> https://github.com/w3c/encrypted-media/issues/461 Issue #461
21:42:55 <tidoust> s|-> https://github.com/w3c/encrypted-media/issues/462 Issue #462||
21:43:25 <tidoust> mounir: Issue #461 seems to be editorial in nature.
21:43:50 <jernoble> q+
21:44:53 <jernoble> ack jernoble
21:44:53 <mounir> #460
21:44:58 <tidoust> 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.
21:45:21 <tidoust> -> https://github.com/w3c/encrypted-media/issues/460 Issue #460
21:45:31 <tidoust> Xiaohan_Wang: Issue #460 seems to be clarification
21:45:33 <mounir> #453
21:45:42 <tidoust> mounir: OK, I'll use the "bug" label too
21:45:49 <tidoust> -> https://github.com/w3c/encrypted-media/issues/453 Issue #453
21:46:06 <mounir> #452
21:46:15 <tidoust> mounir: Just a WebIDL update
21:46:15 <mounir> #450
21:46:23 <tidoust> ... Same for #452
21:46:38 <tidoust> -> https://github.com/w3c/encrypted-media/issues/450 Issue #450
21:47:00 <mounir> #449
21:47:08 <tidoust> 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.
21:47:16 <tidoust> -> https://github.com/w3c/encrypted-media/issues/449 Issue #449
21:47:53 <mounir> #448
21:47:58 <tidoust> 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.
21:48:02 <tidoust> -> https://github.com/w3c/encrypted-media/issues/448 Issue #448
21:48:07 <mounir> #447
21:48:13 <tidoust> -> https://github.com/w3c/encrypted-media/issues/447 Issue #447
21:48:58 <mounir> #445
21:49:00 <tidoust> mounir: #448 and #447 are spec comments / IDL. I will add the bug labels. Right now, v2, but this can be adjusted as needed.
21:49:12 <tidoust> Xiaohan_Wang: Right, not familiar with strings and enums.
21:49:30 <mounir> #443
21:49:32 <tidoust> -> https://github.com/w3c/encrypted-media/issues/443 Issue #443
21:49:45 <tidoust> JoeyParrish: #443 is more a question
21:49:47 <mounir> #442
21:49:52 <tidoust> -> https://github.com/w3c/encrypted-media/issues/442 Issue #442
21:50:12 <tidoust> mounir: #442 seems to be a new feature request.
21:50:37 <tidoust> JoeyParrish: Right, if it were v2, we should discuss.
21:50:49 <tidoust> jernoble: Isn't that a case where update will fail?
21:51:16 <tidoust> JoeyParrish: Potentially, you might have one key that is usable and another one that is not.
21:51:50 <tidoust> Xiaohan_Wang: Similar to scenarios we discussed. When update is called, maybe the key is usable but then becomes unusable later on
21:52:14 <tidoust> mounir: should we move that to backlog?
21:52:15 <mounir> #440
21:52:18 <tidoust> JoeyParrish: Sounds good
21:52:23 <tidoust> -> https://github.com/w3c/encrypted-media/issues/440 Issue #440
21:52:38 <mounir> #438
21:52:45 <tidoust> JoeyParrish: Recurring conversation. We probably want to tweak the spec.
21:52:50 <tidoust> -> https://github.com/w3c/encrypted-media/issues/438 Issue #438
21:53:18 <tidoust> JoeyParrish: I think #438 is "bug" and v2.
21:53:19 <mounir> #433
21:53:24 <tidoust> -> https://github.com/w3c/encrypted-media/issues/433 Issue #433
21:53:57 <tidoust> mounir: bug and v2
21:54:09 <tidoust> mounir: Moving on to MSE.
21:54:39 <tidoust> mattwolenetz_: There is a v2BugFixes milestone already
21:55:08 <tidoust> mounir: 76 issues without milestone
21:55:24 <tidoust> mattwolenetz_: I want to make sure that I have the input from my co-editor.
21:55:42 <tidoust> ... I see Mark dropped from the call.
21:56:15 <tidoust> ... I expect the bulk of triaging to happen offline.
21:56:55 <tidoust> ... MSE in workers feature is the main priority for now, because we expect that to be the bulk of v2. That should soon land.
21:57:08 <tidoust> ... We can look at other issues later on.
21:57:21 <tidoust> mounir: Some of the other issues are rather old and could be closed rather quickly.
21:57:39 <tidoust> ... We may want to do MSE triaging at the end of next call.
21:57:57 <tidoust> mattwolenetz_: I would support doing triaging of MSE issues in next call
21:58:20 <tidoust> mounir: Yes, we need to get down to ~20 issues. 76 is too much to go over them in a call.
21:58:46 <tidoust> Topic: Next calls
21:59:41 <tidoust> 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.
21:59:47 <tidoust> [meeting adjourned]
21:59:52 <tidoust> RRSagent, draft minutes v2
21:59:52 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/08-mediawg-minutes.html tidoust