kenzuya/unshackle
1
0
Fork 2
mirror of https://github.com/unshackle-dl/unshackle.git synced 2026-11-12 12:05:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(remote): match the server CDM to the client's DRM and read vaults first

Browse Source 
A dual widevine/playready cdm entry now loads the device of the client's DRM system, for old clients too since they already send cdm_type. A new client hands a capped track to its own device for the track's DRM system, and raises the refusal only after its local vaults miss.
This commit is contained in:
imSp4rky
2026-11-03 10:51:29 -07:00
parent b710b5b0c9
commit b6429ecdfd
12 changed files with 309 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/configuration/drm.md
+6 -1
View File
@@ -50,7 +50,12 @@ height is known. If the value is still a dict after that, unshackle uses
When an entry holds `widevine` and `playready`, their order sets which device unshackle loads
first. A track that offers the two DRM systems licenses with that system. A track that offers
only the other system uses the other device. A `widevine` / `playready` dict in a quality key
does not set the order. The server CDM of a remote session follows the same order.
does not set the order.
On a server, an entry that holds `widevine` and `playready` gives a remote session the server CDM
of the DRM system of the client's local CDM. The service then makes its manifest for that system,
so the client's vault keys and its own device apply to the tracks. A client with no local CDM gets
the device that the entry lists first.
A quality key can also hold a dict of `widevine` / `playready` devices, and so can the
top-level `default` entry: