Paid video must not be trivially downloadable, and legitimate viewers must not notice the protection. Where does that trade-off sit?
Paid video streaming DRM raises the cost of copying rather than making copying impossible. Start with signed short-lived URLs, add encrypted segments, and use DRM when keys must stay outside application code, while budgeting for licence latency and unsupported devices.
7 min readUpdated 2026-08-15
0
Answer
Short answer
Use short-lived signed access, encrypted HLS or DASH segments, and DRM for premium content; accept that the goal is copy resistance and licence control, not perfect prevention.
Was this answer helpful?
Likely follow-ups
→One account is streaming from four countries at once. Which control handles that, and what is its false-positive rate on a family?
→How do you keep the licence request out of a two-second startup budget when the licence server is in one region?
→A device cannot do hardware-backed protection. What do you serve it, and what does the rights holder need to have agreed to?
→A copy of a new release appears online six hours after launch. Walk through what you can determine from the file itself.
A film appears on a file host six hours after release. Before designing anything, work out what the person did, because the answer determines where protection is worth buying.
It is almost never a broken cipher. There are two routes in practice. Either they scraped a manifest and pulled the segments down with ordinary tooling, because the segments were fetchable by anyone holding the URL. Or they held a legitimate account, played the film, and captured the decoded output on the way to a screen.
Those two have wildly different costs to defeat and wildly different costs to inflict. The first is a design defect and closing it is cheap. The second cannot be closed at all, because the video has to become visible photons for the product to work. Any answer that promises to prevent it is wrong, and an interviewer who has shipped a video product knows that.
So the honest framing, which is also the useful one: you are not preventing copies, you are setting a price. Everything below is a tier on that price, and the design question is which tier your content is worth.
The tiers, priced by what they cost an attacker
Nothing. Segments and manifests are static files behind public URLs. A single command-line tool downloads the manifest, walks the segment list, and concatenates. Cost: minutes, and no expertise. A paid catalogue sitting here has a distribution problem, not a piracy problem.
Signed, short-lived, session-bound URLs. The manifest and every segment carry a signature with an expiry and a binding to the session that requested them. Now a URL shared in a forum is dead in five minutes, and pulling the whole film requires an authenticated session that keeps refreshing. Cost: a script and a subscription. This is the floor, not a strategy.
Encrypted segments with keys fetched over an authenticated channel. Segments are encrypted, and the player asks an endpoint for the key, presenting its session. HTTP Live Streaming has supported exactly this shape for years, with the key referenced from the playlist. Cost: the same authenticated script now also fetches the key, because anything your player can request, an attacker's script can request. Many teams believe this tier is DRM. It is not.
A DRM system, where the key never reaches your code. The distinction that matters is not that the content is encrypted, it is who is allowed to hold the key. Here the licence goes to a content decryption module rather than to your JavaScript or your app. Decryption happens inside that module, ideally on a path where the decoded frames are never addressable by ordinary software, and output can be gated so that an unprotected display link does not receive high-value content. Cost: defeating a hardware-backed pipeline, or falling back to filming the screen. That gap in cost is the entire value of DRM, and it is the one sentence a candidate must be able to say.
Forensic watermarking. It prevents nothing at all. It embeds a per-session identifier in the delivered video so that a leaked file names the account it came from. That converts an unpreventable problem into an enforceable one, which is why rights holders ask for it on high-value releases even though it is not protection in any technical sense.
Why you package the catalogue once
The reason all this is affordable is common encryption. The container-level encryption of the media is standardised, and the DRM systems differ only in how a licence is acquired. So one encrypted copy of an asset can carry key identifiers for several DRM systems at once, and the player picks whichever its platform supports.
Without that, you encode and store the catalogue separately per DRM system, which multiplies your storage and your transcoding bill by three and gives your cache three copies of every segment to keep warm. With it, you store one set of segments and run several licence paths. In the browser the acquisition is mediated by Encrypted Media Extensions; on other platforms it is the native equivalent. You will still need to support three ecosystems in practice - browsers, Android, and Apple's platforms - but the cost is three licence integrations, not three catalogues.
Loading diagram…
The line worth studying is the last one. The licence lands inside the decryption module and not in the player, which is the only structural difference between this and the encrypted-segments tier above it - and it is the difference that costs an attacker orders of magnitude more.
What the viewer notices, which is not the encryption
Decryption is not what viewers feel. Two other costs are.
The first is the licence round trip. It sits between pressing play and the first frame, and if your licence server is in one region while your viewers are worldwide, you have added a quarter of a second or more to a startup budget that was already tight. The fix is structural rather than clever: overlap the licence request with the manifest and first-segment fetches so it is not serialised behind them, and put licence issuance close to viewers even when entitlement lookups are central.
The second is the device matrix, and this is where the trade-off genuinely lives. Rights holders attach protection requirements to resolutions, so the highest rungs of your ladder are typically contractually restricted to platforms that can do hardware-backed protection. A viewer on an older tablet therefore gets a lower rung, and what they perceive is not "my device lacks a security level", it is "why does this look soft". That is the protection being noticed, and no amount of engineering hides it. It is a commercial negotiation dressed as a technical constraint, and treating it as one is the senior answer.
There is a third cost that is invisible to viewers and expensive to you: the licence path is now a hard dependency in the playback critical path. If licence issuance fails, nothing plays, even though the segments are cached and the network is fine. That deserves its own availability target, its own alerting, and a considered answer about what happens to a viewer mid-film when a licence renewal fails.
The control that catches the real leak
For most subscription services the largest revenue loss is not a torrent, it is credential sharing, and DRM is entirely irrelevant to it. A shared password produces perfectly legitimate, fully licensed playback by an unauthorised person.
The controls are concurrency limits and device registration: how many simultaneous streams an account may hold, and how many distinct devices it may bind in a period. Both are policy decisions with real false positives, because a family on holiday in three countries looks exactly like a shared password. Which is why the limits are usually generous, enforced softly, and tuned against churn rather than against theft.
Naming this is what separates a systems answer from a component answer. The engineering question was about encryption; the business question was about a copy escaping, and the two have different largest causes.
The single line most candidates miss
Encrypting the stream and stopping there. A key your own client code can read is a key an attacker's client code can read, so encryption alone raises the cost of a copy from minutes to an afternoon. A key that only a decryption module can hold raises it by a factor you can charge for. Everything else about DRM is licensing and platform support; that one distinction is the mechanism.
A bicycle lock is the right mental model for the whole design, with its limits stated: it does not stop somebody with an angle grinder, and it is not meant to. It makes your bicycle a worse target than the unlocked one beside it, and it makes the theft take long enough to be noticed. Content protection that understands itself as a lock rather than as a vault makes sensible decisions about where to spend.
The pixels must reach a screen, so protection sets a price rather than a prohibition. The one real technical threshold is whether the decryption key can be read by code you shipped, and the costs viewers feel are the licence round trip and the resolution their device is allowed to have.