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

Player config should override license servers from the manifest #1905

Closed
joeyparrish opened this issue Apr 29, 2019 · 2 comments
Closed

Player config should override license servers from the manifest #1905

joeyparrish opened this issue Apr 29, 2019 · 2 comments
Assignees
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@joeyparrish
Copy link
Member

joeyparrish commented Apr 29, 2019

Have you read the FAQ and checked for duplicate open issues?
Yes

What version of Shaka Player are you using?
v2.5.0-beta3 and master

Can you reproduce the issue with our latest release version?
N/A - feature #484 didn't exist in v2.4.x

Can you reproduce the issue with the latest code from master?
Yes

Are you using the demo app or your own custom app?
Demo

What browser and OS are you using?
Chrome, OS N/A

What are the manifest and license server URIs?
No manifest URIs provided in the original feature discussion.
No manifest URIs provided by the internal partner reporting the issue.
Should be reproducible easily with unit tests.

What did you do?
1. Configure the Player with license server URI for Widevine
2. Load DASH content with ms:laurl elements containing a Widevine license server URI

  1. Configure the Player with license server URI for Widevine only
  2. Load DASH content with ms:laurl elements containing both Widevine and PlayReady license server URIs

What did you expect to happen?
The Player config should override the manifest's license server, as discussed in the original bug report: #484 (comment)
The Player config should override the manifest's license servers, including those not specified in the config. So, for example, if the player config contains Widevine only, only Widevine should be used, in spite of PlayReady license server in the manifest.

What actually happened?
PR #1644 which added this feature did not handle the nuance of letting the player config take precedence. So the player config for license servers is ignored with such content.
Player config only replaced the manifest servers for Widevine, and did not erase the PlayReady license server. The app developer only wants Widevine to be used in this case.

@joeyparrish joeyparrish added the type: bug Something isn't working correctly label Apr 29, 2019
@joeyparrish
Copy link
Member Author

Unable to reproduce with manual hacks (simulating license server URI in manifest). I will go back to our partner for a manifest we can use to reproduce the issue.

@joeyparrish joeyparrish added the status: unable to reproduce Issue could not be reproduced by the team label Apr 29, 2019
@shaka-bot shaka-bot added this to the v2.5 milestone Apr 29, 2019
@joeyparrish joeyparrish removed the status: unable to reproduce Issue could not be reproduced by the team label May 1, 2019
@joeyparrish
Copy link
Member Author

We have found the specific circumstances needed to reproduce this. The issue is not what it seemed.

  1. A platform with both PlayReady and Widevine, such as Chromecast or other CE device
  2. Content with ms:pro elements containing license servers for both PlayReady and Widevine, in that order
  3. Player config with a license server for Widevine only

The player config overrides the manifest config only for the specified key system (Widevine), but doesn't erase the PlayReady license server derived from the manifest. Because the <ContentProtection> element for PR comes first, Shaka chooses that. The app's intent in only configuring Widevine was to force the use of Widevine instead of PlayReady.

I think it would be a reasonable change in behavior for the extracting license server URIs from the manifest to be used only if none are configured at the player level.

@shaka-project shaka-project locked and limited conversation to collaborators Jul 1, 2019
@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: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

2 participants