- From: <bugzilla@jessica.w3.org>
- Date: Wed, 22 Jan 2014 23:57:07 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515
David Dorwin <ddorwin@google.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |24368
--- Comment #18 from David Dorwin <ddorwin@google.com> ---
(In reply to Jerry Smith from comment #16)
> I’ve attached a proposed change below that adds a waitingFor attribute to
> the Media Element, and sets it to either data or mediakeys to signal whether
> the waiting event was triggered by readyState changes or the need for new
> media keys.
>
>
> Add a new Media Element property to section 2. Media Element Extensions:
s/property/attribute/?
Do we recommend adding the waitingFor attribute to HTMLMediaElement as part of
HTML 5.x or only when EME is implemented? While the current use case is EME, it
seems generally useful, especially since an HTML5 waiting event might be
transitory and because MSE can cause similar conditions (see bug 24368).
> attribute waitingFor;
^ "readonly"
> With these states defined:
>
> enum waitingFor {
> “notwaiting”,
Maybe "nothing" or "none". Then it reads as "Waiting for nothing/none."
> “mediakeys”,
The element is really waiting for a "key" or for "decryption" to occur. The
latter may be more inclusive, but "key" is probably sufficient.
These names also work regardless of whether a UA or application support EME or
decryption. (This is similar the last purpose of MEDIA_ERR_ENCRYPTED before it
was removed - #2 in https://www.w3.org/Bugs/Public/show_bug.cgi?id=21203#c30 is
essentially one of the issues we're trying to solve in this bug.)
"mediakeys" sounds too much like the mediaKeys attribute/object (which may
actually be valid but not have the needed key).
However, as discussed when choosing the attribute name recently (bug 24117),
there could potentially be other types of keys or key-providing mechanisms.
Would we want one "key" value for all such key dependencies?
I still think "key" is better overall rather than a confusing name to avoid a
conflict that will probably never occur. "decryption" addresses both issues.
> “data”
It seems this should be listed second since it is more common and applies to
UAs that don't support encrypted media.
Depending on how we deal with the playback scenario (bug 24368) we might want
"audiodata", "videodata", etc. Of course, I'm not sure what that looks like
when there are multiple tracks of a single type. Maybe waitingFor should be on
AudioTrack, VideoTrack, etc. if we want to allow some streams to continue. This
will depend on bug 24368.
> };
>
> Add to the playing condition text under 4.2 Encrypted Block Encountered.
>
> Existing:
> The following paragraph is added to Playing the media resource.
> • A media element is said to be waiting for a key when it would be
> potentially playing but the user agent has reached a point in the media
> resource that must be decrypted for the resource to continue and the CDM
> does not have the necessary key.
> • The media element leaves this state when seeking but could re-enter it if
> the same conditions exist.
>
> New:
Where exactly should this text be added? The Existing text was "inserted" into
a specific location in the HTML5 spec.
> • It is possible for media element to be playing protected media and then
> encounter content that requires new media keys.
"playing protected media" could imply "encrypted frames"; this and "new [media]
keys" could lead one to believe this should only apply when there is a key
rotation after having already played encrypted content.
Also, to avoid confusion with "MediaKeys", I suggest s/media keys/decryption
key(s)/.
> For state changes caused by
> pending key requests or delivery, apply the first appropriate substeps from
We should probably generalize this to any time a key is needed, regardless of
whether there is a pending key request.
The message to the application is the same, and the HTMLMediaElement does not
actually know whether there is an outstanding request - only the
MediaKeySession would.
> the following list:
> o If media element was previously playing and had a waitingFor value of
> “notwaiting”:
> - If readyState changes queue a task to fire a waiting event, the
This if clause is ambiguous. It might be better to say "If a readyState change
queues a task..." if that is the intent. Or maybe there is something other than
the fact that the event was queued that we can use as the "trigger".
> user agent must also set the waitingFor attribute on the Media Element to
> “data”.
It seems that this substep would apply to any time a waiting event is fired and
not just when caused by an encryption-related wait (as limited by the solid
bullet ('•') above.
> - If new mediaKeys are needed to continue and the element has not
Same concerns about "new" and - especially - "mediaKeys".
> ended play back, the user agent must set the waitingFor attribute on the
> Media Element to “mediakeys”, queue a task to fire a simple event named
> timeupdate at the element, and queue a task to fire a simple event named
> waiting at the element.
Why is timeupdate fired?
> o If media element was previously waiting and had a waitingFor value of
> “data”:
Does it matter what the readyState changed *to* or do we do this on any state
change? This comment might apply to other [sub-]steps as well.
> - If readyState changes queue a task to fire a canplay event, the
Same comment as above about the if clause.
> user agent must also set the waitingFor attribute on the Media Element to
> “notwaiting”.
> o If media element was previously waiting and had a waitingFor value of
> “mediakeys”:
> - If mediaKeys becomes available for playback to proceed, the user
> agent must set the waitingFor attribute on the Media Element to
> “notwaiting”, queue a task to fire a simple event named timeupdate at the
> element, and queue a task to fire a simple event named canplay at the
> element.
Should this last step be added to step 5 of the update() algorithm where we
currently resume playback if "waiting for a key", which is the Existing text
that is removed in this proposal.
We might need to say something like "Upon successful resumption of playback,
...<actions specified above>."
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 22 January 2014 23:57:09 UTC