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

feat: enable playlists with 'usable' keystatus #1460

Merged
merged 28 commits into from
Dec 13, 2023

Conversation

adrums86
Copy link
Contributor

@adrums86 adrums86 commented Dec 8, 2023

Description

Only enable playlists with a 'usable' keystatus when playing DASH with DRM.

Specific Changes proposed

Reference the playlist keyId after getting a keystatuschange event from contrib-eme and only enable encrypted playlists that we have a matching usable keyId for.

Note: This PR includes changes from #1461

Requirements Checklist

  • Feature implemented / Bug fixed
  • If necessary, more likely in a feature request than a bug fix
  • Reviewed by Two Core Contributors

Copy link

codecov bot commented Dec 8, 2023

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (c726760) 86.01% compared to head (b6504ea) 86.03%.
Report is 1 commits behind head on main.

Files Patch % Lines
src/playlist-controller.js 97.14% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1460      +/-   ##
==========================================
+ Coverage   86.01%   86.03%   +0.02%     
==========================================
  Files          42       42              
  Lines       10673    10712      +39     
  Branches     2456     2462       +6     
==========================================
+ Hits         9180     9216      +36     
- Misses       1493     1496       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@adrums86 adrums86 marked this pull request as ready for review December 12, 2023 17:42
Copy link
Contributor

@wseymour15 wseymour15 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! I left a few nit comments, as well as maybe including an additional test

src/dash-playlist-loader.js Outdated Show resolved Hide resolved
test/dash-playlist-loader.test.js Outdated Show resolved Hide resolved
test/playlist-loader.test.js Outdated Show resolved Hide resolved
src/playlist-controller.js Outdated Show resolved Hide resolved
src/playlist-controller.js Show resolved Hide resolved
@@ -1127,6 +1127,7 @@ class VhsHandler extends Component {

this.player_.tech_.on('keystatuschange', (e) => {
if (e.status !== 'output-restricted') {
this.playlistController_.updatePlaylistByKeyStatus(e.keyId, e.status);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to keep all the code listed further for cases when we receive output-restricted?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it is not longer valid

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I wasn't sure the best approach here. Leaving the code below, we'll maintain the same behavior as before where we exclude all the HD renditions on a single output-restricted status. I was also originally considering having this behind an options flag? Definitely open to some discussion on what we ultimately should have as the default behavior here.

Copy link
Contributor

@dzianis-dashkevich dzianis-dashkevich Dec 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as far as I understand it conflicts with the proposed solution, since when we receive output-restricted we will exclude every HD+ rendition.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we should just remove it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean the change is straightforward and should just work, do we need a flag for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I don't really see much downside in keeping this as is without a flag as the playlists with a keyId and no usable keystatus would not be playable anyway. Also agree, I think the HD rendition filtering is safe to remove here as the same thing would be accomplished through the new logic. Removing the rest below and simplifying this listener.

// // default KID is a 32 digit hext string separated by '-'.
// return playlist.contentProtection.mp4protection.attributes['cenc:default_KID'].replace(/-/g, '');
// }
// }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

commented code

} else if (hasUsableKeyStatus && nonUsableExclusion) {
delete playlist.excludeUntil;
delete playlist.lastExcludeReason_;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add logs for cases when we exclude it and when we restore it back

@adrums86
Copy link
Contributor Author

@wseymour15 and @dzianis-dashkevich Thanks for taking a look at this! I just pushed some updates, another look would be appreciated when you have time.

@adrums86 adrums86 merged commit 7d7c639 into main Dec 13, 2023
15 checks passed
@adrums86 adrums86 deleted the feat-disableNonUsablePlaylists branch December 13, 2023 17:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants