{minutes} HTML WG media telecon 2013-07-30 - EME status and bugs discussion

http://www.w3.org/2013/07/30-html-media-minutes.html

Joe Steele
steele@adobe.com<mailto:steele@adobe.com>


________________________________

[http://www.w3.org/Icons/w3c_home]<http://www.w3.org/>

HTML Media Task Force Teleconference
30 Jul 2013

Agenda<http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0020.html>

See also: IRC log<http://www.w3.org/2013/07/30-html-media-irc>

Attendees

Present
glenn, davide, paulc, pladd, joesteele, ddorwin, BobLund, +1.310.210.aaaa, jdsmith, [IPcaller]
Regrets
John, Simmons
Chair
paulc
Scribe
joesteele
Contents

 *   Topics<http://www.w3.org/2013/07/30-html-media-minutes.html#agenda>
    *   Agenda<http://www.w3.org/2013/07/30-html-media-minutes.html#item01>
    *   previous minutes<http://www.w3.org/2013/07/30-html-media-minutes.html#item02>
    *   review of actions items in the agenda<http://www.w3.org/2013/07/30-html-media-minutes.html#item03>
    *   EME status and bugs<http://www.w3.org/2013/07/30-html-media-minutes.html#item04>
    *   bug#21854<http://www.w3.org/2013/07/30-html-media-minutes.html#item05>
    *   bug 21855<http://www.w3.org/2013/07/30-html-media-minutes.html#item06>
    *   ACTION-25<http://www.w3.org/2013/07/30-html-media-minutes.html#item07>
    *   bug 17673<http://www.w3.org/2013/07/30-html-media-minutes.html#item08>
    *   bug 17750 (action-27)<http://www.w3.org/2013/07/30-html-media-minutes.html#item09>
    *   bug 18515<http://www.w3.org/2013/07/30-html-media-minutes.html#item10>
 *   Summary of Action Items<http://www.w3.org/2013/07/30-html-media-minutes.html#ActionSummary>

________________________________

<trackbot> Date: 30 July 2013
<paulc> trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<trackbot> Date: 30 July 2013
<paulc> Looking for a scribe!
<scribe> Scribe: joesteele
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0020.html
Agenda
previous minutes
<paulc> http://www.w3.org/2013/07/16-html-media-minutes.html
paulc: don't believe anything specific -- actions have been carried forward
review of actions items in the agenda
<paulc> ISSUE-1?
<trackbot> ISSUE-1 -- Consider moving the Clear Key definition into a separate specification -- raised
<trackbot> http://www.w3.org/html/wg/media/track/issues/1
paulc: standing issue we plan on dealing with later
EME status and bugs
<paulc> Editor's draft: http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
paulc: editors draft has not been updated since July 16th
<paulc> Outstanding bugs: http://tinyurl.com/7tfambo
paulc: as of yesterday - 15 bugs
bug#21854
paulc: david replied this morning
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854#c16
ddorwin: a few minor tweaks about error state , ready state
... discussion of keyadded versus keyready -- don't think keyadded needed
... seems to me that every transition has an event so attribute would be a duplicate
<adrianba> i think it is common to have such a state
<adrianba> look at XHR or FileReader
<adrianba> but can easily live without it
joesteele: agree with adrian - can generate from events if needed
paulc: enough information to generate the proposal?
<adrianba> it's a useful debugging tool and not much effort to implement
ddorwin: this is adrians proposal, responding to adrians comments about XHR
... believe that is the ready state event? thought this meant it was a duplicate
paulc: since folks can live without it - does Adrian have enough information?
rrsagent: generate minutes
paulc: Adrian?
<adrianba> i think so
<adrianba> at least to make progress
<ddorwin> adrianba: re: XHR example, are you referring to readystate? readystatechange reflects a change in this event. This seems to be different from the proposal, which has a separate event for the transition into each state.
paulc: note in the minutes that Adrian will implement as amended by conversation this week and last week
bug 21855
paulc: dependent on 21854 - have a current comment
<paulc> Latest: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21855#c6
<adrianba> well, XHR has a readystate variable as well as events - sure the model is slightly different, but it is arguably the same duplication
<adrianba> FileReader is the same
<adrianba> I think WebSocket is the same
ddorwin: not opposing, asking questions
... some concerns I have are if you call createSession every time, you will have extra session objects in memory that serve no purpose
... also this is CDM specific behavior
<adrianba> image element fires load event and also has a status to say if it is loaded
ddorwin: apps might need to have to deal with this
... we are sharing underlying sessions or keys
... so we need to describe how they translate to actual key and session objects
paulc: lets split out the diff questions
<paulc> Are all such objects treated as identical? If not, what is the expected behavior?
pauc: do you have an answer?
ddorwin: no -- posing the question
<paulc> We are assuming: Sharing underlying session/keys among MediaKeySession objects raises some interesting questions.
joesteele: think it would be very lightweight -- is that your thinking
ddorwin: still a memory leak
... for TV playing and playing -- might never go away
joesteele: makes sense
paulc: any answer? or can we move on?
<paulc> Can update() & close() be called on any of them?
<adrianba> you can only call update with a response to a keymessage on a given session
<adrianba> there has to be a correlation
ddorwin: I assume it would impact all of them
... you should call update on whoever called keymessage
<adrianba> you may not get a keymessage if you go straight to READY
ddorwin: may be other times when the app calls update
<ddorwin> is a keymessage is fired after READY (i.e. for renewal), one of the sessions should get the keymessage
<ddorwin> also, as joesteele says, update() can be called not in response to a keymessage
joesteele: we could use this as a channel for providing info from app to CDM so update could be called at anytime -- assuming this is allowed
<paulc> - Which MediaKeySession objects will receive keymessage events (i.e. for renewal)? What about keyerror events?
joesteele: assume that ALL of the objects would get them
ddorwin: probably only fire at one object
... this would make N requests to the server
<adrianba> you should not get keymessage events to all the sessions
<adrianba> that's the problem we're trying to solve
<adrianba> you only need one keymessage event
<adrianba> because you're only going to perform one network interaction
<adrianba> if you fire against all sessions then you don't eliminate the network connections
ddorwin: may be talking about diff things -- I am assuming a single application
... those would all be session objects for the same MediaKeys on the same MediaElement
... yours seems to be re-using offline or saved keys
joesteele: good example - I was thinking of the domain key model where a domain key is shared between two applications
ddorwin: not a key?
joesteele: I am talking about an actual key -- acquired by both applications
ddorwin: close on that might be different
... concern that you would be getting two types of keys in the same session
paulc: what do you think happens on close?
joesteele: think the keys are ref-counted -- would close as session is closed
ddorwin: question -- would domain key be saved only for the lifetime of the session?
<paulc> Who just joined as +[IPcaller]?
joesteele: could be stored or could stay around only as long as a session is using it
... concern with keeping multiple instances of keys around in memory if needed
paulc: need answers in the bug to further resolve this
ACTION-25
ACTION-25?
<trackbot> ACTION-25 -- David Dorwin to and John S to work on corner cases for bug 17673 -- due 2013-07-19 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/25
bug 17673
paulc: related to action above
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c14
paulc: David, added lots of comments, are these implementation comments - would they allow someone to support this?
ddorwin: someone will have to deepdive into ISOBMFF
... some of this is specific changes to proposed text
... rest is more general issues
paulc: we expect John SImmons to be engaged here right?
ddorwin: yes
paulc: maybe we should wait until John comes back from leave
ddorwin: yes - need Johns feedback
paulc: leave action item open
... move date forward?
<paulc> ACTION-25 is due Aug 13
action-25 due 08-13-2013
<trackbot> Set ACTION-25 And John S to work on corner cases for bug 17673 due date to 2013-07-19.
bug 17750 (action-27)
action-27?
<trackbot> ACTION-27 -- Adrian Bateman to add comments to bug 17750 summarising the recent discussion of close -- due 2013-07-09 -- CLOSED
<trackbot> http://www.w3.org/html/wg/media/track/actions/27
paulc: don't believe any responses to Adrian yet
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750#c5
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750
paulc: any responses? looks like no
ddorwin: might have been looking for Marks input as well
... don't have any comments other than that
bug 18515
paulc: discussed on July 2nd
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515
paulc: is this worth spending time on now?
ddorwin: responding to Joe's comment
... behavior would be the same - not planning to change the state
... just need to figure out how to implement
paulc: so you need to make a proposal or the change -- do you need more information?
... see Joe's last question
<paulc> But I am not sure that fully answers the questions I raised. Does this mean the media element remains in the HAVE_FUTURE_DATA state forever? Or can the CDM signal that it has determined that the proper key will never be acquired and therefore playback should be stopped and an error reported?
ddorwin: not really in that state -- just behaving like that
joesteele: that makes sense - but would like to know how to determine this
ddorwin: not sure we can track this
... media element starts playing when it has keys and pauses when it does not have them
... if we want an indication -- need to add something to the spec
... some text that says media element is waiting for a key
... follows some other non-identifiable states in the media element spec
... don't actually have a state or event for this
... this would be a media element state
... not clear what you would do with it?
... please bring forward a proposal on what you would use it for
joesteele: I will propose something in the bug after some more thought
paulc: no more bugs today -- discuss scheduling
rrsagent: generate minutes
paulc: CFC out right now for taking MSE to Last Call -- ends next week
... nominally MSE would meet next week on the 6th, but only two LC bugs to deal with and I am not available
... could stay with same schedule -- MSE call occurs or not next week
... or could do more work on EME right now -- I will prep agenda and we can make more progress on the bugs
... concerned that we are not making progress outside the meetings other than David
... need to decide what the right mtg schedule is
... any holidays coming in August?
ddorwin: not anything major
paulc: Aaron is away this week
... does it make sense for EME to meet next week?
joesteele: I would prefer to meet next week
glenn: should stay on EME and get the bugs down
joesteele: I meant EME
jdsmith: agree -- it would be good to focus on EME
ddorwin: most of the work is offline I think at this point - hard to discuss on a telecon
paulc: before mtg, sent a note to the editors on asking for help on bugs to process but never heard back from Mark or Adrian
... are you saying these are outstanding because they are hard?
... can you live with trying to meet next week? and editors could pick one or two to close?
ddorwin: yes
<paulc> Schedule: EME will meet on Aug 6 and Aug 13
paulc: I will propose we meet on both 8/16 and 8/13
<paulc> That means MSE misses one meeting on Aug 6
<paulc> And we will decide later who meets on Aug 20.
paulc: will resend the editors msg -- but anyone can propose bugs to discuss at next meeting
... or make a comment on a bug -- this will push to the top
glenn: may be some bugs that have been pushed off because they are not getting a lot of attention but could be dispatched quickly
paulc: not assuming that, hoping for editors to tell me that
... so unless someone nominates something specific we do them in reverse order?
glenn: yes
paulc: will work with the editors to determine the order
ddorwin: let me know if one is trivial
paulc: will do an agenda but won't be here next week
... thanks all!
... we are adjourned
Summary of Action Items
[End of minutes]
________________________________
Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.138 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2013-07-30 16:07:59 $