Encrypted Video Streaming — Multi-Key AES-128 HLS Explained

Encrypted Video Streaming on AVCaption

Every video uploaded to AVCaption is encrypted before it hits a CDN edge. Playback decryption happens client-side in the browser via the Web Crypto API, and the keys are delivered through signed, short-lived URLs that bind to your domain.

This page walks through what’s actually happening at each step.

The encryption pipeline

When you upload a video to AVCaption:

  1. GPU encoding — your source file is encoded to HLS adaptive bitrate variants (360p, 540p, 720p, 1080p, 4K) using NVIDIA NVENC.
  2. Segment slicing — each variant is sliced into HLS segments, typically 6 seconds each.
  3. Batch encryption — segments are grouped into batches of 10 (60 seconds of playback). Each batch gets a freshly generated AES-128 key.
  4. CDN upload — encrypted segments are uploaded to Cloudflare R2 and served via the global CF CDN with aggressive caching.
  5. Key vault — encryption keys are stored separately, never on the CDN, never with the segments.

When a viewer clicks play:

  1. Token request — the player requests a playback token from /api/stream/{embed_token}/token. The server verifies the embed token, the requesting domain (against your whitelist), and rate limits.
  2. Master playlist — the player fetches the HLS master .m3u8 and selects a variant based on bandwidth.
  3. Per-batch key fetch — for each batch of segments the player needs, it requests the matching key from /api/stream/{embed_token}/key/{batch}. Each key URL is signed with the playback token and valid only for that session.
  4. Client-side decryption — the browser’s Web Crypto API decrypts segments in memory and feeds them to the video element. Keys are not persisted to disk.

Why multi-key matters

Single-key encryption (the simple model used by many platforms) means: one video, one key, one URL. If that URL leaks, the entire video is decryptable forever.

Multi-key per-batch encryption means: one video, many keys, many short-lived URLs. If a URL leaks, only that batch (about 60 seconds of footage) is exposed. The next batch requires a new key request, which the leaker can’t make without a fresh playback token.

This raises the cost of piracy substantially. Automated rip tools that work against single-key platforms (yt-dlp variants, browser-extension downloaders) need to be re-engineered for every multi-key target — and most don’t bother.

Signed playback tokens

Every embed token has metadata:

  • Allowed origins (your domain whitelist)
  • Optional viewer identifier (used for dynamic watermark on Enterprise)
  • Expiration window (default 24 hours)
  • Rate limit hints

The signing key is server-side only. Forged tokens fail verification at request time.

If you serve gated content (members-only, course access), your application generates a fresh embed token per authenticated session, so the token expires when the session expires. AVCaption’s REST API exposes embed token generation for Enterprise customers.

Domain whitelisting

By default, every embed iframe is hotlinked-only — the browser sends a Referer header with the embedding origin, and AVCaption’s stream API validates that origin against your whitelist before issuing the master playlist.

For Premium and Enterprise tiers you can specify exactly which domains are allowed. Anyone embedding the iframe on a non-whitelisted domain gets a 403 immediately.

This is the layer most piracy stops at: scrapers that lift your iframe URL and embed it on a different site simply get a 403 and the player never loads.

How this compares to other platforms

Approach Examples Strength When it fits
Signed URL only Wistia, basic CF Stream paths Weakest — full video decryptable if URL captured Marketing video, low-piracy-risk
Single-key AES-128 Bunny Stream, CF Stream encrypted paths Strong against casual hotlinking; one captured key + token decrypts the whole video Casual gated content
Multi-key AES-128 AVCaption Rotating keys per batch — a captured key only exposes ~60 seconds Self-produced paid content
Widevine / PlayReady DRM VdoCipher, JW Player Enterprise Strongest — hardware-bound license servers; required for studio-licensed content Contract-mandated DRM

For courses, gated tutorials, paid membership content, B2B training, and internal video — multi-key AES-128 is the right tradeoff. DRM is overkill, single-key is too thin. The full DRM vs encryption breakdown covers the decision.

Get started

Want to see encrypted segments in action? Upload a test video — the first 60 seconds is enough. Open DevTools, watch the .m3u8 and .m4s requests fly, and try yt-dlp against the embed URL: the segments come down encrypted and unplayable without the rotating per-batch keys. The free tier ships the full multi-key stack on every video; encryption is on by default, no toggle needed.

Frequently asked questions

What encryption standard does AVCaption use? +
AES-128 (Advanced Encryption Standard, 128-bit key) applied at the HLS segment level. The same standard used by online banking and most major streaming services. AVCaption rotates keys per segment batch (typically every 10 segments) so a leaked key only exposes a 60-second window.
Is AES-128 enough, or do I need DRM (Widevine/PlayReady)? +
For self-produced content (courses, tutorials, B2B training, internal videos, paid memberships) — AES-128 multi-key plus signed URLs and domain whitelisting is enough. DRM is required when distributing studio-licensed content under contractual obligation.
Can a viewer extract the encryption key from their browser? +
The key is delivered to the player via a signed URL valid for one playback session. A determined attacker can intercept it via dev tools, but the key only decrypts a small batch of segments. AVCaption's multi-key rotation means full-video extraction requires capturing a fresh key for every batch, every session — making automated piracy expensive.
← content.back_to_index