acolwell: resolution may take
longer to figure out what the right behavior is

paulc: if you need help with
github -- ask

CR bug status of MSE

paulc: 5 of these bugs are
fixed
... aaron sent out "cyril draft"
... going to second link in the email
... Aaron summarizes long thread about this problem
... some expressions of support for this direction
... in email

acolwell: David Singers resposne
talks about one of the requests
... resolution for this I think is two remove some of the
definitions MSE makes of language and time on the track
objects

paulc: MSE proposed to make
language and time mutable -- ie change in full flight
... lots of push back on this
... general conclusion is that those should be fixed during the
track and should not change
... applies to audio, text, anything

?1: user can elect to change

acolwell: proposed changes is to
remove the definitions from MSE
... MSE will conform to what HTML5 spec says does not add text
for this
... if time needs to change within a track follow HTML5
guideline
... think that means removing the track and adding a new
track
... second part -- one of orig. justifications is that time is
not available in ISOBMFF file
... third thing - MSE spec should be more clear around language
and time
... looking for input from David and others on how to change
this MPEG spec

<joesteele_> pal: one #2 have
a question

<joesteele_> ... are you
syaing this cannot be communicated via HTML5?

<joesteele_> acolwell: no -
saying we would defined boxes saying what the time attributes
could be -- not communicated today

<joesteele_> pal: this might
exist outside the ISOBMFF package?

<joesteele_> acolwell: if so
then the app has to deal with it

<joesteele_> pal: then you
are proposing to duplicate this rather than using it where is
is today?

<joesteele_> pal: is there
another way of communicating that information so it can be
reflect back to the HTML attributes?

<joesteele_> acolwell: could
probably define special docs? to do this

<joesteele_> paulc: pierre is
looking for an API solution

<joesteele_> pal: trying to
avoid having these boxes be a requirement

<joesteele_> acolwell: making
time immutable seems to be most natural - but that creates a
problem

<joesteele_> pal: would like
to explore ways of doing this that do not require a new
required box

<joesteele_> cyril: I
proposed with CableLabs some extensions to the DASH manifest
for new roles values that would map to HTML time

<joesteele_> ... I think
would be a good idea to carry the time in the MP4 format for
WebVTT for example

<joesteele_> ... I also agree
with Pierre - maybe an API to set the time and language in some
sort of constructor

<joesteele_> ... not at just
any time -- would be useful

<joesteele_> markw: the kind
needs to be in the manifest whatever manifest we use

<joesteele_> ... application
needs to know before it is downloaded

<joesteele_> ... could also
be in the MP4 file but must be in the manifest

<joesteele_> ... also agree
that there is not need to change it after construction

<joesteele_> BobLund: agree
it should be in the manifest and should not be mutable

<joesteele_> ... but not all
media formats include thi sin-band

<joesteele_> glenn: if we add
something to ISOBMFF need to add for other formats

<joesteele_> ... seems to
have been added by WebVTT folks

<joesteele_> cyril: need to
make my contribution public and then will send to the list

<joesteele_> paulc: sounds
like this was made to imply it is mutable at any time

<joesteele_> ... but having a
constructor to set this would be a good idea

<joesteele_> acolwell: have a
chicken and egg problem - no point at which you can intercept
construction of the track

<joesteele_> cyril: but when
your source buffer is single track this is possible?

<joesteele_> acolwell: not
sure what that buys us though

<joesteele_> paulc: sounds
like we have concensus for #1

<joesteele_> pal: #2 is not
sufficient

<joesteele_> paulc: #3 we
need to get these changes made to HTML5 - and what she should
do about it is the next step there

<joesteele_> ... pal - you
need to respond to this and continue the dialogue

<joesteele_> ... we can get
#1 and #3 started

<joesteele_> ... Aaron think
that is enough for today

<joesteele_> acolwell: think
we have concensus for #1 - is there an alternate proposed or
should I just remove language?

<joesteele_> paulc: I am ok
with leaving the bug open with note about waiting for
concensus

EME Should use Promises

At the last meeting April 1st people needed
more time to think about using promises for this purpose

The main bug has the proposed IDL change

Any feedback?

joesteele: This is a good change
and in the direction of the W3C tag
... are other changes like this going to be made in HTML5? Or
will it wait until 5.1?

darobin: New apis are expected to
use promises

paulc: Others have been changed
in last call/WD status even before promises moved out of DOM4
and into ECMA script
... any objections?

adrianba: This is a good
direction and change to make, but I have some detail
questions
... for example I'm not sure how the promise works with the
release method
... it's not clear when the promise completes
... The best approach maybe to make this change and then
itterate on the details that comeout

ddorwin: Yes I added a comment in
the bug about this.

paulc: Room agrees
... I'm concerned about not discussing the other bugs that are
blocked

* Hi johnjan!

jdsmith: We have all replied back
to these bugs

