15:55:39 RRSAgent has joined #html-media
15:55:39 logging to http://www.w3.org/2015/12/15-html-media-irc
15:55:41 RRSAgent, make logs public
15:55:41 Zakim has joined #html-media
15:55:43 Zakim, this will be 63342
15:55:43 I do not see a conference matching that name scheduled within the next hour, trackbot
15:55:44 Meeting: HTML Media Task Force Teleconference
15:55:44 Date: 15 December 2015
15:55:53 rssagent, generate the minutes
15:56:02 present+ paulc
15:56:11 zakim, who is here?
15:56:11 Present: paulc
15:56:13 On IRC I see RRSAgent, paulc, ddorwin, slightlyoff, adrianba, cwilso, timeless, Josh_Soref, robink_, trackbot
15:56:26 Agenda: https://lists.w3.org/Archives/Public/public-html-media/2015Dec/0007.html
15:56:37 Chair: paulc
15:57:25 markw has joined #html-media
16:00:43 rrsagent, generate the minutes
16:00:43 I have made the request to generate http://www.w3.org/2015/12/15-html-media-minutes.html paulc
16:01:07 davide has joined #html-media
16:01:17 present+ markw
16:01:42 Travis has joined #html-media
16:01:47 present+ joesteele
16:01:56 Present+ Travis_Leithead
16:02:34 yes
16:03:09 present+ ddorwin
16:03:15 BobLund has joined #html-media
16:04:23 zakim, who is here?
16:04:23 Present: paulc, markw, joesteele, Travis_Leithead, ddorwin
16:04:25 On IRC I see BobLund, Travis, davide, markw, Zakim, RRSAgent, paulc, ddorwin, slightlyoff, adrianba, cwilso, timeless, Josh_Soref, robink_, trackbot
16:04:34 rrsagent, generate the minutes
16:04:34 I have made the request to generate http://www.w3.org/2015/12/15-html-media-minutes.html paulc
16:05:08 jdsmith has joined #html-media
16:05:15 present+ jdsmith
16:05:15 johnsim has joined #html-media
16:05:21 plh has joined #html-media
16:05:52 Scribe: paulc
16:06:31 Topic: ISSUE-85 - "tracked" sessions: architectural concerns pending resolution with TAG
16:06:47 https://github.com/w3c/encrypted-media/issues/85
16:07:02 paulc: When will the TAG be ready to respond to this issue?
16:07:28 travis: TAG was very busy in Nov and Dec and this kept TAG members busy and blocked progress.
16:08:04 ... I am on my way on vacation and therefore a resolution will not occur until mid to late january
16:08:22 ... Tag is meeting F2F in mid-January and this issue will be on the F2F agenda
16:08:24 hey all
16:08:26 sorry, just joined
16:08:51 paulc: Does the TAG need any more input?
16:08:51 present+
16:08:51 present+ plh
16:09:04 present+ slightlyoff
16:09:14 Travis: I think I have all the input needed but will not speak for Alex.
16:09:33 ... We might be able to use some contact time.
16:09:52 present+ davide
16:10:30 \me could you remind us the dates of the TAG F2F ?
16:10:46 January 12-15, IIRC
16:11:04 but in AUS, so calendar hijinks apply
16:11:13 paulc: Please let us know if you need any more input or time with the TF. We can either do that at the TAG F2F or on a separate TF call.
16:11:56 zakim, who is here?
16:11:56 Present: paulc, markw, joesteele, Travis_Leithead, ddorwin, jdsmith, BobLund, plh, slightlyoff, davide
16:11:58 On IRC I see plh, johnsim, jdsmith, BobLund, Travis, davide, markw, Zakim, RRSAgent, paulc, ddorwin, slightlyoff, adrianba, cwilso, timeless, Josh_Soref, robink_, trackbot
16:12:33 thanks
16:12:33 Topic: ISSUE-132 - EME should support continuous key rotation per MPEG Common Encryption (ISO/IEC 23001-7)
16:12:49 https://github.com/w3c/encrypted-media/issues/132
16:13:53 jdsmith: I have been concerned about key rotation for some time.
16:14:33 ... MSFT has received a lot of input from others that EME did not support this feature of CENC
16:15:04 ... We need to take into consideration the large amt of input about this feature and we believe it should be in EME V1
16:15:37 ... In band keys are one way to go. There has been lots of input but we believe the use case is very important.
16:16:12 johnsimmons: The input has come from DASH-IF, and others that are planning to use EME.
16:16:33 ... They have struggled with the role of app and CDM on handling of keys
16:16:56 ... CENC specifically permits key rotation (... more description of this)
16:17:20 present+ johnsimmons
16:17:59 ... EME lack of support of this feature interferes with these communities use of EME
16:18:33 joesteele: Adobe has several media partner companies about limitations of EME
16:19:19 ... mostly about performance requirements that each PSSH requires message exchanges and was raised in a separate issue
16:19:54 ... I don't have a strong view of media data to CDM
16:20:10 ... We should discuss who should handle the data
16:20:22 q?
16:20:32 ... This was raised at TPAC ATSC break-out session
16:21:01 ... We should be encouraging people to use EME to move on to the web platform
16:21:09 q+
16:21:14 ack plh
16:21:38 q+
16:21:53 plh: My understanding is that Google is pushing back on whether this is a V1 feature - We should remember that every V1 feature needs to implemented
16:22:20 ... So far we don't have a V1 test suite and I don't think we should not work on this given our status
16:22:21 q+
16:22:23 ack dd
16:22:25 EME v1 was intentionally limited to a feature set we could reasonably address and ensure interoperability. Through this effort, we have learned about various optimization requests. These are all interesting and should be addressed, but this should be done in a thoughtful structured manner, not in a hurry and holding up four years of work.
16:23:04 q-
16:23:12 +q
16:23:22 so it sounds like this is about v1 vs. v2?
16:23:42 ... it has taken 4 years to get here for the limited feature set and we believe that this issue needs thought and we need to take time to do this right
16:23:45 q+
16:24:05 ... we need to get V1 out the door and we should be working on test suite instead of more features
16:24:16 q+
16:24:18 ... we should be focused on interoperability of current feature set
16:24:27 slightlyoff: yes
16:24:42 ... and then start up next feature set and that can be done in parallel
16:24:49 ack johnsim
16:25:21 johnsim: Its our view and others in the broadcast side that this is a spec bug and NOT a new feature
16:25:44 ... it is related to inteface of license aquisition between app and CDM
16:26:02 ... we don't believe this is not a new feature but that we should fix this in the current spec
16:26:37 ... we agree that interoperability is very important but that should not stop the implementation of this use case
16:27:00 ... as long as the application does not have to know the CDM that it is using this could be done in current spec
16:27:00 Call it what you want - feature or "bug" - it is still a fundamental change in the behavior that has been mostly stabilized. The current design was not a mistake, oversight, or flaw - it was very intentional to limit the scope and drive interoperability.
16:27:04 ack markw
16:27:37 markw: We should have more technical discussion on the use case and we should have a PR for the use case
16:28:03 ... we need to know what "it" is and then we can determine when it will be implemented by browsers
16:28:25 ack Bob
16:28:52 BobLund: I second what Mark said and we should assess timing when we have a specific proposal on the table
16:28:53 Any time spent on this is time not spent on the existing confirmed v1 bugs.
16:28:54 q+
16:28:58 ack plh
16:29:15 s/implemented by browsers/implemented by browsers and whether it would delay v1 or not/
16:29:40 q+
16:29:44 plh: I don't here disagreement here. Interop for V1 is important and the timing of this use case is a discussion point.
16:30:00 ISTM that the debate here is about wether or not there's a v2 spec to write diffs against?
16:30:01 We should drive our bug count much lower before focusing on this. As plh said, people are welcome to take the lead, but let's not let it distract us.
16:30:02 \me @ddorwin That's not necessarily true if the people contributing to this are different from those who would spend time on the other bugs ;-)
16:30:41 joesteele: A possible way forward is to discuss this in ISSUE-132 and to remove the other issues that are pending
16:30:54 @markw: Yes. I was having a difficult time communicating that nuance.
16:31:32 ... We should also be making progress on the other 40 open issues - they just require work and it would be good "to clear the decks" for V1
16:31:42 ... let's make progress on both fronts
16:31:43 But still, would we delay CR to address this and the other feature requests?
16:31:48 ack jd
16:32:25 jdsmith: I had two goals on entering ISSUE-132 - 1st was to get agreement on the use case 2nd is to decide on when to add this feature
16:32:49 ... We need to drill down into how to accommodate this feature/use case in EME
16:33:00 ...1 direct consumption of keys in the stream
16:33:29 ... 2 reduce ...
16:33:29 @ddorwin depends on the length of the delay which depends on the timing and number of the intent to implement from browsers
16:33:52 q+
16:33:52 ... we need to figure out the nuts and bolts of this feature
16:34:12 I am concerned about trying to just address this use case. I think we should consider all of these use cases together, and I think that would significantly delay v1 CR.
16:34:14 s/2 reduce/2 reducing the need for key requests/
16:34:48 q+
16:34:48 +q
16:34:58 Consider them together to ensure we have a consistent solution and the APIs make sense for all of them.
16:35:07 ack slightyoff
16:35:40 slightlyoff: First apologize for not making enough progress on ISSUE-85
16:36:04 ... I am surprized there is a V1 - V2 discussion and not a living approach
16:36:11 ... how is that being decided?
16:36:37 The charter says CR is to be in Q1.
16:36:40 paulc: The TF has not really touched on the schedule or exit criteria for LC/CR for V1 since we have had > 40 issues open for some time
16:36:51 Pual: the task for ce has not really touched on it, or on our exit criteria . we have greater than 40 issues opened for sometimes
16:37:16 Status as of Dec 14: 41 open issues of which 15 are "needs implementation"
16:37:27 ... as Joe said if we're going to make on use cases like this, we need to make progress on other issues
16:37:46 Paul: we have 26 open issues, so not ready for LC/CR
16:38:27 slightyoff: I was just trying to understand how the group is thinking about the timeliness issue
16:39:10 ddorwin: I thought we had TPAC discussion about the schedule and we are going to have to make some hard decisions
16:39:32 ddowin: I think it is time to wrap up EME
16:39:37 q?
16:39:42 ack sligh
16:39:56 ack mar
16:39:57 ack markw
16:40:36 markw: I don't agree with the description of duplication of key requests and we need to flush out those assumptions
16:40:56 ... I have made this point in my responses to ISSUE-132
16:41:02 ack johnsim
16:41:12 +1 to what markw said. I don't think the use cases are clear. I understand the possible concepts, but what use cases are we trying to solve? I think several have been discussed in 132.
16:41:34 q+
16:41:52 johnsim: As I said earlier I don't believe the use case is a feature request but they are bugs and there is a architectural problem here
16:42:06 ... there is a fundamental error in how the application and CDM interact
16:42:30 ... these bugs are being raised by the industry and the industry is asking for these to be fixed
16:42:34 ISpecs ship with limitations that need to be addressed in future versions.
16:42:46 ... we need to discuss how DASH and key rotation are handled by EME
16:43:06 s/ISpecs ship with limitations that need to be addressed in future versions./Is it uncommon for specs to ship with limitations that need to be addressed in future versions?/
16:43:14 ... let's spend the time looking at these two use cases from an architectural point of view
16:43:29 ... if there is a flaw in the architecture then it should be fixed in V1
16:43:45 johnsim: Are you proposing to change the architecture of EME at this point?
16:44:00 ... if the architecture is okay and they can be handled then a delay could be discussed
16:44:06 markw_ has joined #html-media
16:44:22 ack dd
16:45:23 ddorwin: EME was designed to handle a limited set of features. We address live and broadcast (eventually)
16:45:26 apologies, I need to leave the call
16:45:36 +q
16:45:40 would encourage this group to ship-and-iterate
16:45:46 ... there are assumptions that narrowed the scope and I don't believe there are architectural problems
16:45:47 and you can't do that if you don't ship
16:45:56 q+
16:46:01 ... a change to the architecture is really late
16:46:10 ack johsim
16:46:15 ack john
16:46:58 johnsim: I meant to mention that keys cannot be delivered in the PSSH box is a architecture problem
16:47:33 ... and there is no way for new initialization to arrive without a key acquistion since the app can always know if the initialization it sees contains new keys
16:47:36 re: keys in initData - it's a scope-limiting limitation, not necessarily an architectural one.
16:47:58 ... DASH is doing weird binary comparisons to test for this and it is not always right
16:48:17 ... only the CDM can know if the key acquistion is required
16:48:25 ... I agree we need to get EME done
16:48:30 s/+q/q+/G
16:48:36 ... I agree that we need test suite for V1 interoperability
16:49:02 ... I agree with the need for an interoperability design
16:49:14 ... I disagree that EME is ONLY for Video on Demand
16:49:40 q?
16:50:17 ack markw
16:51:03 markw: 1. it would help if could be clarified if the key acquisition is required problem
16:52:03 2. to answer Alex about the future schedule, I believe that the most importnat question si when there is shipping code
16:52:14 +100 to markw’s statement regarding current discussions treating the symptom without understanding the underlying problem.
16:52:14 and that spec versions do not affect/prevent shipping code.
16:52:17 rssagent, generate the minutes
16:52:32 paulc: Several suggestions here:
16:52:36 so a few things (and apologies for needing to drop off the call)
16:52:59 1. Make progress on the already existing outstanding issues especially those that are "needs implementation" - get the bug count down
16:53:36 2. Continue the technical discuss as suggest by MarkW to clarify the problems and possibly create a pull request to more clearly define what is being proposed
16:53:43 1.) specs are, by definition, backwards-looking. At the point where they are load-bearing, they aren't the state-of-the-art. So there's a real and useful tradeoff the group needs to make regarding when things show up in the "near" version vs. the "far" version
16:53:55 3. Make initial progress on a test suite of the existing features
16:53:57 2.) the way to reduce the FOMO regarding v1 vs. v2 is to iterate faster
16:54:34 paulc: Every one can produce pull request for ANY issue
16:55:56 Topic: Next meeting and holiday period
16:56:21 paulc; I am not expecting we will meet until the 2nd week in January ie maybe Jan 12
16:56:59 ... I hear lots of people starting their end of year holiday this week and to be realistic progress will probably only occur in early jan
16:58:20 ... we could use Jan 12 for a) more discussion on -132 b) more discussion with TAG on -85 or c) for MSE discussion
16:58:30 topic: Any other business
16:58:32 None
16:58:50 rrsagent, generate the minutes
16:58:50 I have made the request to generate http://www.w3.org/2015/12/15-html-media-minutes.html paulc
16:59:22 Safe holidays and safe travels to everyone.
16:59:32 Adjourned
16:59:40 davide has left #html-media
16:59:41 rrsagent, generate the minutes
16:59:41 I have made the request to generate http://www.w3.org/2015/12/15-html-media-minutes.html paulc
18:55:02 Zakim has left #html-media