W3C home > Mailing lists > Public > public-html-media@w3.org > September 2012

{minutes} HTML Media telecon 2012-09-18

From: Joe Steele <steele@adobe.com>
Date: Tue, 18 Sep 2012 09:39:14 -0700
To: "<public-html-media@w3.org>" <public-html-media@w3.org>
Message-ID: <89A16DFF-A94C-4910-BE9F-6771017495D7@adobe.com>
The minutes from today's teleconference are available in HTML here:


or in plain text below:


      [1] http://www.w3.org/

                               - DRAFT -

                  HTML Media Task Force Teleconference

18 Sep 2012


      [2] http://lists.w3.org/Archives/Public/public-html-media/2012Sep/0015.html

   See also: [3]IRC log

      [3] http://www.w3.org/2012/09/18-html-media-irc


          markw, Matt, Clarke, ddorwin, paulc, adrianba,
          [Microsoft], +1.408.536.aaaa, joesteele, johnsim, pal,




     * [4]Topics
         1. [5]Agenda
         2. [6]Minutes from Sept 4
         3. [7]Review Action Items
         4. [8]Baseline docs and Bugzilla info
         5. [9]Actions from previous meeting
         6. [10]Unresolved Bugs
         7. [11]Other Bugs
     * [12]Summary of Action Items

   <trackbot> Date: 18 September 2012

   <whadar> hi

   <adrianba> ScribeNick: joesteele


Minutes from Sept 4

   paulc: make sure we get the attendees correct

Review Action Items

   paulc: on the agenda

Baseline docs and Bugzilla info


     [13] http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

   paulc: did click on the link -- did not look like it has been
   worked on

   ddorwin: added some update last night

   paulc: encrypted media bugs have more open now
   ... regressed a bit?

   joesteele: I reopened a few

   <paulc> [14]http://tinyurl.com/7tfambo

     [14] http://tinyurl.com/7tfambo

   paulc: added those bugs to the agenda

Actions from previous meeting

   paulc: any progress?
   ... Action 2?

   <paulc> ACTION-2?

   <trackbot> ACTION-2 -- Mark Watson to propose a resolution to
   bug 17673 -- due 2012-08-17 -- CLOSED

   <trackbot> [15]http://www.w3.org/html/wg/media/track/actions/2

     [15] http://www.w3.org/html/wg/media/track/actions/2

   johnsim: not at this time now

   paulc: ETA?

   johnsim: should have something this week
   ... spent some time on the common key question

   [16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673 is
   assigned to John Simmons. No progress at this time

     [16] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673

   <adrianba> ACTION-3?

   <trackbot> ACTION-3 -- John Simmons to propose resolution to
   bug 17682 -- due 2012-09-11 -- OPEN

   <trackbot> [17]http://www.w3.org/html/wg/media/track/actions/3

     [17] http://www.w3.org/html/wg/media/track/actions/3

   paulc: last time we changed the due date for this to Sept 11
   ... john you mentioned you did some work


     [18] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17682

   johnsim: did some research, adrian and I discussed this

    there is some lack of clarity on how the key is used

    up till now discussed as a key acquiisition proposal

   johnsim: but how do you use that key?

    assumption is by examination of the media

    ISO based format, Common Encryption Format, etc.

    would know intrinsically how to handle it

    problem with this approach is that if goal is to produce
   interoperable solution between browsers

    common encryption modality without reference to DRM

    how do you assure that all the browsers understand the
   different media types?

   johnsim: need to understand the intent behind clearkey

    we can consider it good if it only handles key acquisition

   scribe: but if goal is to create an interoperable solution, we
   need to be normative about the encryption

    modes algorithms etc.

   ddorwin: intent was the latter
   ... at the encryption level as well

    could call AddKey multiple times

    AES-128 CTR seems to be common, if there are containers that
   do not specify that we need to deal with that

    WebM does not need to specify that? (please correct if I

   johnsim: if you don't know that it is encrypted it will just be

   ddorwin: container format specifies how it is encrypted

   johnsim: container level encryption is not covered by this spec

    i.e. HLS

    so the media stack can always determine the type of
   encryption to be used

   ddorwin: that was the intent -- have not thought deeply

   adrianba: think this is slightly different than what john

    clearkey should work the same way for content encrypted at
   the container format

    if possible for other DRMs

   <adrianba> clear key should be as usable with media files as
   with a DRM system

   <adrianba> if the media format supports envelope encryption
   (e.g. HLS) then this would also work with Clear Key

   johnsim: if it is container level encryption - the CDM will not
   be able to examine the container to determine how the
   encryption was performed
   ... you could set up a mime-handler that knows how to handle it
   ... does not seem like this was envisioned to support container
   level encryption
   ... does not seem practical to implement clearkey for container
   level encryption

   adrianba: I think as interoperable code you have to understand
   how the format works in either case

    this is related to a later agenda item

    being able to start the key request without knowing the
   content/media type

    think we need to understand the media type to be able to fire
   up the approp. CDM

    need indicator of what is encrypted and how

    this will need to be defined normatively somewhere

   paulc: high level comment -- sounds like this should be written
   down in an email thread

    need a wider group to review it

   ddorwin: it was intended to be clear that the container
   specifies this stuff
   ... what john was talking about should be separate from
   clearkey -- e.g. needKey event is independent fro a key system

    for any of these events we want to be commonly supported need

   <adrianba> ACTION-3 due in 1 week

   <trackbot> ACTION-3 Propose resolution to bug 17682 due date
   now in 1 week

   paulc: moving on. need to extend ACTION-3
   ... ACITON-4

   <adrianba> ACTION-4?

   <trackbot> ACTION-4 -- David Dorwin to propose a solution for
   bug 17672 -- due 2012-09-18 -- CLOSED

   <trackbot> [19]http://www.w3.org/html/wg/media/track/actions/4

     [19] http://www.w3.org/html/wg/media/track/actions/4

   ddorwin: added a new section 7.1

    rest of the document is container independent


     [20] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17672

    defines how WebM is encrypted


     [21] http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#webm

   paulc: is this what is needed?

   ddorwin: yes, content is correct

   paulc: marked as RESOLVED, FIXED


   <trackbot> ACTION-5 -- Mark Watson to follow-up on Key Release
   mail thread now that the OO changes have been made - discuss on
   next call -- due 2012-08-28 -- CLOSED

   <trackbot> [22]http://www.w3.org/html/wg/media/track/actions/5

     [22] http://www.w3.org/html/wg/media/track/actions/5

   paulc: have not checked whether this is done -- no record of
   emails on it
   ... not sure what the status is -- was assigned to Mark?
   ... Mark can you update us?

   markw: no followup yet, have some notes in the bug itself I


     [23] http://lists.w3.org/Archives/Public/public-html-media/2012Sep/0004.html

   paulc: don't see an associated bug

   markw: there is a bug for key release


     [24] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199

   ddorwin: posted a link with a proposed solution, next step is
   for Mark to add to the spec


     [25] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199

   paulc: Mark should either respond to the proposal or update the

Unresolved Bugs

   paulc: reopened bugs by Joe

   <ddorwin> previous topic: last email on action 5:

     [26] http://lists.w3.org/Archives/Public/public-html-media/2012Sep/0012.html


     [27] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17470

   <paulc> "Provide specific guidance on when generateKeyRequest
   should be called "

   <adrianba> joesteele: the use case i'm thinking of is for the
   access DRM there are certain keys i can preload ahead of time

   <adrianba> ... there might be a substantial cost in requesting
   the keys that would affect the user experience

   <adrianba> ... i don't know what the media format is going to
   be yet

   <adrianba> ... i can make some guesses

   <adrianba> ... in most cases i probably would know the media
   type but in the general case i don't know the type

   <adrianba> ... but i do know that a particular set of domain
   keys will be needed

   <adrianba> ... so i want to be able to do a key request without
   having seen any media yet

   <adrianba> ddorwin: i think you can create a MediaKeys object
   without a media type

   <adrianba> joesteele: it's not clear where the errors go

   <adrianba> ddorwin: you can create a MediaKeys object and then
   createSession to get a MediaKeySession object and events get
   fired here

   <adrianba> adrianba: is it not true that you need the media
   file format to know the format of the initdata

   <adrianba> ... for example in ISO BMFF we've assumed that
   initdata is a concatenated list of pssh boxes

   <adrianba> ddorwin: i don't think there is initdata in this

   <adrianba> joesteele: that brings up one of the issues, if you
   create a session without initdata then an error is thrown

   <adrianba> ... i'm okay if you have to say there is initdata we
   can fake it up

   <adrianba> ddorwin: the spec says you must have initdata and
   mime type or neither?

   <ddorwin> createSession() may be called with no parameters

   <johnsim> +q

   <adrianba> ddorwin: the algorithm says that if the type is null
   and initdata is NOT null then it's an error - anything else is

   joesteele: I would like to see an example in the spec of how to

   paulc: can you provide the example for us?

   joesteele: ye s-- I will do that

   johnsim: the wording is ambiguous for step 1 of createSession

   paulc: maybe put (or an empty string) in parens
   ... suggest to joe to provide the sample
   ... editors can then decide how to handle


     [28] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17660

   <adrianba> joesteele: this is a related issue

   <adrianba> ... when i asked about authentication at the F2F

   <adrianba> ... i was told it would done at the app level not in
   the CDM

   <adrianba> ... but in the Access case, authentication is bound
   into th ekey request channel

   <adrianba> ... and we have a lot of customers that use this

   <adrianba> ... we think it is more secure than TLS auth

   <adrianba> ... but i don't see another way to pass additional
   parameters down

   <adrianba> ... without having to parse the key data coming back

   <adrianba> ... which we want to avoid

   <adrianba> ... in Access, you would understand that you need to
   do a key request

   <johnsim> +q

   <adrianba> ... and you would get a flag from the DRM system
   saying you need to get auth information

   <adrianba> ... and you might prompt for username password and
   then pass it down into the DRM system

   <adrianba> ... and there doesn't seem to be a mechanism to pass
   that in

   <adrianba> joesteele: this is user authentication

   <adrianba> johnsim: so user credentials associated with the

   <adrianba> joesteele: example: i log in to a web site where my
   queue of videos is but when i play a particular video it has
   credentials from a different service and so now i have to
   provide those to authenticate for it

   paulc: start an email thread pointing back to this comment

    add more details to the question in the comment

   paulc: discussing 17682
   ... this was discussed above under ACTION-3

Other Bugs

   paulc: have a large number of bugs with no progress on them yet
   -- work going on in the background?
   ... would like to know which items we can get done in next two
   ... if so -- can editors propose which ones

   adrianba: a lot of them are related to error which is being

   paulc: what about items we discussed today -- david any others?

   ddorwin: some pending bugs to file ;-)

   <whadar> Considering Media Source Extensions, I would like to
   feedback as a user of the API. There are great benefits of
   having a low-level API that can append bytes. But, the
   implementation underneath should help the developer and even
   defend the developer when setting up a stream and appending
   bytes. Specifically 1) the browser level should help
   understanding the type of CODEC and not require it on init. 2)
   Appending should not necessarily begin at the beginning

   paulc: will watch for those then

   ddorwin: focusing on the implementation bugs

   paulc: mark -- any to queue up?

   markw: should be able to make progress on all of them in the
   next two weeks
   ... assigned to 4

   paulc: we might be stable in two weeks then, with David and
   Mark's work
   ... nothing else on the agenda
   ... Oct 2 is next meeting
   ... should be able to do the next meeting
   ... any other comments?
   ... ready to adjourn

Summary of Action Items

   [End of minutes]

Joe Steele
Received on Tuesday, 18 September 2012 16:39:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:26 UTC