HTML Media Task Force Teleconference -- 21 Jan 2014

<trackbot> Date: 21 January 2014

<ddorwin> zakim I am aabb

<JamilEllis> list attendees

<paulc> scribenick: johnsim

Action items and Issues

<paulc> ACTION-48?

<trackbot> ACTION-48 -- Adrian Bateman to Draft a proposal for bug 17673 -- due 2014-01-21 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/48

adrianba: in light of David's comments we still need to have more discussion at Microsoft about what we think we want to do, specifically around the point that it is not feasible to tell if a particular encoding of ISOBMFF is supported
... also consequences for "istypesupported" - additional argument - but haven't had time to discuss in detail

paulc: this item is on top of the list and blocks 24207 - need to decide if we are blocking on heartbeat until we get this item done.

adrianba: direction the discussion is going may invalidate the discussion at TPAC

<paulc> ACTION-48 is due next week

<adrianba> ACTION-48 due next week

<trackbot> Set ACTION-48 Draft a proposal for bug 17673 due date to 2014-01-27.

<adrianba> ACTION-51?

<trackbot> ACTION-51 -- Jerry Smith to Write a proposal for bug 18515 -- due 2014-01-20 -- CLOSED

<trackbot> http://www.w3.org/html/wg/media/track/actions/51

EME heatbeat priority items

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

<paulc> ACTION-48?

<trackbot> ACTION-48 -- Adrian Bateman to Draft a proposal for bug 17673 -- due 2014-01-27 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/48

paulc: assume that action 48 is pertinent here. Comments 36 and 37 were made since the last meeting

b) Bug 24027 - Define a generic Initialization Data solution for ISO Base Media File Format and/or Common Encryption (will be used by Clear Key) https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027

paulc: assume nothing to discuss about this until we do the dependent bug
... should we stick with David's proposal that they block a heartbeat

<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027#c1

ddorwin: we can start working on what we would like to be in it. for cenc it should be a pssh. the format of pssh can be discussed if not decided

paulc: anyone willing to put a proposal on the table as reflected in comment 1 - shape of pssh boxes for clear key

<paulc> "this bug boils down to defining the shape of PSSH boxes for ClearKey and defining the ClearKey identifier for CENC."

ddorwin: good for people to at least think about - what do they want in this besides the ability to have some number of KIDs - other things we should allow for in the format

<Zakim> adrianba, you wanted to talk about heartbeat

adrianba: heartbeat draft - i think that David's list is good aspiration - and identify the changes in backlog which are likely to be the most impactful

paulc: chairs busy with other docs - give task force this week and next week - but would like to see us moving forward with a consensus in the task force.

joesteele: good to know how long until the following heartbeat

paulc: no maximum time between heartbeats but working group is trying to get things out every 2-3 months, reasonable to execute on David's list today and next week, a little concerned about amount of editing
... reasonable to wait until next week and see where we stand. but if we don't have proposals on the table we are simply blocked.
... willing to action on 24027?

<joesteele> nothing to add to what David has suggested

<paulc> ACTION: johnsim to provide a proposal for bug 24207 to define the shape of CleanKey PSSH boxes [recorded in http://www.w3.org/2014/01/21-html-media-minutes.html#action01]

<trackbot> Error finding 'johnsim'. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.

<adrianba> ACTION: john to provide a proposal for bug 24207 to define the shape of CleanKey PSSH boxes [recorded in http://www.w3.org/2014/01/21-html-media-minutes.html#action02]

<trackbot> Created ACTION-63 - Provide a proposal for bug 24207 to define the shape of cleankey pssh boxes [on John Simmons - due 2014-01-28].

c) Bug 24227 - Rename "closed" event to "close" https://www.w3.org/Bugs/Public/show_bug.cgi?id=24227 Status: Discussed at Jan 14 meeting with no objections: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24227#c1

paulc: fixed since yesterday - this morning

d) Bug 23619 - Change MediaKeyError to extend DOMError and use strings for error names https://www.w3.org/Bugs/Public/show_bug.cgi?id=23619 Status: Current proposal summarized in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23619#c7

paulc: there is a proposal in comment 7, we discussed very briefly last week

<paulc> Depends on https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798

ddorwin: waiting to define the errors - but can be implemented without the actual errors

paulc: this is on the editor's list?

ddorwin: i believe so

<paulc> Error code discussion is at: http://lists.w3.org/Archives/Public/public-html-media/2013Nov/0011.html

paulc: minimum required for heartbeat is what David described above

Simplifying how InitData is identified

<paulc> http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0037.html

paulc: any comments on this thread? Sitting dormant since Jan 14
... this is dependent on what we do on action 48?

<paulc> Related to the outcome of 17673 and ACTION-48

adrianba: i think they are tied together
... i want to figure out what our roll-up position is, and have more discussion with people like david singer

glenn: is this related to representation of initdata or identification of parameters in the initdata?

adrianba: not sure i understand question - bug action 48 relates to is to update the text to provide any of the boxes associated with encyrption in the initdata, not just the pssh boxes
... this bug - when need key fires - rather than saying this is video mp4, which says ISOBFF, but not anything about the form of the encryption, it says it is common encyrption, but then only needs to include pssh boxes
... and if a different type, alternate encryption, then the identifier would be different -

joesteele: only two types, common encryption and other?

adrianba: i think we are saying there would be one format for BMFF (cenc) and something for webm format but don't have another, but if in future for alternative string for that type, what the initdata would look for that
... we touched on this last week - we will end up following what we did with MSE and remove the description of formats into separate document with informal registry like we have for MSE and then you would create a new entry there

joesteele: sounds like this change would be from the browser to the application, would there be a parallel parameter in the createsession?

adrianba: need key event fires and content type is video mp4, and provides initdata - originally pssh boxes - but discussed at TPAC adding senc information -
... then you call createsession, you specify the format there and that indicates the form of the initdata - so matching between those two
... ddorwin has raised the issue - even if we made the change for senc - more schemes than common encryption - probably insufficient interface to determine if a browser supports a particular decryption scheme
... no way for the browser to say "yes for common encryption but no for something else" so we might have to revisit istypesupported()

new bugs

a) Bug 24322 Reorganize spec by object https://www.w3.org/Bugs/Public/show_bug.cgi?id=24322

ddorwin: just a tracking bug, to get spec organized more like mse

<adrianba> i think this is a good idea - i find it difficult to find things in the spec - but it is editorial only so holding is fine

paulc: this item is just on hold for now?

ddorwin: yes

paulc: any questions on this item. No.

b) Bug 24323 - Rename "First Time a Key Reference is Encountered" algorithm and remove key ID checks from Container Guidelines subsections https://www.w3.org/Bugs/Public/show_bug.cgi?id=24323

ddorwin: noticed we still reference - whether key id is encountered in webm - and then found algorithm was named different from what we intended
... question is what the first algorithm should be - needkey is always fired now - but the real question - indications of encryption which are not initdata -
... so the alternative would be - when initdata is encountered - the real question do we want real flexibility or ease to implement

paulc: two sub-proposals

ddorwin: #1 is the only one which is a question about the algorithm.

<paulc> Should we require Initialization Data and that encountering it be the first indication that the stream may be encrypted?

joesteele: if i am understanding correctly, i would argue for more flexibility here

ddorwin: question is what do you do if you fire needkey event without initdata

joesteele: fire needkey with initdata i had in my back pocket

ddorwin: algorithm is for when to fire needkey

<ddorwin> algorithm we're discussing: https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#algorithms-encrypted-stream

<paulc> ack [Microsoft]

paulc: don't have anything further to do on this bug - it would really help if people looked at 24323 and supplied answers

EME bugs with proposals

a) Bug 24081 - The READY state is too limiting and should be more like the PENDING state https://www.w3.org/Bugs/Public/show_bug.cgi?id=24081#c2 Status: See Jan 18 proposal in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24081#c4

paulc: is this a "well formed proposal" or lurking questions?

ddorwin: i guess well formed but not a definitive proposal

paulc: strawman?

<adrianba> we're still discussing this at Microsoft

ddorwin: we could do this but need feedback

paulc: put this on next week's agenda.

jdsmith: previous discussion - at the time you wanted to fire an update on ready when you already had keys but proactively renewing for a future date. not sure if the current model was broken.
... could you clarify if there is a hard blocker here?

ddorwin: mainly, do the states make sense. we probably could work around the current model and make the proactive model work, but what is the value of pending versus ready
... why am I on pending and when should the ready event get fired.

jdsmith: need to sync with johnsim on this proposal.

<paulc> State diagram is near: http://www.w3.org/TR/encrypted-media/#media-element-restictions

<ddorwin> Direct link: https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#session-state-transitions

b) ACTION-51: Write a proposal for bug 18515 [Jerry] http://www.w3.org/html/wg/media/track/actions/51 Status: DONE. https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c16

paulc: from what i can see there are not any responses

jdsmith: the issue of that proposal is you have a situation where you need to renew keys and haven't received updated keys but played all the data,
... waiting even from media element, but we have discussed is using the waiting event to be waiting on a media key
... proposal is to declare what you are waiting for - media or media keys

paulc: david or mark, have you reviewed this proposal?

ddorwin: what we discussed, need to read through details and get feedback internally

paulc: carry this forward to next week's meeting (Action 51 - bug 18515)

Other EME bugs

a) Bug 24216 - setMediaKeys() needs more specification https://www.w3.org/Bugs/Public/show_bug.cgi?id=24216 Status: Adrian indicated that Jerry was looking at this bug in the Jan 14 meeting.

b) Bug 24270 - MediaKeySession State Definitions should be normative https://www.w3.org/Bugs/Public/show_bug.cgi?id=24270 Status: Adrian agreed to update the bug from discussion on Jan 14.

<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=24270#c2

paulc: others can look at that entry - i don't have anything else on the agenda. Any other issues/bugs to discuss? About 19 outstanding bugs, we have touched on 11 today - maybe 12
... propose we adjourn and meet again next week with EME bugs as our major agenda

- DRAFT -

HTML Media Task Force Teleconference

21 Jan 2014

Attendees

Contents