See also: IRC log
minutes are approved
<trackbot> ACTION-10 -- Adrian Bateman to discuss bug 19208 with johnsim -- due 2013-04-08 -- OPEN
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
... [never mind]
Adrian: those are just
... 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
Adrian: see above
Adrian: David made a proposal
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
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> MediaElementAudioSourceNode allows audio samples to be exported to JS
Glenn: you're referring to createPattern?
<adrianba> drawImage -> http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/#dom-context-2d-drawimage
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
... 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
... 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
... 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 http://www.w3.org/2013/03/26-html-media-minutes.html#action01]
<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].
Adrian: Paul will be back for the
... any volunteer to scribe?
Joe: I can