IRC log of mediawg on 2019-09-18

Timestamps are in UTC.

23:46:09 [RRSAgent]
RRSAgent has joined #mediawg
23:46:09 [RRSAgent]
logging to https://www.w3.org/2019/09/18-mediawg-irc
23:46:15 [tidoust]
RRSAgent, make logs public
23:46:21 [tidoust]
Meeting: Media WG F2F - Day 1/2
23:46:41 [tidoust]
Chair: Jer, Mounir
23:48:31 [niwamoto]
niwamoto has joined #mediawg
23:48:59 [tidoust]
Present+ Mounir_Lamouri, Chris_Needham, Narifumi_Iwamoto, Richard_Winterton, Michael_Rosenzweig, Francois_Daoust, Paul_Adenot, Jer_Noble, Jean-Yves_Avenard, Mark_Foltz, Yongjun_Wu, Yikki_Kawamura
23:49:33 [tidoust]
Present+ Youngsun_Ryu
23:50:23 [Richw]
Richw has joined #mediawg
23:53:02 [tidoust]
Present+ Soju_Tanaka
23:53:26 [yuki]
yuki has joined #mediawg
23:56:07 [cpn]
cpn has joined #mediawg
23:57:00 [tidoust]
present+ Greg_Freedman, Scott_Low
23:57:31 [Youngsun]
Youngsun has joined #mediawg
23:57:51 [jernoble]
jernoble has joined #mediawg
23:58:28 [takio]
takio has joined #mediawg
23:59:37 [tidoust]
RRSAgent, this meeting spans midnight
00:00:37 [tidoust]
scribe: tidoust
00:01:29 [tidoust]
jer: Welcome. Looking at the agenda, any change requested? Couple of changes in the last couple of days. Low-latency video signaling was added today.
00:01:49 [MasayaIkeo]
MasayaIkeo has joined #mediawg
00:01:52 [tidoust]
mounir: I added WebCodecs, audiobooks, and I moved some things around for external folks to be able to join relevant sessions.
00:02:10 [tidoust]
Present+ Chris_Cunningham
00:02:24 [tidoust]
i/jer: Welcome/Topic: Agenda bashing
00:02:33 [urata_access]
urata_access has joined #mediawg
00:02:43 [tidoust]
Topic: WG boot up
00:02:47 [Soju]
Soju has joined #mediawg
00:03:12 [tidoust]
jer: This is the first meeting of the Media WG. We don't really have a process or norms setup. We didn't want to settle on anything before we had a chance to discuss
00:03:17 [tidoust]
present+ Mark_Watson
00:03:31 [scottlow]
scottlow has joined #mediawg
00:03:46 [tidoust]
jer: When will we have phone calls, F2F, email threads, github issues, etc?
00:04:00 [tidoust]
scottlow: I personally like calls, good way to progress issues.
00:04:16 [tidoust]
richard: I prefer video calls sometimes.
00:04:33 [tidoust]
jer: Sure, that's through WebEx, video is possible.
00:05:07 [tidoust]
richard: We had troubles with webassembly groups, went through Zoom.
00:05:24 [markw]
markw has joined #mediawg
00:05:35 [tidoust]
jer: Let's try to start with WebEx
00:05:39 [chcunningham]
chcunningham has joined #mediawg
00:05:57 [tidoust]
narifumi: Guidelines for work mode, communications?
00:06:02 [tidoust]
jer: We don't have them yet.
00:06:11 [tidoust]
Present+ John_Riviello
00:06:32 [tidoust]
markw: I would be in favor of not only have calls on topics, but also a regular cadence of calls.
00:06:34 [GregFreedman]
GregFreedman has joined #mediawg
00:06:40 [tidoust]
... Good way to pop issues back to the top.
00:07:03 [tidoust]
... Calling for consensus on the calls.
00:07:22 [tidoust]
mounir: The other side of that is that some groups punt discussions to calls.
00:07:34 [tidoust]
... Work in WICG went well without calls.
00:07:49 [tidoust]
... I could be open to a regular call but don't want to discuss everything.
00:07:53 [tidoust]
markw: I agree with that.
00:08:24 [tidoust]
cpn: Just would like the call not to overlap with Media & Entertainment IG monthly calls.
00:09:00 [JohnRiv]
JohnRiv has joined #mediawg
00:09:05 [tidoust]
mounir: Something we could do. Ada has a bot where you can do /agenda on an issue that adds an issue to the agenda.
00:09:41 [tidoust]
... I don't want to have everyone show up in a weekly call just because the time is booked on your calendar
00:10:19 [tidoust]
markw: Yes, not weekly calls. Regular cadence is a way to process backlog and close issues when there's no activity or call for volunteers to address them.
00:10:57 [tidoust]
richard: Cancellation when there are no agenda items can be good.
00:11:01 [tidoust]
jer: Yes.
00:11:22 [tidoust]
... A monthly cadence seems good. I doubt we'll have nothing to talk after a month.
00:11:55 [tidoust]
cpn: Useful to have a dedicated slot on the calendar instead of ad-hoc doodling.
00:11:59 [tidoust]
mounir: definitely
00:12:43 [tidoust]
... Everyone here ok with a monthly call? And encourage ad-hoc discussions?
00:13:03 [tidoust]
markw: You could have a slot for ad-hoc discussions.
00:13:26 [tidoust]
mounir: Yes, encourage ad-hoc discussions, minute the discussions publicly
00:13:37 [tidoust]
markw: Right, just make sure that everyone is invited.
00:13:47 [tidoust]
mounir: Yes, good point.
00:14:14 [tidoust]
markw: Want to emphasize the need to have a triage task during the monthly call.
00:14:18 [tidoust]
jer: Yes.
00:14:34 [tidoust]
richard: I don't want to take a lot of time on that because you have only one hour.
00:14:51 [tidoust]
jer: Thinking about non assigned issues?
00:14:55 [tidoust]
markw: yes
00:15:18 [tidoust]
jer: So triage could be about assigning issues and not discussing issues in themselves.
00:15:25 [tidoust]
... What about F2F meetings?
00:15:41 [tidoust]
... We have a F2F at TPAC, is that enough?
00:16:03 [tidoust]
mounir: Most of us go to FOMS. I don't know if we should use that as a second F2F opportunity.
00:16:24 [tidoust]
jer: There's an opportunity to do a meeting.
00:16:32 [tidoust]
Present+ Stephan_Steglich
00:16:53 [tidoust]
mounir: It would be less exotic, but more convenient for people
00:17:25 [tidoust]
markw: I think we should revisit in a couple of months whether we want to have another meeting. Good idea to coordinate with other event otherwise.
00:17:40 [tidoust]
mounir: I'm sure 6 months after TPAC, a 1 day meeting is useful
00:18:24 [tidoust]
ACTION: jer and mounir to talk to FOMS organizers about interest to co-host a Media WG F2F
00:19:33 [scottlow]
https://github.com/w3c/media-capabilities/issues/131
00:19:58 [tidoust]
scott: Note Greg's proposal on GitHub
00:20:27 [tidoust]
markw: Question on how formal we want to be. We need to understand what the consensus is.
00:20:40 [tidoust]
jer: Actions and resolutions are a good way to record the TLDR of meetings.
00:20:52 [tidoust]
... Question is do you want to do it for everything?
00:21:11 [tidoust]
mounir: For GitHub issues, I think what works well is aggressively cc'ing people.
00:21:24 [tidoust]
... I don't see any reason to change that, no one complained about changes landed so far.
00:21:35 [tidoust]
... Are there concrete concerns?
00:22:00 [tidoust]
scottlow: I don't think that Greg is concerned about anything in particular, just to have a way to track resolutions.
00:22:27 [tidoust]
chcunningham: Some GitHub issues may be harder/longer than others
00:22:51 [tidoust]
... The HDR one is tricky for instance. Substantial addition to the spec.
00:23:22 [tidoust]
... I don't feel strongly that we have to formalize the process.
00:23:28 [richw]
richw has joined #mediawg
00:23:59 [tidoust]
scottlow: For new people coming to the group, it may be difficult to understand what's going on.
00:24:09 [stepsteg]
stepsteg has joined #mediawg
00:24:20 [stepsteg]
present+
00:24:23 [tidoust]
markw: Good wake up call to have in the issue is to say "I think this is good now"
00:24:45 [tidoust]
mounir: Good to point people at pull request.
00:25:16 [tidoust]
markw: There may be different alternatives without PR and you want to understant what the consensus is. Proposed resolution seems good.
00:25:21 [tidoust]
jer: True.
00:25:34 [tidoust]
... I don't know if we can resolve that now.
00:25:36 [yuki_]
yuki_ has joined #mediawg
00:26:00 [tidoust]
ACTION: jer and mounir to create an issue on the media-wg repo about the resolution process
00:26:45 [tidoust]
PROPOSED RESOLUTION: The Media WG will have monthly calls, and encourage ad-hoc meetings on specific issues
00:26:59 [takumif]
takumif has joined #mediawg
00:27:00 [tidoust]
RESOLUTION: The Media WG will have monthly calls, and encourage ad-hoc meetings on specific issues
00:29:26 [tidoust]
[Side discussion on versioning for MSE and EME and repos]
00:30:21 [mounir]
https://www.w3.org/2019/05/media-wg-charter.html
00:30:28 [tidoust]
jer: Deliverables. I am not an expert on W3C process. We have a number of specs listed in the charter
00:31:29 [tidoust]
... [reviewing the charter]
00:32:21 [tidoust]
... Deliverables include Media Capabilities, Picture-in-Picutre, Media Session, Media Playback Quality, Autoplay policy detection, MSE, EME, all of them coming from the WICG.
00:32:49 [tidoust]
... In the future, we may adopt additional normative deliverables, after incubation in another group.
00:33:17 [tidoust]
cpn: One idea we're floating around is to create a Media Community Group that could act as a companion to this group for incubation.
00:33:55 [tidoust]
... The thing we were talking about yesterday is whether we could reorganize the IG into a more CG structure and use that as a place to incubate.
00:34:24 [tidoust]
jer: So that could be a potential home for some of the incubations listed in the charter as potential normative deliverable.
00:34:39 [tidoust]
... Did we fail to include some deliverable?
00:35:14 [tidoust]
mounir: One additional comment. For MSE, we may extend with additional features. For EME, only 4 additional features listed in the charter, we cannot do more.
00:35:21 [tidoust]
jer: Can we do maintenance?
00:35:23 [tidoust]
mounir: Yes.
00:35:28 [hober]
hober has joined #mediawg
00:35:51 [tidoust]
chcunningham: I've been pushing a new attribute on the video element. More on HTML.
00:36:01 [tidoust]
padenot: just cc everybody.
00:36:37 [tidoust]
jer: Yes, we have a generic issue that by definition, some of our specs need to monkey patch HTML, We'll need to have joint session with HTML in te future.
00:37:04 [tidoust]
markw: Do we have editors assigned for these deliverables?
00:37:25 [tidoust]
mounir: Media Capabilities, chcunningham and I are editors.
00:37:39 [tidoust]
... Picture-in-Picture, François Beaufort and I are editors
00:37:51 [tidoust]
s/te future/the future/
00:38:17 [tidoust]
... Media Session has Becca Hughes and I as editors
00:38:59 [tidoust]
... Media Playback Quality, technically I'm the editor, but I just copied the text out of MSE.
00:39:18 [tidoust]
... Autoplay policy has no one, the plan was to have Paul and Becca.
00:39:43 [tidoust]
... MSE has Matt Wolenetz and folks from Microsoft are no longer there I think.
00:40:16 [tidoust]
... EME has David Dorwin and Mark Watson. David won't continue, but Joey Parrish will take over.
00:40:47 [tidoust]
... Now, let's revisit the list and see what changes we should be making
00:41:02 [heejin]
heejin has joined #mediawg
00:41:09 [tidoust]
jer: Given your chairing responsibilities, should we replace you as editor with other?
00:41:47 [tidoust]
mounir: Practically speaking, I will only do spec reviews. If people are concerned with my having two hats, no problem dropping from editing, but good to have 2 editors to ensure some peer review mechanism.
00:42:09 [tidoust]
... I am editing 0 spec by myself.
00:42:24 [tidoust]
markw: We need to make sure that the other editor doesn't have the same expectation.
00:42:48 [tidoust]
mounir: Sure. For Media Capabilities, chcunningham volunteers. Scott, do you want to have someone?
00:43:00 [tidoust]
scottlow: Yes. We're interested. Greg would be the one.
00:43:30 [tidoust]
PROPOSED RESOLUTION: Add Greg Whitworth as editor of Media Capabilities
00:44:06 [tidoust]
RESOLUTION: Add Greg Whitworth as editor of Media Capabilities
00:44:21 [tidoust]
mounir: For Picture-in-Picture, anyone interested to join?
00:44:34 [tidoust]
jer: Apple is interested in implementing, but cannot take the task.
00:44:38 [tidoust]
mounir: Then no change.
00:45:04 [tidoust]
... Media Session, I heard that Mozilla is shipping it, any interest to edit?
00:45:15 [tidoust]
padenot: I need to check. I can't commit right now.
00:45:36 [tidoust]
ACTION: padenot to check whether someone from Mozilla can become editor of Media Session.
00:46:15 [tidoust]
mounir: For Media Playback Quality, I think chcunningham might be willing to edit.
00:46:38 [tidoust]
chcunningham: Yes, I started to look into it.
00:47:00 [tidoust]
mounir: One issue is that the HTML editors said that they would like to move the spec to HTML.
00:47:08 [tidoust]
... Anyone else on top of chcunningham?
00:47:38 [tidoust]
jer: This is a small spec, it may be sufficient to have only one editor. And the editing role might be a pull request against HTML.
00:47:59 [tidoust]
ACTION: mounir to swap his name with chcunningham as editor of Media Playback Quality
00:48:21 [tidoust]
mounir: I think merging with HTML depends on the content of the spec.
00:48:28 [tidoust]
jer: That can be a discussion in the spec.
00:48:42 [tidoust]
... Autoplay policy, are we happy with Becca and Paul?
00:48:54 [tidoust]
[group nods]
00:49:14 [tidoust]
mounir: For MSE, Matt is happy to continue.
00:49:31 [tidoust]
scottlow: I may be able to have someone on our side, I need to check.
00:49:48 [tidoust]
GregFreedman: I'm expecting to edit either MSE or EME
00:50:02 [tidoust]
mounir: So we'll have someone from Netflix, and maybe someone from Microsoft?
00:50:05 [tidoust]
markw: Correct.
00:50:18 [tidoust]
mounir: And for EME, same thing for Netflix?
00:50:22 [tidoust]
markw: Yes.
00:50:41 [tidoust]
mounir: My undersanding is that Joey might be taking over David.
00:50:53 [tidoust]
scottlow: Same action for me to look into possible candidates.
00:51:02 [bdekoz_]
bdekoz_ has joined #mediawg
00:51:46 [tidoust]
ACTION: markw and GregFreedman to figure out who edits which spec (MSE/EME) among themselves
00:52:03 [tidoust]
ACTION: scottlow to check for possible editors for MSE and EME
00:52:49 [tidoust]
[going back to agenda bashing]
00:53:03 [tidoust]
jer: Anything more for agenda bashing?
00:53:39 [cpn]
scribenick: cpn
00:53:54 [mounir]
q?
00:53:55 [cpn]
francois: We should figure out which of these specs is ready to go to FPWD
00:54:37 [cpn]
... important from a patent policy perspective
00:55:21 [cpn]
... the call for exclusions covers anything that's in the spec
00:55:42 [cpn]
mounir: i think media capabilities is ready
00:56:04 [cpn]
... also picture in picture and media session
00:57:12 [cpn]
francois: the next point that triggers IPR commitment is CR
00:57:53 [tidoust]
scribe: tidoust
00:58:23 [tidoust]
[side discussion on whether Media Capabilities is ready to go to FPWD, or whether HDR support needs to be baked in first]
00:59:41 [kumekawa_]
kumekawa_ has joined #mediawg
01:01:09 [tidoust]
ACTION: jer and mounir to send CfC for publication as FPWD of Media Capabilities, PiP and Media Session the week after TPAC
01:06:12 [Joey_Parrish]
Joey_Parrish has joined #mediawg
01:14:09 [Joey_Parrish]
Joey_Parrish has joined #mediawg
01:26:57 [yuki]
yuki has joined #mediawg
01:29:51 [tidoust]
tidoust has joined #mediawg
01:30:28 [soju]
soju has joined #mediawg
01:30:43 [takio]
takio has joined #mediawg
01:31:43 [jernoble]
jernoble has joined #mediawg
01:32:07 [Joey_Parrish]
Joey_Parrish has joined #mediawg
01:32:11 [Joey_Parrish]
Howdy
01:32:15 [tidoust]
RRSAgent, draft minutes
01:32:15 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-mediawg-minutes.html tidoust
01:32:56 [mdrimages]
mdrimages has joined #mediawg
01:34:05 [tidoust]
Topic: Encrypted Media Extensions (EME)
01:34:24 [tidoust]
mounir: Before we start, in the agenda you had vNext and issues.
01:34:39 [tidoust]
jer: Yes, it's about understanding what we want to see in the next version of the spec
01:34:55 [tidoust]
mounir: OK, that's mostly for MSE, then, because we're constrained on EME.
01:34:58 [tidoust]
jer: Yes.
01:35:50 [markw]
markw has joined #mediawg
01:36:04 [Riju]
Riju has joined #Mediawg
01:36:35 [ving]
ving has joined #mediawg
01:38:52 [tidoust]
Present+ Joey_Parrish
01:39:20 [scottlow]
scottlow has joined #mediawg
01:39:22 [tidoust]
jer: We can talk about Persitent Usage Record sessions, HDCP detection, scheme capability detection, and existing session finding.
01:39:30 [tidoust]
markw: And maintenance issue
01:39:54 [JohnRiv]
JohnRiv has joined #mediawg
01:40:12 [tidoust]
Joey_Parrish: [present context for session finding]
01:40:26 [tidoust]
... Discussion at FOMS was to separate the two issues
01:40:44 [jernoble]
jernoble has joined #mediawg
01:40:55 [tidoust]
mounir: Joey, can you confirm that you want to take editor's rolve over David?
01:41:00 [tidoust]
Joey_Parrish: That's correct.
01:41:15 [mounir]
q?
01:41:23 [Zakim]
Zakim has joined #mediawg
01:41:29 [mounir]
q?
01:41:45 [tidoust]
Joey_Parrish: One other thing I'd like is to get rid of robustness strings.
01:42:21 [tidoust]
... Matches what Microsoft has done with com.microsoft.hardware / com.microsoft.software
01:42:27 [tidoust]
... There seems to be a better way to do that.
01:42:37 [tidoust]
jer: I think that would be considered under maintenance issues.
01:43:07 [tidoust]
... Joey, can you file an issue on that?
01:43:23 [tidoust]
mounir: Just to be explicit, we should be using the W3C repo for that. The WICG one should move away.
01:43:55 [tidoust]
jer: The ability to push new keys on an existing session through some mechanism is captured in an issue, I think. The issue got punted for next release. Part of maintenance as well.
01:44:03 [mounir]
q+
01:44:05 [mounir]
q-
01:44:18 [tidoust]
Topic: Persistent Usage Record
01:44:26 [tidoust]
jer: It was in the spec and got removed.
01:44:56 [tidoust]
... That's a way to have a record of playback to be stored and replayed cryptographically so that the application can verify that the key is no longer in use.
01:45:18 [tidoust]
markw: The language has been sitting in the WICG repo. The charter says it's our starting point, so we should upstream that.
01:45:32 [tidoust]
mounir: Mark, are you driving this?
01:45:42 [tidoust]
... Any concern with moving that to the main spec?
01:45:59 [tidoust]
jya: I would prefer not to implement it
01:46:07 [tidoust]
markw: I don't think that's mandatory.
01:46:47 [tidoust]
mounir: We are talking about persistent usage record
01:47:29 [tidoust]
markw: It's an after-the-fact mechanism for fraud detection.
01:47:46 [tidoust]
richard: there shouldn't be objections, that's in the charter.
01:48:01 [tidoust]
mounir: OK, seems Mark or Greg should prepare a PR.
01:48:32 [tidoust]
markw: Yes, we were actually blocked on ReSpec issues. Now fixed. MSE and EME were built with old versions of ReSpec.
01:48:57 [tidoust]
... There may be work that we can do to switch to the latest version.
01:49:13 [tidoust]
Joey_Parrish: Does this mean we're sticking to ReSpec and not Bikeshed?
01:49:42 [tidoust]
markw: For the spec that already exist, I would stick to the same system.
01:49:56 [tidoust]
... I won't do the transition at least.
01:50:09 [tidoust]
jer: Joey, you can use Bikeshed for new specs, no problem with that.
01:51:07 [tidoust]
mounir: HDCP detection and encryption scheme capability detection are WICG repos.
01:52:14 [tidoust]
... HDCP detection can fill a lot of time, given TAG feedback, etc. so would move it to the end.
01:52:21 [tidoust]
Topic: Encryption scheme capability detection
01:53:00 [tidoust]
jer: Apple Fairplay team would only support CBCS scheme and others CENC. In the meantime, the schemes have been added to the same common file format
01:53:24 [tidoust]
markw: The problem still exists.
01:53:49 [tidoust]
jer: AV1 is on CBCS exclusively?
01:54:50 [niwamoto]
niwamoto has joined #mediawg
01:54:57 [tidoust]
markw: As far as AV1 is concerned, it's an ongoing goal that all encryption patterns get supported.
01:55:09 [niwamoto]
niwamoto has joined #mediawg
01:55:12 [tidoust]
... It's understood, I think, that devices that support AV1 need to support all of them.
01:55:56 [tidoust]
... The portion you apply the pattern to has to be a multiple of 16 bytes chunks.
01:56:08 [tidoust]
... [details potential issue with that]
01:56:36 [tidoust]
... Whether we allow both approaches or require one or the other is an open discussion.
01:56:46 [tidoust]
jer: Do you think that it has implications for the spec?
01:56:49 [tidoust]
markw: I hope not
01:57:20 [tidoust]
jer: Apple is interested in clarifying behavior. Any objection to adding to the EME spec?
01:57:43 [cyril]
cyril has joined #mediawg
01:57:45 [tidoust]
Joey_Parrish: Chrome supports both CBCS and CENC. Just no way for an application to query that yet.
01:58:26 [mounir]
https://wicg.github.io/encrypted-media-encryption-scheme/
01:58:31 [stepsteg]
stepsteg has joined #mediawg
01:58:33 [tidoust]
... Prepared an explainer.
01:58:54 [tidoust]
... It just adds one encryption scheme. Minor change.
01:59:06 [tidoust]
... Not entirely settled how default would work.
02:00:07 [tidoust]
yongjun: CENC version 1 and version 3 have different requirements. In the deployment of Prime videos, we noticed problems.
02:00:15 [markw]
s/an ongoing goal/a requirement/
02:00:42 [tidoust]
... Version 1 requires 4 bytes, version 3 requires 5 bytes. It's not compatible.
02:00:58 [tidoust]
... Basically, we have two specs under ISO 23001-7:2016.
02:01:13 [tidoust]
... It's nearly impossible to backfill everything in the same implementation.
02:01:21 [tidoust]
... It's always a mix.
02:01:36 [tidoust]
jer: Just wondering whether we can mandate a specific version of CENC with the string.
02:01:37 [markw]
s/[details potential issue with that]/This is a lower level detail than the pattern, but there is a question about whether the 16x bytes to which the pattern is applied is aligned with the start or the end of the OBU.
02:01:58 [tidoust]
chcunningham: Can we mandate both?
02:02:04 [tidoust]
jer: We could, but won't help Amazon.
02:02:32 [tidoust]
yongjun: The recommendation is to support everything.
02:02:45 [igarashi]
igarashi has joined #mediawg
02:03:20 [tidoust]
Joey_Parrish: We will be developing a polyfill that allows to query the version supported.
02:03:33 [tidoust]
jer: Is the idea that you will try and fail to detect the version?
02:04:08 [tidoust]
Joey_Parrish: No, apps hardcode what devices support, the polyfill would abstract that in a library
02:05:30 [tidoust]
yongjun: It's a mistake in the CENC specification not to have been backward compatible.
02:06:41 [niwamoto]
niwamoto has joined #mediawg
02:06:44 [tidoust]
Joey_Parrish: Rather than making a more specific query to seek the version of CENC, be more specific in the section that details CENC that all sections of CENC must be supported.
02:07:05 [tidoust]
s/Joey_Parrish/jer/
02:07:40 [mounir]
q?
02:07:53 [tidoust]
yongjun: We don't have enough time to backfill everything. There's always a mixed catalog on the backend.
02:08:40 [tidoust]
GregFreedman: It seems like if 90% of your catalog is CENC 3, it seems strange to be willing to support CENC 1
02:09:26 [tidoust]
chcunningham: Was there a line somewhere that version 3 was a good thing to use when it got introduced, because it would be supported by EME?
02:09:34 [tidoust]
yongjun: We always move to the latest version.
02:09:59 [tidoust]
... When we onboard new devices, we make sure that they support all versions.
02:10:24 [tidoust]
markw: The capability problem is only in one direction there.
02:10:34 [tidoust]
... The newer spec has more bytes in the clear.
02:11:10 [tidoust]
... The older devices should not have an opinion provided that at least the first 4 bytes are encrypted.
02:11:31 [tidoust]
... The problem is that there are newer devices that require fewer bytes in the clear.
02:11:44 [tidoust]
... In practice, that only applies to H.265 streams and not H.264
02:12:01 [tidoust]
yongjun: Microsoft Edge is like this, I think.
02:12:07 [tidoust]
mounir: I think we are digressing here.
02:12:29 [tidoust]
... Maybe you should file an issue about this. Can you do it?
02:12:35 [tidoust]
yongjun: Sure.
02:12:37 [soju]
soju has joined #mediawg
02:12:56 [markw]
s/fewer bytes in the clear/more bytes in the clear/
02:12:57 [tidoust]
... This is super important for Microsoft Edge.
02:13:31 [tidoust]
mounir: Is there something in the change that people have concerns about?
02:14:24 [tidoust]
Joey_Parrish: For backward compatibility, if the encrypted schemes is not provided by the application, the behavior is mostly unspecified. No restriction. The way we would be able to detect support for the field itself, when the application calls getConfiguration, that should be in the configuration returned for media keys.
02:14:55 [tidoust]
... The idea is that a polyfill could be written to make simple calls to detect support for the field.
02:15:02 [tidoust]
mounir: Everyone happy with that?
02:15:11 [tidoust]
scottlow: Yes, as an implementer.
02:16:05 [tidoust]
PROPOSED RESOLUTION: Joey_Parrish to prepare a PR to integrate encryption scheme proposal in EME (W3C repo)
02:16:29 [tidoust]
RESOLUTION: Joey_Parrish to prepare a PR to integrate encryption scheme proposal in EME (W3C repo)
02:16:58 [tidoust]
Topic: API to find existing sessions
02:17:18 [tidoust]
mounir: My understanding from discussion at FOMS is that we need to get back to the drawing board. Not done yet?
02:17:42 [tidoust]
Joey_Parrish: Right. The feedback I get from Jer is that the design was a bit overloaded as I wanted to cover two cases.
02:18:03 [tidoust]
... Example in Widevine, matching base on the content ID.
02:18:16 [tidoust]
GregFreedman: I assume this is active session.
02:18:36 [tidoust]
Joey_Parrish: Correct, active not expired session. In the case of key rotation, expired sessions would not show up.
02:19:18 [tidoust]
... Main purpose of that is that, as application developer, I don't have a deep understanding of sessions, which may lead to duplicate sessions, which can be an issue with CDN sessions.
02:19:30 [tidoust]
jer: Seems reasonable as a future direction.
02:19:38 [markw]
s/least the first 4 bytes are encrypted/least the first 4 bytes are unencrypted/
02:20:53 [tidoust]
Joey_Parrish: Key IDs are not commonly available on all devices.
02:21:00 [tidoust]
GregFreedman: Right. No objection.
02:21:27 [tidoust]
Joey_Parrish: Would an API that would give you back key ids instead of sessions be preferrable? I'm open to that.
02:21:50 [tidoust]
GregFreedman: I don't feel strongly. It may be preferrable for inspection purpose.
02:22:56 [tidoust]
Joey_Parrish: From initialization data to key IDs instead of from initialization data to sessions. I think I went for the latter because I wanted to cover key rotation, but agree based on feedback that it should be kept separate.
02:24:21 [tidoust]
... The only reason to have a session object is [missed]. Other than that, it's not useful.
02:25:15 [tidoust]
richard: There's a limited number of sessions that you can have from an hardware perspective. Is there a way to tell the difference between expired sessions and sessions that exceed the number of available sessions?
02:25:35 [tidoust]
jer: It seems to me that there is a better way [missed]
02:26:34 [tidoust]
GregFreedman: From a diagnostic standpoint, key id would be more useful. I might know that the session is active, but I do like the idea of having the key ID. Whether or not you have an API to check active sessions is less important from my perspective but it's ok.
02:27:13 [cyril]
rrsagent, draft minutes
02:27:13 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-mediawg-minutes.html cyril
02:27:27 [tidoust]
PROPOSED RESOLUTION: Expose an API to expose key ID information from initialization data in order to find existing session
02:28:27 [tidoust]
Joey_Parrish: You could use the API to do the mapping. I don't have a WICG repo for this yet, only a personal repo.
02:28:41 [tidoust]
tidoust: You don't need to have a WICG repo.
02:29:03 [tidoust]
jer: It can be a PR against the W3C repo
02:29:35 [tidoust]
yongjun: Format of key ID is different. CDM specific.
02:29:51 [tidoust]
jer: Yes, ArrayBuffer in the spec.
02:30:19 [tidoust]
markw: The Key ID is a container. 16 byte string
02:30:50 [tidoust]
[discussion on key ID format]
02:31:04 [tidoust]
yongjun: We should not infuse an additional format here, that's my point.
02:31:19 [tidoust]
PROPOSED RESOLUTION: Expose an API to expose key ID information from initialization data in order to find existing session
02:31:29 [tidoust]
RESOLUTION: Expose an API to expose key ID information from initialization data in order to find existing sessions
02:31:41 [tidoust]
Topic: HDCP detection
02:31:42 [chcunningham]
chcunningham has joined #mediawg
02:31:45 [markw]
s/The Key ID is a container/The Key ID format is defined by the container specification (e.g. CENC)/
02:32:01 [mounir]
https://wicg.github.io/hdcp-detection/
02:32:29 [tidoust]
jer: Content may not be licensed for playback given HDCP support or not.
02:32:57 [tidoust]
... The proposal is to have an API to allow early detection of which HDCP levels are supported.
02:33:06 [tidoust]
mounir: Joey_Parrish wrote a spec for that.
02:33:55 [GregFreedman]
GregFreedman has joined #mediawg
02:34:01 [tidoust]
Joey_Parrish: It's a mapping on MediaKeys that returns the version of HDCP. Privacy review suggests concern for fingerprinting. Mitigation is that it is user activated as part of MediaKeys.
02:34:55 [tidoust]
jer: 9 different versions of HDCP that can be supported. Value depends on the connected display, so danger of exposing more unique info per user.
02:35:28 [tidoust]
... It's already possible to gather that information through trial and error.
02:35:42 [km]
km has joined #mediawg
02:35:59 [tidoust]
... And small number of Web sites that can use this since keys need to be got first.
02:36:10 [mounir]
https://github.com/w3ctag/design-reviews/issues/323 <= TAG feedback
02:36:34 [tidoust]
markw: Granularity requirement is basically HD, 4D, perhaps to be refined to add a third one.
02:36:42 [tidoust]
s/4D/4K
02:37:25 [tidoust]
... Slower time to start playback if you don't have such an early capability detection.
02:38:09 [tidoust]
... User consent is for EME at all.
02:38:45 [tidoust]
yongjun: Dynamic detection is needed when user plugs another display.
02:39:18 [tidoust]
jer: Two things can happen: unplug a device that supported HDCP requirement, plug a new one that supports HDCP requirement.
02:39:50 [tidoust]
... One solution would be to poll this API to detect changes.
02:40:12 [tidoust]
mounir: Media capabilities has this idea of adding a change event on the window object, and you could perhaps use this.
02:40:26 [tidoust]
... I believe Mozilla implemented, do you have any feedback?
02:40:30 [tidoust]
jya: I don't know.
02:42:00 [tidoust]
chcunningham: CDM that enforces HDCP during the playback. Multiple screens, Widevine policy is I believe to report the lowest protection value when you have a highly-protected display and a low-protected display.
02:42:20 [tidoust]
jer: Thing happens, because we receive user reports.
02:42:34 [tidoust]
... We take the same approach.
02:42:57 [tidoust]
... The user doesn't understand that a display that used to work no longer work after plugging another one.
02:43:45 [tidoust]
markw: The general problem of reacting to user changes is not one that we see as a priority. We don't object to it, but it's not straightforward to make it a good user experience.
02:44:44 [tidoust]
jer: One thing that someone like Brave or privacy-mode might do is to try to return a single value for HDCP support.
02:45:13 [tidoust]
... I would hate to get in a situation where you couldn't implement a privacy mitigation without breaking existing sites.
02:45:28 [tidoust]
mounir: Mark, you said we could get down to 2-3 values.
02:45:32 [tidoust]
... Is that possible?
02:46:18 [tidoust]
Joey_Parrish: Probably, except it probably depends on the specific contract requirements. Studios may update from 2.2 to 2.3, and this value would need to reflect that.
02:47:02 [tidoust]
... If a browser is faking this value for the benefit of privacy. It's effectively equivalent with fetching the value in advance and the user plugging in a display in between.
02:47:17 [tidoust]
... Any application that cannot handle that is going to break in corner cases in any case.
02:47:28 [tidoust]
markw: Right, I wouldn't say it's equivalent.
02:47:50 [tidoust]
... Difference between a corner case and a case that always happen.
02:48:31 [tidoust]
jer: The fingerprinting of media capabilities is significantly less for Apple because we run in a short number of hardware. But that's not the case for others.
02:48:54 [tidoust]
... The HDCP policy is different because it can change dynamically and dramatically at any time.
02:49:10 [tidoust]
Joey_Parrish: We could add an "unknown" value that would allow not to lie.
02:49:33 [tidoust]
jer: Returning "unknown" is already a signal compared to lying.
02:50:19 [tidoust]
Joey_Parrish: Having implemented something similar in ShakaPlayer, you must start with SD and ramp up with keys you're going to receive.
02:50:48 [tidoust]
... With lying, tt wouldn't mean that you'd be stuck forever, we'd just do what we're already doing
02:50:56 [tidoust]
s/tt wouldn't/it wouldn't
02:52:44 [tidoust]
mounir: I assume EME is HTTPS only, only available on top. No reason for cross-origin iframes should use EME. EME is async API by default, so you can have a prompt. This call itself is aync, so you could have a prompt. Technically, everyone can get this information with Widevine, it's just a bit more work.
02:52:52 [tidoust]
jer: Not the case for everyone, though
02:53:10 [tidoust]
mounir: Right, but fingerprinting is not high risk.
02:54:06 [tidoust]
... I would add in the spec a note to explain what implementations could do if they don't want to increase the fingerprinting surface.
02:54:27 [tidoust]
... And we'd just get back to what we're doing that.
02:55:03 [tidoust]
markw: Inform sites that rejecting this API is something that can always happen.
02:56:12 [tidoust]
jer: Having the ability to reject this promise is good. Links to Privacy Budget discussion as well. The call may succeed at one time and fail at other times.
02:56:22 [tidoust]
... Language like that would be appropriate.
02:56:44 [tidoust]
Joey_Parrish: Adding some language for fingerprinting mitigation is ok.
02:57:21 [tidoust]
GregFreedman: Some HDCP versions are unsecure. 2.0 2.1, anything below 1.4, we'll never query for.
02:57:47 [tidoust]
chcunningham: The privacy gains by doing the collapses is minimal.
02:58:37 [tidoust]
markw: You could bucket those, no problem on our side.
02:58:54 [tidoust]
jer: Any normative reference that we could have not to have to update the list?
02:59:04 [tidoust]
mounir: We'd need a registry.
03:00:49 [tidoust]
[discussion on registries at W3C, possible process updates, etc.]
03:01:32 [tidoust]
ACTION: Joey_Parrish to add language to the privacy path
03:02:30 [MasayaIk_]
MasayaIk_ has joined #mediawg
03:03:22 [cyril]
rrsagent, draft minutes
03:03:22 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-mediawg-minutes.html cyril
03:03:31 [tidoust]
GregFreedman: On Windows, I was told that the media foundation does not recognize 1.4 and reports 1.0
03:03:32 [tidoust]
ACTION: Joey_Parrish to look into reducing the number of HDCP versions we expose to collapse to those actually used
03:03:57 [tidoust]
Joey_Parrish: Fine with the action but I will need some guidance on what values are actually necessary
03:04:17 [tidoust]
mounir: About the TAG issue, should we come back with a resolution?
03:04:43 [tidoust]
jer: If we enact the actions, then I think we can get back to the TAG for a resolution on these issues.
03:04:47 [tidoust]
mounir: Right.
03:05:59 [tidoust]
[short discussion on maintenance issues]
03:06:42 [tidoust]
Joey_Parrish: The two things mentioned earlier are key rotate and my suggest to kill robustness.
03:07:12 [tidoust]
markw: There are a bunch of issues on the repo. Some of which may need to be dropped, or acted upon.
03:07:26 [tidoust]
jer: Seems a good thing to do in a call.
03:07:52 [tidoust]
... About key rotation, internal clients of EME at Apple had issues with adding new keys.
03:08:07 [tidoust]
... Why generateKeyRequest cannot be used multiple times?
03:08:19 [tidoust]
... There seems to be hardware limitations.
03:08:44 [tidoust]
... We closed that early in the first version for lack of time.
03:08:59 [tidoust]
... I'll just re-raise the issue on GitHub, and we'll cover that later on.
03:09:18 [tidoust]
... About removing robustness, any significant pushback?
03:09:27 [tidoust]
[none heard]
03:09:32 [ving]
ving has joined #mediawg
03:10:22 [tidoust]
Joey_Parrish: Issues could reasonably be addressed by introducing things such as .hardware or .software and other properties.
03:10:42 [tidoust]
GregFreedman: I know we use robustness in practice, so need time to transition.
03:11:05 [tidoust]
Joey_Parrish: Yes, long time starting with intent to deprecate.
03:11:50 [tidoust]
mounir: Did you file an issue about that?
03:11:56 [tidoust]
Joey_Parrish: Not yet, will do that.
03:12:23 [tidoust]
mounir: We want to make sure that we can notify everyone else.
03:12:41 [tidoust]
Topic: Low-latency <video> signaling
03:13:01 [chcunningham]
latency proposal https://discourse.wicg.io/t/proposal-hint-attribute-on-htmlmediaelement-to-configure-rendering-latency/3567/7
03:13:17 [tidoust]
jer: Proposal from chcunningham to allow client to signal to a user agent that they would prefer a different style of rendering, e.g. to signal not to use a jitter buffer.
03:13:29 [tidoust]
... Game streaming mentioned as a use case.
03:13:51 [tidoust]
... Currently, Chrome has a heuristic and would like to make it explicit
03:14:02 [tidoust]
chcunningham: Correct, and the heuristic is often wrong
03:14:39 [tidoust]
jer: The right place for incubation is a CG, but there is overlap of interest with Media WG participants.
03:15:00 [tidoust]
chcunningham: [going through the discourse post]
03:15:08 [richw]
richw has joined #mediawg
03:15:25 [tidoust]
alex: Are we talking about the rendering buffer or the jitter buffer?
03:15:34 [tidoust]
chcunningham: The rendering buffer.
03:15:56 [tidoust]
... Proposal is to add an attribute that would cut it down to 1 frame.
03:16:13 [tidoust]
alex: Is there a separate proposal for the jitter buffer?
03:16:26 [tidoust]
jer: I used the wrong term, I don't know anything about jitter buffer.
03:16:46 [tidoust]
alex: Jitter buffer is used in WebRTC.
03:17:10 [markw]
markw has joined #mediawg
03:17:48 [tidoust]
chcunningham: Through discussion with Jer, he thought the API was too low-level. Taking leverage of mediatrack hints, proposal is now to rather take a declarative approach.
03:18:11 [tidoust]
... I did also talk to Harald briefly yesterday, he didn't think this was a crazy idea.
03:18:40 [tidoust]
... He thought we might even use their enums and was open to adjust it, e.g. to support real-time use cases.
03:19:29 [tidoust]
jer: Also, I don't want to impose requirements for this, because I may not be able to implement a 1 frame buffer. Hence the hint approach.
03:20:12 [tidoust]
jya: Moving back to MSE, there would be significant change of behavior, no stop and gap, etc.
03:20:32 [tidoust]
... Would that apply to MSE? It's only when you attach MSE to a video element that you'd have access to it.
03:20:59 [tidoust]
... We would have a different thing in MSE?
03:21:05 [tidoust]
chcunningham: Yes.
03:21:29 [tidoust]
jer: You can imagine having gaps keeping and low-latency rendering
03:22:20 [tidoust]
jya: Could we assume than rather that being associated to the media element, it should be associated with the source?
03:22:56 [tidoust]
... Just trying to have something that could have a smooth continuation on MSE, rather than having a second proposal on MSE.
03:23:35 [tidoust]
jer: Right now, it's written as an IDL change. For attributes, you'd have to add the attribute to each source.
03:23:43 [tidoust]
jya: Yes, even more flexibility!
03:25:07 [tidoust]
mounir: Everyone talking about hints as if it was a done deal. I'm not a huge fan of it. Much harder for people to understand what will happen. Developers will reverse-engineer to understand what's going on behind the scenes.
03:25:43 [tidoust]
... What people care about is the behavior, which user agents can change with an hint approach.
03:26:24 [tidoust]
jer: And I disagree because I don't want to be required to implement a specific behavior.
03:26:45 [tidoust]
mounir: The benefit of this is that we can use this for a lot of stuff, e.g. Audio focus.
03:27:10 [tidoust]
... However, we will end up with a hint that will only be used for buffering.
03:27:21 [tidoust]
... So we'd be stuck with an expected behavior.
03:27:41 [tidoust]
markw: You want things to be well-defined IIUC.
03:27:47 [tidoust]
mounir: Yes.
03:28:02 [tidoust]
chcunningham: Even in Chrome, we make no guarantee.
03:28:34 [tidoust]
markw: There may be use cases where you want to specify 2 content hints.
03:29:02 [tidoust]
alex: Any other optimizations for these hints?
03:29:07 [tidoust]
chcunningham: Only buffering planned.
03:29:25 [tidoust]
jer: I can imagine that being used for other things.
03:30:03 [tidoust]
alex: If you specify by optimization, risk of ending with 12 different parameters.
03:30:13 [tidoust]
mounir: I believe that's OK.
03:30:34 [tidoust]
... If we start changing behavior, people will have expectations.
03:30:59 [tidoust]
jer: Most of media playback is open-ended. It's a kind of a pain but allows for flexibility.
03:31:29 [tidoust]
jya: But then you end up having customers that expect a certain behavior when you have a strong player.
03:32:50 [tidoust]
[revisiting the agenda to find a slot to continue the discussion]
03:32:56 [tidoust]
RRSAgent, draft minutes
03:32:56 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-mediawg-minutes.html tidoust
03:44:39 [horiuchi_]
horiuchi_ has joined #mediawg
04:02:44 [jernoble]
jernoble has joined #mediawg
04:26:56 [scottlow]
scottlow has joined #mediawg
04:29:45 [MasayaIkeo]
MasayaIkeo has joined #mediawg
04:32:13 [tidoust]
tidoust has joined #mediawg
04:32:40 [takio]
takio has joined #mediawg
04:32:50 [horiuchi]
horiuchi has joined #mediawg
04:33:03 [Zakim]
Zakim has left #mediawg
04:34:31 [Youngsun]
Youngsun has joined #mediawg
04:34:32 [cpn]
scribenick: cpn
04:34:43 [cpn]
Topic: Media Capabilities
04:34:47 [mounir]
q?
04:34:51 [Zakim]
Zakim has joined #mediawg
04:35:05 [mounir]
q?
04:35:14 [cpn]
Jer: This is pretty far along, there are some issues needing discussion
04:35:24 [ericc]
ericc has joined #mediawg
04:35:32 [cpn]
... The biggest ones are: queries for HDR support and spatial audio support
04:36:16 [GregFreedman]
GregFreedman has joined #mediawg
04:36:18 [markw]
markw has joined #mediawg
04:36:18 [ving]
Hi everyone. Has the WebEx call starteed?
04:36:25 [mounir]
we are working on it
04:36:40 [jernoble]
https://github.com/w3c/media-capabilities/issues/119
04:36:45 [jernoble]
https://github.com/w3c/media-capabilities/issues/118
04:37:16 [sushrajaMSFT]
sushrajaMSFT has joined #mediaWG
04:37:16 [ving]
Thanks!
04:37:17 [horiuchi]
horiuchi has joined #mediawg
04:37:24 [Jared]
Jared has joined #mediawg
04:37:25 [sam]
sam has joined #mediawg
04:37:38 [chcunningham]
chcunningham has joined #mediawg
04:38:03 [johnroque]
johnroque has joined #mediawg
04:38:09 [cpn]
Jer: These issue both allow applications to determine the ability to decode and display HDR content
04:38:14 [cpn]
... The API shape has changed
04:38:44 [cpn]
... Allows the UA to understand whether formats can be displayed and decoded, given color spaces, transfer fucntions, metadata values
04:39:08 [cpn]
... There's also an API we're considering adding to Screen, to determine whether it's able to handle HDR
04:39:30 [cpn]
... Is this sufficient for clients and implementers? Is the API surface acceptable to expose to the web
04:39:42 [tidoust]
RRSAgent, draft minutes
04:39:42 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-mediawg-minutes.html tidoust
04:39:46 [JohnRiv]
JohnRiv has joined #mediawg
04:39:47 [cpn]
?: Is this HDR, HDR10, HLG, etc.?
04:40:08 [cpn]
Jer: I avoided encoded specific product names into the API
04:40:11 [tidoust]
s/?:/yongjun:/
04:40:15 [cpn]
... e.g., Dolby Vision
04:40:42 [cpn]
Jer: HLG has a specific transfer function, that's being proposed to be added
04:40:54 [niwamoto]
niwamoto has joined #mediawg
04:40:57 [cpn]
... Does the agent accept a particular transfer function?
04:41:10 [cpn]
q?
04:41:28 [mattwoodrow]
mattwoodrow has joined #mediawg
04:41:54 [kajihata]
kajihata has joined #mediawg
04:42:01 [cpn]
MarkW: I think it's more the ability to decode, if a query responds positively to the query, you should know it will display correctly, although may not be the best output you could expect
04:42:36 [cpn]
... For one stream, can I play this? For CSS, selecting between multiple streams
04:43:01 [cpn]
Yongjun: It's not just HDR capability alone, also frame rate, e.g., HDR at 30 fps not 60 fps
04:43:09 [cpn]
Jer: Media Capabilities already has frame rate
04:43:23 [cpn]
Yongjun: So need to be able to signal these combinations
04:43:42 [cpn]
MarkW: The API takes a specific config, you get a yes/no answer
04:44:19 [cpn]
Jongjun: It's more like a query
04:44:58 [cpn]
... What about composition? An SDR and an HDR stream, can you show at the same, e.g, in a picture in picture window?
04:45:32 [cpn]
Jer: That's a problem in the API, regardless of HDR, e.g., can I offload from CPU to GPU?
04:45:53 [cpn]
Jongjun: How to composite SDR and HDR content?
04:46:26 [mounir]
mounir: a design principle of this API from the beginning is that we only answer the question for one video playing regardless of what's happening
04:46:33 [cyril]
cyril has joined #mediawg
04:46:40 [cpn]
MarkW: It's a very difficult problem to cover this in general. You have limited decoder resources being shared between streams
04:46:50 [tidoust]
Present+ Vi_Nguyen, Eric_Carlson
04:47:04 [cpn]
Eric: If you come up with a solution, the answer can change dynamically, there can be a race condition
04:47:24 [cpn]
MarkW: If you want to render multiple streams, you have to constrain things
04:47:37 [cpn]
Yongjun: so what's the scope of Media Capabilities?
04:49:28 [dbaron]
dbaron has joined #mediawg
04:49:57 [cpn]
Jer: VideoConfiguration has 3 additional parameters: hdrMetadataType, colorGamut, transferFunction
04:50:11 [cpn]
... should allow all HDR types currently in existence
04:50:27 [cpn]
Jongjun: Also bit depth?
04:50:58 [tidoust]
present+ Greg_Whitworth
04:51:13 [cpn]
ChrisC: When you have higher bit depth profiles of VP9, you're implicitly saying you support those bit depths, and the rendering
04:52:02 [cpn]
Jongyun: We assume HDR is 10 bit, but also works if 8 bit. It's both the decoding and rendering process, so not sure if 8 bit will be supported across devices
04:52:19 [cpn]
MarkW: The codec profiles are different between 10 bit and 8 bit
04:52:26 [yuki-uchida]
yuki-uchida has joined #mediawg
04:52:27 [atai]
atai has joined #mediawg
04:53:15 [cpn]
Yongjun: Screen and decoder on same device, but what about HDMI, you need separate queries
04:54:09 [cpn]
ChrisC: The definition of rendering is ambiguous, so we recognise applying the transfer function, not a decoding step, also not a display function. The piece between the screen and decoding we call "rendering"
04:54:48 [cpn]
MarkW: There are two kinds of hardware setups. On PCs and laptops, decode to linear half float, and then convert to anything on the way out
04:55:19 [cpn]
... If connection to an old monitor on HDMI, it'll be rendered, so the answer from the API is yes
04:55:40 [cpn]
... If that's the only copy of the content I have, I want it to display
04:56:08 [cpn]
... If we have both HDR and SDR, it will say yes to both, but we can check the HDR flag to select which to show
04:57:09 [cpn]
... This API only addresses what can and can't play. Use that to filter down
04:57:22 [cpn]
Richard: Why does the "maybe" thing happen?
04:57:31 [cpn]
Jer: This is because you could under-specify the MIME type
04:57:57 [cpn]
... We're moving away from that
04:58:22 [cpn]
MarkW: One tells you whether you could, and one is whether you should
04:58:43 [Riju]
Riju has joined #Mediawg
04:59:19 [Riju]
Riju has joined #mediawg
04:59:52 [cpn]
ChrisC: If you have multiple screens, the Screen API gives dimensions, and this changes when you drag windows between screens. Seemed a natural place to expose whether the screen supports HDR
05:00:08 [Riju_]
Riju_ has joined #mediawg
05:00:24 [cpn]
Jongjun: Downgrade from HDR to SDR, we don't use device conversion
05:01:07 [mattwoodrow]
q+
05:01:48 [cpn]
?: Is canPlayType only used to select HDR or SDR
05:01:48 [mounir]
ack mattwoodrow
05:02:01 [cpn]
s/?/Matt/
05:02:13 [cpn]
Jer: No, could also be about available bandwidth
05:02:33 [jroque]
jroque has joined #mediawg
05:02:34 [cpn]
ChrisC: The API tells you what we can do, and how well we can do it.
05:02:54 [cpn]
... So the UA allows the webapp to make the decision
05:03:22 [cpn]
Jer: The API returns if possible, smooth, and if power efficient
05:04:05 [cpn]
Mark: Other dimensions include resolution and color gamut
05:04:21 [cpn]
... This API tells you if a resolution can be rendered, could involve downscaling
05:04:33 [cpn]
... Then you can check the Screen API to select based on resolution
05:04:50 [cpn]
Jer: Could be polyfilled by an API
05:05:38 [cpn]
Mark: Also color gamut,an SDR in 709, and 2020, query the Screen. But we don't have this, as wide gamut capability generally comes along with HDR capability
05:05:52 [cpn]
... Could do it, but doesn't make sense in practice
05:06:48 [cpn]
Jer: Color gamut, should we specfy rec2020, small difference from P3, but it's there
05:07:20 [cpn]
... I believe with these parameters, can distinguigh Dolby Vision, HDR10, HDR10+, HLG (for now...)
05:07:35 [cpn]
s/distinguigh/distinguish/
05:08:03 [cpn]
Jongjun: For one title, we have HDR10, 10+, and Dolby Vision
05:08:14 [cpn]
MarkW: Similar
05:09:01 [cpn]
Jongjun: If someone only has one copy, should we use "maybe"?
05:09:35 [cpn]
ChrisC: We should add some examples
05:09:38 [markw]
s/Similar/Similar, we also have multiple variants/
05:09:50 [mounir]
q?
05:09:56 [cpn]
ACTION: ChrisC to add examples to the Media Capabilities spec
05:11:22 [cpn]
Jer: There are two PRs
05:12:00 [gregwhitworth]
Opened this issue for examples: https://github.com/w3c/media-capabilities/issues/132
05:12:30 [cpn]
... VideoDisplayConfiguration is newly added, you can pass in width, height, hasHDR, can check if this is supported by the display
05:13:07 [cpn]
... This API is more limited, to reduce fingerprinting impact. We hope it's enough for content providers to make decisions about filtering HDR and non-HDR streams
05:13:28 [gregwhitworth]
it is only MQ
05:13:31 [cpn]
... Bit depth and color depth for the display is already exposed in CSS
05:13:32 [gregwhitworth]
matchMedia will work
05:14:33 [cpn]
MarkW: Not sure bitdepth on Screen is that useful. it's difficult to pin down. Most TVs, the actual panel is still 8 bits
05:14:51 [cpn]
... Asking whether its worthwhile sending 10 bits to the display is difficult
05:15:16 [cpn]
Jer: Media Queries were used in webkit so ask if display is capable of displaying wide color gamut images
05:15:22 [mounir]
q?
05:15:34 [jya]
Screen interface: https://drafts.csswg.org/cssom-view/#the-screen-interface
05:15:40 [cpn]
ChrisC: I agree with MarkW, I wouldn't want bitdepth
05:16:08 [cpn]
Jer: Are width and height just there for embedded players with a separate video layer?
05:16:13 [cpn]
ChrisC: Yes
05:16:24 [cpn]
Greg: Don't want to stream 4K unless there are 4K device pixels
05:17:07 [cpn]
ChrisC: Cast has a proprietary API where you can get the display width and height
05:17:18 [cpn]
Mounir: We have feedback that this is generally useful
05:18:22 [soju]
soju has joined #mediawg
05:19:01 [cpn]
ChrisC: As written, it appears like implementations have to support all, but that's not the intent
05:19:28 [Youngsun_]
Youngsun_ has joined #mediawg
05:20:03 [mounir]
https://github.com/w3c/media-capabilities/issues/118#issuecomment-529878912
05:21:57 [cpn]
Mounir: So in general we're happy with the PR, but there's some wording changes needed
05:22:19 [Jared]
Jared has joined #mediawg
05:22:36 [MasayaIkeo]
MasayaIkeo has joined #mediawg
05:23:26 [cpn]
GregW: Can we clarify what's outstanding?
05:23:33 [gregwhitworth]
Proposed Resolution: Remove statements that define what the sRGB, etc and allow that to be defined by UA
05:23:50 [cpn]
ChrisC: I'd want to take one last pass through the PR, need a couple of days for that
05:24:24 [cpn]
... Consensus is what's in the PR is good, feedback on semantics of the enum values
05:24:56 [cpn]
Topic: Media Capabilities: Spatial Audio
05:25:08 [cpn]
ChrisC: We landed the PR, is there any feedback on that?
05:25:55 [cpn]
Mounir: Re decoding vs rendering, the API can say no to rendering even if decoding is possible
05:26:40 [cpn]
Jer: There's no equivalent to Screen for audio, so no other place for those queries to go
05:27:16 [wendyreid]
wendyreid has joined #mediawg
05:27:21 [wendyreid]
present+
05:27:25 [cpn]
Paul: Web Audio didn't take this into consideration. We are addressing this, taking into account modern technologies
05:27:58 [cpn]
... There's a new repo so you can add issues to request stuff
05:28:46 [cpn]
Topic: Audio Books
05:29:09 [cpn]
Wendy: I'm from a digital bookseller, and co-chair and editor from the Publication working group
05:29:19 [wendyreid]
https://www.w3.org/TR/audiobooks/
05:29:22 [cpn]
... on TAG advice, I'm here to tell you about our spec
05:29:28 [wendyreid]
https://www.w3.org/TR/pub-manifest/
05:29:42 [cpn]
Wendy: We have two specs: Publication Manifest, and Audiobook profile
05:29:58 [cpn]
... They're closely relayed. It's a general manifest format for publications on the web
05:30:06 [cpn]
... We have a profile for specific use cases
05:30:14 [cpn]
... We currently have one profile, for audiobooks
05:30:29 [cpn]
... We keep as much audio content in mind, thinking of podcasts
05:30:42 [cpn]
... Want to avoid overlap with other work, and be open about what we're doing
05:31:05 [cpn]
... Manifest format for B2B or B2C. A couple of use cases: listening to an audio book, a11y, and portability
05:31:12 [jroque]
jroque has joined #mediawg
05:31:15 [mounir]
q?
05:31:37 [cpn]
... Make it flexible for users. Using JSON-LD and schema.org for metadata. Focus is on identification and information to user or distributor
05:32:02 [cpn]
... Audiobooks is siloed by retailers, want to break this down with an open format
05:32:38 [cpn]
... Identifying metadata, reading order. There's a CG working on synchronised media
05:33:11 [horiuchi]
horiuchi has joined #mediawg
05:33:19 [cpn]
... An audio file with other media, such as text or video, as a more accessible experience: listen and read, or sign language
05:33:36 [cpn]
... Spec allows for a table of contents, for detailed navigation data for the user
05:33:50 [cpn]
... It's also for podcasts, want to cover their use cases
05:34:17 [cpn]
... I want to sure our spec works with your APIs, or can we help make your work easier?
05:34:51 [cpn]
Jer: Is this about the audiobooks profile or the publishing spec in general?
05:35:19 [cpn]
Wendy: Audiobooks in particular, this has strict rules, e.g., can contain only audio files
05:35:32 [cpn]
Jer: Overlap with ePub?
05:35:54 [cpn]
Wendy: We work closely with the ePub3 CG, can be the future of digital publishing post-ePub
05:35:57 [horiuchi_]
horiuchi_ has joined #mediawg
05:36:19 [cpn]
ChrisC: We should make sure our format strings are the same
05:36:46 [cpn]
... Is audio/vndwave vendor specific?
05:36:47 [mounir]
https://w3c.github.io/media-capabilities/#mime-type
05:37:10 [cpn]
Mounir: Now we require codecs in the mime type for everything
05:37:27 [cpn]
s/vndwave/vnd-wav/
05:37:58 [cpn]
Wendy: We decided not to restrict the allowed audio formats, wanted to be future proof
05:38:14 [cpn]
... We can reference this for the right formats
05:38:30 [cpn]
Jer: When you have a client different capabilities, how to select between different formats?
05:38:59 [cpn]
Wendy: Could have a fallback or high quality or low quality, decided not to do that, will do in a best practice doc. Approach would be to have separate manifests
05:39:00 [cpn]
q+
05:39:18 [cpn]
... We have a list of 2.0 things
05:39:50 [cpn]
ChrisC: Let's have the same language for specifying which codecs to use
05:39:54 [mattwoodrow]
mattwoodrow has joined #mediawg
05:40:11 [cpn]
Mounir: Agree, helps make using APIs together easier
05:40:41 [mfoltzgoogle]
mfoltzgoogle has joined #mediawg
05:40:46 [cpn]
Paul: The temporal fragment - look at the Media Fragments URI spec
05:40:51 [mfoltzgoogle]
q+
05:41:41 [cpn]
Francois: Do you have specific requirements for synchronisation. This is being discussed in the M&E IG
05:42:00 [cpn]
Wendy: That's in a CG, Marisa DeMeglio is an editor
05:42:04 [padenot]
temporal fragments: https://www.w3.org/TR/media-frags/#naming-time
05:42:19 [cpn]
... That spec is separate, want it to be generally usable
05:42:25 [mounir]
q?
05:42:29 [mounir]
ack cpn
05:43:00 [mounir]
cpn: we talked we Marisa about this in the past
05:43:13 [mounir]
... one of the reasons why TAG is interested is because of the general packaging effort
05:43:32 [mounir]
... there is an effort about media containers -- having a MP4 file synchronised with the presentation
05:43:35 [Riju]
Riju has joined #mediawg
05:44:04 [mounir]
... there is a draft MPEG standard nearly finalised and they are now working with W3c -- that is somewhat controversial
05:44:24 [mounir]
... Dave Singer (Apple) has been interested in having a workshop around this topic
05:44:50 [mounir]
Wendy: Dave Singer has been working with us around packaging for the publishing industry as they are not as technical
05:45:03 [mounir]
... we talked about MPEG and HEFF, he gave a presentation and it looked promising
05:45:15 [mounir]
... for this industry, it wasn't a clear cut process
05:45:33 [mounir]
... we are still working on this but this spec will unlikely have anything around it
05:45:42 [markw]
s/HEFF/HEIF/
05:45:48 [mounir]
... we believe web packaging is promising for publishing
05:45:53 [mounir]
q?
05:46:00 [mounir]
ack mfoltzgoogle
05:46:31 [mounir]
mfoltzgoogle: in general, when there is media metadata format, Media Session should be looked at
05:46:37 [mounir]
... we should look at mapping them
05:46:55 [cpn]
scribenick: cpn
05:47:16 [cpn]
Francois: This is schema.org, should we align Media Session to that?
05:47:43 [horiuchi]
horiuchi has joined #mediawg
05:47:51 [mounir]
q?
05:47:52 [cpn]
Wendy: We use the creators list, author and "read by", rather than narrator
05:48:15 [cpn]
Mounir: In Chrome, we've been looking at schema.org to see if we can populate the media session
05:48:27 [cpn]
... Some websites don't use media session, but they do have schema.org
05:48:50 [cpn]
... In future, Media Session could suggest default values based on schema.org
05:49:15 [mounir]
q?
05:49:20 [cpn]
... Today, most browsers use file icon, page title, for artist title, so could use this to provide better information
05:49:42 [cpn]
Richard: Is there overlap regarding security and privacy
05:50:17 [cpn]
Wendy: We're ready for CR, so need to get security and privacy review. As a manifest format, there aren't so many security and privacy concerns
05:50:45 [mfoltzgoogle]
q+
05:50:56 [mounir]
ack mfoltzgoogle
05:51:16 [cpn]
MarkF: Another relevant use case is background fetch for offline use. Can you get the file size from the manifest?
05:51:55 [cpn]
Wendy: The reading order can be a series of URLs. Depends on UA implementation, whether you pre-fetch or not. We don't have instructions on that
05:52:09 [cpn]
... In that case you'd download everything
05:52:25 [cpn]
MarkF: Is there enough information in the manifest to be able to check against storage quotas?
05:53:02 [cpn]
Wendy: We could include bitrate, so that with duration gives a hint. We work with reading systems as UA rather than browsers
05:53:08 [JohnRiv]
JohnRiv has joined #mediawg
05:53:27 [cpn]
... Can request the first bytes from the audio file to calculate the size
05:53:46 [cpn]
... We use zip for compression
05:53:58 [horiuchi_]
horiuchi_ has joined #mediawg
05:54:24 [cpn]
Mounir: If you have multiple files, bitrate is useful, adjust for quality, as with DASH
05:54:50 [horiuchi]
horiuchi has joined #mediawg
05:55:04 [tidoust]
RRSAgent, make minutes
05:55:04 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-mediawg-minutes.html tidoust
05:55:40 [mfoltzgoogle]
mfoltzgoogle has joined #mediawg
05:56:02 [MasayaIk_]
MasayaIk_ has joined #mediawg
05:56:57 [jernoble]
jernoble has joined #mediawg
06:00:05 [JohnRiv_]
JohnRiv_ has joined #mediawg
06:00:29 [atai]
atai has joined #mediawg
06:04:34 [JohnRiv]
JohnRiv has joined #mediawg
06:07:18 [horiuchi]
horiuchi has joined #mediawg
06:23:39 [MasayaIkeo]
MasayaIkeo has joined #mediawg
06:28:00 [horiuchi_]
horiuchi_ has joined #mediawg
06:32:32 [horiuchi_]
horiuchi_ has joined #mediawg
06:36:36 [jernoble]
jernoble has joined #mediawg
06:37:05 [ericc]
ericc has joined #mediawg
06:37:21 [scottlow]
scottlow has joined #mediawg
06:37:21 [markw]
markw has joined #mediawg
06:40:11 [mounir]
mounir has changed the topic to: Media WG
06:40:22 [takio]
takio has joined #mediawg
06:40:26 [mounir]
scribenick: mounir
06:41:03 [mounir]
Topic: Media Capabilities: Issues
06:41:42 [mounir]
jer: do we just want to do triaging of these bugs?
06:42:03 [mounir]
Chris: I think we may want to look at some put issues
06:42:26 [mounir]
[talking about some issues we could look at]
06:42:42 [mounir]
jer: should we walk through them one at a time?
06:42:47 [dbaron]
dbaron has left #mediawg
06:42:49 [mounir]
Chris: we should look at the subset I mentioned
06:43:03 [mounir]
jer: let's start with transition() ergonomics #102
06:43:10 [tidoust]
-> https://github.com/w3c/media-capabilities/issues/102 Issue #102 Discuss transition() ergonomics
06:43:38 [mounir]
jer: it's about transitioning from one codec to the next and the capability of doing so
06:43:48 [mounir]
Chris: it was done before the MSE API change
06:44:13 [mounir]
... the explainer had a method called query() at the time and we had this idea of an API called transition()
06:44:34 [mounir]
... we discussed very complicated solutions like if you can do A and B, can you do A => B or B => A
06:44:53 [mounir]
... after talking to Joey Parrish, he said it was over engineered and he wanted all or nothing as a web author
06:45:03 [mounir]
... websites want to know if you can A <=> B or nothing
06:45:24 [mounir]
... so it seems artificial to say that A => B is doable so is B => C but not C => A
06:46:14 [mounir]
Chris: the proposition I came up with is to have a boolean in the result that says whether the transitions from this codec are allowed
06:46:34 [mounir]
... which calls out cases where a UA cannot transition out of a specific codec