Hacker News Reader

Comment by Cyph0n | Hacker News Reader

For Netflix specifically; it’s because the groups that rip 4K content from Netflix burn a device (i.e. a Widevine L1 key). This is why they typically release 4K Netflix shows in batches.

Here is a good thread on the topic: https://www.reddit.com/r/Piracy/comments/17ez7mi/how_come_it...

View on HN

What I've noticed about Netflix's supposedly 4k content is that it looks like crap compared to the same show downloaded through illicit means (and viewed on Plex or something else).

What's the deal with Netflix's not-very-good 4k streams? Colour quantization or something? It's not just a one-off, why do 4k netflix shows look like rubbish compared to a moderately encoded whatever from bittorrent?

Probably extreme compression, their 4K streams are very low bandwidth.

Must be that way - watching "an evening" (yes, i just made up a time unit) of Netflix consumes 1/4 to 1/3 of the bandwidth "an evening" of consuming content on AppleTV+.

So, about 10GB or less on Netflix to 30GB or more on AppleTV+, dissected by DPI on my TP-Link Omada Gateway.

And indeed, i think it shows - i can't notice any banding or moire effect on pretty much any AppleTV+ content, while it is as clear as night and day that Netflix compresses the hell out of their content.

It depends. The most common reason is bitrate - the non-Netflix could have been ripped from another source (BD), or even from another service that has rights to the show in a different market (with higher bitrate).

The other trick some groups use is so-called hybrid releases. This involves combining video and audio from multiple sources to achieve the best possible quality. These are usually explicitly tagged as HYBRID, and afaik mostly applies to 4K remuxes.

Semi-informed guess: Even when the rip comes from the same source (and not e.g. Blu-ray), they have a blazing fast internet pipe and/or a custom client that locks into the maximum bitrate -- while your residential connection and/or the local PoP's available capacity make your stream use a lower bitrate.

All video encoders have bit–rate — target number of encoded bits per second — as a tunable knob. Lossiness is compensated to match the target bit–rate. When a video is encoded with a lower bit–rate, it produces a smaller file that looks worse. Resolution almost doesn't matter, if your bit–rate is so low that the encoder doesn't have a chance of encoding pixel–level detail.

Bittorrent pirates may source shows from Netflix but they may also source them from other places with higher bit–rate encodings.

Thank you for sharing the breadcrumb~

How does Netflix detect "suspicious" activity? Does $NFLX allow 4k streaming over GrapheneOS? If so, could you pin a different certificate and do some HTTP proxy traffic manipulation to obfuscate the device (presumably an Android phone) identity or otherwise work around the DRM?

I want to understand more about this but unfortunately the reddit thread is bits and pieces scattered amongst clueless commentary, making it challenging to wade through.

I honestly have no clue! This is just a tidbit I randomly learned about haha.

They can trace a torrented 4K piece of content to the device (or private key) that ripped it using A/B watermarking.

See AWS offering: (and probably what they use for Prime Video, Netflix has their own)

  For large-scale per-viewer, implement a content identification strategy that allows you to trace back to specific clients, such as per-user session-based watermarking. With this approach, media is conditioned during transcoding and the origin serves a uniquely identifiable pattern of media segments to the end user. A session to a user-mapping service receives encrypted user ID information in the header or cookies of the request context and uses this information to determine the uniquely identifiable pattern of media segments to serve to the viewer. This approach requires multiple distinctly watermarked copies of content to be transcoded, with a minimum of two sets of content for A/B watermarking. Forensic watermarking also requires YUV decompression, so encoding time for 4K feature length content can take upwards of 20 hours. DRM service providers in the AWS Partner Network (APN) are available to aid in the deployment of per-viewer content forensics.

<https://docs.aws.amazon.com/wellarchitected/latest/streaming...>

They also use a traitor tracing scheme (Tardos codes) such that if multiple pirates get together to try and remove the watermark they will fail, you would need an unreasonably large number of pirates to succeed for some length of time.

To what extent does this watermarking survive transcoding? Would not transcoding multiple times possibly affect it?

> They also use a traitor tracing scheme (Tardos codes) such that if multiple pirates get together to try and remove the watermark they will fail, you would need an unreasonably large number of pirates to succeed for some length of time.

Why?

> To what extent does this watermarking survive transcoding? Would not transcoding multiple times possibly affect it?

They are designed to survive being recorded by a phone at an angle. The embedding is only 1-bit per segment which can be multiple megabytes.

> Why?

Tardos codes scale as the square of the number of traitors times a constant. For example, a movie would typically have 2000 segments -> 2000 bits of encoding. By my calculation, at around 7 traitors some start to skate by detection. And there are ways to make detection additive across leaked content, so with another 2000 all 7 will get caught. This is because while they may not score highly enough to be reliably accused, they will be under suspicion, and that suspicion can later be enhanced.

To be clear, what the traitors are doing is pooling all the segment versions they have available to them, and adversarially choose a segment at random. This is the best strategy they have, a close second is to choose the segment that the majority have.

Trying to remove the actual 1-bit watermark from the segment isn't typically feasible. Every segment will have a unique adjustment to encode it. The embedding algorithm will take a secret key.

That's fascinating, thank you.

> They are designed to survive being recorded by a phone at an angle.

Any idea what this looks like? I assume it's not visible to the human eye, but being able to survive this level of degradation is quite impressive.

It depends on which vendor they're using.

It generally occurs as patterns which are slightly in the noise. Good systems pick locations where its easier to hide and turn it off when the scene would expose it. Usually when badly done increasing sharpness in a scene can help reveal it.

Basically, if you can damage the watermark the picture quality is bad enough that it's harming your viewing. You need to compress into crap SD quality to make it hard to detect and even then you'll get something.

You don't even need a complete pattern, if you can get enough fragments you can narrow down the possible identities until you have a high match probability. I.e. partial fingerprints or DNA match.

My understanding is that it has gotten fairly complex. Don't know if they still use this particular facet but look at the Fourier-Mellin transform: <https://sthoduka.github.io/imreg_fmt/docs/fourier-mellin-tra...>

They don't use the highest frequencies as those watermarks are easy to obliterate, and they don't use the lowest frequencies as those would noticeably affect quality, the focus is generally on the mid range frequencies. However for A/B watermarking in particular which involve 1-bit watermarks, low frequencies may actually be fair game.

Keep in mind that when embedding watermarks of significant size (>100 bits) as for example if you want to create a camera that includes the serial of the device in every photo, error correcting codes would also be used. For 1-bit watermarks the error correction is likely ad-hoc and involves constructing some mathematical object (for example, a few real numbers derived from frames of a segment) which remains approximately fixed through transformations, you can afford to be wasteful.

The main character holds an apple in her hand. The apple is either pink or bright red depending on the LSB of your user ID. Without comparing several rips, you can't tell this is happening.

Netflix does not encode content per-user, it's all static content on CDNs

A/B watermarking is about static content on CDNs...

For every segment in a video there will be two versions. Every user will get a unique sequence of segments served to them.

Netflix puts flat MP4s on the CDN, the segments all reference different offsets within the MP4.

Have you inspected the contents of their CDN servers? Because assembling an mp4 on the fly from segments is not difficult. Especially if they condition them to have identical sizes.

I have indeed inspected the contents of their CDN servers. The URLs have an auth token in them but you can edit the range parameters to grab the whole mp4 in one go without invalidating the auth.

Then this is either an exploit or more likely the mp4 file is virtual. You can find out if you are so inclined by grabbing it from two separate accounts using two separate devices (or keys) and then compare how many of the segments are identical.

Also, I assume the file in question is 4K content. Don't know about how they treat other types.

The normal way to do it would be to deliver different byte ranges per user

Wait, that’s a brilliant way of encoding a watermark without having to embed it within a stream per user.

If a single video has say 100 segments, you get more than enough unique combinations to guarantee uniqueness. There would of course have to be a mapping between user/device ID and segment order.

Isn't it trivial to know all the segments if they are static?

A DRM system is, abstractly, a black box that contains some initial static key material, which is used to identify+authenticate the device and load in more keys at runtime, typically over some network protocol. The DRM uses those dynamically provisioned keys to decrypt the content.

For hardware DRM schemes, the initial key material is typically provisioned during manufacturing.

Since the server-side is able to identify the client device, they can in theory fingerprint the content if they want to. That way if someone cracks and shares the content, they can look at the fingerprint and figure out which device (and which account) leaked it - and then ban them.

I've never seen direct evidence that Netflix fingerprints their 4K content (although I've never properly looked), so I suspect the device-burning thing might be a bit of an urban legend. But it is technically plausible.

If it wasn't real, Netflix would leak 4Ks more frequently. We're inferring by a third-order effect.

Netflix does not allow 4k streaming to GrapheneOS. Every piece of software and hardware in the signal chain must be Hollywood–approved, including your OS, GPU and monitor.

and its easy enough to figure out who ripped the web-dl, because you can have each frame copied into 2 slightly different but functionally identical versions (or perhaps just a longer GOP, but still the same). Create 32 of these sets of 2 (i.e. bits, or even do it for every 32 sets in the video) and assign every user a unique set of 32 "bits" and you'll have the ability to uniquely identify every web-dl (as by definition they aren't modifying the streams) to the user who downloaded it and just a cost of 1x the storage vs not doing anything.

Reply on news.ycombinator.com