W3C home > Mailing lists > Public > public-html-media@w3.org > February 2014

[Bug 24771] New: Provide guidance on object and CDM lifetime (including when events are guaranteed to be fired)

From: <bugzilla@jessica.w3.org>
Date: Fri, 21 Feb 2014 21:40:51 +0000
To: public-html-media@w3.org
Message-ID: <bug-24771-5436@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24771

            Bug ID: 24771
           Summary: Provide guidance on object and CDM lifetime (including
                    when events are guaranteed to be fired)
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: ddorwin@google.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

The spec does not specify the lifetime of the MediaKeys or MediaKeySession
objects or when to destroy the CDM instance. The following are proposals for
each of these.


*** MediaKeys ***
The MediaKeys lifetime is pretty simple - it can be destroyed when there are no
more JS references (including video.mediaKeys) to it.


*** MediaKeySession ***
MediaKeySession is more complex. Since it is an EventTarget for events
originating in the CDM, it should be alive as long as there are JavaScript
references to it OR it may receive events. Since the CDM must outlive the
MediaKeySession (see below) and the CDM could in theory fire events at any
time, this would mean we can never destroy an unclosed MediaKeySession and thus
never destroy the CDM instance. Therefore, we must change the second condition
to: it may receive _meaningful_ events. Defining meaningful is the tricky part.

For the purpose of this discussion, let’s say events are only meaningful when
they can affect a media element, meaning the MediaKeys object is or will
potentially be attached to a media element. (That is, the MediaKeys is either
currently attached or there is a JS reference to it that could be passed to
setMediaKeys().)

It is possible that the CDM could fire (“non-meaningful”) events that would be
caught by an event listener even when there are no JS (or media element)
references to any MediaKeys or MediaKeySession objects. However, as mentioned
above, we have to draw a line somewhere to prevent indefinite memory leaks, so
I think we should require applications to have a reference to one of the two
objects (including an attachment to a media element) in order to receive
MediaKeySession events. (Applications that wish to to handle events that cannot
affect the media element, such as those related to session accounting, must
hold a reference to the session(s).)

This means applications are only guaranteed to receive events for a
MediaKeySession when they hold a reference to the session, its MediaKeys
object, or there is a valid HTMLMediaElement whose mediaKeys attribute
references the MediaKeys object that created the session.

Thus, a MediaKeySession object should be destroyed when both of the following
are true:
1) There are no JS references to it.
2) Either of the following is true:
  a) The session is closed.
  b) The MediaKeys object that created the session has been destroyed.


*** CDM Instance ***
Since MediaKeys represents a CDM instance, the naive approach would be to
destroy it when MediaKeys is destroyed. However, it also needs to remain alive
as long as there are any (non-closed) MediaKeySessions that can be used to
access the CDM instance.

Thus, the CDM instance may be destroyed when both of the following are true:
1) The MediaKeys object has been destroyed.
2) All the MediaKeySession objects that MediaKeys object created have been
destroyed.
(Really, we could add “or closed” to the second condition. Doing so might
slightly accelerate destruction of the CDM instance in some cases since there
could be a slight delay between closing the last session and garbage collection
destroying the MediaKeySession. However, I don’t think it’s worth adding more
conditions to close this gap.)


*** Notes ***
- Another approach would be to tie the CDM instance lifetime to the MediaKeys
object’s lifetime and not destroy the MediaKeys as long as there are valid
MediaKeySession objects. However, that would create a circular reference for
unclosed sessions that would never be broken (since unclosed MediaKeySession
objects are not destroyed until the MediaKeys object is destroyed).

- There is an assumption that no events are fired at a session after the
“close” event. If this is not already explicitly stated, we should probably do
so.

- "CDM instance" is not actually used in the spec. Instead, we just refer to
the "CDM" and loading it (i.e. as if it is a library). We should probably refer
to a "CDM instance" or otherwise limit the context of the CDM to this specific
MediaKeys object. This may be related to issue 17202.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 21 February 2014 21:40:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:02 UTC