- From: ddorwin via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Jan 2015 09:40:32 +0000
- To: public-html-media@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