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

Allow setting LoadErrorHandlingPolicy for DRM session requests #1271

Closed
stevemayhew opened this issue Apr 11, 2024 · 2 comments · Fixed by #1272
Closed

Allow setting LoadErrorHandlingPolicy for DRM session requests #1271

stevemayhew opened this issue Apr 11, 2024 · 2 comments · Fixed by #1272
Assignees

Comments

@stevemayhew
Copy link
Contributor

stevemayhew commented Apr 11, 2024

Use case description

Many of the Widevine proxy implementations require more elaborate retry mechanisms then the simple non-random timed backoff provided by the DefaultLoadErrorHandlingPolicy (for example, 429 back-off). This simple hook allows for implementations of them.

Proposed solution

See pull request #1272

Alternatives considered

Copy the entire DefaultDrmSessionManagerProvider and make this change for ourselves (ugly)

@stevemayhew
Copy link
Contributor Author

@icbaker not sure where you guys are going with the factories around the drm package, as most are marked as @UnstableApi, which I understand as adding to these API's is pretty un-restricted, just don't depend on them to remain in place or produce a stable player.

We are using the DefaultDrmSessionManagerProvider as it allows for caching the DrmSession (critical for live playback with Widevine proxy)

@icbaker icbaker linked a pull request Apr 16, 2024 that will close this issue
@icbaker
Copy link
Collaborator

icbaker commented Apr 22, 2024

#1272 is merged, so closing this.

@icbaker icbaker closed this as completed Apr 22, 2024
@androidx androidx locked and limited conversation to collaborators Jun 22, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants