{minutes} HTML WG F2F 2014-04-09 - Media Task Force breakout session

We setup a new wiki page to capture use cases, external references and other useful information: https://www.w3.org/wiki/HTML/Media_Task_Force

I have started putting things up there — please review and contribute. 

The minutes from our breakout session are below. Enjoy!

Joe Steele
steele@adobe.com


Proposal to implement a wiki
... include Use cases
... include references
... I will send out the link - SENT

Good to list all of the use cases
... 3 categories
... things the spec should address
... things the spec should NOT address
... things that would be nice to have

How do we get consensus?
... add the cases
... have discussion

ddorwin: purpose of EME was to provide apps that works across systems
… turn on any device/browser it will work
… that means app is written once
… I have been driving at that in the past week
… but is failing in practice
… ambiguity is causing problems
… are other cases were legacy systems are causing problems

mark_vickers: do you mean systems?

ddorwin: I mean existing DRM systems

mark_vickers: that is not a use case for me ...
… what I want is use cases - for example streaming Netflix
… Ultraviolet is a different use case
… DLNA is another use case
… in all 3 cases would want a client that works across browsers and DRMs
… that is what I was thinking

ddorwin: I was just describing not specifying the use cases
… existing DRMs and systems could be interacted with
… but may have different goals in mind
… those are the competing problems
… I like what you said (Mark) about how do I solve the Hulu problem?
… that is what we want to solve
… if an application needs something, and a CDM needs something how can it interop?

mick: does it means two CDMs in the same browser or two different browsers?

mark_vickers: my response is that it does not make sense for the EME effort 
… to take on every use case
… good to write it down though
… and good to write down the others to know why they won’t work
… we would like to use browsers to deliver all of our services
… e.g. live TV
… differences between live TV and VOD
… this is meant to be the only API moving forward for protected content

niels: I would not make this an ecosystem like DECE
… includes too much
… but includes use cases like root/leaf, key rotation, domains
… think we can show those use cases are relevant
… for example this is how you could do domain management

mark_vickers: I can see how you want to push this up a level
… not talking about specific services but higher level use cases

niels: I disagree
… I think VOD can be in many different installations
… for example if you group devices
… this is independent of a particular service

ddorwin: I think that identifying things that have been implanted is the wrong way to go forward
… Joe brought up one case - with offline keys
… may be other ways to support this

niels: good point - might be something we should look at

joesteele: what about content

mick: what about slicing this along features?
… aka this API does not support this feature

ddorwin: it would be interesting to know which features have have been used to support which use cases in the past
…most important thing to support one key across multiple devices is how does that work
… we need to look at the use case and how do we solve in a web world

mark_vickers: here are some use cases
… VOD, live video, download to go
… understand some are not supported via EME
… delivery over a LAN

 joesteele: I have a concern about content formats
… don’t want to force re-headering

joesteele: need to slice various ways
... content compatilbity
... features
... use cases

ddorwin: CENC is not the only solution for the web
… PSSH thing is actually a hurdle
… nice to have a standard header - which I would like Widevine to support that
… understand the non-browser model - but that is not what we are shooting for
… was not possible before - had multiple DRMs
… understand that content exists, don’t think that we should poke holes in EME to support this

niels: we are competing with DASH
… it is a trade-off but ideally we would like to bring this stuff into the browser

ddorwin: not sure we are competing with DASH
… goal is one app everywhere
… native app is counter to that

niels: big libraries support DASH

ddorwin: if not providing to more user, then it is not a win
… goal is to provide more content to more users
… writing the HTML app to handle all your existing content will not get you more clients

markv: my understanding is that CENC is a key use case for EME
… however it is my sense that it is not a requirement
… could detect and branch in the application if needed
… that should still work

ddorwin: true but I want to focus on the CENC case
… also said as “commonly encrypted”
… ISO common encryption
… WebM is “commonly encrypted”

<description of how CENC was developed>

… I think the goal with EME is that less and less of that information should be there
… this did not make things truly interoperable

niels: you need some information about where to lookup this key

ddorwin: this is where the use case descriptions help

mark: in this case the app knows the information
… think it is useful to have common encryption

ddorwin: we want to define how you make an interoperable app
… and then support these use cases
… that is where removing ambiguity comes in
… should be able to read a spec
… it was mentioned was back don’t call it the Netflix case - VOD case
… need to fully articulate

mark: think we should focus on the main use cases
… think the other use cases should work as well but have to fit

jdsmith: are you talking about proprietary formats?

mark: I was talking about TCP/IP link-leve delivery - don’t think it would not be supportable
… but I think the API could be used for it
… similar to when we query image-type or mime-type 
… some are standardized, but can be extended
… this is the only place we can ask these questions about protection type
… think this should be like mime-type, can be used for extension

ddorwin: seems like isTypeSupported()
… this is somewhat orthogonal to what we were discussing past two weeks
… you can detect what is available but it won’t work everywhere

mick: its like EME has two parts
… common standard parts - like JPEG eg Errors
… extended parts - custom, proprietary like session management
… could to draw a line where EME can be generic and where can be extended

niels: where would you draw this split? 
… want to keep the proprietary part as small as possible

ddorwin: look at 8.3 in the spec
… this is a simple version of that
… not usually as simple as that.

discussion about persisted licenses and release

mick: release will have to have cryptographic binding
… so really down not matter whether app calls this out

ddorwin: a while ago we said online use case was simple
… other use cases are harder
… offline could be possible within EME probably won’t look like existing DRMs

mark: I want to support the use cases
… not caring about supporting specific DRMs
… want to go towards the idea of a portable application 

joesteele: need to provide lots of detail on the use cases

mark: two use cases i have heard Netflix use case and the offline use case

ddorwin: think we can do lots of optimizations
… but that does not mean you can’t support the base case
… run into lots of issues with supporting the old crap
… prefer to move into the new world

<discussion of key models and delivering>

discussion of multiple episode decryption
... can keys be i-memory
... focus on keys is intended for content keys
... not clear that is a problem

discussion of the embedded key problem versus the persistent key

is there a common PSSH?
... not today
... could define one for Ultraviolet
... MarkV could look into that 

mark_vickers: would be useful to discuss Ultraviolet
… would be of interest to some

<discussion of the Ultraviolet use case>

mark_vickers: interesting questions
… can you build an Ultraviolet player using EME?
… can you use Ultraviolet content from an EME player?

ACTION: put the list of differences between CENC and CFF on the wiki

ddorwin: is anyone on the CENC 2.0 spec?
… are key IDs in the spec and what are they for ….

bug 25201
... no objections ... might solve part of the PSSH problem

bug 18515
... Promises will change all the APIs so we need to revisit

bug 24323
... ditto as above

bug 24027
... EME version of common PSSH

bug 17673
... this is just a revert to what the text said before
... David Singer wanted to do BMFF with another scheme e.g. SINF
... now this is handled by the registration page

bug 24873, 24874
... Adrian mentioned had other discussions going on
... re: feature detection

jdsmith: we have had discussions about broad capabilities exposure
… 4K, HDCL 2.x, AC3 etc. 
… ideally app would know in advance what device is capable of
… there is a contrained() object in WebRTC spec ... can define a dictionary of requirements
… we think it might be leveraged for this
… had another PM I wanted to discuss this with them
… source type is an example

ddorwin: there is a large group of things like this that ideally we could solve

jdsmith: could come up with a useful set of things to support
… would like to be in a better model than to try and then fail

ddorwin: there is a case for “maybe”
… since you have an asynchronous model and you can’t know till you try
… for Chrome codecs these things are hard-coded in the main thread

ddorwin: should we have a meeting next week?
… could get more work done if folks read the bugs and the emails
… could handle a lot of this via email
… probably not have enough time to review anything we do between now and then

bug 25217, 25218
... needs the use cases in place to discuss
… hold off for now

other lower priority things we will continue to hold of on
... have enough to handle right now

to be worked on 
... will be actively worked on once more important things are handled

good meeting! lot’s of progress