{minutes} HTML WG media telecon 2015-12-15 - EME ISSUE-85 and ISSUE-132

The minutes of the Dec 15 Media telecom are at http://www.w3.org/2015/12/15-html-media-minutes.html and below.

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


[W3C]<http://www.w3.org/>

- DRAFT -
HTML Media Task Force Teleconference
15 Dec 2015

Agenda<https://lists.w3.org/Archives/Public/public-html-media/2015Dec/0007.html>

See also: IRC log<http://www.w3.org/2015/12/15-html-media-irc>

Attendees
Present
paulc, markw, joesteele, Travis_Leithead, ddorwin, jdsmith, BobLund, plh, slightlyoff, davide, johnsimmons
Regrets
Chair
paulc
Scribe
paulc
Contents

  *   Topics<http://www.w3.org/2015/12/15-html-media-minutes.html#agenda>
     *   ISSUE-85 - "tracked" sessions: architectural concerns pending resolution with TAG<http://www.w3.org/2015/12/15-html-media-minutes.html#item01>
     *   ISSUE-132 - EME should support continuous key rotation per MPEG Common Encryption (ISO/IEC 23001-7)<http://www.w3.org/2015/12/15-html-media-minutes.html#item02>
     *   Next meeting and holiday period<http://www.w3.org/2015/12/15-html-media-minutes.html#item03>
     *   Any other business<http://www.w3.org/2015/12/15-html-media-minutes.html#item04>
  *   Summary of Action Items<http://www.w3.org/2015/12/15-html-media-minutes.html#ActionSummary>
  *   Summary of Resolutions<http://www.w3.org/2015/12/15-html-media-minutes.html#ResolutionSummary>

________________________________

rssagent, generate the minutes

<ddorwin> yes

<scribe> Scribe: paulc
ISSUE-85 - "tracked" sessions: architectural concerns pending resolution with TAG

https://github.com/w3c/encrypted-media/issues/85

paulc: When will the TAG be ready to respond to this issue?

travis: TAG was very busy in Nov and Dec and this kept TAG members busy and blocked progress.
... I am on my way on vacation and therefore a resolution will not occur until mid to late january
... Tag is meeting F2F in mid-January and this issue will be on the F2F agenda

<slightlyoff> hey all

<slightlyoff> sorry, just joined

paulc: Does the TAG need any more input?

Travis: I think I have all the input needed but will not speak for Alex.
... We might be able to use some contact time.

<markw> \me could you remind us the dates of the TAG F2F ?

<slightlyoff> January 12-15, IIRC

<slightlyoff> but in AUS, so calendar hijinks apply

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.

<slightlyoff> thanks
ISSUE-132 - EME should support continuous key rotation per MPEG Common Encryption (ISO/IEC 23001-7)

https://github.com/w3c/encrypted-media/issues/132

jdsmith: I have been concerned about key rotation for some time.
... MSFT has received a lot of input from others that EME did not support this feature of CENC
... We need to take into consideration the large amt of input about this feature and we believe it should be in EME V1
... In band keys are one way to go. There has been lots of input but we believe the use case is very important.

johnsimmons: The input has come from DASH-IF, and others that are planning to use EME.
... They have struggled with the role of app and CDM on handling of keys
... CENC specifically permits key rotation (... more description of this)
... EME lack of support of this feature interferes with these communities use of EME

joesteele: Adobe has several media partner companies about limitations of EME
... mostly about performance requirements that each PSSH requires message exchanges and was raised in a separate issue
... I don't have a strong view of media data to CDM
... We should discuss who should handle the data
... This was raised at TPAC ATSC break-out session
... We should be encouraging people to use EME to move on to the web platform

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
... So far we don't have a V1 test suite and I don't think we should not work on this given our status

<ddorwin> 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.

<slightlyoff> so it sounds like this is about v1 vs. v2?

plh: 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
... we need to get V1 out the door and we should be working on test suite instead of more features
... we should be focused on interoperability of current feature set

<ddorwin> slightlyoff: yes

plh: and then start up next feature set and that can be done in parallel

johnsim: Its our view and others in the broadcast side that this is a spec bug and NOT a new feature
... it is related to inteface of license aquisition between app and CDM
... we don't believe this is not a new feature but that we should fix this in the current spec
... we agree that interoperability is very important but that should not stop the implementation of this use case
... as long as the application does not have to know the CDM that it is using this could be done in current spec

<ddorwin> 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.

markw: We should have more technical discussion on the use case and we should have a PR for the use case
... we need to know what "it" is and then we can determine when it will be implemented by browsers and whether it would delay v1 or not

BobLund: I second what Mark said and we should assess timing when we have a specific proposal on the table

<ddorwin> Any time spent on this is time not spent on the existing confirmed v1 bugs.

plh: I don't here disagreement here. Interop for V1 is important and the timing of this use case is a discussion point.

<slightlyoff> ISTM that the debate here is about wether or not there's a v2 spec to write diffs against?

<ddorwin> 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.

<markw> \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 ;-)

joesteele: A possible way forward is to discuss this in ISSUE-132 and to remove the other issues that are pending

<ddorwin> @markw: Yes. I was having a difficult time communicating that nuance.

joesteele: 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
... let's make progress on both fronts

<ddorwin> But still, would we delay CR to address this and the other feature requests?

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
... We need to drill down into how to accommodate this feature/use case in EME
... 1 direct consumption of keys in the stream
... 2 reducing the need for key requests ...

<markw> @ddorwin depends on the length of the delay which depends on the timing and number of the intent to implement from browsers

jdsmith: we need to figure out the nuts and bolts of this feature

<ddorwin> 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.

<ddorwin> Consider them together to ensure we have a consistent solution and the APIs make sense for all of them.

slightlyoff: First apologize for not making enough progress on ISSUE-85
... I am surprized there is a V1 - V2 discussion and not a living approach
... how is that being decided?

<ddorwin> The charter says CR is to be in Q1.

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

<plh> 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

Status as of Dec 14: 41 open issues of which 15 are "needs implementation"

<plh> ... as Joe said if we're going to make on use cases like this, we need to make progress on other issues

<plh> Paul: we have 26 open issues, so not ready for LC/CR

slightyoff: I was just trying to understand how the group is thinking about the timeliness issue

ddorwin: I thought we had TPAC discussion about the schedule and we are going to have to make some hard decisions

ddowin: I think it is time to wrap up EME

markw: I don't agree with the description of duplication of key requests and we need to flush out those assumptions
... I have made this point in my responses to ISSUE-132

<ddorwin> +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.

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
... there is a fundamental error in how the application and CDM interact
... these bugs are being raised by the industry and the industry is asking for these to be fixed

<ddorwin> Is it uncommon for specs to ship with limitations that need to be addressed in future versions?

johnsim: we need to discuss how DASH and key rotation are handled by EME
... let's spend the time looking at these two use cases from an architectural point of view
... if there is a flaw in the architecture then it should be fixed in V1

<ddorwin> johnsim: Are you proposing to change the architecture of EME at this point?

johnsim: if the architecture is okay and they can be handled then a delay could be discussed

ddorwin: EME was designed to handle a limited set of features. We address live and broadcast (eventually)

<slightlyoff> apologies, I need to leave the call

<slightlyoff> would encourage this group to ship-and-iterate

ddorwin: there are assumptions that narrowed the scope and I don't believe there are architectural problems

<slightlyoff> and you can't do that if you don't ship

ddorwin: a change to the architecture is really late

johnsim: I meant to mention that keys cannot be delivered in the PSSH box is a architecture problem
... 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

<ddorwin> re: keys in initData - it's a scope-limiting limitation, not necessarily an architectural one.

johnsim: DASH is doing weird binary comparisons to test for this and it is not always right
... only the CDM can know if the key acquistion is required
... I agree we need to get EME done
... I agree that we need test suite for V1 interoperability
... I agree with the need for an interoperability design
... I disagree that EME is ONLY for Video on Demand

markw: 1. it would help if could be clarified if the key acquisition is required problem

2. to answer Alex about the future schedule, I believe that the most importnat question si when there is shipping code

<ddorwin> +100 to markw's statement regarding current discussions treating the symptom without understanding the underlying problem.

<ddorwin> and that spec versions do not affect/prevent shipping code.

rssagent, generate the minutes

paulc: Several suggestions here:

<slightlyoff> so a few things (and apologies for needing to drop off the call)

1. Make progress on the already existing outstanding issues especially those that are "needs implementation" - get the bug count down

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

<slightlyoff> 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

3. Make initial progress on a test suite of the existing features

<slightlyoff> 2.) the way to reduce the FOMO regarding v1 vs. v2 is to iterate faster

paulc: Every one can produce pull request for ANY issue
Next meeting and holiday period

paulc; I am not expecting we will meet until the 2nd week in January ie maybe Jan 12

scribe: 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
... we could use Jan 12 for a) more discussion on -132 b) more discussion with TAG on -85 or c) for MSE discussion
Any other business

None

Safe holidays and safe travels to everyone.

Adjourned

Summary of Action Items
Summary of Resolutions
[End of minutes]
________________________________
Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.144 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2015/12/15 16:59:46 $
________________________________