Skip to content
This repository has been archived by the owner on Feb 16, 2023. It is now read-only.

Dynamic HDCP status changes #4

Open
OrenMe opened this issue Oct 18, 2018 · 2 comments
Open

Dynamic HDCP status changes #4

OrenMe opened this issue Oct 18, 2018 · 2 comments
Labels
question Further information is requested

Comments

@OrenMe
Copy link

OrenMe commented Oct 18, 2018

Does HDCP status can be changed dynamically? E.g. when plugging or unplugging an external display?
If so, how does this API relate to this?

Use case: HDCP might be a requirement for content providers/owner.
If during initial check the HDCP check returns valid response for a certain level then the implementation may choose a manifest with HD or 4K renditions, but if during playback the status chanhes(external monitor connected) then the playback context needs to know about this and update accordingly.

@joeyparrish joeyparrish added the question Further information is requested label Nov 6, 2018
@joeyparrish
Copy link
Member

Hi, @OrenMe!

Yes, HDCP status can change during playback if the user's physical configuration changes. For example: unplugging a monitor, or plugging in a new one. This API does not address that, but rather addresses the need to get a hint before playback begins.

If the HDCP status changes during playback, key statuses will change, and the 'keystatuseschange' event will fire. This is already spec'd in EME and implemented in user agents, and our HDCP detection proposal does not change this.

Does this answer your question?

@OrenMe
Copy link
Author

OrenMe commented Jan 30, 2019

Hi @joeyparrish, so in terms of handling the drm session this means that if HDCP changes then the restriction will be handled by another part?
For example, in Shaka, the DRM engine will propagate an error or event stating that playback restrictions can’t be met and playback will halt?
If this is the case so at least it is handled, but also, it is a bit complicated IMO if you have one API to do initial checks but you can’t register an onChanhe event listener to it and should rely on another, not directly related, API to get real time changes.
WDYT? I mean, what you described still does the job of enforcing and notifying about this change which is what I originally asked, so in this term, yes, it answered my question.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants