1306535 - [EME] "waitingforkey" not fired if MediaKeys not set on HTMLMediaElement

Status: NEW

(Core :: Audio/Video: Playback, defect, P3)

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

If we don't set a MediaKeys on an HTMLMediaElement, and we encounter initialization data, we're supposed to run the "waiting for key" algorithm. That is, we should dispatch a "waitingforkey" event. We currently do not.

Testcase:
http://people.mozilla.org/~cpearce/mediakeys-not-set.html

This should fire a "waitingforkeys" event in Firefox, but does not.

(Note: Chrome plays audio on this page, even though the MediaKeys is not set on the HTMLMediaElement, I've email ddorwin about that).

Comment 1

[Jean-Yves Avenard [:jya]]

I'm not sure I read the specs the same way as you describe. At least not in regards to this particular testcase.

There is only one section describing when to run the "Wait For Keys" algorithm:
7.3.1 Media Data May Contain Encrypted Blocks
"2. If the media element's mediaKeys attribute is null and the implementation requires specification of a MediaKeys object before decoding potentially-encrypted media data, run the following steps:"
 1. Run the Wait for Key algorithm on the media element."

With the HTML Media Element extension stating:
"When one of the following occurs while the decryption blocked waiting for key value is true, the user agent SHALL run the Wait for Key algorithm.
    * The user agent cannot advance the current playback position in the direction of playback.
    * The user agent cannot provide data for the current playback position.
"

When the media element doesn't contain encrypted data and all can be decoded, it is clear that we do not fulfill either of those last two conditions: we can always advance the current playback position and we can provide data for the current playback condition.

Now for 7.3.1 to be called, if "When the user agent is ready to begin playback and has encountered an indication that the media data may contain encrypted blocks during the resource fetch algorithm"

Now, the interpretation of the sentence "the implementation requires specification of a MediaKeys object before decoding potentially-encrypted media data", isn't clear cut I don't think. Does our implementation require specification of the media keys *before* decoding?

Technically, we do, as MediaDecoder::SetCDMProxy can only ever be called prior the media element being started, and even if it wasn't; our MediaFormatReader requires MediaDecoderReader::SetCDMProxy to be called before we attempt to create a decoder; and only that decoder can tell if a sample is encrypted or not.
But it doesn't have to be that way; I even think it would be rather simple to allow the MediaKeys to be set once playback has started and only once we've found an encrypted sample.

If we wanted to do it, upon returning from AsyncReadMetadata; we could upon firing loadedmetadata check if it's encrypted or not and if MediaKey is set.

That particular file however, have Demuxer::GetCrypto() returns false, so the condition "and has encountered an indication that the media data" is false.
So in your particular exmple, I think it should be regardless of the presence of MediaKeys being set.