Bug 17470 - Provide specific guidance on when generateKeyRequest should be called
Provide specific guidance on when generateKeyRequest should be called
Status: RESOLVED FIXED
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions
unspecified
All All
: P2 normal
: ---
Assigned To: Adrian Bateman [MSFT]
HTML WG Bugzilla archive list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-12 13:37 UTC by Martin Soukup
Modified: 2012-11-01 07:53 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Soukup 2012-06-12 13:37:32 UTC
v0.01 of the proposal states that "In general, applications should wait for an event named needKey or loadstart...before calling this method."

If some implementations will require this behaviour the proposal should state the order as a requirement.
Comment 1 David Dorwin 2012-06-22 22:19:20 UTC
I believe the reason for the wording is that you could probably meet the minimum requirements in some other way, so it's not a requirement to wait for these events.

I agree that we should specify that applications should not call generateKeyRequest() before a specific time that all implementations are guaranteed to be ready.

There has been some discussion of wanting to perform operations before loadstart, which requires a source to be specified^. However, for WebKit, the underlying media object in the embedder is not created until loading starts.

^ One potential use case is using an empty media element to manage key release (issue 17199). I believe others were mentioned in the original public-html discussions.
Comment 2 David Dorwin 2012-08-17 06:47:54 UTC
The cited non-normative text in the original report is preceded by normative text that defines the user agent behavior. Thus, it is a requirement of implementations. I do not think the spec needs to specify how applications should be implemented - this non-normative text is simply a suggestion.

The normative text has been updated to more appropriately say, "If loading has not started, throw an INVALID_STATE_ERR."

The use case mentioned in Comment 1 has been addressed by the object-oriented API (bug 16613), so I think it's okay to leave this requirement that MediaKeys not be associated with HTMLMediaElement until the latter has started loading.
Comment 3 Adrian Bateman [MSFT] 2012-08-28 20:19:46 UTC
Fixed in the latest draft. Please reactivate with more information if you disagree.
Comment 4 Joe Steele 2012-09-04 18:25:20 UTC
I would like to reopen this issue. I am concerned about the cases where being able to preload keys would significantly impact the user experience. 

Consider this scenario -- 
The user browses to a video distributor using a domain key model for determining entitlements. If the user has not yet acquired the appropriate keys and there is no additional user interaction required, they could be acquired while the user is browsing the video selection rather than waiting until the user selects a video and tries to play. This would result in a better user experience in cases where the key acquisition takes a perceptible amount of time (i.e. over 1 sec).

Given that loading is required to begin, how can we achieve this? Could the MediaKeys object be instantiated independent of an HTMLMediaElement?
Comment 5 David Dorwin 2012-09-05 11:22:39 UTC
(In reply to comment #4)
> I would like to reopen this issue. I am concerned about the cases where being
> able to preload keys would significantly impact the user experience. 
> 
> Consider this scenario -- 
> The user browses to a video distributor using a domain key model for
> determining entitlements. If the user has not yet acquired the appropriate keys
> and there is no additional user interaction required, they could be acquired
> while the user is browsing the video selection rather than waiting until the
> user selects a video and tries to play. This would result in a better user
> experience in cases where the key acquisition takes a perceptible amount of
> time (i.e. over 1 sec).

This sounds similar to the use case mentioned in Comment 1. I think what you want to do is possible with the new OO APIs.

> Given that loading is required to begin, how can we achieve this? Could the
> MediaKeys object be instantiated independent of an HTMLMediaElement?

Yes, in the OO APIs. You just can't assign the MediaKeys to the HTMLMediaElement until loading has started.
Comment 6 Joe Steele 2012-09-05 15:43:38 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > I would like to reopen this issue. I am concerned about the cases where being
> > able to preload keys would significantly impact the user experience. 
> > 
> > Consider this scenario -- 
> > The user browses to a video distributor using a domain key model for
> > determining entitlements. If the user has not yet acquired the appropriate keys
> > and there is no additional user interaction required, they could be acquired
> > while the user is browsing the video selection rather than waiting until the
> > user selects a video and tries to play. This would result in a better user
> > experience in cases where the key acquisition takes a perceptible amount of
> > time (i.e. over 1 sec).
> 
> This sounds similar to the use case mentioned in Comment 1. I think what you
> want to do is possible with the new OO APIs.
> 
> > Given that loading is required to begin, how can we achieve this? Could the
> > MediaKeys object be instantiated independent of an HTMLMediaElement?
> 
> Yes, in the OO APIs. You just can't assign the MediaKeys to the
> HTMLMediaElement until loading has started.

It would be good if an example of this use case was somewhere in the document. It is not clear now that this would work. This use case could invalidate Step 1 of the createSession algorithm, as there would be no obvious mime-type to pass in to createSession. We could allow null to be passed (currently this would trigger an error), or we could define a special mime-type for this use case (e.g. "undefined") or we could specify that the CDM must ignore it.

In the use case I am thinking of -- the standalone MediaKeys instance would never be attached to an HTMLMediaElement. It would be released after it had been used for pre-loading keys.
Comment 7 Adrian Bateman [MSFT] 2012-09-05 18:51:19 UTC
Why wouldn't you know the media type? The media type is probably going to influence the format of the initData.
Comment 8 Joe Steele 2012-09-05 21:55:24 UTC
(In reply to comment #7)
> Why wouldn't you know the media type? The media type is probably going to
> influence the format of the initData.

But in this case we are prepping the CDM prior to seeing any content. In most cases the mime-type of the content will be known, but I can imagine cases where it is not or can vary between multiple types. 

There is no reason why the initData will be anything like what is embedded in a content stream, since it is not associated with a content stream. It could be a completely different format. The goal here is to pass a bundle of opaque data from the app to the CDM in order to initialize it prior to seeing any content.
Comment 9 Yang Sun 2012-09-21 07:16:00 UTC
If key is relative with different film, but not with different content type, if the web page has 30 films can be delivered to browser, how many key do we need to prepare before we see all the film?

(In reply to comment #8)
> (In reply to comment #7)
> > Why wouldn't you know the media type? The media type is probably going to
> > influence the format of the initData.
> 
> But in this case we are prepping the CDM prior to seeing any content. In most
> cases the mime-type of the content will be known, but I can imagine cases where
> it is not or can vary between multiple types. 
> 
> There is no reason why the initData will be anything like what is embedded in a
> content stream, since it is not associated with a content stream. It could be a
> completely different format. The goal here is to pass a bundle of opaque data
> from the app to the CDM in order to initialize it prior to seeing any content.
Comment 10 Joe Steele 2012-10-15 20:19:38 UTC
I responded with some example code in this email: http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0029.html

If everyone is ok with that example, I am ok with closing this bug again.
Comment 11 David Dorwin 2012-11-01 07:53:44 UTC
There are other threads and/or bugs covering Joe's concerns. Since the original purpose of this bug has been addressed and the summary does not relate to the open issues, I'm going to close it again. Feel free to open specific bugs if there are remaining issues.