Use case description
Per 7.3 of DASH-IF IOP-6 V5.0.0 (https://dashif.org/docs/IOP-Guidelines/DASH-IF-IOP-Part6-v5.0.0.pdf) we would like to ensure consistency of the ContentProtection descriptor in our dash manifests, with the ability to parse the licence server url on program boundaries of a live manifest. This would involve supporting the dashif:Laurl attribute, as current laurl support is limited to clearkey:Laurl and ms:laurl.
Proposed solution
Just as clearkey:Laurl parsing support was added (google/ExoPlayer#10260) a similar change supporting dashif:Laurl could be included through an additional else statement in the DashManifestParser class.
Alternatives considered
We have verified that the player will behave correctly when using widevine and sending clearkey:Laurl, however the naming of that attribute is a cause for confusion and it seems like the industry standard is moving to the more generic dashif:Laurl instead which we would prefer to use.
Use case description
Per 7.3 of DASH-IF IOP-6 V5.0.0 (https://dashif.org/docs/IOP-Guidelines/DASH-IF-IOP-Part6-v5.0.0.pdf) we would like to ensure consistency of the ContentProtection descriptor in our dash manifests, with the ability to parse the licence server url on program boundaries of a live manifest. This would involve supporting the dashif:Laurl attribute, as current laurl support is limited to clearkey:Laurl and ms:laurl.
Proposed solution
Just as clearkey:Laurl parsing support was added (google/ExoPlayer#10260) a similar change supporting dashif:Laurl could be included through an additional else statement in the DashManifestParser class.
Alternatives considered
We have verified that the player will behave correctly when using widevine and sending clearkey:Laurl, however the naming of that attribute is a cause for confusion and it seems like the industry standard is moving to the more generic dashif:Laurl instead which we would prefer to use.