Login

PSSH stands for Protection System Specific Headers and is a part of a so called DRM Signaling. PSSH come as a so called PSSH box (an envelop) which contains DRM provider-specific PSSH data.

PSSH, PSSH box, and DRM signalling

If you use digital rights management (DRM) to protect video content, chances are that earlier or later you will run accross the term PSSH. It stands for Protection System Specific Headers and is a part of a so called DRM signalling. In most cases, you don’t need to deal with PSSH directly, but in case you want to learn more about the topic, this article provides useful starting points.

What is PSSH?

When a video content is protected with DRM, the content is encrypted and metadata is added to the content. The process of including such metadata is referred to as DRM signalling.

PSSH is a standardized container that holds metadata specific to the protection system employed for securing digital content. Hence PSSH is a part of DRM signalling.

PSSH DOES NOT containt the enryption key itself (it’s a secret), but it contains the necessary information about encryption, such as the key ID, the encryption scheme, and other information that is needed to obtain the key from a license server.

PSSH is ultimately defined in "ISO/IEC 23001-7:2023 MPEG systems technologies — Part 7: Common encryption in ISO base media file format files" (see below).

How does it work?

When a packager applies DRM protection to a video, it encrypts the content but it also adds some metadata to the content, usually in the form of a container called PSSH Box. There is a separate PSSH box for each DRM system used to protect the video (i.e., one video can contain multiple PSSH boxes - one per DRM system).

PSSH Box contains DRM system-specific PSSH Data. For example, for PlayReady, the PSSH Data is the PlayReady Header, defined here: https://learn.microsoft.com/en-us/playready/specifications/playready-header-specification.

Packagers usually do not generate encryption keys themselves, but request them from a secure Key Service, acting here as a PSSH generator. When a packager requests a key from a Key Service, it also received a PSSH box for the DRM system used to protect the video. The Key Service generates the key and the PSSH Box and returns them to the packager.

How exactly the PSSH box is returned, is defined by the respective Key Acquisition Protocol, such as AWS SPEKE or Widevine Common Encryption.

When a player plays the content, it detects that the content is encrypted and reads the respective PSSH box. The player then uses the information in the PSSH box to obtain the key from a license server.

PSSH Decoder

PSSH box is a binary structure, so it’s not easy to read it.

Axinom offers a set of free tools that can parse the PSSH box and show the contents in a more readable way.

PSSH Box Decoder (https://tools.axinom.com/decoders/PsshBox) parses the PSSH box and shows the contents.

PSSH Data Decoder (https://tools.axinom.com/decoders/PsshData) parses DRM system-specific PSSH data and shows its content.

Note
 To use the tools you have to register at https://portal.axinom.com.

Details

In this chapter we cover deeper technical details on PSSH box and PSSH data.

DRM signalling details

The format for PSSH Box is DRM system-specific.

For PlayReady and Widevine, the PSSH Box format is essentially the same. The only differences are:

  • The system ID depending on the DRM system

  • The format of the nested PSSH Data

For FairPlay, the DRM signalling is usually either the full #EXT-X-KEY tag that can be inserted to an HLS manifest or the URI attribute of that tag.

(This depends on the Key Acquisition Protocol used to acquire the key.)

The data contained there is basically the Key ID and an optional initialization vector (IV).

Example:

#EXT-X-KEY:METHOD=SAMPLE-AES,URI="skd://302f80dd-411e-4886-bca5-bb1f8018a024:77FD1889AAF4143B085548B3C0F95B9A",KEYFORMATVERSIONS="1",KEYFORMAT="com.apple.streamingkeydelivery"

The following IDs are reserved for specific DRM systems (see also DRM Systems):

Table 1. DRM systems identifiers as defined by DASH-IF (https://dashif.org/identifiers/content_protection/)
DRM Technology Identifier (System ID)

Widevine

edef8ba9-79d6-4ace-a3c8-27dcd51d21ed

FairPlay

94ce86fb-07ff-4f43-adb8-93d2fa968ca2

PlayReady

9a04f079-9840-4286-ab92-e65be0885f95

PSSH Data details

The format for PSSH Data is DRM system-specific.

PlayReady

PSSH Data is the PlayReady Header, defined in the PlayReady Header Specification.

Example of a PlayReady Header
<WRMHEADER xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader" version="4.3.0.0">
  <DATA>
    <PROTECTINFO>
      <KIDS>
        <KID ALGID="AESCBC" VALUE="PV1LM/VEVk+kEOB8qqcWDg=="></KID>
        <KID ALGID="AESCBC" VALUE="tuhDoKUN7EyxDPtMRNmhyA=="></KID>
      </KIDS>
    </PROTECTINFO>
    <LA_URL>http://rm.contoso.com/rightsmanager.asmx</LA_URL>
    <DS_ID>AH+03juKbUGbHl1V/QIwRA==</DS_ID>
  </DATA>
</WRMHEADER>

Widevine

Widevine’s PSSH Data full specification is not public.

Some pieces of it can be found in open sources, such as the Shaka Packager Git repository.

More detailed version of the definition is available to Widevine partners (such as Axinom), but even this definition is not complete.

FairPlay

FairPlay has no known public PSSH Data specification.

Player side details

The PSSHs are first analyzed both by the player and (in a browser) by the media framework (MSE/EME). Usual workflow is that MSE/EME is given some content, it finds it’s encrypted and then automatically reads the PSSH from the fMP4 files and passes it on to player code, where player should then take further action.

Then, a CDM received PSSH as a part if "InitData". It possibly parses it and adds it to the license request, so the license service can also take a necessary action.

Note
 Recommended workflow nowadays is though that PSSH should only be in manifest and not in fMP4 files. And with that, players should themselves be proactive and read it from the manifest and utilize the info later for license request generation. Players can go even that far to generate a full PSSH box themselves, based on the key ID and encryption scheme, which are also available elsewhere.

Versions of the PSSH Box

There are two versions of PSSH box: Version 0 and Version 1.

While the Version 0 is the most commonly used, the Version 1 is the "recommended" one, but it doesn’t have wider adoption yet at the time of writing.

In Version 1, the PSSH box with System ID `1077efec-c0b2-4d02-ace3-3c1e52e2fb4b" is called the "common PSSH box" - it’s a step towards standadization for all DRM systems.

This is defined in EME spec "cenc" Initialization Data Format.

The Version 0 is different only in that it doesn’t contain the KID-count and KID list compared to what is shown in the above link.

Guidelines for PSSH usage

DASH-IF defines/recommends how PSSH should be used.

Note
 While this guide regulate usage of PSSH in a DASH manifest (in the element <cenc:pssh>), it does not regulate its usage in HLS.

PSSH and Axinom DRM

Axinom Key Service generates PSSH boxes for the respective DRM systems and returns according to the used key acquisition protocol. If you use Axinom tools, such as SPEKE and Widevine Common Encryption, you can see the returned PSSH boxes.

Axinom Encoding, when DRM is used, generates the necessary PSSH boxes and includes them to the packaged content. Note: you can’t pass a ready PSSH box to Axinom Encoding.

Axinom License Service receives PSSH boxes as a part of the license request and processes them according to the rules of the DRM system used.

References

Axinom uses cookies for analytics and personalized content. By continuing to browse this site, you agree to this use. Learn more