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

AirPlay support HLS/FairPlay #2177

Closed
raskri opened this issue Oct 8, 2019 · 8 comments · Fixed by #2257
Closed

AirPlay support HLS/FairPlay #2177

raskri opened this issue Oct 8, 2019 · 8 comments · Fixed by #2257
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Milestone

Comments

@raskri
Copy link

raskri commented Oct 8, 2019

I have implemented the initDataTransform function and set fairPlayTransform to false in version 2.5.5. HLS/FairPlay streaming works fine.

But sending the stream over to an Apple TV with AirPlay does not work. I can see that the initDataTransform function is called but nothing more is happening. Apple TV sys-log complains about a "slow decrypt key". So I'm guessing there is some issue inside the handling of "webkitneedkey" event. Have you guys experienced the same issue?

@raskri raskri added the type: question A question from the community label Oct 8, 2019
@raskri raskri closed this as completed Oct 8, 2019
@raskri raskri reopened this Oct 8, 2019
@avelad
Copy link
Member

avelad commented Oct 8, 2019

I have seen the same thing, and I venture to say that it is related to: #2031

@joeyparrish joeyparrish added type: bug Something isn't working correctly and removed type: question A question from the community labels Oct 8, 2019
@joeyparrish
Copy link
Member

We don't have an AppleTV device in our lab yet. Let's work on the assumption that this is a duplicate of #2031 for now. If we have a fix for that, @raskri, would you be able to test it for us on AppleTV?

@shaka-bot shaka-bot added this to the v2.6 milestone Oct 8, 2019
@raskri
Copy link
Author

raskri commented Oct 9, 2019

@joeyparrish, I can test yes! But I'm not sure if #2031 is related.

@joeyparrish joeyparrish modified the milestones: v2.6, Backlog Oct 15, 2019
@KarlGallagher
Copy link

@joeyparrish
One thing to note is that when an AirPlay session is established for FairPlay protected content, an EME key request event is proxied from the ATV via the browser CDM. This request will be for the existing key/contentId.
This also happens when AirPlay is disconnected.

In both cases the key request must be serviced by the license end-point (since each request contains session-bound crypto). Is there a chance that filtering logic in Shaka is ignoring these requests as redundant?

Just a thought...

@TheModMaker
Copy link
Contributor

If the init data is the same, then we'll ignore the duplicate key request. You can check to see if that is the issue by removing the duplicate checks and seeing if that works:

https://github.com/google/shaka-player/blob/02847e3b1ff51e2db85be64fa99e411cff087efe/lib/media/drm_engine.js#L536-L541

@gscragg
Copy link
Contributor

gscragg commented Nov 26, 2019

I can confirm removing that check got airplay working for me.

What is the way forward here?

The DRM Engine can listen for webkitcurrentplaybacktargetiswirelesschanged events and clear the activeSessions_ property, or export an API method that we can call directly when we know we want to start an airplay session?

@avelad
Copy link
Member

avelad commented Nov 27, 2019

I created #2257 to resolved this issue.

@joeyparrish joeyparrish added type: enhancement New feature or request and removed type: bug Something isn't working correctly labels Jan 3, 2020
joeyparrish pushed a commit that referenced this issue Jan 3, 2020
@joeyparrish joeyparrish modified the milestones: Backlog, v2.6 Jan 3, 2020
joeyparrish pushed a commit that referenced this issue Jan 15, 2020
Closes #2177

Change-Id: I681f34d103955055b25f8a0cb6f9fe7030dbd383
@joeyparrish
Copy link
Member

These changes have been cherry-picked for v2.5.8.

@shaka-project shaka-project locked and limited conversation to collaborators Mar 3, 2020
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants