Inline keys

[the-darkvoid]

The inline-keys branch adds supports for inlining encryption keys as base64 data URIs in the m3u8 playlist. This significantly reduces the number of HTTP requests required when playing back content and allows key data to be cached as well.

Example output

#EXT-X-KEY:METHOD=AES-128,URI="data:;base64,pC09WSndrgA5Sz7fk/yk3Q==",IV=0x00000000000000000000000000000CE1
#EXTINF:2.0480,
http://127.0.0.1:7080/aHR0cH......

Changes made:

• Support of --inline-keys command line parameter, this requires --cache-segments as well to work
• Updated segment-cache.js to allow caching other URLs besides ".ts" URLs by default
• Updated proxy.js to handle lines with #EXT-X-KEY: for key injection

[warren-bank]

hi, thanks for the PR :)

a few quick/initial thoughts..

• i believe that a video host would set cache-control headers in the response to requests for encryption keys, which a (well written) video player would honor.. and only re-request a fresh encryption key after the old one has expired
• if a video player (for whatever reason) fails to do so.. and ends up re-requesting the encryption key for every video segment, then I would agree with you that this proxy should provide a simple way to extend its caching feature to include (by default) both (.ts) video segments as well as encryption keys
  • offhand, I think that I'd probably implement this feature a little differently
  • I wouldn't have thought to offer an option to embed the encryption key with a data URI..
    • it's a good idea, though I'd offer that as an additional option
    • for example:
    • --prefetch-encryption-keys
    • --embed-encryption-keys
      • which would implicitly enable --prefetch-encryption-keys
  • the caching library should probably distinguish between video segments and encryption keys, since..
    • the user specifies its size (per manifest) based on the maximum number of video segments it should hold
    • we wouldn't want encryption keys to occupy slots that were allocated for (much larger) blobs of video
  • I'll need to take a closer look at your changes before I comment on the methodology
  • tomorrow.. it's very late right now

links to other similar/related discussions:

• https://github.com/videojs/http-streaming/issues/367