How does remote playback interact with EME?

[joeyparrish]

This came out of discussion started in w3ctag/design-reviews#323 (comment):

I don't see any mention of MediaKeys in the spec, and I don't understand the resolution from #41 or #55. Can you give an example of how EME would work with remote playback? Or is it simply not supported / supportable?

Thanks!

[mounirlamouri]

IMO Remote Playback shouldn't work with EME because there are two ways to do Remote Playback:

• Send the file URL to the remote device for it to play. In this case, if the file is protected, the other device wouldn't be able to play it.
• Stream the media to the other device. In this case, it seems not the best idea to stream the decoded bytes in clear.

@mfoltzgoogle may have other thoughts especially with Open Screen.

[markafoltz]

As far as the Remote Playback API spec is concerned, it looks like it's up to the user agent to implement remote playback or not for encrypted media. It's possible to implement, though. Either the remote display needs to obtain a license to decode the media locally (which generally requires messaging through e.g. the Presentation API), or the media transport needs to comply with a standard like HDCP. No reasonable implementation sends remote playback media "in the clear" for security and privacy reasons.

Regarding Open Screen Protocol, handling encrypted content is specifically out of scope for the charter of the spec, so there won't be any spec language around it at this point. If an agent implements OSP for remote playback, and wants to query and report the HDCP status of the remote display, it would have to be through a custom extension to the core protocol.

However, there may be interest in adding this to the current or a future iteration of the OSP spec.

[cynthia]

(NOTE: Not an advocate of DRM. Feedback is from an end user experience perspective.)

Having this supported in a future iteration of the spec would be definitely useful. From a user's perspective, some videos being possible to cast to a remote display and some being impossible (internally due to DRM) is not something that would be expected.

From an end user perspective, requesting a Netflix video (which presumably is DRM protected) which you were watching on a native app to be put on the big screen should not be different from that stream request being initiated from web content.

[mounirlamouri]

I fully agree that ideally Remote Playback should work with EME and as @mfoltzgoogle pointed out, there isn't anything in the spec that mentions EME. A user agent may simply implement Remote Playback for EME if they can figure it out.

In practice, it would be really hard to do, as @mfoltzgoogle mentioned, and the right solution would be to use more advanced features like the Presentation API which allows to have a Javascript context running on the target device that can get a MediaKey and decode the EME stream. In the case of Netflix, this is what they would have to do. The end user wouldn't really see the difference as they would simply press the "Cast" button. The developers however would have to know the difference: the quick and easy API wouldn't allow for advanced features. The same way, today, all implementations of the API wouldn't work with MSE.

Given that the issue doesn't appear to be actionable (I don't think we can guarantee EME support with Remote Playback) and the use case is resolved with a different API (Presentation API), I will close this issue. Please feel free to re-open if that doesn't sound reasonable.