Why Are Pack Headers Unencrypted in CSS VOB Files?

This article examines why the Content Scramble System (CSS) on DVD-Video leaves pack and packet headers unencrypted within VOB (Video Object) files. While the underlying audiovisual data is scrambled to prevent unauthorized copying, critical container-level metadata remains in plaintext. As detailed below, this design choice was dictated by the structural requirements of MPEG-2 Program Streams, the need for efficient hardware demultiplexing, real-time audio/video synchronization, and the mechanics of encryption signaling.

MPEG-2 Program Stream Architecture

A VOB file is fundamentally an MPEG-2 Program Stream (PS). In this specification, continuous multimedia data is divided into self-contained units called Packs, each typically 2,048 bytes to align precisely with standard DVD sector sizes. Each Pack begins with a 14-byte Pack Header and contains one or more Packetized Elementary Stream (PES) packets, which consist of a PES header followed by the actual payload (such as MPEG-2 video, AC-3 audio, or sub-picture subtitles).

CSS was engineered specifically to protect the intellectual property contained in the audio and video elementary streams, not the container format itself. Therefore, CSS applies encryption exclusively to the payload data of specific PES packets, leaving all higher-level structural headers unencrypted.

Hardware Demultiplexing and Routing

When the DVD standard was finalized in the late 1990s, consumer DVD players relied on low-cost, fixed-function hardware decoders with limited memory and compute power. Leaving headers unencrypted enabled stream demultiplexing to occur prior to decryption:

• Stream Identification: The PES header contains a Stream ID indicating whether the enclosed data is video, a specific audio track, or subtitle data. Plaintext headers allow the hardware demultiplexer to instantly route packets to their corresponding decoders without needing a CSS decryption core at the front of the pipeline.
• Selective Decryption: Not all streams inside a VOB are encrypted. For example, navigation packets (PCI and DSI) and certain audio formats are typically left uncompressed and unencrypted. The player determines whether to invoke the decryption hardware by inspecting the PES header.

Audio/Video Synchronization and Trick Play

MPEG-2 playback relies on strict timing mechanisms that must be read continuously by the drive and processor:

• Clock References (SCR): The Pack Header contains the System Clock Reference (SCR), which synchronizes the player's internal clock with the multiplexer's clock.
• Presentation and Decode Timestamps (PTS/DTS): PES headers contain PTS and DTS markers that instruct the decoders exactly when to decode and display a specific frame or audio sample.

If these timestamps were encrypted, seeking, fast-forwarding, rewinding, or recovering from read errors would require continuous real-time decryption and decryption-state tracking across non-sequential reads. Plaintext headers allow DVD drives to quickly scan sectors, locate keyframes, and maintain temporal alignment with minimal computational overhead.

Signaling the Encryption State

The PES header itself contains the mechanism used to signal CSS encryption. Within the optional PES header extension, standard MPEG-2 provides a two-bit field known as the PES_scrambling_control field.

CSS utilizes these bits to notify the playback hardware whether the payload is scrambled and which key generation rule to apply:

• 00 denotes an unencrypted payload.
• 01, 10, or 11 specify scrambled states and indicate how the decrypter should handle specific key shifts.

If the PES header were encrypted, the playback system would face a circular dependency: it would not be able to read the scrambling control bits to determine that the packet requires decryption, nor would it know which parameters to pass to the CSS decryption engine.