HTML Media Task Force Teleconference

30 Jul 2013


See also: IRC log


glenn, davide, paulc, pladd, joesteele, ddorwin, BobLund, +1.310.210.aaaa, jdsmith, [IPcaller]
John, Simmons


<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


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


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 ammended 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 extrat 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



<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)


<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


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

rrsagent: generate minutes

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


trackbot, bye

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-07-30 16:07:59 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/m ethat/me that/
Succeeded: s/senses/sense/
Succeeded: s/more though/more thought/
WARNING: Bad s/// command: s/8\/16/8\/6
WARNING: Bad s/// command: s/8\/16/8\/6/
Succeeded: s/respding/responding/
WARNING: Bad s/// command: s/8[/]16/8//6/
Succeeded: s/ends this week/ends next week/
Succeeded: s/does is/does it/
Succeeded: s/N request/N requests/
Succeeded: s/concern that you/ddorwin: concern that you/
Found Scribe: joesteele
Inferring ScribeNick: joesteele
Default Present: glenn, davide, paulc, pladd, joesteele, ddorwin, BobLund, +1.310.210.aaaa, jdsmith, [IPcaller]
Present: glenn davide paulc pladd joesteele ddorwin BobLund +1.310.210.aaaa jdsmith [IPcaller]
Regrets: John Simmons
Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0020.html
Found Date: 30 Jul 2013
Guessing minutes URL: http://www.w3.org/2013/07/30-html-media-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]