Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove note that MediaKeySession events may not be fired until the MediaKeys object is associated with a media element #9

Closed
ddorwin opened this issue Dec 20, 2014 · 11 comments

Comments

Projects
None yet
4 participants
@ddorwin
Copy link
Contributor

commented Dec 20, 2014

The spec currently contains the following non-normative note:

In some implementations, MediaKeySession objects may not fire any events until the MediaKeys object is associated with a media element using setMediaKeys().

The spec should not allow this because it breaks a lot of use cases, including:

  • Proactively obtaining licenses (there are at least several of variations of this one)
  • Managing persistent licenses or key releases independent of any actual playback.
@jdsmith3000

This comment has been minimized.

Copy link
Contributor

commented Jan 23, 2015

I agree with making this guidance normative.

@ddorwin

This comment has been minimized.

Copy link
Contributor Author

commented Jan 23, 2015

Did you mean to post the same comment as in 8?

To clarify, the proposal is to remove the non-normative note because such implementations break use cases. We should probably also normatively require that implementations do fire events without association. I think the algorithms probably do this already, but it might be good to explicitly state this.

@jdsmith3000

This comment has been minimized.

Copy link
Contributor

commented Jan 23, 2015

Yes, I made the same comment on 8.

I want to be sure I understand your intent. In 8, you propose:

  •      To leave the non-normative guidance recommending creating MediaKeys and calling setMediaKeys() before providing media data (setting the src) to avoid delays (waits).
    
  •      To add a step to Initialization Data Encountered that requires implementations that FOLLOW this guidance to fire a waiting event and wait for a signal that playback can resume.  Did you mean implementations that DO NOT FOLLOW this guidance fire these events?  That was my read.
    

Assuming this, then 9 allows the waiting event you describe above?

Jerry

From: ddorwin [mailto:notifications@github.com]
Sent: Friday, January 23, 2015 10:00 AM
To: w3c/encrypted-media
Cc: Jerry Smith (WINDOWS)
Subject: Re: [encrypted-media] Remove note that MediaKeySession events may not be fired until the MediaKeys object is associated with a media element (#9)

Did you mean to post the same comment as in 8?

To clarify, the proposal is to remove the non-normative note because such implementations break use cases. We should probably also normatively require that implementations do fire events without association. I think the algorithms probably do this already, but it might be good to explicitly state this.


Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-71234954.

@ddorwin

This comment has been minimized.

Copy link
Contributor Author

commented Jan 23, 2015

This issue is about MediaKeySession events (keystatuseschange and message).

Issue #8 is about the media element's behavior related to playback of encrypted media data and is unrelated to the session or its events. In that issue, I propose that the media element should fire the waiting for key event defined in 7.

Note: The other event defined in the spec, encrypted, is always fired.

@jdsmith3000

This comment has been minimized.

Copy link
Contributor

commented Jan 23, 2015

Can you also clarify this question?

  •      To add a step to Initialization Data Encountered that requires implementations that FOLLOW this guidance to fire a waiting event and wait for a signal that playback can resume.  Did you mean implementations that DO NOT FOLLOW this guidance fire these events?  That was my read.
    

You want to normatively define behaviors if the non-normative guidance is not followed, correct?

Jerry

From: ddorwin [mailto:notifications@github.com]
Sent: Friday, January 23, 2015 11:16 AM
To: w3c/encrypted-media
Cc: Jerry Smith (WINDOWS)
Subject: Re: [encrypted-media] Remove note that MediaKeySession events may not be fired until the MediaKeys object is associated with a media element (#9)

This issue is about MediaKeySession events (keystatuseschange and message).

Issue #8#8 is about the media element's behavior related to playback of encrypted media data and is unrelated to the session or its events. In that issue, I propose that the media element should fire the waiting for key event defined in 7.

Note: The other event defined in the spec, encrypted, is always fired.


Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-71248189.

@ddorwin

This comment has been minimized.

Copy link
Contributor Author

commented Jan 27, 2015

There are implementations that will delay playback of potentially encrypted streams until a MediaKeys (and thus media pipeline) has been attached. This is the reason for the non-normative note referenced in #8. (See #8 for more details.) In #8, I propose defining the behavior of these implementations. This is really independent of the note other than the note acknowledges that such implementations exist (as described in bug 19156).

The guidance is for applications, not implementations, and the normative text for user agent implementations does not strictly depend on or relate to the guidance.

To restate your question, #8 proposes to normatively define the application-visible behavior on such implementations should an application fail to provide a MediaKeys via setMediaKeys() before providing media data (as suggested by the the non-normative note).

@mwatson2

This comment has been minimized.

Copy link
Contributor

commented Feb 17, 2015

Is there consensus that for this issue, we should do as David suggests in the OP and require that implementations support key system message exchanges without any association with a video element ? I think this was always the intention and, as David says, is necessary for the use case where the page pro-actively fetches multiple licenses in advance of playback.

@jernoble

This comment has been minimized.

Copy link

commented Feb 24, 2015

I disagree with the proposal. We specifically asked for this language to be added. Whether or not UAs support key message exchanges before being associated with a video element should be left as a quality-of-implementation issue.

@ddorwin

This comment has been minimized.

Copy link
Contributor Author

commented Mar 2, 2015

This is more than a quality-of-implementation issue because it affects important use cases (i.e. those in the original description) enabled by the MediaKeys representation of a CDM instance. Today, this note basically tells authors they cannot implement any of these use cases and expect their application to work across clients.

@mwatson2

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2015

I suggest that we adopt the proposal made (somewhere) by David that implementations which require association with a Media Element before emitting keymessages should fail at the createSession() stage if there is no Media Element associated with the MediaKeys objects.

This allows applications attempting to perform key exchanges without a Media Element association to receive an explicit and early indication that this is not supported. The application can then choose between working around this restriction (e.g. with an off-DOM Media Element) or not performing those key exchanges at all.

@ddorwin ddorwin self-assigned this Apr 7, 2015

@ddorwin ddorwin modified the milestone: V1 Oct 16, 2015

@ddorwin

This comment has been minimized.

Copy link
Contributor Author

commented Feb 25, 2016

@ddorwin ddorwin closed this in fe6b8ed Feb 25, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.