HN Reader

I also recommend an insightful talk by the author of the article, delivered at a Chaos Computer Club (CCC) event (GPN, Gulaschprogrammiernacht) on this topic. Unfortunately, it's only available in German, but it's definitely worth watching: https://media.ccc.de/v/gpn22-382-kein-kinoerlebnis-ohne-korr...

„No cinema experience without correct certificate management... A look behind the scenes of a cinema with a digital projector system, how distributors deliver films to cinemas with end-to-end encryption, and how films are protected from piracy. In addition to an overview of projector technology, the presentation will demonstrate the file format and manual decryption of film data.“

Edit: I just realized that the author of the article also delivered the recorded talk, adapted my comment.

Even with all of this onerous encryption and DRM, it's not hard to find pirated copies of movies. It makes me think that the sacrifice in ownership rights for the theaters over their equipment isn't worth it.

It's remarkable that they do all this in the context of box office revenues cratering. In 2024 American theaters has less gross ticket sales than they did in 1982, in constant dollars. The whole thing of movie theaters is just over.

Packaging DCPs used to be a massive faff. (it might still be one)

Basically they are a tar[1] of images with a bunch of audio streams for different speaker configurations. depending on the quality settings, they can be encoded for higher colour space (ie 16 bit log per channel)

Even with lossless jpeg2000, these packages can be huge.

But, back in 2011, the biggest problem was encoding jpeg2000 required hardware to get anything near realtime performance. (I also think there were dedicated DCP packaging machines, but I never actually saw one.)

One of my colleagues decided the best way to ship the finalised movie was to open up an NFS port on sohonet and let the technicolor hook the DCP packager directly.

it worked, but our CTO diplomatically asked them to stop.

[1] not actually but conceptually similar

Hi, asdcplib author here (mentioned in the article.) Excellent writeup of DCP and related tech. FYI the colorspace of an SDR DCP MXF file is X'Y'Z' with gamma 2.6 (see SMPTE 428-1.) Other MXF formats (i.e., not cinema) use a wide variety of colorspaces. Despite the huge range of XYZ, DCP image files are usually constrained to code values that fall within P3 (again, SDR.) The HDR applications are more interesting.

Upon reading the comments: • DCP is a B2B format. DCP usage is licensed by contract, not EULA. Please keep these important differences in mind when commenting on DRM. • Decrypt, decode, color processing, watermark occurs in FPGA. If you think that sounds hard, remember that all of this tech was originally deployed 20 years ago. Moore's law has made our lives much easier since! • Frame-by-frame encipherment, rather than whole stream, better supports random access and the famous tobacco intermissions popular in the EU.

>Encrypted DCPs use Forensic Watermarks which contain the serial number of the projection system. So if a recorded copy of a movie appears online, the theatre will have to answer serious questions and may never get movies again.

Is this not as simple as dumping the same movie from two different projectors, diffing the output, then obfuscating the watermark?

"Standards that have to be purchased". Someone is just trying to fleece the participants. That's what whole DRM is about most of the time.

JPEG 2000 for each frame? I wonder what they use for decompression. JPEG 2000 decompressors are really slow. Most couldn't keep up with frame rate without GPU support.

How are groups getting the high quality digital dumps of some movies then?

I'm confused why it's encrypted as a JPEG image per frame instead of one AES encrypted video file. Since the same AES key is used for each frame it wouldn't add any additional security imo

> The video stream is encoded as one single JPEG2000 picture per frame. Each frame is encrypted with the same static AES key.

Is this not a problem? It’s not a good idea to reuse the same key to encrypt very similar files. Similar to ECB. See the famous penguin https://words.filippo.io/the-ecb-penguin/

I’m surprised they don’t use something like XTS commonly used for disk encryption. It derives a unique key for each block/frame and allow you to access each individual blocks/frames non sequentially.

Fascinating read and I think an accessible presentation of a lot of the concepts / framework and mechanics of this type of system.

> 31. May 2024

I’m trying to understand the timeline here; the article was originally written last year and the latest spec is also from 2024 but the article has a link to this HN thread created yesterday?

Maybe someone with more knowledge could comment on what happened here: https://wikileaks.org/sony/docs/05/docs/Digital%20Cinema/Dig...