paulc: What I am asking for when
is the next meeting and with enough next steps to know the
overall status of the next meeting
... Maybe these 'blocked' bugs can be addressed or have
progress on once the main bug is addressed (25199)

ddorwin: Some of these may just
be fixed or need minor changes

paulc: Once the root bug is fixed
can you send something to the TF on what needs to be done with
the other bugs (maybe close/duped by the root bug)

joesteele: The issue I'm trying
to raise here - a session is composed of licenses and
keys
... Load session and release assume a single content key
... You can deliver keys at a higher level that a specific
content stream
... if you impl release/session on a lower level it can impact
a higher level

ddorwin: alot of other ways
exist
... but EME is generic and simple
... the model is session based
... What happens if you load a key from another sessions, you
should not do this...
... I understand the domain thing, but I don't think it's
interoperable
... Likewise if it's built to support a specific device it
won't work on other devices
... I'm worried that do this change will cause more interop
issues
... We should fix the common case and then move to some other
complex cases
... For example web crypto..

niels_t: We do see limits in
EME

<joesteele_> +q

niels_t: allowing the CDM to
contact the license server directly
... intitlal for legacy
... but now we see additional use cases (init)
... could be allowed by this change
... it could be more of a conceptual change in the abstract

glenn: To the comments about
supporting exist solutions
... EME came about to support existing systems is an implicit
goals
... from cox's perspect we do have intrest in various legacy
systems (adobe, microsoft, etc.) would be a major issue for
adopting EME

pal: At a very high level,
encrypted media comes in, but I have a CDM
... I get a key and decrypt
... or a few others, so I create a connection to the CDM
... CDM can make a call to get the right keys to the
client
... This part doesn't really matter - how the keys get created
by the CDM
... I don't understand how this impacts apps

ddorwin: It comes down to wanting
to release a single key driven by the app and impact the whole
session

pal: doesn't the api support
this?

joesteele: But this starts all
over
... I'm done releaseing the license for a movie the only way is
to release them all

ddorwin: joe wants to release
some but not all keys

joesteel: The CDM can tell the
app to release specific keys
... The spec says to release all keys

pal: I'm just trying to
understand

ddorwin: I don't think the spec
states this..

others agree in the room

glenn: But the app has no
'hints'

pal: The current spec doesn't
block this..
... are we missing arguments in the release call itself?

boblund: If the you want to
persist some information then the CDM needs some
information

ddorwin: Their is ambiguity in
this and they exploit this ambigutiy we have interop
issues
... We are seeing this in real places that breaks interop
... This is even using the simple model that makes a Chrome,
Microsoft and Adobe app not work when they should
... I want to point out that it's not just about API
compliance, it's about the behaviour you get
... So we need to not have this ambiguity

<joesteele_> +q

ddorwin: I have seen in
production this breaks interop and solve behaviour compliance
and not just the API compliance

markw: I think that ddorwin if
correct that removing complexity is the way to go

<joesteele_> my goal is to
*hide* the complexity not to expose it

markw: The whole point about EME
was to make this easy and simple which will address interop on
various devices

<ddorwin> I agree with what
Mark said above.

boblund: I agree with markw that
EME should make things as simple as possible
... But if we don't suport uses cases that are used today we
are not going to get broad adoption

niels_t: from my analysis side
channel communication will help interop and enable broad
adoption
... I don't know the limits where a specific interop issue will
arise with side channel

ddorwin: This won't work with
current EME and impacts privacy and security (CORS)
... part of the spec process is to respect normal web security
and privacy

glenn: since we have not speced
the UA to CDM nothing is preventing the UA to create
issues
... maybe it's not a problem between CDM and UAs
... I think their are options here

pal: I'm trying get to the actual
spec, let's talk about release
... is their a problem with release as spec'd

joesteele: Yes it needs to be
more specific

pal: It's spec'd as a hint...

joesteele: I have seem that this
has become more than a hint and impacts a CDM
... The last thing I wanted to point out was that adding
support for domains increase complexity
... We just need text in the spec that either says this is OK
or gets specific
... leaving this in the domain in the CDM

paulc: are their any specific
bugs to change the release method?
... Because I don't see them..

joesteele: Not in the bug just in
the email

paulc: Let's try to continue on
the agenda and assume when we get to the related bug later to
skip over since we had a good discussion about this issue

<joesteele_> q:

Bug 25267 - Remove ability for in-memory
sessions to be re-used

dorwin: I think we need to have
more consistent behaviour
... when doing adaptive streaming you can get the same keys,
over and over
... which will create new media sessions
... So this text was added to just re-use an existing
session

Paulc: is related to 25268?

ddorwin: I'd like to find a new
way other than this bug..basically if we fix bug 25268 it
should resolve this issue

scribe: basically you end up with
multiple net requests...
... it doesn't sound like this woudl be a complete fix

ddorwin: 25268 is the biggest
issue for EME app devs..

Bug 25268 - Reduce the burden on applications
to dedupe initData from

ddorwin: what is an app to do?
simplest is to ignore but is key system specific
... the goal is to allow the app to know what to do...
... The previous misses some cases
... It pretty complex for an app to deal with..
... and might break down with key rotation
... even in the previous bug you'll end up with hundreds of
sessions which is not good

Bug 25269 - Add a container-independent
initialization data type for

ddorwin: nothing fundemental says
that the keys must come from the media
... basically it's container independent structure for keys or
psh systems
... the license request should not be restricted by a container
format
... simple just need to make it accessible via javascript
... herry was asking why psh's are even needed?

joesteele: The reason I brought
this up - not that this is a bad idea
... How would one support this for content that exists
... the only mechansim for how I would support tihs would be to
make a new request and I would get the actual psh
... which leads to what is in the session, since thie psh is
now part of the session
... It's not a bad idea but I don't see how this would work for
DRM's that use pshs

ddorwin: This is part of
accepting using EME

joesteele: This is fundemental to
how DRM exists today

ddorwin: If an app wants to do
this then their key systems needs to support this but it's not
required.
... We are not replacing PSSHs
... adrianba has a nice change in the spe

We would add a new item but all of these are
optional, just like webm or cenc

paulc: any more need to
discuss

joesteele: doesn't seem to do
damage but doesn't seem to support my DRM system
... what is missing?
... we would need to have more information in the session

ddorwin: you can do this
today

adrianba: The one question I had
was the for the other intitData types, we talk about how they
get called
... is this just for call createsession with?
... it sounds like a good solution when you get keys from a
manifest
... so it seems reasonable

pal: we discussed this in the
past that was simalar
... for example some css transformation may not be
available
... seems like we don't have a way to inform the app what is
available, permitted or not permitted

glenn: no real way to do this in
general - some terrible poor hueristics

markw: the multiple key thinks
looks like a hack

paulc: we'll just continue the
dialog in the bug, please add your comments to the bug

Bug 25200 - Add optional "licenseType"
parameter to createSession()

ddorwin: I was going for the
normal streaming case as well as persisted (offline on a
plane)
... app needs to tell drm what it wants - save to play later
(offline) for example
... The others are TBD or other session types...

paulc: we have a long email
thread, is the related?

ddorwin: I tried to clarify that
I am trying to solve the offline case, though other cases are
being discussed
... I'm trying to get back to the main use case and then from
their we could potentially build on the enum
... to support other use cases

adrianba: The message signature -
I'd like a dictionary, since I'm worried we need to add another
param later

ddorwin: the point of this is to
make it obvious so as long as the dictionary is specific

joesteele: I wanted to add one
more, I'm more conserned about persistance to not keep request
access
... but I do support the dictionary proposal from adrianba

ddorwin: The type may have more
information if it's persisted or no (flags)

markw: will the server need do
anything differenent?

ddorwin: I'm aware of two
cases...

joesteele: if it's an open device
(kiosk) the app may want to NOT persist stuff
... it's really about providing a hint

ddorwin: the goal is to allow an
app to make a specific request
... multiple systems have this in the request today

Markw: asking question...
... I don't disgree with the proposal, but I don't think in
your case we want to use the persistance
... it might be temporary but you my still have a persistent
session even though the license and keys were temporary

ddorwin: yes

paulc: Lets' see if we can talk
about content editable during the IAB talk from 14:00 ->
15:00
... We need to discuss when EME TF wants to meet - maybe next
tuesday

dorwin: we need people to respond
first to make session

paulc: maybe the EME folks can
meet today and work on these issues working F2F

room agrees to take advantage of F2F to
discuss more about these EME issues and make more progress

paulc: It would be great to take
simple notes and send to the group

We are now breaking for lunch and will meet
back at 13:00 (DOM4 stuff)

DOM 4 test results and features at risk

<darobin> Elements interface
(whole section), query/queryAll

<darobin> ArrayClass extended
attribute

<darobin> append/prepend

<darobin>
before/after/replace

<darobin>
MutationObservers

robin: we have a small set of
features at risk.
... I"m not sure that these aren't supported, but I'm sure that
we don't have enough tests to prove it
... the first 2 are known failures
... the last 3 are new things where we don't have enough
tests

pc: robin was to prepare a
candidate cr, with changes to red text. we didn't set a date
for that
... we proposed a min length of 30 days for cr. we also
identified 5 items at risk
... we also need to have a meeting with the director. when do
we want to do that, and do we want to do them together?

robin: don't think we need to
coordinate publications, but a single meeting would be ok.

pc: a phone call with Ralph may
be enough
... I will also send an announcement to the chairs list
... will you do a page, like we have for canvas, that explains
the bad results?

kris: the features at risk,
mutation observers are in a different class than append and
prepend

plh: class?

kris: I don't think any browsers
support append/prepend. we have some tests for mutation
observers, and mozilla has an implementation
... if you write a test for mutation observers, you may find it
exists. not so for append/prepend