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

Deployed b30e6d7 with MkDocs version: 1.6.1

Browse Source
This commit is contained in:
2026-09-18 14:57:39 +00:00
parent 1c7509aa8d
commit 41956b3027
3 changed files with 9 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
reference/configuration/vaults/index.html
+6 -4
View File
@@ -2096,10 +2096,12 @@ name) and a <code>name</code>, plus backend-specific keys.</p>
</div>
<div class="admonition note">
<p class="admonition-title">Bad content keys</p>
<p>A content key from a vault is proven by a short FFmpeg decode of the decrypted output.
A content key that fails the decode is written to the <code>bad_keys</code> table of every <code>SQLite</code>
vault with the name of the vault that supplied it, and every vault lookup skips a flagged
pair from then on. Only the <code>SQLite</code> backend stores flags. A <code>serve</code> instance with
<p>A content key from a vault is proven by short FFmpeg decodes of the decrypted output,
with windows inside the fragments of each KID in a fragmented MP4. A content key that
fails the decode is written to the <code>bad_keys</code> table of every <code>SQLite</code> vault with the name
of the vault that supplied it, and every vault lookup skips a flagged pair from then on. A <code>SQLite</code> vault also refuses to
store a flagged pair again. Only the <code>SQLite</code> backend stores flags; an <code>API</code> vault that
supplied the pair gets a report. A <code>serve</code> instance with
<code>server_cdm</code> flags a pair the same way when a remote client reports it, so a server whose
<code>key_vaults</code> hold no <code>SQLite</code> entry cannot remember a bad content key.</p>
</div>