{minutes} HTML WG media telecon 2013-03-26 - EME bug discussion

Available at
 http://www.w3.org/2013/03/26-html-media-minutes.html

Text version:

                  HTML Media Task Force Teleconference

26 Mar 2013

   Agenda
http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0064.html

   See also: IRC log
    http://www.w3.org/2013/03/26-html-media-irc

Attendees

   Present
          glenn, Bin, ddorwin, Plh, joesteele, markw, BobLund,
          MartinSoukup, adrianba, pladd, johnsim, Aaron_Colwell,
          pal, jdsmith, Henri

   Regrets
          Paul

   Chair
          Adrian

   Scribe
          plh

Contents

     * [4]Topics
         1. [5]previous minutes
         2. [6]Action items
         3. [7]Baseline documents
         4. [8]Progression to FPWD
         5. [9]Discussion of outstanding bugs
         6. [10]AOB?
     * [11]Summary of Action Items
     __________________________________________________________

previous minutes

   http://www.w3.org/2013/03/12-html-media-minutes.html

   minutes are approved

Action items

   action-10?

   <trackbot> ACTION-10 -- Adrian Bateman to discuss bug 19208
   with johnsim -- due 2013-04-08 -- OPEN

   <trackbot> [13]Keymessage event not needed when Key System
   already has Key

     [13] http://www.w3.org/html/wg/media/track/actions/10

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


   Adrian: John and I talked about it last week
   ... need a bit more time
   ... the proposal we'll make is related to a discussion we had a
   few weeks ago avbout the lifetime of a session
   ... there are some suggestions we want to make about session
   management
   ... different from what the spec is suggesting at the momnet

   Adrian: so we'll need to come back on this

   Joe: I did update a related bug...
   ... [never mind]

Baseline documents

   Adrian: those are just links
   ... no update since the previous discussion
   ... not sure where the Chairs are at for the moment
   ... waiting on feeback from Paul

   plh: I don't know the status from the Chairs point of view
   either

Progression to FPWD

   Adrian: see above

Discussion of outstanding bugs

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

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

   <adrianba>
     [16]
http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0070.html

   Adrian: David made a proposal

   [17]SessionID may be assigned asynchronously in
   MediaKeys.createSession

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

   Mark: we already have a mention that the sessionID may be
   assigned by the CDM
   ... we want it to be async
   ... so the sessionId might not be assigned when the
   MediaKeys.createSession returns
   ... you'll get it on the first event instead

   <MartinSoukup> +1 to require assignment of session ID prior to
   event firing

   ?: is there proposed languagejohnsim

   Mark: not yet

   Martin: I understand that the proposal that the sessionId might
   be assigned before the first event

   Mark: that's right

   Adrian: this might be related that John and I have an action on
   ... if you already have the information about the keys in the
   init state, that might have an impact on when the sessionId
   gets set

   Mark: right, you want to do that async. the spec implies
   otherwise at the moment

   David: if we do go to reusing sessions, then we would already
   have the info.

   Adrian: should there be a serie of events that fire before the
   progress event
   ... that reuse MSE
   ... we could have an event that fires that says that the
   session is open and running
   ... if Mark proposal is before the first event, that would mesh
   with any proposal we would make about progress event

   John: the important part is that we make it async
   ... we can figure out the relationship later

   [18]EME should be explicit about its relationship with Web
   Platform APIs that allow video frames and audio samples to be
   extracted from an HTMLMediaElement

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

   Henri: it seems there are at least two classes of CDMs. one
   that gives the pixel data back to the browser, and one that
   gives it to the GPU
   ... for the later, painting on canvas wouldn't work
   ... for the former, it seems we wouldn't want it to work either
   ... we need to be more explicit about the expected behavior
   ... ie we should cover both cases
   ... if you're writing JS, you should be able to know the
   expected by looking at the spec

   Joe: agreed. I propose that we never pass back the data to the
   JS layer

   Joe: that would introduce too much complexity to the CDM layer
   ... so let's not have that use case

   Glenn: what API currently exist to allow video frame access?

   Henri: pixels can be extracted using canvas. not quite sure
   about the Web Audio API
   ... there are restrictions on canvas due to same origin policy

   Henri: it seems simpler to say that painting to a canvas with a
   non-null media key fails in some fashion

   <acolwell> [19]MediaElementAudioSourceNode allows audio samples
   to be exported to JS

     [19]
https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#MediaElementAudioSourceNode

   Glenn: you're referring to createPattern?

   <adrianba> drawImage ->
   [20]http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/#do
   m-context-2d-drawimage

     [20]
http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/#dom-context-2d-drawimage

   <pal>
   drawImage(document.getElementById("video1"),5,5,260,120,005)

   David: re complexity in passing back the frames from the CDM.
   It depends on the CDM. If it's hardware backed, that's not
   possible. Otherwise, it would be more work to prevent it from
   happening. so not sure that prevention would be the easy
   solution

   Henry: my reading is that it wouldn't be possible in webkit

   Henri: I can live with a resolution that depends on the kind of
   CDM
   ... just want to make the spec is clear on the behavior

   Pierre-Anthony: Is there any value in exposing to the app
   whether the CDM can or cannot expose the data back

   Adrian: is it sufficient for the EME spec to simply that the
   media frame may not be available to other Web platform APIs
   that consume them

   Adrian: it may be possible to do some operations
   ... like transforms
   ... would it be possible to say that some operations may not be
   possible, or should we be more explicit

   Henri: there is to be a well defined failure mode

   Adrian: possibly a no-op

   Henri: if there are CDMs passing the data back to the browser,
   so is it ok for extensions to access it?

   Plh: captioning tracks need to be considered as well

   Mark: it would be useful to have a note on the failure mode(s).
   those methods can fail for other reasons
   ... the CDM might want to restrict what the browser can do

   Joe: re the caption question. we exclude the use case of
   encrypted captions. the captions would always be available.
   ... if the app needs some logic based on the type of CDM, this
   is going to be a huge burden.
   ... if we allow any type of discovery mechanism for the type of
   restrictions, this will get complex. We could add one type of
   error
   ... but more would be complex
   ... if we don't allow to come back, folks would have to
   recompile the browser but wouldn't be able to access the CDM.
   so not an issue.

   Glenn: (1) canvas 2d drawImage/createPattern has language about
   lack of decoability of image (frame), so may want to suggest
   expanding decodability to accessibility; (2) regarding
   caption/subtitles, text tracks can also include other metadata,
   some of which may need to remain encrypted so should be
   particular about which "kind" of text track should be exposed
   to JS in case a CDM is involved

   Bob: I think captioning is a different issue than the video
   frame one. I would imagine captioning would be dealt with in
   the same way as text tracks in general.

   Henri: what I hear about text tracks is scary.
   ... I would rather see the approach that captions are not part
   of the DRM sphere

   Bob: Henri's point is interesting. UA is responsible for
   rendering of captions.

   Bob: we need to think more about the case

   Adrian: two issues:
   ... what should happen to video and audio data? two proposals:
   (1) until we find a use case, no access. (2) leave it up to the
   CDM to impose the restriction or not.
   ... captions are different. Either outside of EME scope, or we
   need to consider them specifically for the TextTrack API.

   David: caption text tracks are outside the scope of EME
   ... no decoding etc.

   Pierre-Anthony: if MSE and EME are supposed to work together,
   how would captions work?

   David: different tracks at the moment and encryption is by
   tracks.

   Pal: but MSE adds segments

   ?: it's multiplexed

   Patrick: captions have requirements about sync with video
   frames
   ... and JS can't keep up for that

   Glenn: 608/708 is embedded in the user data of the video
   stream, and will be encrypted along with the video, like MPEG-2
   streams.

   ?: is that a use case for us? ie will any browser support that?

   Glenn: well, I think it's possible from a functional
   perspective.

   ?: I don't know where the performance requirement is coming
   from...

   Adrian: I'd like to see concrete proposals/bugs
   ... any volunteer?
   ... Joe? Mark?

   Joe: I can try but don't have much bandwidth at the moment

   Mark: at least we need to consider the case where the data may
   not be available and go from there

   Pierre-Anthony: it is possibility that it is not available

   Glenn: it's up to the APIs that give access to describe their
   own failure modes

   ?: the API needs to be able to tell if a failure happened or
   not

   Mark: I'll write a proposal

   <scribe> ACTION: Mark to write a proposal for the case where
   the data is not available to the JS [recorded in
   [21]http://www.w3.org/2013/03/26-html-media-minutes.html#action
   01]

   <trackbot> Created ACTION-11 - Write a proposal for the case
   where the data is not available to the JS [on Mark Watson - due
   2013-04-02].

AOB?

   none

   Adrian: Paul will be back for the next meeting
   ... any volunteer to scribe?

   Joe: I can

   [adjourned]

Summary of Action Items

   [NEW] ACTION: Mark to write a proposal for the case where the
   data is not available to the JS [recorded in
   [22]http://www.w3.org/2013/03/26-html-media-minutes.html#action
   01]

Received on Tuesday, 26 March 2013 20:01:58 UTC