-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Comments
I have seen the same thing, and I venture to say that it is related to: #2031 |
@joeyparrish, I can test yes! But I'm not sure if #2031 is related. |
@joeyparrish 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... |
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: |
I can confirm removing that check got airplay working for me. What is the way forward here? The DRM Engine can listen for |
I created #2257 to resolved this issue. |
Closes #2177 Change-Id: I681f34d103955055b25f8a0cb6f9fe7030dbd383
These changes have been cherry-picked for v2.5.8. |
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?
The text was updated successfully, but these errors were encountered: