Persistent license w/ streaming content #1956
Comments
|
I think that the use case is related to my comments in #1833 |
|
@nibredy, FYI |
|
@deisenbacher01, FYI |
|
Hi @joeyparrish, We have a use case where we are serving certain cost sensitive customers who want the features of DRM based encryption, but the license request costs are not affordable to them. Persisting the licenses therefore reduces the cost significantly. Any help is appreciated. Thanks |
|
No, we have not worked on this. We would be happy to discuss a design and review a PR if anyone wants to contribute to this. The shortest path probably involves modifying the |
|
@joeyparrish is it possible to prioritize #4461 |
Add capability to re-use persistent license sessions across sessions. DrmEngine will now always: - try to start stored persistent sessions before trying to fetch a license, as-to be able to check if all needed keys are already loaded. - ask for a new license when the persistent session doesn't have the needed keys for playback, Given the flag `persistentSessionOnlinePlayback` is true, DrmEngine: - won't remove the persistent session from the device at the end of the playback, - won't throw an error when the persistent session isn't found on the device, For now, it needs Shaka's users to persist session information by themselves (localStorage, IndexDB, ...) before giving it back for the next session. Still, it lays foundation to develop the feature to fully handling it on Shaka's side. Related to #1956
|
I think that can be close it with cc97da1 , @joeyparrish what do you think? |
avelad
added
the
status: waiting on response
|
Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including |
shaka-bot
removed
the
status: waiting on response
A partner asked me if we had any way to support persistent licenses with streaming content. At the moment, we do not.
We would have to persist the session ID somehow, even though the app wouldn't be using offline storage. I'm not sure if this would require a new API, or use of the
StorageAPI, or something else.The use-case was described as a live sporting event. The app developer would like to avoid all users requesting a license when the event starts, which would cause a huge spike of traffic on the license server. If they could pre-license the user before the event starts, the could spread that traffic out.
This may also relate to our proposed preload API (#880). It's not clear if preload would solve the same problem without the need for a persistent license, but it may.
The text was updated successfully, but these errors were encountered: