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

perf(drm): decrypt fMP4 segments during download with mp4decrypt

Browse Source 
Opt-in decrypt_segments runs mp4decrypt --fragments-info per segment on a thread pool as segments land (DASH, single-init HLS), then decrypts the init alone; hides the post-download decrypt step with byte-identical output.
This commit is contained in:
imSp4rky
2026-08-26 16:27:55 -06:00
parent 8827ffd5cd
commit 89f09f8e84
9 changed files with 425 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/configuration/drm.md
+24
View File
@@ -156,3 +156,27 @@ unshackle decrypts HLS AES-128 ClearKey in-process and ignores this setting.
default: shaka
EXAMPLE1: mp4decrypt
```
## `decrypt_segments`
- **Type:** `bool`  ·  **Default:** `false`
Decrypts each fragmented MP4 segment as it arrives, instead of decrypting the whole track
after the download ends. The decryption runs during the download, so the wait after the last
segment goes away. The output file is the same either way.
This works with `mp4decrypt` only. Set [`decryption`](#decryption) to `mp4decrypt` for the
service (or as the default); with `shaka` the option has no effect, because shaka-packager
cannot decrypt a segment without its init segment. It applies to DASH tracks and to HLS
tracks that use one init segment, one `EXT-X-KEY` and no `EXT-X-DISCONTINUITY`. Every other
track keeps the whole-file decryption.
!!! note "No resume"
A track that decrypts segment by segment always downloads from the start.
[`continue_downloads`](download.md#continue_downloads) cannot reuse its segments, because a reused segment
is already decrypted.
```yaml
decrypt_segments: true
```