HTML Media Task Force Teleconference -- 10 Sep 2013

<trackbot> Date: 10 September 2013

<scribe> Scribe: joesteele

Agenda

F2F coming up

<markw> Yes, I'm going

is anyone going to the F2F

johnsim: not sure whether Adrian is going -- think he is

jerry: believe he is attending

do we have a timeslot scheduled?

jdsmith: believe we have something scheduled for Thursday
... should figure out what we want to accomplish
... should take advantage of being together

johnsim: some topics are hard to do over the phone
... should come up with a list

Previous Minutes

http://www.w3.org/2013/09/03-html-media-minutes.html

any objections?

scribe: any corrections?
... mark as approved

Review of Action items and issues

https://www.w3.org/html/wg/media/track/

any information on Adrian's actions?

Adrian is not here

jdsmith: have not heard much -- he has been out for family reasons

johnsim: working on it with David

ddorwin: this is the ISOBMFF data format issue

johnsim: growing consensus that is we are talking about CENC we should just have the concatenated PSSH boxes rather than the generic approach of the entire SINF
... suggested at the last TPAC

<markw> +1

johnsim: my proposal would be to return to the old CENC definition
... in the section where we talk about formats
... we could make that normative sections be specific to CENC

joesteele: we are ok with that position

johnsim: does that resolve my action?

ddorwin: there were some other issues with the text I identified
... you proposed some revised text, that cleaned up some things but raised other issues
... we need to decide how/whether other key systems are supported

johnsim: in other words what the initData would be for ClearKey

ddorwin: this was one of the issues
... could just define a generic one and ClearKey would happen to use that as well

johnsim: a generic PSSH would have a format would be defined in the spec for ClearKey?

ddorwin: that is one issue, there is a list in the bug

johnsim: so the action is to go through the bug issues and highlight the ones that go away with CENC
... and propose solutions to the remainders

<ddorwin> ^ correct

Moving ClearKey into separate spec

ddorwin: is is an issue but has been punting forward -- need impl feedback
... in every agenda

joesteele: no resolution yet

s/ye /yet/

johnsim: what led us to suggest this?

ddorwin: discussion about a year ago
... might add extra work, might not be possible
... my opinion is that we should keep it in
... links is in the issue (e.g. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21016)

here is the link to the issue -- https://www.w3.org/html/wg/media/track/issues/1

EME heartbeat

any progress?

<ddorwin> I was wrong - 7 months ago.

scribe: this would be Adrian so no progress

johnsim: no one on the call to address this I think -- need someone saavy in W3C arcana

ddorwin: obligation to update the spec, but not sure what the downside is

johnsim: so what do we need to do to publish the heartbeat?

joesteele: don't believe any specific bugs needed to be in the hearbeat, no specific changes needed, ...

EME status abd bugs

joesteele: does anyone have any specific bugs they want o go over?

ddorwin: Adrian had the same-origin bug which I reviewed
... also opened the ClearKey bug about the key format

<ddorwin> Clear Key format bug: https://www.w3.org/bugzilla_public/show_bug.cgi?id=17682

joesteele: why the change here?

ddorwin: some ambiguity about key id, wanted to specify things more
... will make implementations easier and interoperable

Revisit Key Error codes

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798

ddorwin: on me to document - people can continue the discussion in the bug
... this will spark more discussion

Define initialization data for ISO-BMFF

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673

joesteele: john will do more investigation before we close this out

ddorwin: john do you want a new date?
... I will change the date to next week

Need non-normative security condierations sections

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909

ddorwin: Adrian closed the privacy bug
... 22910
... tjoesteele: here is a discrepancy with 20965 the master bug, we should either close 909 or close 910
... either this was an oversight or there was proposed text for one and not the other

joesteele: should get Adrians feedback on that

ddorwin: I will update the bug

PetrPeterka: can we talk about 17615

Support for different CDM communication models

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17615

PetrPeterka: one model is that DRM as explicit out of band channel, other model is that all comms go through the browser
... some changes came later to exclude the out-of-band model
... text in the abstract that explicitly prevents this
... supporting both models should not require architectural changes
... just need to return the right status

<ddorwin> The original discussion was that the out-of-band mode was *already* supported by HTML5 media elements

<markw> david is saying just what I was going to say

ddorwin: what is the new information that you think changes this?
... taking out needKey and other messages makes this not EME anymore

PetrPeterka: goal is to make this interoperable and remove app-specific knowledge
... eg. MPEG-DASH with CENC could just provide the stream to the DRM and say "handle this - I don't know much"

<ddorwin> Interoperable is the key - the two modes are not interoperable. Applications written for one would not be interoperable with the other.

PetrPeterka: application designer has to treat either model in the same way without pushing too much information into the app

ddorwin: that is the issue -- application does have to know

PetrPeterka: application could say "take care of the keys" and not have to deal with it
... in some cases the app would have to be involved, in others the DRM could just handle it

markw: is that a realistic scenario? that would imply the app provider has both ends of the system
... they also have a front-end server which talks to the back end-server correctly
... distinguishing between front-end DRM server and back-end DRM server

PetrPeterka: why does the application have to make that decision?
... today there are operators that are using multiple DRMs
... so they would have multiple license servers

markw: the point of EME was to make it simpler for application providers to support multiple DRMs

PetrPeterka: think we have the same goal, that app should not be aware of those differences
... service providers want to choose which DRMs they support
... and invoke te matching services based on their needs

markw: intention was to make it easier for apps to support multiple DRMs -- that was the idea behind the model
... providers are restricted to the models they support
... if you add additional models it makes it more complicated

PetrPeterka: this is what I am missing -- from my point of view the application generates the message and either the CDM handles it or it does not.

markw: I am including the server side when I say application

BobLund: want to comment on whether service proivders want to choose the DRMs they use
... our members want and need to support the clients they provide service to
... this means they have to support a set of DRMs and want to support a common set of functionality
... EME as defined does a good job of that

PetrPeterka: at the recent CableLabs conference I heard opposite to this, that MSOs want to choose the DRMs and that browsers have already made they choices and will want to stick with them

BobLund: have to distinguish between the goals with the leased equipments and retail euqipment
... in the legacy environment they have already started to deliver DRM
... this will be the same set as the retail devices
... IP delivery is all about delivering to the non-legacy devices

PetrPeterka: I am not talking about the legacy devices, I am talking about the IP devices today
... those devices have built-in DRM of their choise

BobLund: I would not agree

pal: reading the bug -- what are the proposed changes?
... is it just to remove the informative statement in the introduction?

PetrPeterka: that was the main request I believe
... there was also the issue of informing the browser that the key has been acquired

pal: difference between normative and informative changes to the spec

PetrPeterka: first is an informative change
... not familiar with the details of the key request today to tell the browser that the key has been requested

pal: would be good to know the full consequences of these changes
... please provide more details

markw: briefly - a service provider who thinks they can convince every provider to support their DRM is out of luck
... in the model we have, there is an ability to message the browser that no more key request is needed
... we should get the sevice providers to support this model

PetrPeterka: model today allows for this existing key model right?
... then the end result to the API is the same?

markw: the spirit of the spec disagrees, but the letter allows it
... browser providers might not agree with this

PetrPeterka: one provider on the call who wants a different model -- why should we forbid?

ddorwin: should we call that EME compatible?

PetrPeterka: but it meets the same normative requirements? why would it not be compatible?

ddorwin: what would be the point of that level of interop if it is not really interoperabl?

<markw> @pal The document describes the architecture as well as the API

<ddorwin> From the abstract: "License/key exchange is controlled by the application…" This was also an important design requirement. This is not the case with the second model.

<ddorwin> Applications should be able to expect consistent behavior, such as (as mentioned earlier) being able to proxy the license requests through its front end server.

<ddorwin> Reiterating what was just said: Regardless of what the spec says, key systems using the other model are unlikely to be supported by applications written for the application-driven EME model.

<ddorwin> As discussed in the email thread, there are concerns related to origin, etc. with out-of-band license exchanges.

<markw> +1 to what david said

joesteele: cutting off conversation -- please continue via email or at next weeks meeting!
... thanks all!

<pal> "Reiterating what was just said: Regardless of what the spec says, key systems using the other model are unlikely to be supported by applications written for the application-driven EME."

s/we (Adobe)/joesteele: we/

trackbot, end meeting

- DRAFT -

HTML Media Task Force Teleconference

10 Sep 2013

Attendees

Contents