W3C home > Mailing lists > Public > public-html-media@w3.org > January 2015

[encrypted-media] Define behavior for implementations that delay playback until setMediaKeys() is called

From: ddorwin via GitHub <sysbot+gh@w3.org>
Date: Mon, 05 Jan 2015 09:40:32 +0000
To: public-html-media@w3.org
Message-ID: <issues.opened-52546231-1419038203-sysbot+gh@w3.org>
ddorwin has just created a new issue for
https://github.com/w3c/encrypted-media:

== Define behavior for implementations that delay playback until
setMediaKeys() is called ==
Because the selection of a key system can affect the pipeline and/or
decoders used, some implementations MAY delay playback of media
resources that may contain encrypted blocks (i.e. when Initialization
Data [is] Encountered during demuxing) until a Key System is specified
by passing a `MediaKeys` object to `setMediaKeys()`.

There is currently a non-normative note that acknowledges this:
> As a best practice, applications should create a `MediaKeys` object
and call `setMediaKeys()` before providing media data (for example,
setting the `src` attribute). This avoids potential delays in some
implementations.

We should normatively define the behavior for such implementations.

I propose adding a step to the end of the [Initialization Data
Encountered](https://w3c.github.io/encrypted-media/#initdata-encountered)
algorithm that says such implementations will:
1. Run the queue a "waiting" event algorithm on the media element.
2. Wait for a signal to resume playback.
(These are the same steps that are run when the needed key is not
available (or `mediaKeys` has not been set) when an [Encrypted Block
[is] Encountered]
(https://w3c.github.io/encrypted-media/#encrypted-block-encountered).


See https://github.com/w3c/encrypted-media/issues/8
Received on Monday, 5 January 2015 09:40:33 UTC

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