Digital Cinema System Specification: Compliance Test Plan

Version 1.4b 1.4.1
(build c010086)
Approved for Distribution   July 18, 2023 April 24, 2024
Digital Cinema Initiatives, LLC, Member Representative Committee

Front Matter 🔗

Important Notice 🔗

This document is a Compliance Test Plan developed by Digital Cinema Initiatives, LLC (DCI). DCI is the owner of this Compliance Test Plan for the purpose of copyright and other laws in all countries throughout the world. The DCI copyright notice must be included in all reproductions, whether in whole or in part, and may not be deleted or attributed to others. DCI hereby grants to its members and their suppliers a limited license to reproduce this Compliance Test Plan for their own use, provided it is not sold. Others must obtain permission to reproduce this Compliance Test Plan from Digital Cinema Initiatives, LLC.

This Compliance Test Plan is intended solely as a guide for companies interested in developing products that can be compatible with other products developed using this document and [DCI-DCSS] . Each DCI member company shall decide independently the extent to which it will utilize, or require adherence to, this Compliance Test Plan. DCI shall not be liable for any exemplary, incidental, proximate or consequential damages or expenses arising from the use of this document. This document defines only one approach to compatibility, and other approaches may be available to the industry. Only DCI has the right and authority to revise or change the material contained in this document, and any revisions by any party other than DCI are unauthorized and prohibited.

Using this document may require the use of one or more features covered by proprietary rights (such as features which are the subject of a patent, patent application, copyright, mask work right or trade secret right). By publication of this document, no position is taken by DCI with respect to the validity or infringement of any patent or other proprietary right. DCI hereby expressly disclaims any liability for infringement of intellectual property rights of others by virtue of the use of this document. DCI has not and does not investigate any notices or allegations of infringement prompted by publication of any DCI document, nor does DCI undertake a duty to advise users or potential users of DCI documents of such notices or allegations. DCI hereby expressly advises all users or potential users of this document to investigate and analyze any potential infringement situation, seek the advice of intellectual property counsel, and, if indicated, obtain a license under any applicable intellectual property right or take the necessary steps to avoid infringement of any intellectual property right. DCI expressly disclaims any intent to promote infringement of any intellectual property right by virtue of the evolution or publication of this document.

DCI gratefully acknowledges the participation and technical contributions of Sandflow Consulting LLC, San Mateo, CA, https://www.sandflow.com/ , in the preparation of this document.

DCI gratefully acknowledges the participation and technical contributions of CineCert LLC, 2840 N. Lima St, Suite 110A, Burbank, CA 91504 https://www.cinecert.com/ , in the preparation of this document.

DCI gratefully acknowledges the participation and technical contributions of the Fraunhofer Institute for Integrated Circuits, IIS, Am Wolfsmantel 33, 91058 Erlangen, Germany, http://www.iis.fraunhofer.de/ , in the preparation of this document.

Table of Contents 🔗

  1. Chapter 1. Introduction
  2. Part I. Procedural Tests
  3. Part II. Design Evaluation Guidelines
  4. Part III. Consolidated Test Procedures
  5. Appendix A. Test Materials
  6. Appendix B. Equipment List
  7. Appendix C. Source Code
  8. Appendix D. Deleted Section
  9. Appendix E. GPIO Test Fixture
  10. Appendix F. Reference Documents
  11. Appendix G. Digital Cinema System Specification References to CTP
  12. Appendix H. Abbreviations
  13. Appendix I. Subtitle Test Evaluation and Pass/Fail Criteria
  14. Appendix J. OBAE Test Evaluation Requirements
  15. Appendix K. Summary of substantive changes

Table of Figures 🔗

  1. Figure 1.1 . Typical DCI Compliant System Configuration
  2. Figure 6.1 . Standard Frame Panel Designations
  3. Figure 6.2 . Audio Delay Timing
  4. Figure 7.1 . Pixel Structure 16 x 16 Array
  5. Figure 7.2 . Pixel Structure 8 x 8 Array
  6. Figure 7.25(a) . Sample aliasing artifacts
  7. Figure 7.25(b) . Sample ringing artifacts
  8. Figure 7.25(c) . Sample spatial discontinuities (jaggies)
  9. Figure 7.5 .27 Illustration of a fringing artifact (not to scale)
  10. Figure 7.5 .33. Location of the elements displayed when testing image frame rates (not to scale)
  11. Figure 7.5 .34. Location of the elements displayed when testing stereoscopic image frame rates (not to scale)
  12. Figure A.2.2 . Sync Count
  13. Figure A.2.8 . "NIST" 2K Test Pattern
  14. Figure A.2.10 . Black to Gray Step Series
  15. Figure A.2.11 . Black to White Step Series
  16. Figure A.2.12 . Color Accuracy Series
  17. Figure A.2.16 . Intra-Frame Contrast Sequence
  18. Figure A.2.20 . DCI Numbered Frame Sequence
  19. Figure A.2.39 . FM Constraints Begin (Encrypted)
  20. Figure A.2.53 . DCI_gradient_step_s_white_j2c_pt
  21. Figure A.2.222 . Sync Count with Subtitle Reticles
  22. Figure A.2.239 . Black frame with registration marks (not to scale)
  23. Figure A.2.245 . Frame with an active area (not to scale)
  24. Figure A.2.253 . Frame with horizontal, vertical and oblique white lines on a black background (not to scale)
  25. Figure A.2.254 . Frame with line segments, uniform gray square and zone plate
  26. Figure E.1 . GPIO Test Fixture Schematic
  27. Figure E.2 . GPIO Test Fixture Connector
  28. Figure J.1 . Visual contents of the OBAE Rendering Expectations test material

Table of Examples 🔗

  1. Example 2.1 . D-Cinema Certificate
  2. Example 3.1 . Packing List Example (Partial)
  3. Example 3.2 . checksig execution
  4. Example 3.3 . dsig_cert.py execution
  5. Example 3.4 . An X.509 certificate in PEM format
  6. Example 3.5 . dsig_extract.py execution
  7. Example 3.6 . KDM - AuthenticatedPublic area
  8. Example 3.7 . KDM - AuthenticatedPrivate area
  9. Example 3.8 . KDM - Signature area
  10. Example 3.9 . kdm-decrypt Usage and Output
  11. Example 4.1 . Asset Map
  12. Example 4.2 . Volume Index
  13. Example 4.3 . Packing List
  14. Example 4.4 . Composition Playlist
  15. Example 4.5 . MXF Partition Header
  16. Example 4.6 . Source Package structure
  17. Example 4.7 . Cryptographic Framework and Cryptographic Context
  18. Example 4.8 . Essence Descriptor for JPEG 2000
  19. Example 4.9 . Essence Descriptor for PCM Audio
  20. Example 4.10 . MXF Random Index Pack (RIP)
  21. Example 5.1 . Log Report Example
  22. Example 5.2 . Log Report Record Example
  23. Example 5.3 . Log Report Signature Example
  24. Example C.1 . dc-thumbprint execution
  25. Example C.2 . Using schema-check to check well-formedness
  26. Example C.3 . Using schema-check to check validity
  27. Example C.4 . kdm-decrypt execution
  28. Example C.5 . j2c-scan execution
  29. Example C.7 . uuid_check.py execution
  30. Example C.8 . dsig_cert.py execution
  31. Example C.9 . dsig_extract.py execution

Table of Tables 🔗

  1. Table 4.1 . Essence Container UL Values for D-Cinema
  2. Table 4.2 . Audio Samples Per Frame
  3. Table 4.3 . Image Structure Operational Levels
  4. Table 5.1 . Media Block Leaf Certificate Criteria
  5. Table 6.1 . List of Compositions with missing integrity pack items
  6. Table 7.5 .11(a) Black-to-white gray step-scale test pattern nominal luminance values
  7. Table 7.5 .11(b) Black-to-dark gray step-scale test pattern nominal luminance values
  8. Table 7.5 .14(a) HDR White (Peak)
  9. Table 7.5 .14(b) HDR White (Angular Nonuniformity)
  10. Table 7.5 .15(a) SDR White (Peak)
  11. Table 7.5 .15(b) SDR White (Angular Nonuniformity)
  12. Table 7.5 .16 Target HDR color luminances and chromaticities
  13. Table 7.1 . Measurement positions and tolerances for horizontal and vertical full screen off-axis performance measurements
  14. Table 7.5 .28(a) HDR black-to-white gray step-scale test pattern nominal luminance values
  15. Table 7.5 .28(b) HDR black-to-dark gray step-scale test pattern nominal luminance values
  16. Table 7.5 .31 Target SDR and HDR luminances
  17. Table 8.2 .14. List of Compositions and associated KDMs with mismatched content keys
  18. Table 11.1 . Test Session Data
  19. Table 11.2 . Test Sequences
  20. Table 11.3 . General family group information
  21. Table A.2 .292 Dark Gray Scale X′Y′Z′ 12-bit Codevalues
  22. Table A.2 .293 Dark Gray Scale X″Y″Z″ 12-bit Codevalues
  23. Table J.4.1 . Sync Test
  24. Table J.4.2 . Simple Bed Channel Routing (5.1)
  25. Table J.4.3 . Simple Bed Channel Routing (7.1DS)
  26. Table J.4.4 . Simple Bed Channel Routing (9.1OH)
  27. Table J.4.5 . '91OH' Bed - Gain Test
  28. Table J.4.6 . '91OH' Bed - Decorrelation Test
  29. Table J.4.7 . Pink Noise 13.1HT Bed with 3 Spoken Conditional Beds
  30. Table J.4.8 . Bed Remap Test (Source: 13.1HT Bed, Dest: 5.1, 7.1DS, 11.1HT, 9.1OH)
  31. Table J.4.9 . Mixing of Two Simultaneous Beds
  32. Table J.4.10 . Object Gain Test
  33. Table J.4.11 . Object Snap Test
  34. Table J.4.12 . Object Zone Gain Test (using ZERO/ONE gain flags)
  35. Table J.4.13 . Object Zone Gain Test (using decimal gain)
  36. Table J.4.14 . Object Spread Test
  37. Table J.4.15 . Object - Decorrelation Test
  38. Table J.4.16 . Multiple Objects (3) combined with Snap/Spread Test
  39. Table J.4.17 . Pan Sub-Block Test #2
  40. Table J.4.18 . 10 Simultaneous Objects, No Bed
  41. Table J.4.19 . 15 Simultaneous Objects, No Bed
  42. Table J.4.20 . 18 Simultaneous Objects, No Bed
  43. Table J.4.21 . 30 Simultaneous Objects, No Bed
  44. Table J.4.22 . 50 Simultaneous Objects, No Bed
  45. Table J.4.23 . 128 Simultaneous Objects, No Bed
  46. Table J.4.24 . 10 Simultaneous Objects, Quiet 9.1OH Bed
  47. Table J.4.25 . 15 Simultaneous Objects, Quiet 9.1OH Bed
  48. Table J.4.26 . 18 Simultaneous Objects, Quiet 9.1OH Bed
  49. Table J.4.27 . 30 Simultaneous Objects, Quiet 9.1OH Bed
  50. Table J.4.28 . 50 Simultaneous Objects, Quiet 9.1OH Bed
  51. Table J.4.29 . 118 Simultaneous Objects, Quiet 9.1OH Bed
  52. Table J.4.30 . Authoring Tool Info Test
  53. Table J.4.31 . Authoring Tool Info Test
  54. Table J.4.32 . Unknown Element Test
  55. Table J.4.33 . Unknown Element Test
  56. Table J.4.34 . User Data Test
  57. Table J.4.35 . User Data Test
  58. Table J.4.36 . Audio Description Test
  59. Table K.1 . CTP releases

Chapter 1. Introduction 🔗

Digital Cinema Initiatives, LLC (DCI) is a joint venture of Disney, Fox, Paramount, Sony Pictures Entertainment, Universal, and Warner Bros. Studios. The primary purpose of DCI is to establish uniform specifications for d-cinema. These DCI member companies believe that d-cinema will provide real benefits to theater audiences, theater owners, filmmakers and distributors. DCI was created with the recognition that these benefits could not be fully realized without industry-wide specifications. All parties involved in d-cinema must be confident that their products and services are interoperable and compatible with the products and services of all industry participants. The DCI member companies further believe that d-cinema exhibition will significantly improve the movie-going experience for the public.

Digital cinema is today being used worldwide to show feature motion pictures to thousands of audiences daily, at a level of quality commensurate with (or better than) that of 35mm film release prints. Many of these systems are informed by the Digital Cinema System Specification, Version 1.0, published by DCI in 2005. In areas of image and sound encoding, transport security and network services, today's systems offer practical interoperability and an excellent movie-going experience. These systems were designed, however, using de-facto industry practices.

With the publication of the Digital Cinema System Specification [DCI-DCSS] , and the publication of required standards from SMPTE, ISO, and other bodies, it is possible to design and build d-cinema equipment that meets all DCI requirements. Manufacturers preparing new designs, and theaters planning expensive upgrades are both grappling with the same question: how to know if a d-cinema system is compliant with DCI requirements?

Note: This test plan references standards from SMPTE, ISO, and other bodies that have specific publication dates. The specific version of the referenced document to be used in conjunction with this test plan shall be those listed in Appendix F .

1.1. Overview 🔗

This Compliance Test Plan (CTP) was developed by DCI to provide uniform testing procedures for d-cinema equipment. The CTP details testing procedures, reference files, design evaluation methods, and directed test sequences for content packages and specific types of equipment. These instructions will guide the Test Operator through the testing process and the creation of a standard DCI compliance evaluation report.

This document is presented in three parts and eight appendices.

1.2. Normative References 🔗

The procedures in this document are substantially traceable to the many normative references cited throughout. In some cases, DCI have chosen to express a constraint or required behavior directly in this document. In these cases it will not be possible to trace the requirement directly to an external document. Nonetheless, the requirement is made normative for the purpose of DCI compliance testing by its appearance in this document.

1.3. Audience 🔗

This document is written to inform readers from many segments of the motion picture industry, including manufacturers, content producers, distributors, and exhibitors. Readers will have specific needs of this text and the following descriptions will help identify the parts that will be most useful to them. Generally though, the reader should have technical experience with d-cinema systems and access to the required specifications. Some experience with general operating system concepts and installation of source code software will be required to run many of the procedures.

Equipment Manufacturers
To successfully pass a compliance test, manufacturers must be aware of all requirements and test procedures. In addition to understanding the relevant test sequence and being prepared to provide the Test Operator with information required to complete the tests in the sequence, the manufacturer is also responsible for preparing the documentation called for in Part II. Design Evaluation Guidelines .
Testing Organizations and Test Operators
The Testing Organizations and Test Operators are responsible for assembling a complete testing environment with all required tools and for guiding the manufacturer through the process of compliance testing. Like the manufacturer, Testing Organizations and Test Operators must be aware of all requirements and test procedures at a very high level of detail.
System Integrators
Integrators will need to understand the reports issued by Testing Organizations. Comparing systems using reported results will be more accurate if the analyst understands the manner in which individual measurements are made.

1.4. Conventions and Practices 🔗

1.4.1. Typographical Conventions 🔗

This document uses the following typographical conventions to convey information in its proper context.

A Bold Face style is used to display the names of commands to be run on a computer system.

A Fixed Width font is used to express literal data such as string values or element names for XML documents, or command-line arguments and output.

Examples that illustrate command input and output are displayed in a Fixed Width font on a shaded background: 

           
$ echo "Hello, World!"
Hello,
World!

1

Less-than ( < ) and greater-than ( > ) symbols are used to illustrate generalized input values in command-line examples. They are placed around the generalized input value, e.g. , <input-value> . These symbols are also used to direct command output in some command-line examples, and are also an integral part of the XML file format.

Callouts (white numerals on a black background, as in the example above) are used to provide reference points for examples that include explanations. Examples with callouts are followed by a list of descriptions explaining each callout.

Square brackets ([ and ]) are used to denote an external document reference, e.g. , [SMPTE-377-1] .

1.4.2. Documentation Format 🔗

The test procedures documented in Part I. Procedural Tests will contain the following sub-sections (except as noted)

Objective —
Describes what requirements or assertions are to be proven by the test.
Procedures —
Defines the steps to be taken to prove the requirements or assertions given in the corresponding objective.
Material —
Describes the material (reference files) needed to execute the test. This section may not be present, for example, when the objective can be achieved without reference files.
Equipment —
Describes what physical equipment and/or computer programs are needed for executing the test. The equipment list in each procedure is assumed to contain the Test Subject. If the equipment list contains one or more computer programs, the list is also assumed to contain a general purpose computer with a POSIX-like operating system ( e.g. , Linux). This section may not be present, for example, when the objective can be achieved by observation alone.
References —
The set of normative documents that define the requirements or assertions given in the corresponding objective.

1.4.3. Terms, Definitions and Abbreviated Terms 🔗

Media Block and Controlling Devices
This term refers to the combination of a Media Block (MB), Screen Management System (SMS) or Theater Management System (TMS), content storage and all cabling necessary to interconnect these devices. Depending upon actual system configuration, all of these components may exist in a single chassis or may exist in separate chassis. Some or all components may be integrated into the imaging device (see below).
High-Dynamic Range (HDR)
Refers to image content that conforms to the HDR-DCDM characteristics specified at [DCI-HDR] .
Standard Dynamic Range (SDR)
Refers to image content that conforms to the Image DCDM characteristics specified at [SMPTE-428-1] .
Imaging Device
The imaging device is the device responsible for converting the electrical signals from the Media Block to a human visible picture. This includes all necessary power supplies and cabling. This includes both Projectors and Direct View Displays.
Testing Organization
An organization which offers testing services based on this document.
Test Operator
A member of the Testing Organization that performs testing services.
Test Subject
A device or computer file which is the subject of a test based on this document.
Theater System
A complete exhibition system to perform playback of d-cinema content, including all cabling, power supplies, content storage devices, controlling terminals, media blocks, imaging devices and sound processing devices necessary for a faithful presentation of the content, plus all the surrounding devices needed for full theater operations including theater loudspeakers and electronics (the "B-Chain"), theater automation, a theater network, and management workstations (depending upon implementation), etc.

Note – There may be additional restrictions, depending on implementation. For example, some Media Blocks may refuse to perform even the most basic operations as long as they are not attached to an SMS or Imaging Device. For these environments, additional equipment may be required.

1.5. Digital Cinema System Architecture 🔗

The [DCI-DCSS] allows different system configurations, meaning different ways of grouping functional modules and equipment together. The following diagram shows what is considered to be a typical configuration allowed by DCI.

Diagram that illustrates (on the left) the transformation of DCDM essence into the DCP and the distribution of the DCP to theaters; and (on the right) the playback of the DCP whinin the theatre
Figure 1.1 . Typical DCI Compliant System Configuration 🔗

The left side of the diagram shows the extra-theater part, which deals with DCP and KDM generation and transport. The right side shows the intra-theater part, which shows the individual components of the theater system and how they work together. This test plan will test for proper DCP and KDM formats ( i.e. , conforming to the Digital Cinema System Specification), for proper transport of the data and for proper processing of valid and malformed DCPs and KDMs. In addition, physical system properties and performance will be tested in order to ensure that the system plays back the data as expected and implements all security measures as required by DCI.

While the above diagram shows what is considered to be a typical configuration allowed by the Digital Cinema System Specification, the [DCI-DCSS] still leaves room for different implementations, for example, some manufacturers may choose to integrate the Media Decryptor blocks into the Imaging Device, or share storage between d-cinema servers.

1.6. Strategies for Successful Testing 🔗

In order to successfully execute one of the test sequences given in Part III. Consolidated Test Procedures , the Test Operator must understand the details of many documents and must have assembled the necessary tools and equipment to execute the tests. This document provides all the necessary references to standards, tutorials and tools to orient the technical reader.

As an example, Section 7.5.12 requires a calculation to be performed on a set of measured and reference values to determine whether a Imaging Device's colorimetry is within tolerance. Section C.6 provides an implementation of this calculation, but the math behind the program and the explanation behind the math are not presented in this document. The Test Operator and system designer must read the reference documents noted in Section 7.5.12 (and any references those documents may make) in order to fully understand the process and create an accurate design or present accurate results on a test report.

Preparing a Test Subject and the required documentation requires the same level of understanding as executing the test. Organizations may even choose to practice executing the test internally in preparation for a test by a Testing Organization. The test procedures have been written to be independent of any proprietary tools. In some cases this policy has led to an inefficient procedure, but the resulting transparency provides a reference measurement that can be used to design new tools, and verify results obtained from any proprietary tools a Testing Organization may use.

Part I. Procedural Tests 🔗

Many tests in this Part rely on the Security Manager promptly making available log records of events. In order to provide a bound on test durations, failure of a Security Managers to make the record of an event available as part of a log report within 5 minutes of the event being recorded is cause to fail the test being conducted.

Chapter 2. Digital Cinema Certificates 🔗

Authentication of devices in d-cinema is accomplished using asymmetric cryptography . Unlike symmetric cryptography, which uses the same key to encrypt and decrypt data, asymmetric cryptography uses a pair of keys that each reverse the other's cryptographic operations: data encrypted with one key in the key pair can only be decrypted by the other key in the key pair. In such a key pair, there is a public key that is distributed freely, and a private key that is closely held and protected. Public keys are not easily distinguished from one another because they don't carry any identifying information (they're just really long random numbers). To address this, public keys are distributed with metadata that describes the person or device that holds the private key, called the subject . This set of metadata and the public key comprise the digital certificate . The standard that defines a digital certificate for d-cinema is [SMPTE-430-2] . It is based on the ITU standard for Public Key Infrastructure, called X.509 , and specifies a number of constraints on the X.509v3 standard, such as the X.509 version that can be used and the size of the RSA keys, among other things.

A digital certificate also contains a signature , created by generating a message digest of the certificate and then encrypting that message digest with a (usually different) private key. The signature is then added to the certificate, and is used to verify that the certificate is authentic. The holder of the (private) key used to sign a certificate (encrypt the message digest) is known as the issuer , and identifying information about the issuer is in the Issuer field of the certificate, linking the issuer to the subject's certificate. Similarly, identifying information about the subject is in the Subject field. In most cases, the issuer and the subject are different. When the issuer and subject are the same, the certificate is known as being self- signed . A self-signed certificate is also self-validating, as its own public key is used to validate its signature. When a self-signed certificate is used to sign other certificates, it becomes the Certificate Authority (CA) for those certificates. The collection of certificates, from the top CA certificate to the last certificate (known as a leaf certificate ) are collectively called the certificate chain .

Certificate authentication is recursive: in order to verify that a certificate is valid you have to decrypt the signature using the public key in the issuer's certificate. Once that signature is validated, if the issuer's certificate is not self signed then the signature validation process continues up the chain until a self-signed (CA) certificate is validated. A certificate is trusted only if its entire chain is valid.

The test procedures in this chapter are organized into two groups: tests that evaluate a certificate's compliance to [SMPTE-430-2] and tests that evaluate the behavior of devices that decode certificates. The Certificate Decoder tests are in this section because they are not specific to any particular type of system. All d-cinema devices that decode certificates must behave in the manner described by these tests.

2.1. Certificate Structure 🔗

The testing procedures that follow make use of the openssl cryptographic tools and library. openssl is a well known, free, and open source software package available for a number of hardware platforms and operating systems.

Much of the information in a digital certificate can be viewed in a human-readable format using openssl 's 'text' option. The information presented in the text output can be used to validate a number of certificate requirements, and to validate certificate-related KDM requirements by comparing the values present in the text output to the values in the KDM. The following example illustrates the features of a typical d-cinema leaf certificate: 

$ openssl x509 -text -noout -in smpte-430-2-leaf-cert.pem1
Certificate:
    Data:
        Version: 3 (0x2)2
        Serial Number: 39142 (0x98e6)3
        Signature Algorithm: sha256WithRSAEncryption4
        Issuer: O=.ca.example.com, OU=.ra-1b.ra-1a.s430-2.ca.example.com,
                CN=.cc-admin/dnQualifier=0sdCakNi3z6UPCYnogMFITbPMos=5
    Validity:6
        Not Before: Mar 9 23:29:52 2007 GMT7
        Not After : Mar 8 23:29:45 2008 GMT8
    Subject: O=.ca.example.com, OU=.cc-admin.ra-1b.ra-1a.s430-2.ca.example.com,9
            CN=SM.ws-1/dnQualifier=H/i8HyVmKEZSFoTeYI2UV9aBiq4=10
    Subject Public Key Info:11
        Public Key Algorithm: rsaEncryption12
        RSA Public Key: (2048 bit)13
          Modulus (2048 bit):14
              [hexadecimal values omitted for brevity]
          Exponent: 65537 (0x10001)15
    X509v3 extensions:16
        X509v3 Key Usage:17
          Digital Signature, Key Encipherment, Data Encipherment18
        X509v3 Basic Constraints: critical19
          CA:FALSE
        X509v3 Subject Key Identifier:20
          1F:F8:BC:1F:25:66:28:46:52:16:84:DE:60:8D:94:57:D6:81:8A:AE
        X509v3 Authority Key Identifier:21
          keyid:D2:C7:42:6A:43:62:DF:3E:94:3C:26:27:A2:03:05:21:36:CF:32:8B
          DirName:/O=.ca.example.com/OU=.ra-1a.s430-2.ca.example.com/
                CN=.ra-1b/dnQualifier=3NMh+Nx9WhnbDcXKK1puOjX4lsY=
          serial:56:CE
Signature Algorithm: sha256WithRSAEncryption22
[hexadecimal
values
omitted
for
brevity]
  • 1 Openssl command line and arguments to view the certificate text
  • 2 The x509 version of the certificate
  • 3 The serial number of the certificate.
  • 4 The algorithm that was used to sign the certificate.
  • 5 Information about the Issuer of the certificate.
  • 6 The validity section of the certificate.
  • 7 The date the certificate validity period begins.
  • 8 The date the certificate validity period ends.
  • 9 The Subject Name of the certificate.
  • 10 Information about the Subject of the certificate
  • 11 Information about the Subject's public key.
  • 12 The algorithm used to create the public key
  • 13 Information about the RSA public key.
  • 14 The modulus value, which is a component of the public key.
  • 15 The exponent value, which is a component of the public key
  • 16 x509 Version 3 Extensions. These extensions provide more information about the private key, the purposes for which it can be used, and how it is identified.
  • 17 Key Usage. These are the actions that the private key can perform.
  • 18 The enumerated list of actions that the private key can perform.
  • 19 x509 Basic Constraints. These declare whether or not the certificate is a CA certificate, and whether or not there is a path length limitation. Basic Constraints must be marked Critical
  • 20 The Subject Key Identifier identifies the public key in the certificate.
  • 21 The Authority Key Identifier identifies the Issuer key used to sign the certificate.
  • 22 The Signature Algorithm used to sign the certificate.
Example 2.1 . D-Cinema Certificate 🔗
2.1.1. Basic Certificate Structure 🔗
Objective
Verify that the certificate uses the ITU X.509, Version 3 standard with ASN.1 DER encoding as described in [ITU-X509] . Also verify that the Issuer and Subject fields are present inside the signed part of the certificate.
Procedures
The certificate format and encoding can be verified by using the openssl command to display the certificate information as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-inform
PEM
-in
<certificate>
A correctly formatted and encoded certificate will be displayed as text output by openssl . An incorrectly formed certificate will cause openssl to display an error. A certificate that causes an error to be displayed by the openssl command is incorrectly formed and shall be cause to fail this test.

The version of the certificate and the presence of the Issuer and Subject fields in the signed portion of the certificate can be verified by viewing openssl's text output of the certificate. The version number is indicated by 2 in the example certificate, and the issuer and subject fields are indicated by numbers 5 and 10 , respectively. An x509 version number other than 3, or the absence of either the Subject field or the Issuer field shall be cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
2.1.2. SignatureAlgorithm Fields 🔗
Objective
Verify that the SignatureAlgorithm of the signature and the SignatureAlgorithm in the signed portion of the certificate both contain the value "sha256WithRSAEncryption" .
Procedures
The signature algorithms of the signature and of the certificate can be verified by using the openssl command to display the certificate text as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
The signature algorithm of the certificate is indicated by 4 in the example certificate, and the signature algorithm of the signature is indicated by number 22 of the example certificate.

Verify that these fields both contain the value "sha256WithRSAEncryption" . If either field contains a different value, this shall be cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
2.1.3. SignatureValue Field 🔗
Objective
Verify that the SignatureValue field is present outside the signed part of the certificate and contains an ASN.1 Bit String that contains a PKCS #1SHA256WithRSA signature block.
Procedures
The certificate signature value can be verified by using the openssl command to display the certificate information as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
A correct certificate signature will be displayed as colon separated hexadecimal values in the text output by openssl . The signature block, omitted from the example certificate, will be present below the signature algorithm at the bottom of the output below callout number 22 of the example certificate. An incorrect certificate signature will cause openssl to display an error. A certificate that causes openssl to generate errors is cause to fail this test. A signature value other than sha256WithRSAEncryption is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
2.1.4. SerialNumber Field 🔗
Objective
Verify that the Serial Number field is present inside the signed part of the certificate and that it contains a nonnegative integer that is no longer than 64 bits (8 bytes).
Procedures
The certificate serial number can be verified by using the openssl command to display the certificate information as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
The serial number field is indicated by 3 in the example certificate. Confirm that the serial number is a non-negative integer that is no longer than 64 bits (8 bytes), and that the parenthetical phrase "neg" is not present. A negative serial number or a number larger than 64 bits shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
2.1.5. SubjectPublicKeyInfo Field 🔗
Objective
Verify that the Subject Public Key Info field is present inside the signed part of the certificate and that it describes an RSA public key with a modulus length of 2048 bits and a public exponent of 65537.
Procedures
The subject public key info can be verified by using the openssl command to display the certificate information as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
The Subject Public Key Info is indicated by 11 in the example certificate. The modulus length and the public exponent are indicated by 14 and 15 , respectively.

Verify that the Public Key Algorithm type is rsaEncryption and RSA Public Key is (2048 bit) . Failure to meet both requirements is cause to fail this test.

Verify that the Modulus is (2048 bit) and that Exponent is 65537 (0x10001) . Any other value for the modulus length or the exponent shall be cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
2.1.6. Deleted Section 🔗

The section "RSA Key Format" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

2.1.7. Validity Field 🔗
Objective
Verify that the Validity field is present inside the signed part of the certificate and contains timestamps in UTC. Timestamps with years up to and including 2049 must use two digits (UTCTime) to represent the year. Timestamps with the year 2050 or later must use four digits (GeneralizedTime) to represent the year.
Procedures
The presence of the validity field can be verified by using the openssl command to display the certificate text as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
The validity field is indicated by callout 6 in the example certificate. Confirm that the field is present and that it contains a "Not Before" value as a UTC timestamp as indicated by 7 of the example certificate and a "Not After" value as a UTC timestamp as indicated by 8 of the example certificate. If the validity field is not present, this shall be cause to fail this test.

Verifying the format of the timestamps as either UTCTime or GeneralizedTime can be accomplished by viewing the ASN.1 sequences of the certificate with openssl . Additionally, by using the grep command to specify a text string to display, in this case, "TIME", the time formats can be quickly identified: 

$ openssl asn1parse -in <certificate> |grep TIME 
154:d=3 hl=2 l= 13 prim: UTCTIME :070312145212Z 
169:d=3
hl=2
l=
13
prim:
UTCTIME
:270307145212Z
Confirm that timestamps up to the year 2049 are in UTCTime format, and that timestamps starting with the year 2050 are in GeneralizedTime format. Timestamps in UTCTime format will be formatted as "YYMMDDhhmmssZ", and Timestamps in GeneralizedTime format will have the year coded as "YYYYMMDDhhmmssZ", where "Y" represents the year, "M" represents the month, "D" represents the day, and "h", "m", "s", and "Z" represent hours, minutes, seconds, and the Universal Coordinated Time zone. A timestamp prior to 2049 that is not in UTC format shall be cause to fail this test. A timestamp starting in 2050 or later that is not in GeneralizedTime format shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
2.1.8. AuthorityKeyIdentifier Field 🔗
Objective
Verify that the Authority Key Identifier field is present in the X509v3 Extensions section inside the signed part of the certificate.
Procedures
The presence of the Authority Key Identifier field can be verified by using the openssl command to display the certificate information as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
The Authority Key Identifier of the certificate is indicated by 21 in the example certificate. Confirm that this field exists. The absence of the Authority Key Identifier field shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
2.1.9. KeyUsage Field 🔗
Objective
Verify that the Key Usage field is present in the X509v3 Extensionssection inside the signed part of the certificate.

For signer certificates, verify that only the "Certificate Sign" (keyCertSign) flag is true, the "CRL Sign" (cRLSign) flag may optionally be present.

For the SM role leaf certificate of a dual certificated MB, verify that the "Certificate Sign" (keyCertSign) , "CRL Sign" (cRLSign) , and the "Digital Signature" (digitalSignature) flags are false or not present and that the "Key Encipherment" (keyEncipherment) flag is true.

For the LS role leaf certificate of a dual certificated MB, verify that the "Certificate Sign" (keyCertSign) , "CRL Sign" (cRLSign) , and the "Key Encipherment" (keyEncipherment) flags are false or not present, and that the "Digital Signature" (digitalSignature) flag is true.

For all leaf certificates not part of a dual certificated MB, verify that the "Certificate Sign" (keyCertSign) and "CRL Sign" (cRLSign) flags are false or not present, and that the "Digital Signature" (digitalSignature) , and "Key Encipherment" (keyEncipherment) flags are true.

Procedures
The presence of the Key Usage field can be verified by using the openssl command to display the certificate information as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
The Key Usage field in the certificate is indicated by 17 in the example certificate.

For all certificates, confirm that this field exists. Absence of the Key Usage field shall be cause to fail this test.

For signing certificates, confirm that the key usage listed in the usage list (indicated by 18 ) has only "Certificate Sign" (keyCertSign) , the optional "CRL Sign" (cRLSign) flag may be present. Absence of the "Certificate Sign" (keyCertSign) flag, or presence of any other flag except for "CRL Sign" (cRLSign) , shall be cause to fail this test.

For the SM role leaf certificate of a dual certificated MB, confirm that the key usage lists "Key Encipherment" (keyEncipherment) , and that "Digital Signature" (digitalSignature) is absent. Absence of "Key Encipherment" (keyEncipherment) , or presence of "Digital Signature" (digitalSignature) , shall be cause to fail this test. Presence of "Certificate Sign" (keyCertSign) or "CRL Sign" (cRLSign) shall be cause to fail this test.

For the LS role leaf certificate of a dual certificated MB, confirm that the key usage lists "Digital Signature" (digitalSignature) , and that the "Key Encipherment" (keyEncipherment) is absent. Absence of "Digital Signature" (digitalSignature) , or presence of "Key Encipherment" (keyEncipherment) , shall be cause to fail this test. Presence of "Certificate Sign" (keyCertSign) or "CRL Sign" (cRLSign) shall be cause to fail this test.

For all leaf certificates not part of a dual certificated MB, confirm that the key usage lists "Digital Signature" (digitalSignature) and "Key Encipherment" (keyEncipherment) . Absence of "Digital Signature" (digitalSignature) and "Key Encipherment" (keyEncipherment) shall be cause to fail this test. Presence of "Certificate Sign" (keyCertSign) or "CRL Sign" (cRLSign) shall be cause to fail this test.

Note that leaf certificates may have other key usages specified, and the presence of other usages not specifically referenced here shall not be a reason to fail this test.

Supporting Materials
Reference Documents
Test Equipment
2.1.10. Basic Constraints Field 🔗
Objective
Verify that the Basic Constraints field is present in the X509v3 Extensions section of the signed portion of the certificate. For signer certificates, verify that the certificate authority attribute is true (CA:TRUE) and the PathLenConstraint value is present and either zero or positive. For leaf certificates, verify that the certificate authority attribute is false (CA:FALSE) and the PathLenConstraintis absent or zero.
Procedures
The presence of the Basic Constraints field can be verified by using the openssl command to display the certificate information as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
The Basic Constraints field in the certificate is indicated by 19 in the example certificate. For signing certificates, confirm that this field exists, that the certificate authority value is true (CA:TRUE), and that the path length is present and is a positive integer. For leaf certificates, confirm that the certificate authority value is false (CA:FALSE) and that the path length is absent or zero. The absence of the Basic Constraints field shall be cause to fail this test. For signer certificates, the absence of the CA:TRUE value, or a negative or missing Path Length value shall be cause to fail this test. For leaf certificates, the presence of the CA:TRUE value or the presence of a path length greater than zero shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
2.1.11. Public Key Thumbprint 🔗
Objective
Verify that there is exactly one DnQualifier present in the Subject field and that the DnQualifier value is the Base64 encoded thumbprint of the subject public key in the certificate. Also verify that there is exactly one DnQualifier present in the Issuer field and that the DnQualifier value is the Base64 encoded thumbprint of the issuer's public key.
Procedures
The presence of a single instance of the DnQualifier field can be verified by using the openssl command to display the certificate information as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
The Subject DnQualifier in the certificate is in the Subject information as indicated by 10 in the example certificate, and the Issuer DnQualifier in the certificate is in the Issuer information as indicated by 5 . Confirm that each of these fields contain only one DnQualifier. Missing DnQualifier values in either of these fields or the presence of more than one DnQualifier in either field shall be cause to fail this test.

The public key DnQualifier must be recalculated to confirm that the DnQualifier value in each of these fields is correct.

The following steps perform this calculation:

  1. Extract the public key from the certificate (using openssl )
  2. Convert the public key from Base64 to binary (using openssl )
  3. Skip 24 bytes into the binary form of the public key (using dd)
  4. Calculate the SHA-1 digest over the remaining portion of the binary form of the public key (using openssl )
  5. Convert the SHA-1 digest value to Base64 (using openssl )
The steps above can be performed in sequence by redirecting the output from one step to the next, and using openssl and the dd command present on most posix compliant operating systems, such as: 
$ openssl x509 -pubkey -noout -in <certificate> | openssl base64 -d \ 
|
dd
bs=1
skip=24
2>/dev/null
|
openssl
sha1
-binary
|
openssl
base64
The resulting value is the calculated DnQualifier of the public key in the input certificate. Confirm that when this calculation is performed on the public key in the subject certificate, the calculated value is equal to the DnQualifier present in the Subject field. Confirm that when this calculation is performed on the public key in the issuer certificate, the calculated value is equal to the DnQualifier present in the Issuer field of the subject certificate. A DnQualifier that does not match the calculated value of the corresponding certificate's public key shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
2.1.12. Organization Name Field 🔗
Objective
Verify that exactly one instance of the OrganizationName field is present in the Issuer and Subject fields. Verify that the two OrganizationName values are identical.
Procedures
The presence of the OrganizationName in the Subject and Issuer fields can be verified by using the openssl command to display the certificate information as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
The OrganizationName values are in the Subject and Issuer fields in the certificate as indicated by 5 and 10 in the example certificate. Confirm that the Organization name, the value specified as " O=<organization-name>" , is the same in both fields. Non-identical Organizational name values in the Subject and Issuer fields shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
2.1.13. OrganizationUnitName Field 🔗
Objective
Verify that exactly one instance of the OrganizationUnitName (OU) value is present in the Issuer and Subject fields.
Procedures
The presence of the OrganizationUnitName in the Subject and Issuer fields can be verified by using the openssl command to display the certificate information as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
The OrganizationUnitName values are in the Subject and Issuer fields in the certificate as indicated by 5 and 10 in the example certificate. The absence of an OrganizationUnitName in either the Subject or Issuer fields of the certificate shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
2.1.14. Entity Name and Roles Field 🔗
Objective
Verify that the CommonName (CN) is present exactly once in both the Subject and Issuer fields. Also verify that the CommonName fields contain a physical identification of the entity ( i.e. , make, model, or serial number, for devices). For leaf certificates ( i.e. , certificate authority is set to False), verify that at least one role is specified and that it is the role expected for the certificate.
Procedures
The presence of the CommonName in the Subject and Issuer fields can be verified by using the openssl command to display the certificate information as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
The CommonName values are in the Subject and Issuer fields in the certificate as indicated by 5 and 10 in the example certificate. Confirm that the CommonName , the value specified as "CN=<common-name>" is present only once and that it contains information that identifies the entity. For leaf certificates, confirm that the common name specifies at least one role and that it is correct for the certificate. The absence of the CommonName value in either the Subject or Issuer fields shall be cause to fail this test. For leaf certificates, the absence of a role designation shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
2.1.15. Unrecognized Extensions 🔗
Objective
Verify that any X.509v3 extensions in the certificate that are not specified in [SMPTE-430-2] (unrecognized extensions) are not marked critical.
Procedures
The list of X.509v3 extensions in a certificate can be viewed by using the openssl command to display the certificate information as described in Example 2.1 , e.g. : 
$
openssl
x509
-text
-noout
-in
<certificate>
For signer certificates (certificates that have CA:TRUE), of the X.509v3 extensions listed in the certificate, "Basic Constraints" (indicated by 19 ) must be marked critical. "Basic Constraints" may be marked critical for leaf certificates. "Key Usage" and "Authority Key Identifier" (indicated by 17 ) may be marked critical. No other unrecognized X.509v3 extensions may be marked critical. A signer certificate with a "Basic Constraints" section that is not marked critical shall be cause to fail this test. A Certificate that has any X.509v3 extension marked critical other than "Basic Constraints", "Key Usage" or "Authority Key Identifier" shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
2.1.16. Signature Validation 🔗
Objective
Using the issuer's public key, verify that the signature contained in the certificate is valid.
Procedures
For this operation to be successful, validation must be performed down the certificate chain, from the self-signed root certificate (the CA) to the leaf certificate being validated. Certificate chain validation is recursive, so as each certificate in the chain is validated it is included as part of the validation of the next certificate. With openssl , this results in a file that contains the root certificate and, incrementally, each of the signer certificates of certificate chain of the leaf certificate. This file is then used to validate the signature on the leaf certificate. A certificate chain containing three certificates can be validated by following these steps:
  1. Verify that the CA certificate signature is valid
  2. Verify that the CA's signature on the signer's certificate is valid.
  3. Verify that the signer's signature on the leaf certificate is valid.
This example uses openssl to validate each certificate, and the unix command 'cat' to append each successive certificate to a single file. This file is specified to openssl using the -CAfile option. 
$ openssl verify -CAfile caroot.pem caroot.pem 
caroot.pem: OK 
$ cp caroot.pem certchain.pem 
$ openssl verify -CAfile certchain.pem signer.pem 
signer.pem: OK 
$ cat signer.pem >> certchain.pem 
$ openssl verify -CAfile certchain.pem leaf.pem 
leaf.pem:
OK
Error messages from openssl indicate that a certificate in the chain did not validate, and that the chain is not valid. Error messages that indicate that the certificate chain is not valid shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
2.1.17. Certificate Chains 🔗
Objective
For a given certificate chain:
  • Verify that the certificate chain is complete, i.e. , for each certificate specified in an Issuer field, there is a corresponding certificate whose Subject field matches that Issuer field.
  • Verify that, for each certificate in the chain, the validity period of any child certificate is completely contained within the validity period of the parent certificate.
  • Verify that the root certificate ( i.e. , a self-signed certificate where the CA-flag is true) is a valid root certificate.
Procedures

A complete certificate chain starts with a leaf certificate and ends with a self-signed (CA root) certificate. Between the leaf certificate and the CA root certificate there should be one or more signer certificates. A leaf certificate is signed by a signer certificate, and the signer certificate is identified by its DnQualifier in the "Issuer" field of the leaf certificate. In a chain of three certificates, the signer certificate is in turn signed by the CA root certificate, which is similarly identified by its DnQualifier in the Issuer field of the signer's certificate. The CA root certificate is self-signed and has its own DnQualifier in both the Subject and Issuer fields.

To verify that the certificate chain is complete, confirm that the certificates corresponding to the Issuer DnQualifiers of each of the certificates is present, as explained in Section 2.1.11: Public Key Thumbprint . A certificate chain that does not contain all of the certificates matching the DnQualifiers specified in the Issuer fields of the certificates means the chain is not complete and shall be cause to fail this test.

The validity period of a certificate can be viewed using the procedure described in Section 2.1.7: Validity Field . Confirm that for each certificate in the chain, the signer certificate's validity period completely contains the validity period of the signed certificate. A certificate that has a validity period that extends beyond the validity period of its signer (either starting before, or ending after, the validity period of its signer) shall be cause to fail this test.

To confirm that the CA root certificate is a valid root certificate:
  1. Verify that the DnQualifier in the Issuer field is the same as the DnQualifier in the Subject field as described in Section 2.1.11: Public Key Thumbprint .
  2. Confirm that the Certificate Authority value in the Basic Constraints field is true and the path length value is a number, zero or greater, as described in Section 2.1.10: Basic Constraints Field .
  3. Confirm that the X.509v3 Key Usage contains "Certificate Sign" as described in Section 2.1.9: KeyUsage Field .
A CA certificate that does not have a non-negative path length of zero or greater, or that does not have the basic constraints extension marked critical and containing CA:TRUE, shall be cause to fail this test.

A CA Root certificate that is not self-signed shall be cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment

2.2. Certificate Decoder Behavior 🔗

2.2.1. ASN.1 DER Encoding Check 🔗
Objective
Verify that a certificate is rejected by the decoding device if it contains syntax errors or does not conform to the ASN.1 DER (Distinguished Encoding Rules) format.
Procedures
For the malformed certificate below, perform an operation with the Test Subject using a malformed certificate. Verify that the operation fails. A successful operation using a malformed certificate is cause to fail this test.
  1. A certificate encoded as BER ( chain-c3-BER-enc , IMB-chain-a3-BER-enc )
Supporting Materials
Reference Documents
Test Materials
2.2.2. Missing Required Fields 🔗
Objective
Verify that certificates with missing required fields are rejected by a Test Subject.
Procedures
For each of the malformations below, perform an operation on the device with the certificate that contains that malformation. Verify that the operation fails. A successful operation using a malformed certificate is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
2.2.3. PathLen Check 🔗
Objective
Verify that, if the Certificate Authority attribute of the BasicConstraint field is True , the PathLenConstraint value is present and is either zero or positive. Verify that if the certificate authority attribute of the BasicConstraint field is False, the PathLenConstraint field is absent or set to zero.
Procedures
  1. Perform an operation on the Test Subject using a leaf certificate with a PathLen greater than zero (0). Verify that the operation fails. A successful operation using a certificate with an incorrect Path Length is cause to fail this test.
  2. Perform an operation on the Test Subject using a leaf certificate with a PathLen that is negative. Verify that the operation fails. A successful operation using a certificate with an incorrect Path Length is cause to fail this test.
  3. Perform an operation on the Test Subject using a signer certificate that does not contain a PathLen (PathLen absent). Verify that the operation fails. A successful operation using a certificate with an incorrect Path Length is cause to fail this test.
  4. Perform an operation on the Test Subject using a signer certificate that contains a PathLen that is negative. Verify that the operation fails. A successful operation using a certificate with an incorrect Path Length is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
2.2.4. OrganizationName Match Check 🔗
Objective
Verify that the certificate is rejected by the device if the OrganizationName in the subject and issuer fields do not match.
Procedures
Perform an operation on the device with a certificate that has mismatched OrganizationName values in the Subject and Issuer fields. Verify that the operation fails. A successful operation using a malformed certificate is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
2.2.5. Certificate Role Check 🔗
Objective
Verify that when the validation context includes a desired role, a Test Subject rejects a leaf certificate with a role that is different than the role expected.
Procedures
Perform an operation on the Test Subject using a certificate with a role that is not permitted for the operation. Verify that the operation fails. A successful operation using a certificate with an incorrect role is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
2.2.6. Validity Date Check 🔗
Objective
Verify that the certificate is rejected if it is not valid at the desired time (according to the validation context, e.g. , time of playback).
Procedures
Perform an operation on the device with a certificate that is not valid. Verify that the operation fails. A successful operation using a certificate at a time outside of its validity period is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
2.2.7. Signature Algorithm Check 🔗
Objective
Verify that a certificate is rejected by a Test Subject if the signature algorithms in the certificate body and the signature are not sha256WithRSAEncryption .
Procedures
Perform an operation on the device with a certificate that has mismatched or incorrect signatures for each of the following types of signature errors. Verify that the operation fails. A successful operation using an incorrectly signed certificate is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
2.2.8. Public Key Type Check 🔗
Objective
Verify that the certificate is rejected if the subject's Public Key is not a 2048 bit RSA key with an exponent of 65537 .
Procedures
For each of the types of incorrect public keys below, perform an operation on the device with the certificate that has an public key that is not correct. Verify that the operation fails. A successful operation using a certificate with an incorrect public key is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
2.2.9. Issuer Certificate Presence Check 🔗
Objective
Verify that the certificate is rejected if the issuer's certificate cannot be located by looking it up using the value of the AuthorityKeyIdentifier X.509v3 extension.
Procedures
Perform an operation on the Test Subject using certificates that do not include the certificate's signer specified by the AuthorityKeyIdentifier . Verify that the operation fails. A successful operation using a certificate without the certificate signer present is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials

Chapter 3. Key Delivery Messages 🔗

This chapter contains tests for Key Delivery Messages (KDM). The test procedures in this chapter are organized into three groups: tests that evaluate a KDM's compliance to [SMPTE-430-1] , tests that evaluate a KDM's compliance to [SMPTE-430-3] , and tests that evaluate the behavior of devices that decode KDMs. The KDM Decoder tests are in this section because they are not specific to any particular type of system. All d-cinema devices that decode KDMs must behave in the manner described by these tests.

Before diving in to testing KDM files, we will first introduce XML and provide some examples of KDM documents.

3.1. eXtensible Markup Language 🔗

XML is a file metaformat: a file format for creating file formats. Many of the files that comprise a d-cinema composition ( e.g. , a feature or trailer), are expressed in XML. While the various d-cinema file formats represent different concepts within the d-cinema system, the arrangement of data within the files is syntactically similar for those files that use XML. This section will provide an overview of XML as used for d-cinema applications. Readers looking for more detailed technical information are referred to the home of XML at http://www.w3.org .

3.1.1. XML Documents 🔗

The main unit of data storage in an XML document is the XML element . XML elements are expressed in a document using tags ; strings of human-readable text enclosed between less-than (<) and greater-than (>) characters. An XML document is an element that is meant to be interpreted as a complete unit. Every XML document consists of a single XML element having zero or more (usually hundreds more) elements inside. XML documents may be stored as files, transmitted over networks, etc. The following example shows a very simple XML element, rendered as a single tag 

<Comment/>

By itself, this XML element is a complete, though very uninteresting XML document.

To be more useful, our example element needs some data, or content . XML content may include unstructured text or additional XML elements. Here we have expanded the element to contain some text: 

<Comment>The
quick
brown
fox...</Comment>

Notice that when an XML element has content, the content is surrounded by two tags, in this case <Comment> and </Comment>. The former is an opening tag, the latter a closing tag.

We now have some data inside our element. We could help the reader of our example XML document by indicating the language that the text represents (these same characters could of course form words from other languages). The language of the text is metadata : in this case, data about the text. In XML, metadata is stored as sets of key/value pairs, or attributes , inside the opening tags. We will add an attribute to our example element to show some metadata, in this case we are telling the reader that the text is in English: 

<Comment
language="en">The
quick
brown
fox...</Comment>

The following example shows an actual d-cinema data structure (there is no need to understand the contents of this example as this particular structure is covered in more detail in Section 4.2.1 .): 

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> 
<PackingList xmlns="http://www.smpte-ra.org/schemas/429-8/2007/PKL"> 
  <Id>urn:uuid:59430cd7-882d-48e8-a026-aef4b6253dfc</Id> 
  <AnnotationText>Perfect Movie DCP</AnnotationText> 
  <IssueDate>2007-07-25T18:21:31-00:00</IssueDate> 
  <Issuer>user@host</Issuer> 
  <Creator>Packaging Tools v1.0</Creator> 
  <AssetList> 
    <Asset> 
      <Id>urn:uuid:24d73510-3481-4ae5-b8a5-30d9eeced9c1</Id> 
      <Hash>AXufMKY7NyZcfSXQ9sCZls5dSyE=</Hash> 
      <Size>32239753</Size> 
      <Type>application/mxf</Type> 
      <AnnotationText>includes M&amp;E</AnnotationText> 
    </Asset> 
  </AssetList> 
</PackingList>
Example 3.1 . Packing List Example (Partial) 🔗
3.1.2. XML Schema 🔗

You may have noticed that the basic structure of XML allows the expression of almost unlimited types and formats of information. Before a device (or a person) can read an XML document and decide whether it is semantically correct, it must be possible for the reader to know what the document is expected to contain.

The XML standard dictates some initial requirements for XML documents. The document shown in Example 3.1 above illustrates some of these requirements:

  1. Element tags must be correctly nested: an element must be closed in the same scope in which it was opened. For example, the following XML fragment shows incorrect nesting of the Element3 element (it should close before Element2 closes, not after). 
    <Element1>
  <Element2>
  <Element3>
  </Element2>
  </Element3>
</Element1>
  2. The document may not contain special characters in unexpected places. For example, the &, < and > characters may not appear except in certain cases. Special encodings must be used to use these characters literally within an XML document.

A document which meets these requirements is said to be well formed . All XML documents must be well formed. An XML parser (a program that reads XML syntax) will complain if you give it XML that is not well-formed. Well-formedness, however, does not help us understand semantically what's in an XML document. To know the meaning of a particular XML structure, we have to have a description of that structure.

The structure and permitted values in an XML document can be defined using XML Schema. There are other languages for expressing the content model of an XML document, but XML Schema is the standard used by the SMPTE specifications for d-cinema. XML Schema is a language, expressed in XML, which allows the user to define the names of the elements and attributes that can appear in an XML document. An XML Schema can also describe the acceptable contents of and combinations of the XML elements.

Given an XML Schema and an XML document, a validating XML parser will report not only errors in syntax but also errors in the use and contents of the elements defined by the schema. Throughout this document, we will use the schema-check program (see Section C.3 ) to test XML documents. The command takes the instance document and one or more schema documents as arguments 

$
schema-check
<input-file>
smpte-430-3.xsd

If this command returns without errors, the XML document can be said to be both well-formed and valid

Some XML documents are defined using more than one schema. In these cases, you can supply the names of any number of schemas on the command line: 

$
schema-check
<input-file>
smpte-430-3.xsd
smpte-430-1.xsd
3.1.3. XML Signature Validation 🔗

XML Signature is a standard for creating and verifying digital signatures on XML documents. Digital signatures are used to allow recipients of Composition Playlists, Packing Lists and Key Delivery Messages (KDM) to authenticate the documents; to prove that the documents were signed by the party identified in the document as the document's signer, and that the documents have not been modified or damaged since being signed.

The checksig program (distributed with the XML Security library) can be used to test the signature on an XML document. The program is executed with the name of a file containing a signed XML document: 

$ checksig test-kdm.xml
Signature
verified
OK!
Example 3.2 . checksig execution 🔗

The program expects that the first certificate in the <KeyInfo> element is the signer. This has two implications:

  1. The program will fail if the signer is not the first (SMPTE standards allow any order)
  2. The program does not check the entire certificate chain

To address the first issue, the dsig_cert.py program (see Section C.8 ) can be used to re-write the XML document with the signer's certificate first in the <KeyInfo> element. This is demonstrated in the following example: 

$ dsig_cert.py test-kdm.xml > tmp.xml
$ checksig tmp.xml
Signature
verified
OK!
Example 3.3 . dsig_cert.py execution 🔗

The second issue is addressed by extracting the certificates from the document's XML Signature data and validating them directly with openssl . This procedure is the subject of the next section.

3.1.3.1. Extracting Certificates from an XML Document 🔗
In order to test certificates separately from the XML document in which they are embedded, this procedure will manually extract them into separate PEM files (see [RFC-1421] ). A PEM file contains a certificate (more than one if desired, but we're not going to do that just yet) as a DER-encoded binary string which is then encoded using Printable Encoding (see [RFC-1421] ). The encoded text is prefixed by the string -----BEGIN CERTIFICATE----- followed by a newline. The encoded text is followed by the string -----END CERTIFICATE----- . An example of this format can be seen below. Note that the Printable Encoding has newlines after every 64 characters. 
-----BEGIN CERTIFICATE-----
MIIEdzCCA1+gAwIBAgICNBowDQYJKoZIhvcNAQELBQAwgYQxGTAXBgNVBAoTEC5j
YS5jaW5lY2VydC5jb20xLDAqBgNVBAsTIy5yYS0xYi5yYS0xYS5zNDMwLTIuY2Eu
Y2luZWNlcnQuY29tMRIwEAYDVQQDEwkuY2MtYWRtaW4xJTAjBgNVBC4THGNwSmxw
NDBCM0hqSG9kOG9JWnpsVi9DU0xmND0wIBcNMDcwMTE1MjI0OTQ0WhgPMjAwODAx
MTUyMjQ5NDJaMIGLMRkwFwYDVQQKExAuY2EuY2luZWNlcnQuY29tMTUwMwYDVQQL
EywuY2MtYWRtaW4ucmEtMWIucmEtMWEuczQzMC0yLmNhLmNpbmVjZXJ0LmNvbTEQ
MA4GA1UEAxMHU00ud3MtMTElMCMGA1UELhMcdC8zQ2xNWjdiQWRGUnhnam1TRTFn
NGY4NUhNPTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOBejWa3Lg+Y
uvTYhCaFy0ET6zH6XrB3rLRrlbeMrrTuUMCX0YSmA7m3ZO1Bd/HQrJxyq6hJmPGu
auxwWiF4w+AajBRp4eSiAt8srACcEmUyqGHwPLoaKVEaHXSOY8gJp1kZwqGwoR40
RQusfAb2/L76+RlMUyACoJuR6k4kOBW3bjEE4E76KKR4k5K580d7uFf5G86GhGfU
AfXHJXboqzHnxQHaMldKNaSskxWrW8GrX43+2ZZUHM2ZKe0Ps/9g2gCRZ6eYaim4
UF+szH0EUY0Mbx4poqn+SZFrUWtEoWcDM6PSTTgCQVOQ1BtzD1lBQoNQGOJcd73N
9f5MfGioWMkCAwEAAaOB5zCB5DALBgNVHQ8EBAMCBLAwDAYDVR0TAQH/BAIwADAd
BgNVHQ4EFgQUt/3ClMZ7bAdFRxgjmSE1g4f85HMwgacGA1UdIwSBnzCBnIAUcpJl
p40B3HjHod8oIZzlV/CSLf6hf6R9MHsxGTAXBgNVBAoTEC5jYS5jaW5lY2VydC5j
b20xJjAkBgNVBAsTHS5yYS0xYS5zNDMwLTIuY2EuY2luZWNlcnQuY29tMQ8wDQYD
VQQDEwYucmEtMWIxJTAjBgNVBC4THEJteVdZV3d0M29FNlJGSTVYdDd3K0hGaEtW
Zz2CAwDpzTANBgkqhkiG9w0BAQsFAAOCAQEAowjAFQsyoKto7+WBeF9HuCRpKkxk
6qMgXzgAfJFRk/pi7CjnfjxvWukJq4HWgWHpXsGFf/RTp08naV1UHNe71sDYV2Fb
MOSFRi2OrRwZExO9SBKQHLZ7ZdLU+6GIHXKjmp9DiofUNOqvZPQnvwG/CmO84CpG
K14ktxtOghczzEiJCk2KISsgOU6NK4cmcFfMjuklTwmD5C6TvaawkvcNJQcldjUw
TWbvd+Edf9wkHNvBERR9lbCGWr16C5BVQZtFBJAU++3guL/4Qn4lkeU/gmR6o99S
UQ+T344CBSIy06ztiWZiuxoONoXfy12DTSepB+QShmuhsScrfv0Q9bB5hw==
-----END
CERTIFICATE-----
Example 3.4 . An X.509 certificate in PEM format 🔗

Within an XML document signed using XML Signature, certificates are stored in <dsig:X509Certificate> elements. These elements can be found at the end of the document, within the </dsig:Signature> element. The encoding method for storing certificate data in XML Signature is virtually identical to PEM. The Base64 encoding (see [RFC-2045] ) uses the same mapping of binary data to text characters, but the line length is not limited as with PEM.

It is a relatively easy task to use a Text Editor to copy and paste certificate data from an XML document:

  1. Open a new Text Editor window, and paste -----BEGIN CERTIFICATE----- , then press the Enter key. Note that the number of '-' (dash) characters on either side of the BEGIN CERTIFICATE label is five (5).
  2. Copy the content of the selected <dsig:X509Certificate> element (but not the element tags) from the KDM and paste it into the new editor window. The cursor should now be positioned at the last character of the certificate; press the Enter key.
  3. Paste -----END CERTIFICATE----- at the end of the new editor window and press the Enter key.
  4. Note again that Printable Encoding lines in PEM format files must be no more than 64 characters in length. If the Base64 certificate string copied from the KDM contains long lines, manually break the lines using the cursor and the Enter key.
  5. Save the editor's contents to a file, usually with a .pem suffix.

In most cases the procedure given above can be automated using the dsig_extract.py program (see Section C.9 ). As shown below, the -p option can be used to provide a prefix for the automatically-generated filenames. In this example, the input document contained four certificates. 

$ dsig_extract.py -p my_prefix_ test-kdm.xml
$ ls my_prefix_*
my_prefix_1.pem
my_prefix_2.pem
my_prefix_3.pem
my_prefix_4.pem
Example 3.5 . dsig_extract.py execution 🔗

You can test that the certificate has been correctly extracted by using openssl to view the contents of the certificate file: 

$
openssl
x509
-text
-noout
-in
<certificate-file.pem>

The output from this command should look similar to Example 2.1

To validate a complete chain of extracted certificates, use the procedure in Section 2.1.16 .

3.2. Key Delivery Message Example 🔗

The Key Delivery Message (KDM) is an XML document that contains cryptographic information necessary to reproduce an encrypted composition. A KDM also contains metadata about the cryptographic information, such as the validity period and the associated Composition Playlist (CPL). The format of the KDM file is specified by [SMPTE-430-1] . A KDM is a type of Extra-Theater Message (ETM), as specified by [SMPTE-430-3] .

The following examples show the elements of the KDM that will be examined during the procedures. Each example is followed by a list of descriptive text that describes the various features of the KDM called out in the examples. These features will be referred to from the test procedures. 

<?xml version="1.0" encoding="UTF-8" standalone="no"?>1
<DCinemaSecurityMessage xmlns="http://www.smpte-ra.org/schemas/430-3/2006/ETM"2
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
<AuthenticatedPublic Id="ID_AuthenticatedPublic">3
<MessageId>urn:uuid:b80e668c-a175-4bc7-ae48-d3a19c8fce95</MessageId>4
<MessageType>http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type</MessageType>5
<AnnotationText>Perfect Movie KDM</AnnotationText>6
<IssueDate>2007-07-24T17:42:58-00:00</IssueDate>7
<Signer>8
  <dsig:X509IssuerName>dnQualifier=wBz3yptkPxbHI/\+LUUeH5R6rQfI=,CN=.cc-admin-x,
      OU=.cc-ra-1a.s430-2.ca.example.com,O=.ca.example.com</dsig:X509IssuerName>
  <dsig:X509SerialNumber>6992</dsig:X509SerialNumber>
</Signer>
<RequiredExtensions>
  <KDMRequiredExtensions xmlns="http://www.smpte-ra.org/schemas/430-1/2006/KDM">
    <Recipient>9
      <X509IssuerSerial>
        <dsig:X509IssuerName>dnQualifier=wBz3yptkPxbHI/\+LUUeH5R6rQfI=,CN=.cc-admin-x,
          OU=.cc-ra-1a.s430-2.ca.serverco.com,O=.ca.serverco.com</dsig:X509IssuerName>
        <dsig:X509SerialNumber>8992</dsig:X509SerialNumber>10
      </X509IssuerSerial>
      <X509SubjectName>dnQualifier=83R40icxCejFRR6Ij6iwdf2faTY=,CN=SM.x_Mastering,
        OU=.cc-ra-1a.s430-2.ca.example.com,O=.ca.example.com</X509SubjectName>11
    </Recipient>
    <CompositionPlaylistId>12
      urn:uuid:20670ba3-d4c7-4539-ac3e-71e874d4d7d1
    </CompositionPlaylistId>
    <ContentTitleText>Perfect Movie</ContentTitleText>13
    <ContentKeysNotValidBefore>2007-07-24T17:42:54-00:00</ContentKeysNotValidBefore>14
    <ContentKeysNotValidAfter>2007-08-23T17:42:54-00:00</ContentKeysNotValidAfter>15
    <AuthorizedDeviceInfo>
      <DeviceListIdentifier>urn:uuid:d47713b9-cde1-40a9-98fe-22ef172723d0</DeviceListIdentifier>
      <DeviceList>16
          <CertificateThumbprint>jk4Z8haFhqCGAVbClW65jVSOib4=</CertificateThumbprint>17
      </DeviceList>
    </AuthorizedDeviceInfo>
    <KeyIdList>18
      <TypedKeyId>
        <KeyType scope="http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type">MDIK</KeyType>19
        <KeyId>urn:uuid:15e929b3-1d86-40eb-875e-d21c916fdd3e</KeyId>20
      </TypedKeyId>
      <TypedKeyId>
          <KeyType scope="http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type">MDAK</KeyType>
          <KeyId>urn:uuid:ca8f7756-8c92-4e84-a8e6-8fab898934f8</KeyId>
      </TypedKeyId>
    [remaining key IDs omitted for brevity]
    </KeyIdList>
    <ForensicMarkFlagList>21
      <ForensicMarkFlag>
          http://www.smpte-ra.org/430-1/2006/KDM#mrkflg-audio-disable
      </ForensicMarkFlag>
    </ForensicMarkFlagList>
  </KDMRequiredExtensions>
</RequiredExtensions>
<NonCriticalExtensions/>
</AuthenticatedPublic>
  • 1 XML Declaration. This specifies the version of the XML standard to which the document conforms, and the character encoding of the document
  • 2 The root DCinemaSecurityMessage element. This element contains the XML namespace declaration for a KDM as specified in [SMPTE-430-1] .
  • 3 The beginning of the AuthenticatedPublic section of the KDM.
  • 4 The Unique Universal ID (UUID) of the KDM. This is used to uniquely identify the asset map
  • 5 The type of message, in this case a KDM.
  • 6 An annotation text describing the contents or purpose of the KDM.
  • 7 The date the KDM was issued.
  • 8 The portion of the KDM that holds information about the certificate used to sign the KDM.
  • 9 The portion of the KDM that contains information about the recipient (target) certificate.
  • 10 The serial number of the recipient certificate.
  • 11 The Subject Name information from the recipient certificate.
  • 12 The UUID of the CPL used to create the KDM.
  • 13 The ContentTitleText from the CPL used to create the KDM.
  • 14 The starting validity date of the KDM.
  • 15 The ending validity date of the KDM
  • 16 Device list. This list contains the list of certificates thumbprints authorized for use with at least a portion of the KDM.
  • 17 A certificate thumbprint in the device list.
  • 18 The list of KeyIDs and their associated type.
  • 19 The type of key represented by the KeyID.
  • 20 The KeyID.
  • 21 This flag determines whether forensic marking is enabled or disabled. The ForensicMarkFlagList may contain multiple instances of ForensicMarkFlag.
Example 3.6 . KDM - AuthenticatedPublic area 🔗 
<AuthenticatedPrivate Id="ID_AuthenticatedPrivate">1
  <enc:EncryptedKey xmlns:enc="http://www.w3.org/2001/04/xmlenc#">2
    <enc:EncryptionMethod 
                Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">3
      <ds:DigestMethod
          xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
          Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
    </enc:EncryptionMethod>
    <enc:CipherData>
    <enc:CipherValue>4
[256 Byte long encrypted cipherdata block omitted] 
</enc:CipherValue>
    </enc:CipherData>
  </enc:EncryptedKey>
  <enc:EncryptedKey xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
    <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
      <ds:DigestMethod
          xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
          Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
    </enc:EncryptionMethod>
    <enc:CipherData>
      <enc:CipherValue> 
[256 Byte long encrypted cipherdata block omitted] 
</enc:CipherValue>
    </enc:CipherData>
  </enc:EncryptedKey>
  <enc:EncryptedKey xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
    <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
      <ds:DigestMethod
          xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
          Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
    </enc:EncryptionMethod>
    <enc:CipherData>
      <enc:CipherValue> 
    [ 256 Byte long encrypted cipherdata block omitted] 
    </enc:CipherValue>
    </enc:CipherData>
  </enc:EncryptedKey>
  <enc:EncryptedKey xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
    <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
      <ds:DigestMethod
          xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
          Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
    </enc:EncryptionMethod>
    <enc:CipherData>
      <enc:CipherValue> 
    [ 256 Byte long encrypted cipherdata block omitted] 
    </enc:CipherValue>
    </enc:CipherData>
  </enc:EncryptedKey>
  [additional EncryptionKey entries omitted]
</AuthenticatedPrivate>
  • 1 The start of the AuthenticatedPrivate section of the KDM
  • 2 The EncryptedKey element indicates there is data encrypted with an RSA public key algorithm.
  • 3 3 The algorithm used to encrypt the data in the CipherData element.
  • 4 A 256 Byte long block of RSA encrypted data.
Example 3.7 . KDM - AuthenticatedPrivate area 🔗 
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">1
<dsig:SignedInfo>
  <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments" />2
  <dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />3
  <dsig:Reference URI="#ID_AuthenticatedPublic">4
    <dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />5
    <dsig:DigestValue>cnn8M41NR4jQF+9GOZiNJTlfl+C/l8lBFljuCuq9lQE=</dsig:DigestValue>6
  </dsig:Reference>
  <dsig:Reference URI="#ID_AuthenticatedPrivate">7
    <dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
    <dsig:DigestValue>TEW7tPwML2iOkIpK2/4rZbJbKgnnXjAtJwe9OJSe8u4=</dsig:DigestValue>
  </dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>uH41s9odRPXzFz+BF3dJ/myG09cLSE9cLzf2C7f2Fm49P9C53T5RSeEIyqt6p5ll8
zlH2q3ZJRZcZuV5VA7UkIb4z6U4CGUTU51D8lL/anY1glLFddjUiDU/0nmC4uAsH 
rzwQgzOTZmZd2eLo0N70DBtNhTcJZftKUN2O2ybHZaJ7Q/aBxAiCK3h/fRW/b7zM 
bcbsD9/VfJFI7VQCOLYwTxq643Exj7sYGKISrjuN+MLAubG50hu74YLOtA/dmGB1 
G4VeXkBBR/BEjOEeoxyfFpxbZwkdoI18/Qd1JF32xpE1PlTLrJoRyjrX/6qkm9OJ 
X9GyFNd8jVxdYNI4s1JCnQ==</dsig:SignatureValue>
<dsig:KeyInfo>9
  <dsig:X509Data>
    <dsig:X509IssuerSerial>
      <dsig:X509IssuerName>dnQualifier=wBz3yptkPxbHI/\+LUUeH5R6rQfI=, 
CN=.cc-admin-x,OU=.cc-ra-1a.s430-2.ca.example.com,O=.ca.example.com</dsig:X509IssuerName>
      <dsig:X509SerialNumber>6992</dsig:X509SerialNumber>
    </dsig:X509IssuerSerial>
    <dsig:X509Certificate>10
[PEM encoded certificate omitted] 
</dsig:X509Certificate>
  </dsig:X509Data>
  <dsig:X509Data>
    <dsig:X509IssuerSerial>
      <dsig:X509IssuerName>dnQualifier=8O8W8oYHlf97Y8n0kdAgMU7/jUU=, 
CN=.s430-2,OU=.ca.example.com,O=.ca.example.com</dsig:X509IssuerName>
      <dsig:X509SerialNumber>50966</dsig:X509SerialNumber>
    </dsig:X509IssuerSerial>
    <dsig:X509Certificate> 
[PEM encoded certificate omitted] 
</dsig:X509Certificate>
  </dsig:X509Data>
  <dsig:X509Data>
    <dsig:X509IssuerSerial>
      <dsig:X509IssuerName>dnQualifier=8O8W8oYHlf97Y8n0kdAgMU7/jUU=, 
CN=.s430-2,OU=.ca.example.com,O=.ca.example.com</dsig:X509IssuerName>
      <dsig:X509SerialNumber>13278513546878383468</dsig:X509SerialNumber>
    </dsig:X509IssuerSerial>
    <dsig:X509Certificate> 
[PEM encoded certificate omitted] 
</dsig:X509Certificate>
  </dsig:X509Data>
</dsig:KeyInfo>
</dsig:Signature></DCinemaSecurityMessage>
  • 1 Start of the signature section of the KDM
  • 2 The canonicalization algorithm of the signature
  • 3 Specifies the signature algorithm (RSA) and the digest algorithm (SHA-256) of the signature.
  • 4 The AuthenticatedPublic reference element
  • 5 The method used to create the digest of the AuthenticatedPublic portion of the KDM
  • 6 The digest of the AuthenticatedPublic portion of the KDM
  • 7 The AuthenticatedPrivate reference element
  • 8 The RSA encrypted form of the two digests
  • 9 The section of the signature portion that contains the singer certificate and its certificate chain
  • 10 The certificate used to sign the KDM
Example 3.8 . KDM - Signature area 🔗

Since the KDM carries encrypted data, a tool that can decrypt the encrypted portions of the KDM has been provided in Section C.1 . kdm-decrypt takes two arguments, a KDM and the RSA private key that corresponds to the certificate to which the KDM was targeted, and displays the contents of the encrypted section. Here is an example of kdm-decrypt and the resulting output: 

$ kdm-decrypt <kdm-file>
  <rsa-private-key.pem>
    CipherDataID: f1dc124460169a0e85bc300642f866ab1
  SignerThumbprint: q5Oqr6GkfG6W2HzcBTee5m0Qjzw=2
              CPL Id: 119d8990-2e55-4114-80a2-e53f3403118d3
              Key Id: b6276c4b-b832-4984-aab6-250c9e4f91384
            Key Type: MDIK5
          Not Before: 2007-09-20T03:24:53-00:006
            Not After: 2007-10-20T03:24:53-00:007
Key
Data:
7f2f711f1b4d44b83e1dd1bf90dc7d8c

8
  • 1 The CipherData ID. This value is defined in [SMPTE-430-1]
  • 2 Thumbprint of the certificate that signed the KDM
  • 3 The UUID of the CPL associated with this KDM
  • 4 The KeyID that corresponds to the key contained in this EncryptedKey cipherblock
  • 5 The type of key contained in this EncryptedKey cipherblock
  • 6 The beginning of validity period of the key
  • 7 The end of validity period of the key
  • 8 The encryption key
Example 3.9 . kdm-decrypt Usage and Output 🔗

3.3. ETM Features 🔗

3.3.1. ETM Structure 🔗
Objective
Verify that the ETM portion of the KDM validates against the ETM schema in [SMPTE-430-3] .
Procedures
To verify that the ETM defined elements of the KDM are well formed, validate the KDM against the ETM schema in [SMPTE-430-3] , use the procedure described in Section 1.4 , i.e. , 
$ schema-check smpte-430-3.xsd <input-file> 
schema
validation
successful
If the KDM is not valid or well formed, the program will report an error. A reported error is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.3.2. ETM Validity Date Check 🔗
Objective
Verify that the signer's certificate chain was valid at the date specified in the <IssueDate> element in the <AuthenticatedPublic> area of the KDM.
Procedures
  1. Extract each of the certificates in the signer's certificate chain from the KDM using a Text Editor , then, using the process described in Section 2.1.16: Signature Validation , validate the certificate chain. Validation failure of the certificate chain is cause to fail this test.
  2. Once the certificate chain has been successfully validated, view the signer certificate in text form using the openssl command as described in Example 2.1 . Locate the Validity section of the certificate as indicated by 6 in the example certificate.
  3. Using a Text Editor , view the contents of the KDM and locate the <IssueDate> ; element as shown in 7 of Example 3.6 .
  4. Compare the Not Before and Not After values of the signer certificate to the date in the <IssueDate> element of the KDM and confirm that it is within the date range. An <IssueDate> value outside the date ranges of the certificate is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.3.3. ETM Signer Element 🔗
Objective
Verify that the certificate chain in the <Signer> element of the KDM is valid.
Procedures
  1. Extract each of the certificates in the signer's certificate chain from the KDM using a Text Editor as described in Section 1.4 .
  2. Using the process described in Section 2.1.16: Signature Validation , validate the certificate chain. Validation failure of the certificate chain is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.3.4. ETM EncryptionMethod Element 🔗
Objective
Verify that the Algorithm attribute of the <EncryptionMethod> for the encrypted key has the value "http:// www.w3.org/2001/04/xmlenc#rsaoaep-mgf1p" .
Procedures
Using a Text Editor , view the KDM and confirm that the Algorithm attribute of the <EncryptionMethod> element in the <AuthenticatedPrivate> element for each of the encrypted keys, as indicated by 3 in the example KDM, is "http://www.w3.org/2001/04/xmlenc#rsaoaep-mgf1p" . Any other value in this attribute is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.3.5. ETM AnnotationText Language 🔗
Objective
Verify that the content of the <AnnotationText> element is in a human-readable language. If the optional xml:lang attribute is present, the language must match. If the xml:lang attribute is not present, the language must be English.
Procedures
Using a Text Editor , view the KDM and confirm that the <AnnotationText> element as indicated by 6 in the Example 3.6 is a human-readable language. The presence of non-human-readable data or text in a language other than English without that language's corresponding xml:lang value is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.3.6. ETM ReferenceList Element 🔗
Objective
Verify that the <ReferenceList> element of the <EncryptedKey> element is not present.
Procedures
Using a Text Editor , view the KDM and confirm that, for each instance of the <EncryptedKey> element, the <ReferenceList> element is not present. The presence of the <ReferenceList> element indicates that the KDM is malformed and is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.3.7. ETM SignedInfo CanonicalizationMethod Element 🔗
Objective
Verify that the value of the Algorithm attribute of the <CanonicalizationMethod> element of the <SignedInfo> element in the <Signature> area of the KDM is "http://www.w3.org/TR/2001/RECxml-c14n-20010315#WithComments" .
Procedures
Using a Text Editor , view the KDM and confirm that the value of the Algorithm attribute of the <CanonicalizationMethod> of the <SignedInfo> element of the <Signature> element is "http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments" , as shown in 2 of Example 3.8 . Any other value in this attribute is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.3.8. ETM Signature Reference Elements 🔗
Objective
Verify that the <SignedInfo> element of the <Signature> area of the KDM contains at least two child <Reference> elements. The value of the URI attribute of each <Reference> element must correspond to the respective ID attribute of the digested element. Verify that the URI attribute of one of the <Reference> element identifies the AuthenticatedPublic portion of the KDM. Verify that the URI attribute of one of the <Reference> ; element identifies the AuthenticatedPrivate portion of the KDM.
Procedures
  1. Using a Text Editor , view the KDM and confirm that the <SignedInfo> element of the <Signature> area of the KDM has at least two child <Reference> elements as shown in 4 and 7 of Example 3.8 The presence of fewer than two <Reference> elements is cause to fail this test.
  2. Confirm that the URI attribute of one of the <Reference> element matches the value of the ID attribute of the AuthenticatedPublic element, as shown by 4 in Example 3.8 and 3 in Example 3.6 . The absence of this association in the KDM is cause to fail this test.
  3. Confirm that the URI attribute of one of the <Reference> element matches the value of the ID attribute of the AuthenticatedPrivate element, as shown by 7 in Example 3.8 and 1 in Example 3.7 . The absence of this association in the KDM is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.3.9. ETM SignatureMethod Element 🔗
Objective
Verify that the <SignatureMethod> element of the <SignedInfo> element of the <Signature> area of the KDM contains the URI value "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" .
Procedures
Using a Text Editor , view the KDM and confirm that the <SignatureMethod> element of the <SignedInfo> element of the <Signature> section of the KDM contains the URI value "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" , as shown in 3 of Example 3.8 . Any other value is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.3.10. ETM Signature Transforms Field 🔗
Objective
Verify that <Reference> elements of the <SignedInfo> element in the <Signature> section of the KDM do not contain a Transforms attribute.
Procedures
Using a Text Editor , view the KDM and confirm that the <Reference> elements of the <SignedInfo> element in the <Signature> section of the KDM do not contain a Transforms attribute. The presence of the Transforms attribute is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.3.11. ETM Signature DigestMethod Element 🔗
Objective
Verify that the value of the Algorithm attribute of the <DigestMethod> element of each of the <Reference> elements in the <SignedInfo> element of the <Signature> section of the KDM is " http:// www.w3.org/2001/04/xmlenc#sha256" .
Procedures
Using a Text Editor , view the KDM and confirm that the value of the Algorithm attribute of the <DigestMethod> element of each of the <Reference> elements is "http://www.w3.org/2001/04/xmlenc#sha256" , as shown in 5 of Example 3.8 . Any other value is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.3.12. ETM Signature Validity 🔗
Objective
Verify that the signature is properly formed, i.e. , the <Signature> element is properly encoded, all digests are properly formed, the <SignatureMethod> and <CanonicalizationMethod> in the <SignedInfo> element are correct, and the <Reference> values are correct. Verify that the signature is valid.
Procedures
Verifying that the signature is well formed (the XML structure is correct) and that the signature is valid (is properly encoded) can be done by verifying the signature XML against the schema using a validating XML parser, then validating the signature.
  1. Using the schema validating tool schema-check , validate the KDM against the schema found in [SMPTE-430-3] as described in Section 1.4 , i.e. , 
    $ schema-check <input-file> smpte-430-3.xsd 
schema
validation
successful
    If the KDM is not valid or well formed, the program will report an error. A reported error is reason to fail this test.
  2. Using the checksig program, verify that there is a signature included in the KDM and that it is valid. A missing or invalid signature is cause to fail this test. Note: Depending on the order of the certificates contained in the log report, the dsig_cert.py program may need to be used to re-order the certificates for the checksig program.
Supporting Materials
Reference Documents
Test Equipment

3.4. KDM Features 🔗

3.4.1. KDM MessageType Element 🔗
Objective
Verify that the <MessageType> element of the KDM contains the string "http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type"
Procedures
Using a Text Editor , view the KDM and confirm that the <MessageType> element of the KDM contains the string "http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type" as shown in 5 of Example 3.6 . Any other value in this element is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.2. KDM SubjectName Element 🔗
Objective
Verify that the Subject Name of the recipient X.509 certificate (target certificate) is identical to the value of the <SubjectName> element of the <Recipient> element of the <KDMRequiredExtensions> element in the KDM.
Procedures
Comparison of the Subject Name of the certificate against the content of the SubjectName element can be achieved by viewing the text version of the certificate and comparing it to the KDM element to verify they are the same.
  1. Using the method described in Example 2.1 , view the text information of the certificate and identify the X.509 subject name as shown in 9 .
  2. Using a Text Editor , view the contents of the KDM and identify the <SubjectName> of the <Recipient> element as shown in 11 .
  3. Confirm that the value of the <SubjectName>element is the same as the Subject Name of the certificate. Differing values are cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.3. KDM ContentAuthenticator Element 🔗
Objective
Verify that, when present, the <ContentAuthenticator> element of the <KDMRequiredExtensions> element of the KDM contains one of the certificate thumbprints of one of the certificates in the chain of the signer of the CPL.
Procedures
If the element exists in the KDM:
  1. Using Text Editor , view value of the <ContentAuthenticator> element of the <KDMRequiredExtensions> element of the KDM. If the element is not present, this test is considered passed and the remaining procedure steps are not performed.
  2. Extract the certificates from the CPL signature. Note: This may be accomplished using the dsig_extract.py program.
  3. Using dc-thumbprint , calculate the thumbprint each of the certificates: 
    $
dc-thumbprint
<certificate.pem>
  4. Confirm that the <ContentAuthenticator> value matches one of the thumbprints of the certificate chain of the signer certificate.
Presence of the <ContentAuthenticator> with a value that does not match one of the thumbprints is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.4. KDM Signer Certificate Presence 🔗
Objective
Verify that the certificate that signed the KDM is present in one of the <X509Data> elements of the <KeyInfo> elements in the signature portion of the KDM.
Procedures
Testing that the certificate that signed the KDM is present in an <X509Data> element can be achieved by validating the signature. If the validation is successful then the certificate that signed the KDM is present. The signature can be validated using the dsig_cert.py and checksig commands:

Example: 

$ dsig_cert.py <kdm-file.kdm.xml> > tmp.xml 
$
checksig
tmp.xml
A KDM that causes checksig to display errors indicates that the signature did not validate and shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.5. KDM KeyIdList/TypedKeyId Field 🔗
Objective
Verify that <TypedKeyId> element of the <KeyIdList> element in the <KDMRequiredExtensions> element is well formed. Verify that the element contains one of the following values: MDIK, MDAK, MDSK, FMIK, or FMAK .
Procedures
To complete this test, validate the KDM against the schema in [SMPTE-430-1] , then verify that one of the required values is present in the element.
  1. Validate the KDM against the schema in [SMPTE-430-1] using the procedure described in Section 1.4 , i.e. , 
    $ schema-check <kdm-file.kdm.xml> smpte-430-1.xsd 
schema
validation
successful
    If the KDM is not valid or well formed, the program will report an error. A reported error is cause to fail this test.
  2. Using a Text Editor , view the value of the <TypedKeyId> element, and verify that the element contains one of: MDIK, MDAK, MDSK, FMIK, or FMAK , as shown in 19 of Example 3.6 Any other value in this element is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.6. KDM ForensicMarkFlagList Element 🔗
Objective
Verify that, if present, the <ForensicMarkFlagList> element contains a list of one or both of the following two URIs:
  • http://www.smpte-ra.org/430-1/2006/KDM#mrkflg-picture-disable
  • http://www.smpte-ra.org/430-1/2006/KDM#mrkflg-audio-disable
Procedures
Using a Text Editor , view the KDM and confirm the presence of the <ForensicMarkFlagList> element. The absence of the element is cause to pass this test and the remainder of this procedure can be skipped. If present, the element must contain one or both of the following URI values:
  • http://www.smpte-ra.org/430-1/2006/KDM#mrkflg-picture-disable
  • http://www.smpte-ra.org/430-1/2006/KDM#mrkflg-audio-disable
as shown by 21 of Example 3.6 The presence of the element with any other value, or no value, is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.7. KDM EncryptedData Element 🔗
Objective
Verify that element <EncryptedData> is not present.
Procedures
Using a Text Editor , view the KDM and confirm that the <EncryptedData> element is not present. The presence of the element is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.8. KDM KeyInfo Element 🔗
Objective
If present, verify that the values of each <KeyInfo> element of all <EncryptedKey> elements in the <AuthenticatedPrivate> section of the KDM are identical.
Procedures
Using a Text Editor , view the KDM and, if present, confirm that the <KeyInfo> values are identical in all instances of <EncryptedKey> elements. The absence of <KeyInfo> elements is cause to pass this test. The presence of differing <KeyInfo> values in <EncryptedKey> elements is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.9. KDM DeviceListDescription Element 🔗
Objective
Verify that when present, the value of the <DeviceListDescription> element is in a human-readable language. If the optional xml:lang attribute is present, the language must match. If the xml:lang attribute is not present, the language must be English.
Procedures
See Objective.

Using a Text Editor , view the KDM and confirm that the <DeviceListDescription> element is either absent or is present and contains human-readable text. The presence of non-human-readable data or text in a language other than English without that language's corresponding xml:lang value is cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
3.4.10. KDM ContentTitleText Language Attribute 🔗
Objective
Verify that value of the <ContentTitleText> element is in a human-readable language. If the optional xml:lang attribute is present, the language must match. If the xml:lang attribute is not present, the language must be English.
Procedures
Using a Text Editor , view the KDM and confirm that the <ContentTitleText> element as indicated by 13 in the Example 3.6 is a human-readable language. The presence of non-human-readable data or text in a language other than English without that language's corresponding xml:lang value is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.11. KDM KeyType Scope Attribute 🔗
Objective
Verify that the optional scope attribute of the <TypedKeyId> element of the <KeyIdList> element is absent or contains the value http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type.
Procedures
Using a Text Editor , view the KDM and confirm that the scope attribute of the <TypedKeyId> element is either not present or is present and contains the value http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type , as shown in 19 of Example 3.6 Presence of the scope attribute with any other value is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.12. KDM EncryptionMethod 🔗
Objective
Verify that the Algorithm attribute of the <EncryptionMethod> element of the <EncryptedKey/> element has the value "http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" .
Procedures
Using a Text Editor , view the KDM and confirm that the Algorithm attribute of the <EncryptionMethod> of the <EncryptedKey/> element contains the value http://www.w3.org/2001/04/xmlenc#rsa-oaepmgf1p , as shown in 3 of Example 3.7 . Presence of the Algorithm attribute with any other value is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.13. KDM CompositionPlaylistId Element 🔗
Objective
Verify that the value of the <CompositionPlaylistId> element in the KDM matches the value in the RSA protected <EncryptedKey> structure, and that these values match the value of the <Id> element in the respective composition playlist.
Procedures
The data in the encrypted portion of the KDM can be viewed using the kdm-decrypt tool included in Section C.1 . To view the data contained in the encrypted section of the KDM, run the command specifying the KDM and the RSA private key corresponding to the certificate to which the KDM was targeted, i.e. , 
$
kdm-decrypt
<kdm-file>
<rsa-private-key.pem>
Verify that the <CompositionPlaylistId> element of the <KDMRequiredExtensions> element in the plaintext portion of the KDM contains the same value as the CPL ID present in the RSA protected <EncryptedKey> structure. Non-identical values shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.14. KDM Validity Fields 🔗
Objective
Verify that value of the <ContentKeysNotValidBefore> and <ContentKeysNotValidAfter> elements match their counterparts in the RSA protected <EncryptedKey> structure and that the values are in UTC format.
Procedures
The information in the encrypted portion of the KDM can be viewed using the kdm-decrypt tool included in Section C.1 . To view the data contained in the encrypted section of the KDM, run the command specifying the KDM and the RSA private key corresponding to the certificate to which the KDM was targeted, i.e. , 
$
kdm-decrypt
<kdm-file>
<rsa-private-key.pem>
Verify that the <ContentKeysNotValidBefore> element of the <KDMRequiredExtensions> element has the same value as the corresponding field inside the RSA protected EncryptedKey structure, and that it is in UTC format as specified in [RFC-3339] . Non-identical values shall be cause to fail this test.

Verify that the <ContentKeysNotValidAfter> element of the <KDMRequiredExtensions> element has the same value as the corresponding field inside the RSA protected EncryptedKey structure, and that it is in UTC format as specified in [RFC-3339] . Non-identical values shall be cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
3.4.15. KDM KeyIdList Element 🔗
Objective
Verify that each of the KeyID values in the <KeyIdList> element of the <KDMRequiredExtensions> element matches a KeyID in the RSA protected <EncryptedKey> structure and that there are no KeyIDs without corresponding <EncryptedKey> structures, nor <EncryptedKey> structures with KeyIDs that are not present in the KeyIDList.
Procedures
The data in the encrypted portion of the KDM can be viewed using the kdm-decrypt tool included in Section C.1 . To view the data contained in the encrypted section of the KDM, run the command specifying the KDM and the RSA private key corresponding to the certificate to which the KDM was targeted, i.e. , 
$
kdm-decrypt
<kdm-file>
<rsa-private-key.pem>
Compare the list of KeyIDs to the KeyIDs in the RSA protected EncryptedKey structures and verify that each of the KeyIDs in the list correspond to a KeyID in an RSA protected EncryptedKey structure. The presence of KeyIDs in the KeyIDList that do not correspond to a KeyID in an RSA protected EncryptedKey structure shall be cause to fail this test. The presence of a KeyID in an RSA protected EncryptedKey structure that is not also present in the KeyIDList shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.16. KDM CipherData Structure ID 🔗
Objective
Verify that the value of the CipherData Structure ID in the RSA protected <EncryptedKey> structure is f1dc124460169a0e85bc300642f866ab .
Procedures
The data in the encrypted portion of the KDM can be viewed using the kdm-decrypt tool included in Section C.1 . To view the data contained in the encrypted section of the KDM, run the command specifying the KDM and the RSA private key corresponding to the certificate to which the KDM was targeted, i.e. , 
$
kdm-decrypt
<kdm-file>
<rsa-private-key.pem>
Verify that the plaintext value of the CipherData Structure ID is f1dc124460169a0e85bc300642f866ab . Any other value shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.17. KDM CipherData Signer Thumbprint 🔗
Objective
Verify that the thumbprint of the signer's certificate in the RSA protected <EncryptedKey> element matches the thumbprint of the certificate that signed the KDM.
Procedures
The data in the encrypted portion of the KDM can be viewed using the kdm-decrypt tool included in Section C.1 . To view the data contained in the encrypted section of the KDM, run the command specifying the KDM and the RSA private key corresponding to the certificate to which the KDM was targeted, i.e. , 
$
kdm-decrypt
<kdm-file>
<rsa-private-key.pem>
A certificate thumbprint can be calculated using the dc-thumbprint tool included in Section C.1 . Calculate the thumbprint with dc-thumbprint , i.e. , 
$dc-thumbprint
<certificate.pem>
Identify the certificate used to sign the KDM and calculate its thumbprint. Compare this thumbprint against the thumbprint decrypted from the <EncryptedKey> element and confirm that they are the same. Non-identical values shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.18. KDM CipherData Validity 🔗
Objective
Verify that the two CipherData validity fields contain UTC format time values.
Procedures
The data in the encrypted portion of the KDM can be viewed using the kdm-decrypt tool included in Section C.1 . To view the data contained in the encrypted section of the KDM, run the command specifying the KDM and the RSA private key corresponding to the certificate to which the KDM was targeted, i.e. , 
$
kdm-decrypt
<kdm-file>
<rsa-private-key.pem>
Verify that the plaintext representation of the <EncryptedKey> element contains two validity time stamps in UTC format. Time stamps that are not present or that are not in UTC format shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.19. KDM CipherData CPL ID 🔗
Objective
Verify that the CipherData Composition Playlist ID is identical to the value of the <CompositionPlaylistId> element in the other portions of the KDM.
Procedures
The data in the encrypted portion of the KDM can be viewed using the kdm-decrypt tool included in Section C.1 . To view the data contained in the encrypted section of the KDM, run the command specifying the KDM and the RSA private key corresponding to the certificate to which the KDM was targeted, i.e. , 
$
kdm-decrypt
<kdm-file>
<rsa-private-key.pem>
Verify that the decrypted plaintext value of the CompositionPlaylistID the same as the <CompositionPlaylistId> element in the AuthenticatedPublic area of the KDM. Mismatching composition playlist IDs shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.20. KDM EncryptedKey KeyType 🔗
Objective
Verify that the key types in the <EncryptedKey> elements of the KDM use only the allowed key types ( MDIK, MDAK, MDSK, FMIK and FMAK ), and that they match the plaintext fields in the <TypedKeyId> element values for the KeyIDs in the <KeyIdList> element.
Procedures
The data in the encrypted portion of the KDM can be viewed using the kdm-decrypt tool included in Section C.1 . To view the data contained in the encrypted section of the KDM, run the command specifying the KDM and the RSA private key corresponding to the certificate to which the KDM was targeted, i.e. , 
$
kdm-decrypt
<kdm-file>
<rsa-private-key.pem>
For each <EncryptedKey> element, verify that the plaintext representation contains a key type that is one of MDIK, MDAK, MDSK, FMIK or FMAK , and that the key type is identical to the key type for the corresponding KeyID in the KeyIDList. A key type that is not either MDIK, MDAK, MDSK, FMIK or FMAK shall be cause to fail this test. A key type in the <EncryptedKey> element that does not match the key type for the corresponding KeyID in the KeyIDList shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
3.4.21. KDM Recipient X509IssuerName 🔗
Objective
Verify that the Distinguished Name value in the <X509IssuerName> element is compliant with [RFC-2253] .
Procedures
Using a Text Editor , view the KDM and confirm that the <X509IssuerName> element as shown below 8 of Example 3.6 . Verify that any special characters are properly escaped, and the sequence is correct and valid. Improperly escaped characters or sequences that do not conform to [RFC-2253] shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment

3.5. KDM Decoder Behavior 🔗

The procedures in this section test the behavior of a KDM decoding device, such as a Security Manager (SM) or a KDM authoring device. The procedures use a generic syntax to instruct the test operator to cause the Test Subject to decode a KDM.

In the case of an SM, the text "Perform an operation..." should be interpreted to mean "Assemble and play a show with DCI 2K StEM (Encrypted) ...".

In the case of a KDM authoring device, the text "Perform an operation..." should be interpreted to mean "Perform a KDM read or ingest operation...".

Some of the procedures in this section require test content that is specifically malformed. In some implementations, these malformations may be caught and reported directly by the SMS without involving the SM. Because the purpose of the procedures is to assure that the SM demonstrates the required behavior, the manufacturer of the Test Subject may need to provide special test programs or special SMS testing modes to allow the malformed content to be applied directly to the SM.

3.5.1. KDM NonCriticalExtensions Element 🔗
Objective
Verify that a decoding device does not reject a KDM when the <NonCriticalExtensions> element is present and not empty.
Procedures
Perform an operation on the Test Subject using KDM with non-empty NonCriticalExtensions , a KDM that contains the <NonCriticalExtensions> element with child content. Verify that the operation is successful. A failed operation shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
3.5.2. ETM IssueDate Field Check 🔗
Objective
  • Verify that the Test Subject verifies that the signer's certificate is valid at the time when the KDM was issued.
  • Verify that the Test Subject verifies that the KDM validity does not extend beyond the ending validity period of the certificate.
Procedures
For each of the malformations below, perform an operation on the Test Subject using the test material that has that malformation. Verify that the operation fails. A successful operation is cause to fail this test.
  1. KDM in which the certificate that signed the KDM has an ending validity date prior to the KDM issue date ( KDM with expired Signer certificate ).
  2. KDM in which the certificate that signed the KDM has a starting validity date after the KDM issue date ( KDM issued before certificate valid ).
  3. KDM in which the validity period extends beyond the end of the signing certificate's validity period ( KDM validity exceeds signer validity ).
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
3.5.3. Deleted Section 🔗

The section "Maximum Number of DCP Keys" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

3.5.4. Structure ID Check 🔗
Objective
Verify that the Test Subject checks the validity of the CipherData Structure ID as specified in [SMPTE-430-1] and rejects the KDM if the Structure ID is incorrect.
Procedures
Perform an operation on the Test Subject using KDM with corrupted CipherData block , a KDM with an invalid CipherData Structure. Verify that the operation fails. A successful operation is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
3.5.5. Certificate Thumbprint Check 🔗
Objective
Verify that the Test Subject checks that the thumbprint of the signer's certificate matches the signer of the KDM and rejects the KDM if it does not.
Procedures
Perform an operation on the Test Subject using the KDM with a signer's certificate whose thumbprint does not match the thumbprint of the certificate used to sign the KDM ( KDM with incorrect signer thumbprint ). Verify that the operation fails. A successful operation is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
3.5.6. Deleted Section 🔗

The section "Certificate Presence Check" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

3.5.7. KeyInfo Field Check 🔗
Objective
Verify that when KeyInfo elements are present in the <EncryptedKey> elements of the <AuthenticatedPrivate> area of the KDM, the Test Subject verifies that they all match, and that the Test Subject rejects the KDM if they do not match.
Procedures
Perform an operation on the Test Subject using the KDM with KeyInfo element values that do not match ( KDM with KeyInfo mismatch ). Verify that the operation fails. A successful operation is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
3.5.8. KDM Malformations 🔗
Objective
Verify that the SM checks that the KDM is well formed and labeled with the correct namespace name.
Procedures
  1. Perform an operation on the Test Subject using KDM with invalid XML , which contains XML that is not well-formed. If the operation succeeds this is cause to fail this test.
  2. Perform an operation on the Test Subject using KDM with invalid MessageType , which contains an incorrect ETM <MessageType> value. If the operation succeeds this is cause to fail this test.
  3. Perform an operation on the Test Subject using KDM with expired Signer certificate , which contains a KDM whose signing certificate has expired. If the operation succeeds this is cause to fail this test.
  4. Perform an operation on the Test Subject using KDM with incorrect namespace name value , which contains an incorrect ETM namespace name. If the operation succeeds this is cause to fail this test.
  5. Perform an operation on the Test Subject using KDM with empty TDL , which contains a TDL with no entries. If the operation succeeds this is cause to fail this test.
  6. Extract a security log from the Test Subject and using a Text Editor , identify the KDMKeysReceived events associated with the above steps and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. For the log record produced by the operation using KDM with invalid MessageType , verify that the value of the SignerID parameter contains the Certificate Thumbprint of the signing certificate of KDM with invalid MessageType . Verify that ReferencedIDs element contains a KeyDeliveryMessageID parameter with a value that is the MessageId of KDM with invalid MessageType . Failure of any verification shall be cause to fail this test.
    3. For the log record produced by the operation using KDM with expired Signer certificate , verify that the contentId element contains the Id of DCI 2K StEM (Encrypted) . Verify that the value of the SignerID parameter contains the Certificate Thumbprint of the signing certificate of KDM with expired Signer certificate . Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of DCI 2K StEM (Encrypted) and KeyDeliveryMessageID parameter with a value that is the MessageId of KDM with expired Signer certificate . Failure of any verification shall be cause to fail this test.
    4. Confirm the presence of a KDMFormatError exception in each KDMKeysReceived log record. Record any additional parameters associated with the exception. A missing KDMFormatError exception in any of the associated KDMKeysReceivedlog records shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
3.5.9. KDM Signature 🔗
Objective
Verify that the Test Subject checks that the KDM signature is valid, including checking that the certificate that signed the KDM is included in the KDM and rejecting the KDM if it is not.
Procedures
  1. Perform an operation on the Test Subject using KDM with incorrect message digest . The KDM KDM with incorrect message digest is invalid (wrong signature/hash error). If the operation succeeds this is cause to fail this test.
  2. Perform an operation on the Test Subject using KDM with incorrect signer thumbprint . The KDM KDM with incorrect signer thumbprint is invalid (wrong signature identity). If the operation succeeds this is cause to fail this test.
  3. Perform an operation on the Test Subject using KDM without signer certificate . The KDM KDM without signer certificate is invalid (broken certificate chain). If the operation succeeds this is cause to fail this test.
  4. Extract a security log from the Test Subject and using a Text Editor , identify the KDMKeysReceived events associated with the above steps and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Verify that the contentId element contains the Id of DCI 2K StEM (Encrypted) . Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of DCI 2K StEM (Encrypted) and KeyDeliveryMessageID parameter with a value that is the MessageId of the KDM used. Missing required elements or incorrect parameters shall be cause to fail this test.
    2. For the log records produced by the operation using KDM with incorrect message digest and KDM with incorrect signer thumbprint , verify that the value of the SignerId parameter contains the Certificate Thumbprint of the signing certificate of the KDM.
    3. Confirm the presence of a SignatureError exception in each KDMKeysReceived log record. Record any additional parameters associated with the exception. A missing SignatureError exception in any of the associated KDMKeysReceived log records shall be cause to fail this test.
  5. Perform an operation on the Test Subject using KDM signed with incorrect signer certificate format . The KDM KDM signed with incorrect signer certificate format is invalid (wrong signer certificate format). If the operation succeeds this is cause to fail this test.
  6. Extract a security log from the Test Subject and using a Text Editor , identify the KDMKeysReceived event associated with the above step and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Verify that the contentId element contains the Id of DCI 2K StEM (Encrypted) . Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of DCI 2K StEM (Encrypted) and KeyDeliveryMessageID parameter with a value that is the MessageId of the KDM used. Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a CertFormatError exception in the KDMKeysReceived log record. Record any additional parameters associated with the exception. A missing CertFormatError exception in the associated KDMKeysReceived log record shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
3.5.10. KDM NonCriticalExtensions Element (OBAE) 🔗
Objective
Verify that a decoding device does not reject a OBAE-capable KDM when the <NonCriticalExtensions> element is present and not empty.
Procedures
Perform an operation on the Test Subject using KDM with non-empty NonCriticalExtensions (OBAE) , a KDM that contains the <NonCriticalExtensions> element with child content. Verify that the operation is successful. A failed operation shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
3.5.11. ETM IssueDate Field Check (OBAE) 🔗
Objective
  • Verify that the OBAE-capable Test Subject verifies that the signer's certificate is valid at the time when the KDM was issued.
  • Verify that the OBAE-capable Test Subject verifies that the KDM validity does not extend beyond the ending validity period of the certificate.
Procedures
For each of the malformations below, perform an operation on the Test Subject using the test material that has that malformation. Verify that the operation fails. A successful operation is cause to fail this test.
  1. KDM in which the certificate that signed the KDM has an ending validity date prior to the KDM issue date ( KDM with expired Signer certificate (OBAE) ).
  2. KDM in which the certificate that signed the KDM has a starting validity date after the KDM issue date ( KDM issued before certificate valid (OBAE) ).
  3. KDM in which the validity period extends beyond the end of the signing certificate's validity period ( KDM validity exceeds signer validity (OBAE) ).
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
3.5.12. Structure ID Check (OBAE) 🔗
Objective
Verify that the OBAE-capable Test Subject checks the validity of the CipherData Structure ID as specified in [SMPTE-430-1] and rejects the KDM if the Structure ID is incorrect.
Procedures
Perform an operation on the Test Subject using KDM with corrupted CipherData block (OBAE) , a KDM with an invalid CipherData Structure. Verify that the operation fails. A successful operation is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
3.5.13. Certificate Thumbprint Check (OBAE) 🔗
Objective
Verify that the OBAE-capable Test Subject checks that the thumbprint of the signer's certificate matches the signer of the KDM and rejects the KDM if it does not.
Procedures
Perform an operation on the Test Subject using the KDM with a signer's certificate whose thumbprint does not match the thumbprint of the certificate used to sign the KDM ( KDM with incorrect signer thumbprint (OBAE) ). Verify that the operation fails. A successful operation is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
3.5.14. KeyInfo Field Check (OBAE) 🔗
Objective
Verify that when KeyInfo elements are present in the <EncryptedKey> elements of the <AuthenticatedPrivate> area of the KDM, the OBAE-capable Test Subject verifies that they all match, and that the OBAE-capable Test Subject rejects the KDM if they do not match.
Procedures
Perform an operation on the Test Subject using the KDM with KeyInfo element values that do not match ( KDM with KeyInfo mismatch (OBAE) ). Verify that the operation fails. A successful operation is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
3.5.15. KDM Malformations (OBAE) 🔗
Objective
Verify that the OBAE-capable SM checks that the KDM is well formed and labeled with the correct namespace name.
Procedures
  1. Perform an operation on the Test Subject using KDM with invalid XML (OBAE) , which contains XML that is not well-formed. If the operation succeeds this is cause to fail this test.
  2. Perform an operation on the Test Subject using KDM with invalid MessageType (OBAE) , which contains an incorrect ETM <MessageType> value. If the operation succeeds this is cause to fail this test.
  3. Perform an operation on the Test Subject using KDM with expired Signer certificate (OBAE) , which contains a KDM whose signing certificate has expired. If the operation succeeds this is cause to fail this test.
  4. Perform an operation on the Test Subject using KDM with incorrect namespace name value (OBAE) , which contains an incorrect ETM namespace name. If the operation succeeds this is cause to fail this test.
  5. Perform an operation on the Test Subject using KDM with empty TDL (OBAE) , which contains a TDL with no entries. If the operation succeeds this is cause to fail this test.
  6. Extract a security log from the Test Subject and using a Text Editor , identify the KDMKeysReceived events associated with the above steps and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. For the log record produced by the operation using KDM with invalid MessageType (OBAE) , verify that the value of the SignerID parameter contains the Certificate Thumbprint of the signing certificate of KDM with invalid MessageType (OBAE) . Verify that ReferencedIDs element contains a KeyDeliveryMessageID parameter with a value that is the MessageId of KDM with invalid MessageType (OBAE) . Failure of any verification shall be cause to fail this test.
    3. For the log record produced by the operation using KDM with expired Signer certificate (OBAE) , verify that the contentId element contains the Id of DCI 2K StEM (OBAE) (Encrypted) . Verify that the value of the SignerID parameter contains the Certificate Thumbprint of the signing certificate of KDM with expired Signer certificate (OBAE) . Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of DCI 2K StEM (OBAE) (Encrypted) and KeyDeliveryMessageID parameter with a value that is the MessageId of KDM with expired Signer certificate (OBAE) . Failure of any verification shall be cause to fail this test.
    4. Confirm the presence of a KDMFormatError exception in each KDMKeysReceived log record. Record any additional parameters associated with the exception. A missing KDMFormatError exception in any of the associated KDMKeysReceivedlog records shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
3.5.16. KDM Signature (OBAE) 🔗
Objective
Verify that the OBAE-capable Test Subject checks that the KDM signature is valid, including checking that the certificate that signed the KDM is included in the KDM and rejecting the KDM if it is not.
Procedures
  1. Perform an operation on the Test Subject using KDM with incorrect message digest (OBAE) . The KDM KDM with incorrect message digest (OBAE) is invalid (wrong signature/hash error). If the operation succeeds this is cause to fail this test.
  2. Perform an operation on the Test Subject using KDM with incorrect signer thumbprint (OBAE) . The KDM KDM with incorrect signer thumbprint (OBAE) is invalid (wrong signature identity). If the operation succeeds this is cause to fail this test.
  3. Perform an operation on the Test Subject using KDM without signer certificate (OBAE) . The KDM KDM without signer certificate (OBAE) is invalid (broken certificate chain). If the operation succeeds this is cause to fail this test.
  4. Extract a security log from the Test Subject and using a Text Editor , identify the KDMKeysReceived events associated with the above steps and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Verify that the contentId element contains the Id of DCI 2K StEM (OBAE) (Encrypted) . Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of DCI 2K StEM (OBAE) (Encrypted) and KeyDeliveryMessageID parameter with a value that is the MessageId of the KDM used. Missing required elements or incorrect parameters shall be cause to fail this test.
    2. For the log records produced by the operation using KDM with incorrect message digest (OBAE) and KDM with incorrect signer thumbprint (OBAE) , verify that the value of the SignerId parameter contains the Certificate Thumbprint of the signing certificate of the KDM.
    3. Confirm the presence of a SignatureError exception in each KDMKeysReceived log record. Record any additional parameters associated with the exception. A missing SignatureError exception in any of the associated KDMKeysReceived log records shall be cause to fail this test.
  5. Perform an operation on the Test Subject using KDM signed with incorrect signer certificate format (OBAE) . The KDM KDM signed with incorrect signer certificate format (OBAE) is invalid (wrong signer certificate format). If the operation succeeds this is cause to fail this test.
  6. Extract a security log from the Test Subject and using a Text Editor , identify the KDMKeysReceived event associated with the above step and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Verify that the contentId element contains the Id of DCI 2K StEM (OBAE) (Encrypted) . Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of DCI 2K StEM (OBAE) (Encrypted) and KeyDeliveryMessageID parameter with a value that is the MessageId of the KDM used. Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a CertFormatError exception in the KDMKeysReceived log record. Record any additional parameters associated with the exception. A missing CertFormatError exception in the associated KDMKeysReceived log record shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —

Chapter 4. Digital Cinema Packaging 🔗

The DCP is the file format for d-cinema content. Entire suites of standards documents from SMPTE define this format, most notably the 428 and 429 multi-part documents. In addition, many IETF documents and some ISO documents are referenced from the SMPTE works. Reading and understanding all of these documents is a substantial task, but it is essential knowledge for accurate and efficient analysis of d-cinema files

In the following procedures, simple tools are used to display the contents of d-cinema files. Example output from these tools is shown with descriptions of the features that will be interesting to the Test Operator. In addition to the tools used in this text, the Test Operator may use more sophisticated methods so long as the results obtained are equivalent to the procedures presented here. The reader should also note that a programmer's Text Editor and a binary viewer or editor are essential tools for direct inspection of data.

4.1. Asset Map 🔗

D-cinema track files and composition playlists are identified by unique, embedded identifiers. These identifiers, called UUIDs , are defined by [RFC-4122] . d-cinema XML files use UUIDs to refer to other d-cinema XML files and MXF files (assets). When d-cinema assets are written to a filesystem, a mechanism is needed to relate the UUID values to filename values in the filesystem. An Asset Map is an XML document that provides a mapping from UUID values to filesystem paths. When a d-cinema package is written to a volume, an Asset Map is created that includes the size and location of every file in the package 1 .

Along with the Asset Map, each volume has a Volume Index file. The Volume Index file is used to differentiate volumes in a multiple-volume distribution. Both Asset Maps and Volume Indexes are XML files (as described in Section 3.1 ). The formats of the Asset Map file and the Volume Index file are specified in [SMPTE-429-9] 

<?xml version="1.0" encoding="UTF-8"?>1
<AssetMap xmlns="http://www.smpte-ra.org/schemas/429-9/2007/AM">2
  <Id>urn:uuid:425e93f7-bca2-4255-b8ec-8c7d16fc8881</Id>3
  <Creator> Packaging Tools v1.0 </Creator>4
  <VolumeCount>1</VolumeCount>5
  <IssueDate>2007-07-06T18:25:42-00:00</IssueDate>6
  <Issuer>user@host</Issuer>7
  <AssetList>8
    <Asset>9
      <Id>urn:uuid:034b95b0-7424-420f-bbff-a875a79465a5</Id>10
      <PackingList>true</PackingList>11
      <ChunkList>12
        <Chunk>13
          <Path>perfect_movie_domestic_51.pkl.xml</Path>14
          <VolumeIndex>1</VolumeIndex>15
          <Offset>0</Offset>16
          <Length>14366</Length>17
        </Chunk>
      </ChunkList>
    </Asset>
    <Asset>
      <Id>urn:uuid:4f89a209-919b-4f21-a1d6-21ad32581115</Id>
      <ChunkList>
        <Chunk>
          <Path>perfect_movie_j2c_r01.mxf</Path>
          <VolumeIndex>1</VolumeIndex>
          <Offset>0</Offset>
          <Length>342162304</Length>
        </Chunk>
      </ChunkList>
    </Asset>
    <Asset>
      <Id>urn:uuid:e522f7b6-6731-4df5-a80e-8cfd74f82219</Id>
      <ChunkList>
        <Chunk>
          <Path>perfect_movie_wav_r01.mxf</Path>
          <VolumeIndex>1</VolumeIndex>
          <Offset>0</Offset>
          <Length>34591246</Length>
        </Chunk>
      </ChunkList>
    </Asset>
    [additional assets omitted for brevity] 
    ...
  </AssetList>
</AssetMap>
  • 1 XML Declaration. This specifies the version of the XML standard to which the document conforms, and the character encoding of the document.
  • 2 The root Assetmap element. This element contains the XML namespace declaration for an Assetmap as specified in [SMPTE-429-9] .
  • 3 The Unique Universal ID (UUID) of the asset map. This is used to uniquely identify the asset map
  • 4 The person, software, or system that generated the asset map.
  • 5 The Volume count indicates the total number of volumes that are referenced by the asset map
  • 6 The date the asset map was issued.
  • 7 The organization or entity that issued the asset map.
  • 8 The AssetList contains all of the assets in the asset map. Each asset is described in an Asset sub-element of the AssetList
  • 9 The Asset element contains all the data about an asset necessary to locate it in the filesystem.
  • 10 The Asset UUID is the unique ID of a particular asset in the asset map
  • 11 The Packinglist element identifies whether or not the asset being described is a Packing List document
  • 12 The Chunklist contains the list of chunks that comprise the complete asset
  • 13 The Chunk element
  • 14 The asset chunk path is the path and filename, in the file system, of the file that contains the asset data
  • 15 The chunk volume index indicates the volume number on which the chunk resides
  • 16 The chunk offset is the number of bytes from the beginning of the complete asset file that this chunk begins. A chunk that is either a complete file or that is the beginning of a file will have an offset of 0.
  • 17 The chunk length is the length, in bytes, of the chunk of the asset
Example 4.1 . Asset Map 🔗 
<?xml version="1.0" encoding="UTF-8"?>1
<VolumeIndex xmlns="http://www.smpte-ra.org/schemas/429-9/2007/AM">2
<Index>1</Index>3
</VolumeIndex>
  • 1 XML Declaration. This specifies the version of the XML standard to which the document conforms, and the character encoding of the document
  • 2 The root Assetmap element. This element contains the XML namespace declaration for an Assetmap as specified in [SMPTE-429-9] .
  • 3 The index number of the volume.
Example 4.2 . Volume Index 🔗
4.1.1. Asset Map File 🔗
Objective
Verify that the Asset Map file is in the root of the volume, and that it it named ASSETMAP.xml . Verify that the Asset Map validates against the schema defined in [SMPTE-429-9] .
Procedures
  1. Mount the media that contains the volume with a computer, and obtain a directory listing of the root of the filesystem. The absence of the file ASSETMAP.xml is cause to fail this test.
  2. Using the schema-check software utility, validate the file ASSETMAP.xml against the schema in [SMPTE-429-9] . Failure to correctly validate is cause to fail this test. For more information on schema validation see Section 1.4: Conventions and Practices

E.g.: 

$ cd / 
$ ls -F 
ASSETMAP.xml 
PKL_c2434860-7dab-da2b-c39f-5df000eb2335.xml 
J2K_a13c59ec-f720-1d1f-b78f-9bdea4968c7d_video.mxf 
WAV_22d190bd-f43b-a420-a12e-2bf29a737521_audio.mxf 
... 
$ 
$ schema-check ASSETMAP.xml smpte-429-9.xsd 
schema validation successful 
$
Supporting Materials
Reference Documents
Test Equipment
4.1.2. Volume Index File 🔗
Objective
Verify that the Volume Index file is in the root of the volume and that it it named VOLINDEX.xml . Verify that the Volume Index file validates against the schema defined in [SMPTE-429-9] .
Procedures
  1. Mount the media that contains the volume with a computer, and obtain a directory listing of the root of the filesystem. The absence of the file VOLINDEX.xml is cause to fail this test.
  2. Using the schema-check software utility, validate the file VOLINDEX.xml against the schema in [SMPTE-429-9] . Failure to correctly validate is cause to fail this test. For more information on schema validation see Section 1.4: Conventions and Practices .
E.g.: 
$ cd / 
$ ls -F 
VOLINDEX.xml 
PKL_c2434860-7dab-da2b-c39f-5df000eb2335.xml 
J2K_a13c59ec-f720-1d1f-b78f-9bdea4968c7d_video.mxf 
WAV_22d190bd-f43b-a420-a12e-2bf29a737521_audio.mxf 
... 
$ 
$ schema-check VOLINDEX.xml smpte-429-9.xsd 
schema validation successful 
$
Supporting Materials
Reference Documents
Test Equipment

4.2. Packing List 🔗

The Packing List (PKL) is an XML document (see Section 3.1 ) that specifies the contents of a d-cinema Package. It contains the UUID, file type (MXF track file, CPL, etc.), and a message digest of each file in the DCP. This information is used to ensure that all of the expected files have been included and have not been modified or corrupted in transit. The format of the Packing List file is specified by [SMPTE-429-8] . 

<?xml version="1.0" encoding="UTF-8" standalone="no"?>1
<PackingList xmlns="http://www.smpte-ra.org/schemas/429-8/2007/PKL">2
  <Id>urn:uuid:59430cd7-882d-48e8-a026-aef4b6253dfc</Id>3
  <AnnotationText>Perfect Movie DCP</AnnotationText>4
  <IssueDate>2007-07-25T18:21:31-00:00</IssueDate>5
  <Issuer>user@host</Issuer>6
  <Creator>Packaging Tools v1.0</Creator>7
  <AssetList>8
    <Asset>9
      <Id>urn:uuid:24d73510-3481-4ae5-b8a5-30d9eeced9c1</Id>10
      <Hash>AXufMKY7NyZcfSXQ9sCZls5dSyE=</Hash>11
      <Size>32239753</Size>12
      <Type>application/mxf</Type>13
    </Asset>
    <Asset>
      <Id>urn:uuid:456e547d-af92-4abc-baf3-c4d730bbcd65</Id>
      <Hash>kAAo0kXYVDBJUphIID89zauv50w=</Hash>
      <Size>86474446</Size>
      <Type>application/mxf</Type>
    </Asset>
    <Asset>
      <Id>urn:uuid:e4a4e438-63ec-46cb-b9aa-43acee787d79</Id>
      <Hash>kt5bP8y4zmHNAY1qVnujItAb4sY=</Hash>
      <Size>12163</Size>
      <Type>text/xml</Type>
    </Asset>
    <Asset>
      <Id>urn:uuid:3d445456-54d5-42bc-a7cc-a8c00b20ffb7</Id>
      <Hash>AQWMKCxxMv001zTS3Y3Oj8M+d9s=</Hash>
      <Size>62500144</Size>
      <Type>application/mxf</Type>
    </Asset>
    [Remaining assets and signature omitted for brevity]
  </AssetList>
  [Signature omitted for brevity]
</PackingList>
  • 1 XML Declaration. This specifies the version of the XML standard to which the document conforms
  • 2 The root packing list element. This element contains the XML namespace declaration for the packing list as specified in [SMPTE-429-8]
  • 3 The Unique Universal ID (UUID) of the packing list
  • 4 The Annotation text is a plain text, human readable language description of the packing list's contents
  • 5 The date the packing list was issued
  • 6 The organization or entity that issued the packing list
  • 7 The person, software, or system that generated the packing lis
  • 8 The assetlist contains all of the assets in the packing list
  • 9 The Asset element contains all the metadata necessary to identify the file
  • 10 The Asset UUID is the unique ID of a particular asset in the packing list
  • 11 The asset hash is a message digest of the asset file
  • 12 The asset size is the size, in bytes, of the asset's file in the filesystem
  • 13 The asset type contains the mime type of the asset, which is a generic description of the file format. It also contains an attribute that specifies the specific kind of type, such as a CPL, Picture, or Sound file
Example 4.3 . Packing List 🔗
4.2.1. Packing List File 🔗
Objective
  • Verify that the Packing List is an XML document and that it validates against the schema defined in [SMPTE-429-8] .
  • Confirm that if the language attribute of the <AnnotationText> element is not present, or present with a value of "en", that the Annotation text is in human-readable English.
  • Verify that the Packing List contains urn:uuid values as specified in [RFC-4122] .
  • Verify that the listed file sizes match those for each of the referenced assets.
Procedures
In the following procedures, the callout numbers refer to Example 4.3 .
  1. Using the schema-check software utility, validate the XML file structure against the schema in [SMPTE-429-8] . Failure to correctly validate is cause to fail this test. For more information on schema validation see Section 1.4: Conventions and Practices . 
      $ schema_check.py <input-file> smpte-429-8.xsd 
  schema validation successful 
$
  2. Open the Packing List file in a Text Editor and verify that if the "language" attribute of the <AnnotationText> 4 element is not present, or present with a value of "en", that the contents of the <AnnotationText> 4 element is human readable English. Failure to meet this requirement is cause to fail this test. 
      $ vi <input-file> 
  ... 
  <AnnotationText>Perfect Movie Reel #1 Picture</AnnotationText> 
  ... 
  <AnnotationText language="en">Perfect Movie Reel #1 Sound</AnnotationText> 
  ... 
  :q 
$
  3. Supply the filename of the Packing List file as an argument to the uuid_check.py software utility. Examine the output for error messages that identify expected UUID values that do not conform to the format specified in [RFC-4122] . One or more occurrences is cause to fail this test. 
      $ uuid_check.py <input-file> 
  all UUIDs conform to RFC-4122 
$
  4. To verify that the real file sizes of the referenced assets are equal to the values of the related XML elements, the path to those assets must be known. The following procedure may be used if the ASSETMAP.xml file is available, otherwise the tester will need to devise a method for locating the relevant assets. For each of the <Asset> 9 elements contained in the Packing List, compare the contents of the child <Id> 10 element with the contents of the ASSETMAP.xml file to discover the path to the asset. List the file size of the referenced asset and verify that it is identical to the value of the child <Size> 12 element inside the <Asset> 9 element. One or more failures to verify the file sizes is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
4.2.2. Packing List Signature Validation 🔗
Objective
Verify that the Packing List is signed and that the signature validates.
Procedures
Using the checksig software utility, verify that there is a signature included in the Packing List and that it is valid. If the signature is missing or invalid, this is cause to fail this test. Note: Depending on the order of the certificates contained in the log report, the dsig_cert.py program may need to be used to re-order the certificates for the checksig program. Example: 
$ dsig_cert.py <pkl-file.pkl.xml> > tmp.xml 
$ checksig tmp.xml 
The supplied signature is valid 
$
Supporting Materials
Reference Documents
Test Equipment

4.3. Composition Playlist 🔗

The Composition Playlist (CPL) is an XML document (see Section 3.1 ) that contains the information necessary to reproduce a composition. It contains metadata about the composition such as the title and the rating, and references to the track files that contain the composition's essence. The format of the Composition Playlist file is specified by [SMPTE-429-7] . 

<?xml version="1.0" encoding="UTF-8" standalone="no"?>1
<CompositionPlaylist xmlns="http://www.smpte-ra.org/schemas/429-7/2006/CPL">2
  <Id>urn:uuid:20670ba3-d4c7-4539-ac3e-71e874d4d7d1</Id>3
  <IssueDate>2007-07-25T00:35:03-00:00</IssueDate>4
  <Issuer>user@host</Issuer>5
  <Creator> Packaging Tools v1.0 </Creator>6
  <ContentTitleText>Perfect Movie</ContentTitleText>7
  <ContentKind>feature</ContentKind>8
  <ContentVersion>0
    <Id>urn:uuid:e5a1b4dc-faf3-461b-a5e2-9d33088b1b28</Id>10
    <LabelText>Perfect Movie - Domestic - US 5.1 </LabelText>11
  </ContentVersion>
  <RatingList />12
  <ReelList>13
    <Reel>14
      <Id>urn:uuid:f62cffe9-2da7-4d28-b73e-f21c816ab02f</Id>15
      <AssetList>16
        <MainPicture>17
          <Id>urn:uuid:93270dd0-8675-42fa-9ce8-34b61c963997</Id>18
          <EditRate>24 1</EditRate>19
          <IntrinsicDuration>480</IntrinsicDuration>20
          <EntryPoint>0</EntryPoint>21
          <Duration>480</Duration>22
          <FrameRate>24 1</FrameRate>23
          <ScreenAspectRatio>1998 1080</ScreenAspectRatio>24
        </MainPicture>25
        <MainSound>26
          <Id>urn:uuid:e33b7b37-da90-4429-88af-5c5b63506017</Id>
          <EditRate>24 1</EditRate>
          <IntrinsicDuration>2880</IntrinsicDuration>
          <EntryPoint>120</EntryPoint>
          <Duration>2760</Duration>
        </MainSound>
      </AssetList>
    </Reel>
  </ReelList>
  [Additional reel data and CPL Signature omitted for brevity]
</CompositionPlaylist>
  • 1 The XML version of the XML standard to which the document conforms, the character encoding of the document, and whether the document relies on external declarations or parameter entities.
  • 2 The Root Composition Playlist element. This element contains the XML namespace declaration for the Composition Playlist as specified in [SMPTE-429-7] .
  • 3 The Unique Universal ID (UUID) of the composition playlist.
  • 4 The date the CPL was issued
  • 5 The organization or entity that issued the CPL
  • 6 The person, software, or system that generated the CPL
  • 7 A descriptive string that describes the composition and is displayed to the user
  • 8 The kind of presentation the CPL represents, such as a feature, trailer, or advertisement
  • 0 The version of the content represented by the composition playlist. This element contains sub-elements that contain a descriptive label and UUID of the content
  • 10 The unique ID of the version of the content represented by the CPL (as opposed to the unique ID of the CPL
  • 11 A text description of the version of the content represented in the CPL
  • 12 The list of ratings applied to the content represented by the CPL. In compositions that contain rating information, the <RatingList> element contains at least one instance of the <Rating> element, which in turn contains two elements, <Agency>, that contains a URI that represents the agency that issued the rating, and <Label> , that contains the rating
  • 13 The list of reels that comprise the composition
  • 14 A reel of the composition
  • 15 The unique ID of the reel
  • 16 The list of assets that comprise the reel
  • 17 The element in the reel that contains the information required to produce images onscreen
  • 18 The unique ID of the MXF track file that contains the picture essence (the picture track file) to be reproduced onscreen
  • 19 The edit rate, or the number of editable units of content, per second, of the picture track file
  • 20 The total number of frames in the track file, inclusive of frames not intended for reproduction onscreen
  • 21 The first frame of the track file to be reproduced onscreen
  • 22 The number of frames of the track file to be reproduced onscreen. When a picture track file is present in a composition, its duration is effectively the duration of the reel
  • 23 The rate, in frames-per-second, at which the essence in the track file will be reproduced
  • 24 The aspect ratio of the essence in the picture track file. This is represented in the CPL as a ratio of two numbers separated by a space
  • 25 The closing tag of the reel's MainPicture element
  • 26 The element in the reel that contains the information required to reproduce sound essence through the primary speaker system. The parameters of a MainSound track file are the same as those of a picture track file
Example 4.4 . Composition Playlist 🔗
4.3.1. Composition Playlist File 🔗
Objective
Verify that the Composition Playlist is an XML document and that it validates against the schema defined in [SMPTE-429-7] .
Procedures
Using the schema-check software utility, validate the XML file structure against the schema in [SMPTE-429-7] . Failure to correctly validate is cause to fail this test. 
$ schema-check <input-file> smpte-429-7.xsd 
schema validation successful 
$
Supporting Materials
Reference Documents
Test Equipment
4.3.2. Composition Playlist Signature Validation 🔗
Objective
Verify that the Composition Playlist is signed and that the signature validates.
Procedures
Using the checksig software utility, verify that there is a signature included in the Composition Playlist List and that it is valid. If the signature is missing or invalid, this is cause to fail this test. Note: Depending on the order of the certificates contained in the log report, the dsig_cert.py program may need to be used to re-order the certificates for the checksig program. Example: 
$ dsig_cert.py <cpl-file.cpl.xml> > tmp.xml 
$ checksig tmp.xml 
The supplied signature is valid 
$
Supporting Materials
Reference Documents
Test Equipment
4.3.3. Composition Playlist Key Usage 🔗
Objective
An encrypted Asset is associated with a Decryption Key that is effective for a period of time equal to one Reel. Only one Decryption Key shall be associated with a specific encrypted Asset. Each unique Decryption Key shall be associated with only one encrypted Asset.
  • Verify that for each encrypted Asset present in the Composition Playlist, only one <KeyId> value is listed. If an Asset Id occurs more than once in the CPL, verify that the same <KeyId> is utilized throughout.
  • Verify that each <KeyId> is associated with only one Asset Id.
Procedures
  1. Use a Text Editor to view the Composition Playlist. For all encrypted Assets (those that have a <KeyId> value) make a list of all Asset Id values and the associated <KeyId> values.
  2. Examine the list to determine that each Asset Id has exactly one <KeyId> . If Asset Ids are repeated in the CPL, the same <KeyId> should be associated for that Asset every time. Any deviation is cause to fail this test.
  3. Examine the list to determine that each <KeyId> is associated with exactly one Asset Id ( i.e. a particular Decryption Key should only be associated with one, unique Asset). Any deviation is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment

4.4. Track Files 🔗

A Track File is a container for encoded essence. In the d-cinema system, each Track File contains a single track of a single type of essence. For example, a Track File may contain images or sound or timed text, but never more than one type of essence 2 .

D-cinema Track Files are based on the Material eXchange Format (MXF). MXF is a file metaformat, i.e. , a file format for creating file formats. While the various d-cinema Track File formats represent different methods of encoding essence data, the arrangement of metadata within the files is syntactically similar. This section will provide an overview of MXF as used for d-cinema applications. Readers looking for more detailed technical information are referred to [SMPTE-377-1]

4.4.1. MXF Internals 🔗
4.4.1.1. Overview 🔗

Before diving head-first into examining MXF files, it is important to understand the structure of the files. This section will briefly describe the contents of some example MXF files by displaying the files' header metadata using the klvwalk software utility from the free ASDCPLib software package.

Briefly, an MXF file [SMPTE-377-1] contains a sequence of Key-Length-Value (KLV) packets. Some packets carry essence and some carry metadata. MXF files are divided into partitions . Each partition is comprised of a set of KLV packets. The first KLV packet in each partition is a Partition Pack.

The number of partitions in a digital cinema sound or picture Track File is usually three (Timed Text Track Files may have more than three partitions). The first partition in an MXF file contains the metadata which describe the coding parameters of the essence and the MXF file itself. The second partition contains the essence data as a sequence of KLV-wrapped frames. The final partition contains the index table

To display the metadata in the header partition of an MXF file testfile.mxf , use klvwalk like so 

$ klvwalk -r testfile.mxf
...

The following sections illustrate the expected output

4.4.1.2. MXF Header Partition 🔗

As shown in Example 4.5 , the first structure to be output is the Partition Pack of the Header Partition. This structure documents the MXF version that the file conforms to and provides a description of the general architecture to be found inside 

06.0e.2b.34.02.05.01.01.0d.01.02.01.01.02.04.00 len: 120 (ClosedCompleteHeader)1
  MajorVersion = 1 
  MinorVersion = 2 
  KAGSize = 1 
  ThisPartition = 0 
  PreviousPartition = 0 
  FooterPartition = 218362864 
  HeaderByteCount = 16244 
  IndexByteCount = 0 
  IndexSID = 0 
  BodyOffset = 0 
  BodySID = 1 
  OperationalPattern = 060e2b34.0401.0101.0d010201.100000002
Essence Containers:3
  060e2b34.0401.0103.0d010301.027f0100 
060e2b34.0401.0107.0d010301.020b0100
  • 1 This is an MXF Partition Pack structure. The Universal Label (UL) value indicates that the file is "Closed and Complete".
  • 2 The Operational Pattern UL indicates that the file conforms to OP Atom [SMPTE-390]
  • 3 Essence Container labels indicate the type of essence and the wrapping format. This example shows two container labels: the JPEG 2000 container [SMPTE-422] and the Generic Container [SMPTE-379-1] (the file contains encrypted JPEG 2000 essence)
Example 4.5 . MXF Partition Header 🔗

The following table gives the list of valid Essence Container ULs for d-cinema Track File

Table 4.1 . Essence Container UL Values for D-Cinema 🔗
UL Value Container Type
060e2b34.0401.0101.0d010301.02060100 Linear PCM Audio [SMPTE-429-3] , [SMPTE-382]
060e2b34.0401.0107.0d010301.020c0100 JPEG 2000 Images [SMPTE-429-4]
060e2b34.0401.010a.0d010301.02130101 Timed Text [SMPTE-429-5]
060e2b34.0204.0101.0d010301.027e0100 Encrypted Essence [SMPTE-429-6]
4.4.1.3. File Package 🔗

An MXF file may contain zero or more continuous segments of essence data. Each segment is described by a Source Package structure. Per [SMPTE-429-3] , MXF files for digital cinema must contain exactly one top-level Source Package (thus one segment of essence), referred to in MXF jargon as a File Package. Example 4.6 shows a Source Package structure that points to JPEG 2000 essence data. 

06.0e.2b.34.02.53.01.01.0d.01.01.01.01.01.37.00 len: 294 (SourcePackage)1
            InstanceUID = 42b5a376-c740-42e2-99f1-4ec782c4837e
            PackageUID = [060a2b34.0101.0105.01010f20],13,00,00,00,
                                    [b4f492cd.b89b.0f65.490c35ec.5f6340b7]2
                  Name = File Package: SMPTE 429-4 frame wrapping of JPEG 2000 codestreams
        PackageCreationDate = 2007-03-21 07:42:04.000
        PackageModifiedDate = 2007-03-21 07:42:04.000
                  Tracks:3
  9227a330-7e64-4c90-b4ef-d057ed6ef159
  0de983e3-255b-4d26-bde7-f33c530c077d
  54e13d93-abcf-4869-b008-c59573b8d01d
Descriptor
=
c6a35640-d6d8-433c-82c9-23df2eae9311

4
  • 1 This is a Source Package structure [SMPTE-377-1]
  • 2 A Unique Material Identifier (UMID) value which identifies the essence in the file. It has a UUID component which is the value that external entities ( e.g. Packing Lists and Composition Playlists) use to refer to the essence in the file. See [SMPTE-429-3] for details about how d-cinema UMIDs are formed
  • 3 The list of tracks that appear in the file. There is only one essence track, but it is accompanied by a virtual timecode track and, optionally, a descriptive metadata track that gives cryptographic information (see Section 4.4.1.4 below).
  • 4 This value gives the internal ID of a data set that describes the essence encoding. This set is called an Essence Descriptor. Two examples of essence descriptors are given below in Section 4.4.1.5 and Section 4.4.1.6
Example 4.6 . Source Package structure 🔗
4.4.1.4. Encrypted Essence 🔗

If the MXF file contains encrypted essence, the header metadata will contain one Cryptographic Framework set with a link to a single Cryptographic Context set (defined in [SMPTE-429-6] ). These structures are shown in Example 4.7 

06.0e.2b.34.02.53.01.01.0d.01.04.01.02.01.00.00 len: 40 (CryptographicFramework)1
            InstanceUID = b98ca683-2e49-4e6a-88ff-af33910ba334
              ContextSR = 8dcd2f7b-fd0b-4602-bae7-806c82dcfd94
06.0e.2b.34.02.53.01.01.0d.01.04.01.02.02.00.00 len: 120 (CryptographicContext)2
            InstanceUID = 8dcd2f7b-fd0b-4602-bae7-806c82dcfd94
              ContextID = 3472d593-e9ff-4b2e-84ca-5303b5ce53f7
  SourceEssenceContainer = 060e2b34.0401.0107.0d010301.020c01003
          CipherAlgorithm = 060e2b34.0401.0107.02090201.010000004
              MICAlgorithm = 060e2b34.0401.0107.02090202.010000005
CryptographicKeyID
=
c030f37a-bf84-496b-bdc2-81744205a944

6
  • 1 This is a Cryptographic Framework structure [SMPTE-429-6]
  • 2 This is a Cryptographic Context structure [SMPTE-429-6]
  • 3 A UL that identifies the type of essence inside the encrypted container. It should be a JPEG 2000 or PCM audio descriptor.
  • 4 A UL that identifies the type of encryption used. This value should always be 060e2b34.0401.0107.02090201.01000000
  • 5 A UL that identifies the algorithm used to calculate the Message Integrity Check value in each Encrypted KLV (EKLV) packet. When present, this value should always be 060e2b34.0401.0107.02090202.01000000
  • 6 A UUID value that identifies the 16-byte symmetric key (stored externally) that is required to decrypt the essence data. The key is usually delivered to a system via a Key Delivery Message (see Chapter 3)
Example 4.7 . Cryptographic Framework and Cryptographic Context 🔗
4.4.1.5. Essence Descriptor for JPEG 2000 🔗

If the MXF file contains image essence for DCI-compliant digital cinema, the header metadata will contain an RGBA Essence Descriptor (defined in [SMPTE-377-1] , with a strong link to a JPEG 2000 Picture SubDescriptor (defined in [SMPTE-422] . These structures are shown in Example 4.8 

06.0e.2b.34.02.53.01.01.0d.01.01.01.01.01.29.00 len: 169 (RGBAEssenceDescriptor)1
              InstanceUID = 18a47da5-53d1-4785-a91e-41155753a02f
                  Locators:
            SubDescriptors:
  05f80258-beb2-4769-b99a-af4d6c3895da
            LinkedTrackID = 2
               SampleRate = 24/12
        ContainerDuration = 7203
         EssenceContainer = 060e2b34.0401.0107.0d010301.020c0100
                    Codec = 00000000.0000.0000.00000000.00000000
              FrameLayout = 0
              StoredWidth = 20484
             StoredHeight = 10805
              AspectRatio = 2048/1080
     PictureEssenceCoding = 060e2b34.0401.0109.04010202.030101036
          ComponentMaxRef = 4095
          ComponentMinRef = 0
          06.0e.2b.34.02.53.01.01.0d.01.01.01.01.01.5a.00 len: 174 (JPEG2000PictureSubDescriptor)7
              InstanceUID = 05f80258-beb2-4769-b99a-af4d6c3895da
                    Rsize = 3
                    Xsize = 2048
                    Ysize = 1080
                   XOsize = 0
                   YOsize = 0
                   XTsize = 2048
                   YTsize = 1080
                  XTOsize = 0
                  YTOsize = 0
                    Csize = 3
   PictureComponentSizing = 00000003000000030b01010b01010b0101
       CodingStyleDefault = 01040001010503030000778888888888
QuantizationDefault
=
227f187f007f007ebc76ea76ea76bc6f4c6f4c6f645803580358455fd25fd25f61
  • 1 This is an MXF RGBA Essence Descriptor structure
  • 2 The frame rate of the underlying essence. The essence may be sampled on a finer scale, but this value is the smallest temporal increment than can be accessed in the file
  • 3 The number of frames in the file. Divide this value by the SampleRate to get the duration as a time value in seconds
  • 4 The width of the encoded image as a count of pixels.
  • 5 The height of the encoded image as a count of pixels
  • 6 This UL value indicates the type of compression and the color space of the encoded essence
  • 7 This is an MXF JPEG 2000 Picture SubDescriptor structure. It provides additional metadata associated with the JPEG 2000 encoding
Example 4.8 . Essence Descriptor for JPEG 2000 🔗
4.4.1.6. Essence Descriptor for PCM Audio 🔗

If the MXF file contains audio essence for DCI-compliant digital cinema, the header metadata will contain a Wave Audio Descriptor (defined in [SMPTE-382] ). This structure is shown in Example 4.9 . 

06.0e.2b.34.02.53.01.01.0d.01.01.01.01.01.48.00 len: 134 (WaveAudioDescriptor)1
                InstanceUID = 0b7eac6c-85e2-47e4-b0bf-b3e60f6e6cd7
                    Locators:
              SubDescriptors:
              LinkedTrackID = 2
                 SampleRate = 24/12
          ContainerDuration = 5283
           EssenceContainer = 060e2b34.0401.0101.0d010301.02060100
          AudioSamplingRate = 48000/14
                     Locked = 0
              AudioRefLevel = 0
               ChannelCount = 65
           QuantizationBits = 246
                   DialNorm = 0
                 BlockAlign = 187
             SequenceOffset = 0
AvgBps
=
144000
  • 1 This is a Wave Audio Descriptor structure [SMPTE-382]
  • 2 The frame rate of the underlying essence. The essence may be sampled on a finer scale, but this value is the smallest temporal increment than can be accessed in the file.
  • 3 The number of frames in the file. Divide this value by the SampleRate to get the duration as a time value in seconds.
  • 4 The base sample rate of the essence.
  • 5 The number of channels in the file. Each frame of essence will have the same number of channels, multiplexed in the same order
  • 6 The number of bits used to encode a sample of a single channel.
  • 7 The size, in bytes, of a set of samples for all channels in a single sample period. This value should be equal to (QuantizationBits / 8) * ChannelCount .
Example 4.9 . Essence Descriptor for PCM Audio 🔗
4.4.1.7. Random Index Pack (R.I.P.) 🔗

All d-cinema Track Files end with a Random Index Pack (RIP). The RIP provides a lookup table that gives the location of all partitions in the file for easy random access. The number of partitions shown by the RIP should be three if the MXF file is a sound or picture Track File, and may be more than three for a Timed Text Track File. 

06.0e.2b.34.02.05.01.01.0d.01.02.01.01.11.01.00 len: 40 (RandomIndexMetadata)11
  0       : 0
  1       : 16384
0
:
110688380
  • 1 The Random Index Pack (RIP) maps the location of each partition in an MXF file. This example shows three partitions
Example 4.10 . MXF Random Index Pack (RIP) 🔗
4.4.2. Image and Audio Packaging Standard 🔗
Objective
Procedures
  1. Using the klvwalk software utility, produce a listing of the MXF KLV Header Metadata Structure. Error free completion of the command confirms the validity of the MXF structure. Any other result is cause to fail the test.
  2. Examine the listing for the MXF Partition Pack structure with a ClosedCompleteHeader Universal Label (UL) value:
    060e2b34.0205.0101.0d010201.01020400
    as shown in Example 4.5 item 1 . Absence of this value is cause to fail this test.
  3. Examine the listing for the OperationalPattern value:
    060e2b34.0401.0102.0d010201.10000000 ,
    as shown in Example 4.5 item 2 . Absence of this value is cause to fail this test.
  4. Examine the listing for the Essence Container values as shown in Example 4.5 item 3 . There are three valid possibilities for the data in this field:
    1. If two values are present, and they are:
      060e2b34.0401.0103.0d010301.027f0100 and
      060e2b34.0401.0107.0d010301.020c0100 ,
      then the file is an Image file. For more information see Section 4.4.1.5: Essence Descriptor for JPEG 2000 .
    2. If two values are present, and they are:
      060e2b34.0401.0103.0d010301.027f0100 and
      060e2b34.0401.0101.0d010301.02060100 ,
      then the file is an Sound file. For more information see Section 4.4.1.6: Essence Descriptor for PCM Audio .
    3. If two values are present, and they are:
      060e2b34.0401.0103.0d010301.027f0100 and
      060e2b34.0401.0107.0d010301.020b0100 ,
      the Essence is ciphertext and an additional procedure, listed below, must be carried out.
    Failure to meet exactly one of the valid possibilities is cause to fail this test.
  5. Examine the listing and locate the EssenceContainerData set, UL value:
    060e2b34.0253.0101.0d010101.01012300 .
    This should contain exactly one LinkedPackageUID value. Verify that there is only one SourcePackage set, UL value:
    060e2b34.0253.0101.0d010101.01013700
    and that the PackageUID value exactly matches the LinkedPackageUID value of the EssenceContainerData set. Failure of any of the above conditions is cause to fail this test.
  6. Only for the case of Encrypted Essence, the SourcePackage set, UL value:
    060e2b34.0253.0101.0d010101.01013700 ,
    should contain a third Track UID that matches the InstanceUID value of a single StaticTrack set, UL value:
    060e2b34.0253.0101.0d010101.01013a00 .
    The StaticTrack set should have a Sequence value that matches the InstanceUID of a Sequence set, UL value:
    060e2b34.0253.0101.0d010101.01010f00 .
    The found Sequence set should have a StructuralComponents value that matches the InstanceUID of a single DMSegement set, UL value:
    060e2b34.0253.0101.0d010101.01014100 .
    The DMSegment set should have a DMFramework value that matches a single CryptographicFramework set, UL value:
    060e2b34.0253.0101.0d010401.02010000 .
    The CryptographicFramework set should have a ContextSR value that matches the InstanceUID of a single CryptographicContext set, UL value:
    060e2b34.0253.0101.0d010401.02020000 .
    The CryptographicContext set has a SourceEssenceContainer value, which should contain either the UL value:
    060e2b34.0401.0107.0d010301.020c0100
    for an Image file, or:
    060e2b34.0401.0101.0d010301.02060100
    for a Sound file. For more information see Section 4.4.1.4: Encrypted Essence . Failure of any of the above conditions is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
4.4.3. Timed Text Track File Format 🔗
Objective
Procedures
  1. Using the klvwalk software utility, produce a listing of the MXF KLV Header Metadata structure. Error free completion of the command confirms the validity of the MXF structure. Any other result is cause to fail the test.
  2. Examine the listing for the MXF Partition Pack structure with a ClosedCompleteHeader Universal Label (UL) value:
    060e2b34.0205.0101.0d010201.01020400
    as shown in Example 4.5 item 1 . Absence of this value is cause to fail this test.
  3. Examine the listing for the OperationalPattern value:
    060e2b34.0401.0102.0d010201.10000000 ,
    as shown in Example 4.5 item 2 . Absence of this value is cause to fail this test.
  4. Examine the listing for the Essence Container values as shown in Example 4.5 item 3 . There are two valid possibilities for the data in this field:
    1. If two values are present, and they are:
      060e2b34.0401.0103.0d010301.027f0100 and
      060e2b34.0401.010a.0d010301.02130101 ,
      then the file is a Timed Text file. For more information see Section 4.4.1.5: Essence Descriptor for JPEG 2000 .
    2. If two values are present, and they are:
      060e2b34.0401.0103.0d010301.027f0100 and
      060e2b34.0401.0107.0d010301.020b0100 ,
      the Essence is ciphertext and an additional procedure, listed below, must be carried out.
    Failure to meet exactly one of the valid possibilities is cause to fail this test.
  5. Examine the listing and locate the EssenceContainerData set, UL value:
    060e2b34.0253.0101.0d010101.01012300 .
    This should contain exactly one LinkedPackageUID value. Verify that there is only one SourcePackage set, UL value:
    060e2b34.0253.0101.0d010101.01013700
    and that the PackageUID value exactly matches the LinkedPackageUID value of the EssenceContainerData set. Failure of any of the above conditions is cause to fail this test.
  6. Only for the case of Encrypted Essence, execute sub-procedure #6 as given in Section 4.4.2 . In this case the SourceEssenceContainer value within the CryptographicContext set contain the UL value:
    060e2b34.0401.010a.0d010301.02130101
    to indicate a Timed Text file. Failure of any of the above conditions is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
4.4.4. Track File Length 🔗
Objective
For each Track File, verify that the minimum duration is a number of frames which is greater or equal to one second of content playback at the specified edit rate. This means that each image Track File needs to contain at least 24 (at 24 fps frame rate) or 48 (at 48 fps frame rate) frames, and that each audio Track File needs to contain at least 48,000 (at 48kHz sampling rate) or 96,000 (at 96 kHz sampling rate) audio samples.
Procedures
This may be accomplished by using the asdcp-test software utility to provide information about the file and confirming that the reported ContainerDuration value is equal or greater than the SampleRate value. Failure to meet the above conditions is cause to fail this test.

E.g. 

$ asdcp-test -i -v <input-file> 
... 
SampleRate: 24/1 
... 
ContainerDuration: 528 
... 
$
Supporting Materials
Reference Documents
Test Equipment
4.4.5. Image Track File Frame Boundary 🔗
Objective
  • Image Track Files must begin and end with complete frames that allow for splicing. Verify that both the first and the last JPEG2000 image in a sequence are completely contained within the Image Track File, i.e. , no other Track Files are needed for complete decoding or displaying of the first and the last frame.
  • Each complete Frame of Image Data must be wrapped within the KLV structure according to [SMPTE-336] and [SMPTE-422] .
Procedures
  1. Determine the number of frames contained in the Track File. This will be used in the next step to extract the last frame in the file. This can be achieved by using the asdcp-test software utility, and subtracting one from the ContainerDuration value, as shown below. 
    $ asdcp-test -i -v PerfectMovie-j2c-pt.mxf 
File essence type is JPEG 2000 pictures. 
ProductUUID: 43059a1d-0432-4101-b83f-736815acf31d 
ProductVersion: Unreleased 1.1.13 
CompanyName: DCI 
ProductName: asdcplib 
EncryptedEssence: No 
AssetUUID: 0e676fb1-951b-45c4-8334-ed2c59199815 
Label Set Type: SMPTE 
AspectRatio: 2048/1080 
EditRate: 24/1 
StoredWidth: 2048 
StoredHeight: 1080 
Rsize: 3 
Xsize: 2048 
Ysize: 1080 
XOsize: 0 
YOsize: 0 
XTsize: 2048 
YTsize: 1080 
XTOsize: 0 
YTOsize: 0 
ContainerDuration: 240 
Color Components: 
11.1.1 
11.1.1 
11.1.1 
Default Coding (16): 01040001010503030000778888888888 
Quantization
Default
(33):
227f187f007f007ebc76ea76ea76bc6f4c6f4c6f645803580358455fd25fd25f61
  2. Using the asdcp-test software utility, extract the first and the last frames of content from the Track File. 
    $ asdcp-test -x first -d 1 -f 0 PerfectMovie-j2c-pt.mxf 
$ asdcp-test -x last -d 1 -f 239 PerfectMovie-j2c-pt.mxf 
$ ls 
first000000.j2c 
last000239.j2c 
PerfectMovie-j2c-pt.mxf
  3. Verify that the first and the last frames of content decode completely, and without errors. Failure to correctly decode either frame is cause to fail this test. This can be achieved by using JPEG 2000 decoding software. An example is shown below. (Note that the output of the j2c-scan program is long and has been truncated here for brevity. Please see Section C.5 for a detailed example.) 
    $ j2c-scan frame000000.j2c 
digital cinema profile: none 
rsiz capabilities: standard 
pixel offset from top-left corner: (0, 0) 
tile width/height in pixels: (2048, 1080) 
image width/height in tiles: (1, 1) 
tile #1 
coding style: 1 
progression order: Component-Position-Resolution-Layer 
POC marker flag: 0 
number of quality layers: 1 
rate for layer #1: 0.0 
multi-component transform flag: 1 
...
Supporting Materials
Reference Documents
Test Equipment
4.4.6. Audio Track File Frame Boundary 🔗
Objective
The Audio Track File is required to begin and end with complete frames that are associated with its Image Track File to allow for a clean transition between reels. The audio data within the Track File shall be wrapped using KLV on an image frame boundary.
Procedures
Verify that exactly the expected number of Audio bytes are embedded within each KLV encoded triplet for each frame of the Audio Track File. This can be achieved by using the software command klvwalk to display the length of every WAVEssence set (UL value 060e2b34.0102.0101.0d010301.16010101 ) and checking that each frame contains the appropriate number of bytes. The expected number of Audio Bytes per frame can be calculated by using the formula len=BPS*Ch*SPF, where BPS is the number of Bytes Per Sample (BPS=3), Ch is the number of Audio Channels in the DCP, and SPF is the number of Samples Per Frame value taken from Table 4.2 .

If any frame has an actual len that differs from the expected value, calculated from the formula, this is cause to fail this test.

The example below shows eight frames of a composition containing six channels of 48kHz samples at 24fps, completely wrapped in KLV triplets (3 * 6 * 2000 = 36000). 

$klvwalk PerfectMovie-pcm-pt.mxf 
... 
060e2b34.0102.0101.0d010301.16010101 len: 36000 (WAVEssence) 
060e2b34.0102.0101.0d010301.16010101 len: 36000 (WAVEssence) 
060e2b34.0102.0101.0d010301.16010101 len: 36000 (WAVEssence) 
060e2b34.0102.0101.0d010301.16010101 len: 36000 (WAVEssence) 
060e2b34.0102.0101.0d010301.16010101 len: 36000 (WAVEssence) 
060e2b34.0102.0101.0d010301.16010101 len: 36000 (WAVEssence) 
060e2b34.0102.0101.0d010301.16010101 len: 36000 (WAVEssence) 
060e2b34.0102.0101.0d010301.16010101 len: 36000 (WAVEssence) 
...
The possible values for the Samples/Frame are shown in table below.
Table 4.2 . Audio Samples Per Frame 🔗
FPS Sample Rate Samples/Frames
24 28 kHz 2000
24 96 kHz 4000
48 48 kHz 1000
48 96 kHz 2000
Supporting Materials
Reference Documents
Test Equipment

4.5. Essence 🔗

4.5.1. Image Structure Container and Image Container Format 🔗
Objective
  • Verify that the images contained in the Track Files conform to an Image Structure Container that consists of either 4K (4096x2160) (Operational Level 1) or 2K (2048x1080) (Operational Level 2 and 3). It is expected that the image structure shall use one of the two containers such that either the horizontal or vertical resolution is filled.
  • Verify that both the horizontal and vertical dimensions of the image structure container are divisible by four for Level 1, or two for Level 2 and 3 image structures. This ensures that the image can be centered correctly.
  • Verify that the bit depth for each code value for a color component shall be 12 bits. This yields 36 bits per pixel.
Procedures
  • Using the software command klvwalk , locate the RGBAEssenceDescriptor set and record the StoredWidth, StoredHeight, and AspectRatio values within. The failure to meet any of the following conditions is cause to fail this test:
    1. Verify that the first number (numerator) of the AspectRatio field is the same as the StoredWidth value.
    2. Verify that the second number (denominator) of the AspectRatio field is the same as the StoredHeight value.
    3. Verify that exactly one of the StoredWidth or StoredHeight values are equal to the Maximum Horizontal Pixels or Maximum Vertical Pixels values from Table 4.3 .
    4. Verify that both the StoredWidth and StoredHeight values are equal to, or less than, the Maximum Horizontal Pixels or Maximum Vertical Pixels values, respectively, from Table 4.3 .
    5. Verify that both the StoredWidth and StoredHeight values are exactly divisible by two for a 2K file, and four for a 4K file.
    An example of the RGBAEssenceDescriptor set is shown below: 
    $ klvwalk -r PerfectMovie-j2c-pt.mxf 
... 
060e2b34.0253.0101.0d010101.01012900 len: 169 (RGBAEssenceDescriptor)
InstanceUID = 82141918-ce1b-47a5-ac13-c47cfb2e51a7 
GenerationUID = 00000000-0000-0000-0000-000000000000 
Locators: 
SubDescriptors: 
92e96e5e-6bef-4985-8117-7dfa541f96fa 
LinkedTrackID = 2 
SampleRate = 24/1 
ContainerDuration = 240 
EssenceContainer = 060e2b34.0401.0107.0d010301.020c0100
Codec = 060e2b34.0401.0109.04010202.03010103 
FrameLayout = 0 
StoredWidth = 2048
StoredHeight = 1080
AspectRatio = 2048/1080 
ComponentMaxRef = 4095 
ComponentMinRef = 0 
...
    The valid Image Structure Container values are shown in table below.
    Table 4.3 . Image Structure Operational Levels 🔗
    Operational level Maximum Horizontal Pixels MaximumVertical Pixels Frames per Second
    1 4096 2160 24
    2 2048 1080 48
    3 2048 1080 24
  • Using the software commands asdcp-test and j2c-scan , extract an image frame from the file and verify that the bit depth for each component is 12 bits. A component bit-depth value other than 12 shall be cause to fail this test.
    An example of this operation is shown below: 
    $ asdcp-test -d 1 -x frame j2c/PerfectMovie-j2c-pt.mxf 
$ j2c-scan frame_000001.j2c 
coding parameters 
digital cinema profile: none 
rsiz capabilities: standard 
pixel offset from top-left corner: (0, 0) 
tile width/height in pixels: (2048, 1080) 
image width/height in tiles: (1, 1) 
...
Supporting Materials
Reference Documents
Test Equipment
4.5.2. Image Compression Standard & Encoding Parameters 🔗
Objective
Verify that the image encoding parameters in a Picture Track File conform to [SMPTE-429-4] .
Procedures
  1. Verify that the UL value in the PictureEssenceCodingfield of the MXF RGBAEssenceDescriptor (see 6 in Example 4.8 ) is one of:
    060e2b34.0401.0109.04010202.03010103 (for 2K images) or
    060e2b34.0401.0109.04010202.03010104 (for 4K images).
    If the UL value does not match one of those listed above, or is the wrong value for the contained essence, this is cause to fail the test.
  2. Using a software command such as asdcp-test , extract all the frames in the Track File to a directory. An example is shown below. 
    $ asdcp-test -x frame j2c/PerfectMovie-j2c-pt.mxf 
$ ls j2c 
frame000000.j2c frame000057.j2c frame000124.j2c frame000191.j2c 
frame000001.j2c frame000058.j2c frame000125.j2c frame000192.j2c 
frame000002.j2c frame000059.j2c frame000126.j2c frame000192.j2c 
frame000003.j2c frame000060.j2c frame000127.j2c frame000194.j2c 
...
  3. Verify that every frame is correctly JPEG 2000 encoded as described in [ISO-15444-1] . Verify that the proper JPEG 2000 encoding parameters as specified in [ISO-15444-1-AMD-1] were used. The Codestream Specifications for 2K and 4K distributions are listed in [DCI-DCSS] , section 4.4. This can be achieved by using JPEG 2000 decoding software. An example is shown below. (Note that the output of the j2c-scan program is long and has been truncated here for brevity. Please see Section C.5 for a detailed example.) If any frame fails to correctly decode or does not conform to the appropriate Codestream Specifications, this is cause to fail the test. 
    $ j2c-scan frame000000.j2c 
digital cinema profile: none 
rsiz capabilities: standard 
pixel offset from top-left corner: (0, 0) 
tile width/height in pixels: (2048, 1080) 
image width/height in tiles: (1, 1) 
tile #1 
coding style: 1 
progression order: Component-Position-Resolution-Layer 
POC marker flag: 0 
number of quality layers: 1 
rate for layer #1: 0.0 
multi-component transform flag: 1 
...
Supporting Materials
Reference Documents
Test Equipment
4.5.3. Audio Characteristics 🔗
Objective
Sound Track Files shall conform to the specifications given in [SMPTE-428-2] and [SMPTE-428-3] , and be constrained as specified in [SMPTE-429-2] . A Sound Track File shall contain linear PCM audio sampled at 48000 or 96000 samples per second, 24 bits per sample. The file shall contain no more than 16 channels of audio.
Procedures
Using the software command klvwalk , locate the WaveAudioDescriptor set which starts with the Universal Label (UL) of 060e2b34.0253.0101.0d010101.01014800 . An example is shown below. 
$ klvwalk -r PerfectMovie-pcm-pt.mxf
...
060e2b34.0253.0101.0d010101.01014800 len: 134 (WaveAudioDescriptor)
InstanceUID = e1c4c755-2c3e-4274-a3bf-581aadd63a4b
GenerationUID = 00000000-0000-0000-0000-000000000000
Locators:
SubDescriptors:
LinkedTrackID = 2
SampleRate = 24/1
ContainerDuration = 480
EssenceContainer = 060e2b34.0401.0101.0d010301.02060100
Codec = 00000000.0000.0000.00000000.00000000
AudioSamplingRate = 48000/1
Locked = 0
AudioRefLevel = 0
ChannelCount = 6
QuantizationBits = 24
DialNorm = 0
BlockAlign = 18
SequenceOffset = 0
AvgBps = 144000
...
Verify the following:
  1. The EssenceContainer field has a value of 060e2b34.0401.0101.0d010301.02060100 . Any other value is cause to fail this test.
  2. The ChannelAssignment field is not present, or, if present, has a value from the set of UL values defined in [SMPTE-429-2] , Appendix A , "Audio Channel Assignment Label". Any other value in the ChannelAssignment field is cause to fail this test.
  3. The AudioSamplingRate field has a value of either 48000/1 or 96000/1. Any deviation from these values is cause to fail this test.
  4. The ChannelCount field has a value of no fewer than six (6) and no greater than sixteen (16). Any deviation from these values is cause to fail this test.
  5. The QuantizationBits field has a value of 24. Any other value is cause to fail this test.
  6. The BlockAlign field is exactly the value of ChannelCount * 3 . Any other value is cause to fail this test.
  7. The AvgBps field is exactly the value of the AudioSamplingRate * ChannelCount * 3 . Any other value is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
4.5.4. Timed Text Resource Encoding 🔗
Objective
Procedures
  1. Extract the Timed Text Resource and any Ancillary Resources from the Track File.
  2. Verify that the Timed Text Resource is an XML document that can be validated using the schema from [SMPTE-428-7] . If the XML validation produces errors, this is cause to fail this test. 
    $ schema-check testfile.xml S428-7-2007.xsd 
$
  3. Verify that any font resources are valid according to [ISO-144496] . If the font validation produces errors, this is cause to fail this test. 
    $ ftlint 1 font_file.otf 
font_file.otf: OK. 
$
  4. Verify that any subpicture resources are valid according to [ISO-15948] . The subpicture must be of PNG format, decode without errors, and the size (geometry) must be smaller than, or equal to, that of the main picture. If the png file causes identify to report errors, or if the geometry of the PNG is greater than that of the main picture, this is cause to fail this test. 
    $ identify -verbose subpicture_0001.png 
Image: subpicture_0001.png 
Format: PNG (Portable Network Graphics) 
Geometry: 120x420 
Class: DirectClass 
Colorspace: RGB 
Type: GrayscaleMatte 
Depth: 8 bits 
...
Supporting Materials
Reference Documents
Test Equipment

4.6. Digital Cinema Package 🔗

4.6.1. DCP Integrity 🔗
Objective
  • Verify that the Volume Asset Map is present, correctly formatted, and correctly located in the filesystem.
  • Verify that for all the Packing Lists found in the Asset Map file, all of the assets referenced in each Packing List are present and are valid ( i.e. , each Referenced Asset's file size and Message Digest are correct).
    File Integrity will be guaranteed by applying the SHA-1 hashing algorithm [RFC-3174] to each asset included in the DCP. The resulting message digest is Base64 encoded and included in the Packing List file.
  • Verify that for all the Composition Playlists found in each Packing List, the Referenced Assets exist in the Packing List file.
Procedures
  1. Validate the Format of the Volume Asset Map file by executing the test procedure Section 4.1.1: Asset Map File .
  2. Validate the Format of the Volume Index file by executing the test procedure Section 4.1.2: Volume Index File .
  3. Validate the Format of each Packing List file by executing the test procedure Section 4.2.1: Packing List File .
  4. Validate the Signature of each Packing List file by executing the test procedure Section 4.2.2: Packing List Signature Validation .
  5. For each Packing List file ( e.g. PerfectMovie.pkl.xml) in the Asset Map:
    1. Open the Packing List and for each Asset Id contained within:
      1. Locate the Referenced Asset in the filesystem and compare its file size with the value listed in the <Size> element of the <Asset> element. Inconsistency is cause to fail this test.
      2. Calculate the Message Digest of the Referenced Asset and encode the result in Base64. Compare the result with the value listed in the <Hash> element of the <Asset>element. Inconsistency is cause to fail this test. The following is an example using the asdcp-test software utility: 
            $ asdcp-test -t PerfectMovie-j2c-pt.mxf 
t0MirEHOVFF4Mi1IP0iYVjrvb14=
PerfectMovie-j2c-pt.mxf
  6. Validate the Format of each Composition Playlist file by executing the test procedure Section 4.3.1: Composition Playlist File .
  7. Validate the Signature of each Composition Playlist file by executing the test procedure Section 4.3.2: Composition Playlist Signature Validation .
  8. For each Composition Playlist ( e.g. PerfectMovie.cpl.xml) in the Asset Map:
    1. Open the Composition Playlist and for each Asset Id contained within:
      1. Locate the Asset Id in the Packing List file. Any missing Asset Ids are cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment

Chapter 5. Common Security Features 🔗

This chapter contains test procedures of security features that apply to more than one type of device. Procedures are given for Type 1 and Type 2 Secure Processing Block (SPB) physical security requirements, Intra-theater communications, and security log reporting.

5.1. SPB Security Features 🔗

The test procedures in this section apply to any device or component that is classified as a Type 1 or Type 2 SPB.

5.1.1. SPB Digital Certificate 🔗
Objective
This following applies only if the Test Subject is an SPB
  • Verify that the Test Subject carries the correct number of leaf certificates.
  • Verify that the leaf certificates conform to [SMPTE-430-2] and Section 9.5.1 of [DCI-DCSS] .
  • Verify that the roles contained in the Common Name field of the Test Subject certificate(s) accurately reflect the security functions of the Test Subject.
  • Verify that the exterior surface of the device containing the Test Subject is labeled with information traceable to the Common Name of the Test Subject.
Procedures

If the Test Subject is a Media Block:

  1. Obtain the Test Subject leaf certificates from the manufacturer, and using manufacturer-supplied documentation, compile the list of expected role identifiers corresponding to the security functions of the Test Subject -- see [SMPTE-430-2] , and Section 9.5.1 of [DCI-DCSS] for lists of roles.
  2. Verify that exactly three leaf certificates are presented.
  3. Verify that each leaf certificate has a distinct Subject DnQualifier value.
  4. Verify that each row of Table 5.1 is matched by exactly one of the leaf certificates.
  5. For each leaf certificate, verify that each role listed in the Subject Common Name field corresponds to a security function implemented by the Test Subject.
  6. For each leaf certificate, verify that the Subject Common Name field contains the serial number of the Test Subject. Additional identifying information may be present.
  7. For each leaf certificate, verify that information identifying the make and model of the Test Subject is carried in the Subject field. Additional identifying information may be present.
  8. For each leaf certificate, verify that either the make, model and serial number of the Test Subject, or information that is unambiguously traceable by the manufacturer to the Subject field of all certificates, is clearly placed on the exterior of the device containing the Test Subject.
  9. Failure to verify any of the conditions above is cause to fail this test.

Table 5.1 . Media Block Leaf Certificate Criteria 🔗
Roles listed in the Subject Common Name DigitalSignature flag KeyEncipherment flag
includes the SM and MIC roles, but does not include any of the LS and RES roles false true
includes the SM, MIC and RES roles, but does not include the LS role false true
includes LS role true false

For any other Test Subject:

  1. Obtain the Test Subject leaf certificates from the manufacturer, and using manufacturer-supplied documentation, compile the list of expected role identifiers corresponding to the security functions of the Test Subject -- see [SMPTE-430-2] , and Section 9.5.1 of [DCI-DCSS] for lists of roles.
  2. Verify that exactly one leaf certificate is presented.
  3. Verify that the Subject Common Name of the leaf certificate presented includes at least one the role combinations listed in Section 9.5.1.1 of [DCI-DCSS] and does not contain any of the role combination listed in Sections 9.5.1.2 and 9.5.1.3 of [DCI-DCSS] .
  4. Verify that each role listed in the Subject Common Name field of the leaf certificate corresponds to a security function implemented by the Test Subject.
  5. Verify that the Subject Common Name field of the leaf certificate collected contains the serial number of the Test Subject. Additional identifying information may be present.
  6. Verify that information identifying the make and model of the Test Subject is carried in the Subject field of the leaf certificate. Additional identifying information may be present.
  7. Verify that either the make, model and serial number of the Test Subject, or information that is unambiguously traceable by the manufacturer to the Subject field of the leaf certificate, is clearly placed on the exterior of the device containing the Test Subject.
  8. Failure to verify any of the conditions above is cause to fail this test.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
20.4. OMB Confidence Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
24.2. SDR Projector Test Sequence Pass/Fail —
24.4. SDR Projector Confidence Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
26.4. HDR Direct View Display Confidence Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
27.4. SDR Direct View Display Confidence Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
28.4. HDR Projector Confidence Sequence Pass/Fail —
5.1.2. Deleted Section 🔗

The section "SPB Type 2 Security Perimeter" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.1.3. Deleted Section 🔗

The section "SPB Type 2 Secure Silicon" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2. Intra-Theater Communication 🔗

5.2.1. Deleted Section 🔗

The section "TLS Session Initiation" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.2. Auditorium Security Messages 🔗
5.2.2.1. Deleted Section 🔗

The section "Auditorium Security Message Support" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.2.2. Deleted Section 🔗

The section "ASM Failure Behavior" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.2.3. Deleted Section 🔗

The section "ASM 'RRP Invalid'" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.2.4. Deleted Section 🔗

The section "ASM 'GetTime'" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.2.5. Deleted Section 🔗

The section "ASM 'GetEventList'" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.2.6. Deleted Section 🔗

The section "ASM 'GetEventID'" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.2.7. Deleted Section 🔗

The section "ASM 'LEKeyLoad'" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.2.8. Deleted Section 🔗

The section "ASM 'LEKeyQueryID'" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.2.9. Deleted Section 🔗

The section "ASM 'LEKeyQueryAll'" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.2.10. Deleted Section 🔗

The section "ASM 'LEKeyPurgeID'" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.2.11. Deleted Section 🔗

The section "ASM 'LEKeyPurgeAll'" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.2.12. Deleted Section 🔗

The section "ASM 'GetProjCert'" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.2.3. Deleted Section 🔗

The section "TLS Exception Logging" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.3. Event Logs 🔗

Secure Processing Block (SPB) modules are required to provide event log reports on demand. The log reports are XML documents (see Section 3.1 ) having a structure defined by [SMPTE-430-4] . This section will describe the report format and present procedures for testing general operational requirements for event logging.

The method of generating a log report will vary between implementations. Consult the manufacturer's documentation for log report generation instructions.

5.3.1. Log Report Format 🔗

Standard d-cinema log reports are encoded as XML documents per [SMPTE-430-4] . The reports consist of a preamble, which identifies the device that created the report, and a sequence of log records. In log reports which contain security events (Security Event Logs), some of the log records may contain XML Signature elements. The report format includes many unique security features; the reader should study [SMPTE-430-4] in detail to understand how log authentication works.

The following subsections detail the major features of a log report

5.3.1.1. Log Report 🔗

A collection of one or more log records is presented as an XML document having a single LogReport element as the top-level element. The log report begins with reportDate and reportingDevice elements. The contents of the elements identify the time the log was created and the device that created the log 

<?xml version="1.0" encoding="UTF-8"?>
<LogReport1
  xmlns="http://www.smpte-ra.org/schemas/430-4/2008/LogRecord/"2
  xmlns:dcml="http://www.smpte-ra.org/schemas/433/2008/dcmlTypes/">
  <reportDate>2007-05-04T09:30:47-08:00</reportDate>3
  <reportingDevice>4
    <dcml:DeviceIdentifier idtype="CertThumbprint">YmVsc3dpY2tAZW50ZXJ0ZWNoLmNvbQ==
    </dcml:DeviceIdentifier>
    <dcml:DeviceTypeID scope="http://www.smpte-ra.org/schemas/433/2008/dcmlTypes#DeviceTypeTokens">SM
    </dcml:DeviceTypeID>
    <dcml:AdditionalID>vnqteTcB2Gji\+1Hl23sxxgOqvwE=</dcml:AdditionalID>5
    <dcml:DeviceSerial>000000042</dcml:DeviceSerial>6
    <dcml:ManufacturerCertID>rlpve6MSncWouNIpFcTSIhk6w2A=</dcml:ManufacturerCertID>7
    <dcml:DeviceCertID>9czqa+0orIADHDIYxAkn/IcmZ3o=</dcml:DeviceCertID> 
    <dcml:ManufacturerName>Acme Digital Cinema Inc.</dcml:ManufacturerName>
    <dcml:DeviceName>Mojo Media Block</dcml:DeviceName>
    <dcml:ModelNumber>MB-3000</dcml:ModelNumber>
    <dcml:VersionInfo>
      <dcml:Name>Bootloader</dcml:Name>
      <dcml:Value>1.0.0.0</dcml:Value>
      <dcml:Name>Security Module</dcml:Name>
      <dcml:Value>3.4.2.1</dcml:Value>
    </dcml:VersionInfo>
</reportingDevice>
  • 1 The LogReport element is the root element of a log report document.
  • 2 The LogRecord and DCML namespaces are used
  • 3 This value gives the date on which this report document was generated
  • 4 This structure identifies the device that generated this report
  • 5 For log reports generated by an SM that implements dual certificates (see Section 9.5.1.2 at [DCI-DCSS] ), the AdditionalID element is present and contains a thumbprint of the SM Log Signer digital certificate
  • 6 The serial number of reporting device
  • 7 The certificate thumbprint (per [SMPTE-430-2] ) of the reporting device
Example 5.1 . Log Report Example 🔗
5.3.1.2. Log Record 🔗

Each event contained in the log report is encoded as a LogRecordElement element. This element type has three major sub-elements: LogRecordHeader , LogRecordBody , and LogRecordSignature . The first two are shown in the example below, the last is the subject of the next section.

The log record element defined in [SMPTE-430-4] is known by two names. The correct name to use depends on context. Testing a candidate document against the LogRecord schema will verify correct use. When a log record (defined as the complex type logRecordType in the LogRecord schema) appears as a sub-element of a LogReport element, the record element name is LogRecordElement . When a log record appears as the root element of an XML document, the record element name is LogRecord .

LogRecord elements are used directly (without a containing LogReport parent element) as the return value from an ASM GetEventID procedure (see Section 5.2.2.6 .) Because ASM procedures are executed exclusively via TLS with a trusted peer, the LogRecordSignature element is not required for that particular use. 
<LogRecordElement1
  xmlns="http://www.smpte-ra.org/schemas/430-4/2008/LogRecord/"
  xmlns:dcml="http://www.smpte-ra.org/schemas/433/2008/dcmlTypes/">
  <LogRecordHeader>
    <EventID>urn:uuid:8a221dfc-f5c6-426d-a2b8-9f6ff1cc6e31</EventID>2
    <TimeStamp>2005-12-17T10:45:00-05:00</TimeStamp>3
    <EventSequence>1000003</EventSequence>4
    <DeviceSourceID>
      <dcml:PrimaryID idtype="CertThumbprint">kkqiVpDUAggQDHyHz0x9cDcsseU=</dcml:PrimaryID>
    </DeviceSourceID>
    <EventClass>http://www.smpte-ra.org/430.5/2007/SecurityLog/</EventClass>5
    <EventType scope="http://www.smpte-ra.org/430.5/2007/SecurityLog/#EventTypes">Key</EventType>6
    <contentId>urn:uuid:733365c3-2d44-4f93-accd-43cb39b0cedf</contentId>7
    <previousHeaderHash>9czqa+0orIADHDIYxAkn/IcmZ3o=</previousHeaderHash>8
    <recordBodyHash>9czqa+0orIADHDIYxAkn/IcmZ3o=</recordBodyHash>9
  </LogRecordHeader>
  <LogRecordBody>
    <EventID>urn:uuid:8a221dfc-f5c6-426d-a2b8-9f6ff1cc6e31</EventID>
    <EventSubType scope="http://www.smpte-ra.org/430.5/2007/SecurityLog/#EventSubTypes-key">
      KDMKeysReceived
    </EventSubType>10
    <Parameters>11
      <dcml:Parameter>
        <dcml:Name>SignerID</dcml:Name>
        <dcml:Value xsi:type="ds:DigestValueType">rlpve6MSncWouNIpFcTSIhk6w2A=</dcml:Value>
      </dcml:Parameter>
    </Parameters>
    <Exceptions>12
      <dcml:Parameter>
        <dcml:Name>KDMFormatError</dcml:Name>
        <dcml:Value xsi:type="xs:string">XML validation failed on line 36</dcml:Value>
      </dcml:Parameter>
    </Exceptions>
    <ReferencedIDs>13
      <ReferencedID>
        <IDName>CompositionID</IDName>
        <IDValue>urn:uuid:64bb6972-13a0-1348-a5e3-ae45420ea57d</IDValue>
      </ReferencedID>
      <ReferencedID>
        <IDName>KeyDeliveryMessageID</IDName>
        <IDValue>urn:uuid:64bb6972-13a0-1348-a5e3-ae45420ea57d</IDValue>
      </ReferencedID>
    </ReferencedIDs>
  </LogRecordBody>
</LogRecordElement>
  • 1 The LogRecordElement element contains a single log record, corresponding to a single system event. If the log record is the root element of an XML document, the element name will be LogRecord .
  • 2 A UUID value that uniquely identifies this event. This ID must be the same wherever this event appears ( i.e. , if the event appears in more than one report, the ID will be the same.)
  • 3 The time and date at which the event occurred.
  • 4 The sequence number of this event in the report. This element should not be used in a stand-alone LogRecord element.
  • 5 The event Class ( e.g. , Security .)
  • 6 The event Type ( e.g. , Key .)
  • 7 Gives the UUID most closely associated with the content element that was being handled when the event occurred. This element should not be used in a stand-alone LogRecord element
  • 8 The SHA-1 message digest of the Header element in the record that preceded this one in the report. This element should not be used in a stand-alone LogRecord element
  • 9 The SHA-1 message digest of the Body element contained within the same parent LogRecordElement or LogRecord element
  • 10 Describes the event Sub-type ( e.g. , KDMKeysReceived .)
  • 11 A list of parameters which augment the event sub-type.
  • 12 If an exception (an error) occurred during the procedure that generated the event, this element will contain a list of tokens which describe the error.
  • 13 A list of important identifiers that existed in the procedure context when the event occurred.
Example 5.2 . Log Report Record Example 🔗
5.3.1.3. Log Record Signature 🔗

An XML Signature is used to create a tamper-proof encoding. The signature is made over the contents of the RecordAuthData element as shown in the following example. The RecordAuthData element contains the digest of the containing record's LogRecordHeader element. Consult [SMPTE-430-4] for details on extending the signature's proof of authenticity to preceding records via the contents of the header's previousHeaderHash element. 

<LogRecordSignature>1
  <HeaderPlacement>stop</HeaderPlacement>
  <SequenceLength>2</SequenceLength>
  <RecordAuthData Id="ID_RecordAuthData">2
    <RecordHeaderHash>SG93IE1hbnkgTW9yZSBSZXZpc2lvbnM/</RecordHeaderHash>3
    <SignerCertInfo>4
      <ds:X509IssuerName>CN=DistCo-ca,OU=DistCo-ra,O=DistCo-ra,
        dnQualifier=vnqteTcB2Gji\+1Hl23sxxgOqvwE=</ds:X509IssuerName>
      <ds:X509SerialNumber>16580</ds:X509SerialNumber>
    </SignerCertInfo>
  </RecordAuthData>
  <Signature>5
    <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
      <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha256" />
      <ds:Reference URI="#ID_RecordAuthData">
        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
        <ds:DigestValue>VGhpcyBvbmx5IHRvb2sgdHdvIHllYXJz</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>
      Vqe6MS0pHovkfqhHlkt/NNEI1GGchCW/EyqxOccSenuzNQc63qL+VIQoIJCcwgnE0i/w/8bIgjfB
      PrsOW5M3zlR0eAZc7tt6f7q50taNmC+O2wfATVXqEE8KC32qO//NQHuOL6bLLH+12oqgR5fS/mlI
      /wpn8s/pAtGA9lAXDRp03EVOvzwq0m9AjzOxIbgzGg6AIY0airJ1gecT1qccb1zGQjB81pr3ctlp
      ECchubtSCqh+frRn4CZc4ZRMLhjnax/zwHIG4ExiMCEKbwaz7DwN8zv1yoPUzut9ik7X0EyfRIlv
      F3piQoLeeFcFrkfNwYyyhTX8iHTO4Cz8YfGNyw==</ds:SignatureValue>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509IssuerSerial>
          <ds:X509IssuerName>Sample Issuer Name</ds:X509IssuerName>
          <ds:X509SerialNumber>1234567</ds:X509SerialNumber>
        </ds:X509IssuerSerial>
        <!-- X509 certificate value as block of Base64 encoded characters, -->
        <!-- truncated for brevity -->
        <ds:X509Certificate>
          QSBDZXJ0aWZpY2F0ZSB3b3VsZCBiZSBsb25nZXIgdGhhbiB0aGlz</ds:X509Certificate>
      </ds:X509Data>
      <ds:X509Data>
        <ds:X509IssuerSerial>
          <ds:X509IssuerName>Sample Issuer Name 2</ds:X509IssuerName>
        </ds:X509IssuerSerial>
        <!-- X509 certificate value as block of Base64 encoded characters, -->
        <!-- truncated for brevity -->
        <ds:X509Certificate>TG9uZ2VyIHRoYW4gdGhpcyB0b28sIGZvciBzdXJl</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
  </Signature>
</LogRecordSignature>
  • 1 The LogRecordSignature contains the signature of a log record.
  • 2 The RecordAuthData element is the content that is actually signed for the signature. This element is identified for the signature processor by the Id attribute value
  • 3 A message digest value calculated over the sibling Header element.
  • 4 This information identifies the creator of the XML Signature (the document's signer.)
  • 5 A standard XML Signature element.
Example 5.3 . Log Report Signature Example 🔗
5.3.1.4. Log Report Signature Validation 🔗

XML Signatures on log reports can be checked using the procedure in Section 3.1.3 .

5.3.1.5. Deleted Section 🔗

The section "Log Record Proxy" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.3.2. Event Log Operations 🔗
5.3.2.1. Log Structure 🔗
Objective
Verify that that the Log Report retrieved from a security manager (SM):
Procedures
  1. Set up and play a show using the following composition:
  2. Extract a security log report from the Test Subject that includes the range of time during which the above steps were carried out.
  3. Using the schema-check software utility, validate the XML file structure against the XML schemas in [SMPTE-430-4] and [SMPTE-433] . Failure to correctly validate is cause to fail this test. For more information on schema validation see Section 3.1.2: XML Schema . 
    $ schema-check <input-file> smpte-433.xsd smpte-430-4.xsd 
schema
validation
successful
  4. Supply the filename of the Log Report file as an argument to the uuid_check.py software utility. Examine the output for error messages that identify expected UUID values that do not conform to the format specified in [RFC-4122] . One or more occurrences is cause to fail this test, unless the non-conforming value is derived from an external source ( i.e. , a DCP or KDM). Examples of fields that record external values are the parameters "KeyDeliveryMessageID", "CompositionID" and "TrackFileID", and the header element "contentId". 
    $ uuid_check.py <input-file> 
all UUIDs conform to RFC-4122 
$
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.3.2.2. Deleted Section 🔗

The section "Log Records for Multiple Remote SPBs" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.3.2.3. Log Sequence Numbers 🔗
Objective
Verify that the security manager (SM) maintains a secure and persistent counter to provide a unique sequential EventSequence number to each log record it creates. Verify that this EventSequence number appears in the Header node of each log record in a report.
Procedures
  1. Set up and play a show using the composition DCI 2K StEM (Encrypted) , keyed with KDM for 2K StEM (Encrypted) .
  2. Extract a security log report from the Test Subject that includes the range of time during which the above steps were carried out.
  3. Examine the log report using a Text Editor . Verify that the header in each record contains an EventSequence value that is one greater than the value in the previous record.
  4. Failure to correctly sequence log records in a report shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.3.2.4. Deleted Section 🔗

The section "Log Collection by the SM" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.3.2.5. Deleted Section 🔗

The section "General Log System Failure" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.3.2.6. Log Report Signature Validity 🔗
Objective
Verify that the Test Subject provides log event information in the form of Log Reports

Verify that all Log Records within a Log Report are properly authenticated as specified in [SMPTE-430-4] and [SMPTE-430-5] .

Verify that the Log Report is signed by the SM.

Verify that EventID for a given event is maintained across collections.

Procedures

The CPLStart and CPLEnd records are triggered by the first and last edit unit, respectively, of the CPL reproduced by the Test Subject. For example, in the case of an OMB with OBAE capability, the first and last edit units of the CPL are OBAE edit units, since picture edit units are not reproduced despite Main Picture assets being present in the CPL received by the OMB.

If the Test Subject uses a single certificate implementation as defined in Section 9.5.1.1 of [DCI-DCSS] :
  1. Set up and play a show using the composition DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) .
  2. Extract a Log Report from the Test Subject covering the time period during which Step 1 was performed.
  3. Leave the system idle for no less than 1 minute, then extract a second security Log Report from the Test Subject covering the time period during which Step 1 was performed.
  4. Using a Text Editor , locate in each of the Log Reports extracted in Steps 2 and 3 the CPLStart record. Failure for the records in the two reports to have the same EventID value is cause to fail this test. Note: The following steps shall use the Log Report extracted in Step 2 .
  5. Using a Text Editor , verify that the root element of the Log Report is LogReport . Failure of this verification is cause to fail the test.
  6. Using a Text Editor , identify all individually signed Log Records and sequences of Log Records, as defined in [SMPTE-430-5] . Failure for any Log Record to either be signed individually or be part of a sequence is cause to fail this test.
  7. Authenticate each individually signed Log Record identified in Step 4 as specified in [SMPTE-430-4] and [SMPTE-430-5] , including:
    1. Validating the recordBodyHash elements as specified in Section 6.1.1.5 of [SMPTE-430-5] ; and
    2. Validating the LogRecordSignature element as specified in Section 7.3 of [SMPTE-430-4] and Section 6.1.3 of [SMPTE-430-5] .
    Failure to authenticate any individually signed Log Record is cause to fail the test.
  8. Authenticate each sequence of Log Records identified in Step 4 as specified in Section 9 of [SMPTE-430-4] , including:
    1. Validating the previousHeaderHash (unless the Log Record is the first of a sequence) and recordBodyHash elements as specified in Section 6.1.1.5 of [SMPTE-430-5] ;
    2. Validating the authenticated chain as specified in Section 9 of [SMPTE-430-4] ; and
    3. Validating the LogRecordSignature element as specified in Section 7.3 of [SMPTE-430-4] and Section 6.1.3 of [SMPTE-430-5] .
    Failure to authenticate any sequence of Log Records is cause to fail the test.
  9. Using a Text Editor , locate one LogRecordSignature element. Using its X509IssuerName and X509SerialNumber from the SignerCertInfo element, locate elements that match in one of the KeyInfo elements and extract the device certificate from its X509Certificate element. Absence of a device certificate or mismatched X509IssuerName and X509SerialNumber values shall be cause to fail the test.
  10. Obtain the SM certificate of the Test Subject.
  11. Using openssl , compare the certificate obtained in Step 10 to the device certificate obtained in Step 9. Mismatch between the two certificates shall be cause to fail the test.
If the Test Subject uses a dual certificate implementation as defined in Section 9.5.1.2 of [DCI-DCSS] :
  1. Perform Steps 1-9 above.
  2. Obtain the SM and LS certificates of the Test Subject.
  3. Using a Text Editor , verify that the LogReport element contains a single reportingDevice child element as defined in [SMPTE-430-4] . Failure of this verification is cause to fail this test.
  4. Using a Text Editor , verify that the reportingDevice element meets the following requirements. Failure to meet any of these requirements is cause to fail this test.
    1. If the idtype attribute of the DeviceIdentifier element is equal to "DeviceUID" , the DeviceCertID element shall also be present and shall contain the certificate thumbprint of the SM Certificate.
    2. If the idtype attribute of the DeviceIdentifier element is equal to "DeviceUID" , it shall contain the device UUID of the Test Subject.
    3. If the idtype attribute of the DeviceIdentifier element is equal to "CertThumbprint" , it shall contain the certificate thumbprint of the SM Certificate of the Test Subject.
    4. The AdditionalID element shall be present and its value set to the certificate thumbprint of the LS Certificate, encoded as an ds:DigestValueType type.
  5. Using openssl , compare the LS certificate obtained in Step 2 to the device certificate obtained in Step 9 above. Mismatch between the two certificates shall be cause to fail the test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.3.2.7. Log Sequence Numbers (OBAE) 🔗
Objective
Verify that the OBAE-capable security manager (SM) maintains a secure and persistent counter to provide a unique sequential EventSequence number to each log record it creates. Verify that this EventSequence number appears in the Header node of each log record in a report.
Procedures
  1. Set up and play a show using the composition DCI 2K StEM (OBAE) (Encrypted) , keyed with KDM for 2K StEM (Encrypted) (OBAE) .
  2. Extract a security log report from the Test Subject that includes the range of time during which the above steps were carried out.
  3. Examine the log report using a Text Editor . Verify that the header in each record contains an EventSequence value that is one greater than the value in the previous record.
  4. Failure to correctly sequence log records in a report shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
5.3.2.8. Log Report Signature Validity (OBAE) 🔗
Objective

Verify that the OBAE-capable Test Subject provides log event information in the form of Log Reports

Verify that all Log Records within a Log Report are properly authenticated as specified in [SMPTE-430-4] and [SMPTE-430-5] .

Verify that the Log Report is signed by the SM.

Verify that EventID for a given event is maintained across collections.

Procedures

The CPLStart and CPLEnd records are triggered by the first and last edit unit, respectively, of the CPL reproduced by the Test Subject. For example, in the case of an OMB with OBAE capability, the first and last edit units of the CPL are OBAE edit units, since picture edit units are not reproduced despite Main Picture assets being present in the CPL received by the OMB.

If the Test Subject uses a single certificate implementation as defined in Section 9.5.1.1 of [DCI-DCSS] :

  1. Set up and play a show using the composition DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) .
  2. Extract a Log Report from the Test Subject covering the time period during which Step 1 was performed.
  3. Leave the system idle for no less than 1 minute, then extract a second security Log Report from the Test Subject covering the time period during which Step 1 was performed.
  4. Using a Text Editor , locate in each of the Log Reports extracted in Steps 2 and 3 the CPLStart record. Failure for the records in the two reports to have the same EventID value is cause to fail this test. Note: The following steps shall use the Log Report extracted in Step 2 .
  5. Using a Text Editor , verify that the root element of the Log Report is LogReport . Failure of this verification is cause to fail the test.
  6. Using a Text Editor , identify all individually signed Log Records and sequences of Log Records, as defined in [SMPTE-430-5] . Failure for any Log Record to either be signed individually or be part of a sequence is cause to fail this test.
  7. Authenticate each individually signed Log Record identified in Step 4 as specified in [SMPTE-430-4] and [SMPTE-430-5] , including:
    1. Validating the recordBodyHash elements as specified in Section 6.1.1.5 of [SMPTE-430-5] ; and
    2. Validating the LogRecordSignature element as specified in Section 7.3 of [SMPTE-430-4] and Section 6.1.3 of [SMPTE-430-5] .
    Failure to authenticate any individually signed Log Record is cause to fail the test.
  8. Authenticate each sequence of Log Records identified in Step 4 as specified in Section 9 of [SMPTE-430-4] , including:
    1. Validating the previousHeaderHash (unless the Log Record is the first of a sequence) and recordBodyHash elements as specified in Section 6.1.1.5 of [SMPTE-430-5] ;
    2. Validating the authenticated chain as specified in Section 9 of [SMPTE-430-4] ; and
    3. Validating the LogRecordSignature element as specified in Section 7.3 of [SMPTE-430-4] and Section 6.1.3 of [SMPTE-430-5] .
    Failure to authenticate any sequence of Log Records is cause to fail the test.
  9. Using a Text Editor , locate one LogRecordSignature element. Using its X509IssuerName and X509SerialNumber from the SignerCertInfo element, locate elements that match in one of the KeyInfo elements and extract the device certificate from its X509Certificate element. Absence of a device certificate or mismatched X509IssuerName and X509SerialNumber values shall be cause to fail the test.
  10. Obtain the SM certificate of the Test Subject.
  11. Using openssl , compare the certificate obtained in Step 10 to the device certificate obtained in Step 9. Mismatch between the two certificates shall be cause to fail the test.

If the Test Subject uses a dual certificate implementation as defined in Section 9.5.1.2 of [DCI-DCSS] :

  1. Perform Steps 1-9 above.
  2. Obtain the SM and LS certificates of the Test Subject.
  3. Using a Text Editor , verify that the LogReport element contains a single reportingDevice child element as defined in [SMPTE-430-4] . Failure of this verification is cause to fail this test.
  4. Using a Text Editor , verify that the reportingDevice element meets the following requirements. Failure to meet any of these requirements is cause to fail this test.
    1. If the idtype attribute of the DeviceIdentifier element is equal to "DeviceUID" , the DeviceCertID element shall also be present and shall contain the certificate thumbprint of the SM Certificate.
    2. If the idtype attribute of the DeviceIdentifier element is equal to "DeviceUID" , it shall contain the device UUID of the Test Subject.
    3. If the idtype attribute of the DeviceIdentifier element is equal to "CertThumbprint" , it shall contain the certificate thumbprint of the SM Certificate of the Test Subject.
    4. The AdditionalID element shall be present and its value set to the certificate thumbprint of the LS Certificate, encoded as an ds:DigestValueType type.
  5. Using openssl , compare the LS certificate obtained in Step 2 to the device certificate obtained in Step 9 above. Mismatch between the two certificates shall be cause to fail the test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
5.3.3. SM Proxy of Log Events 🔗
5.3.3.1. Deleted Section 🔗

The section "SM Proxy of Log Events" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.3.3.2. Deleted Section 🔗

The section "SM Proxy of Security Operations Events" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.3.3.3. Deleted Section 🔗

The section "SM Proxy of Security ASM Events" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.3.3.4. Deleted Section 🔗

The section "Remote SPB Time Compensation" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.4. Security Log Events 🔗

Secure Processing Blocks (SPB) are required to record Security Log Events (defined in [SMPTE-430-5] ) upon the occurrence of certain operational states. The procedures in this section should cause the Test Subject to record the respective events.

5.4.1. Playout, Validation and Key Events 🔗
5.4.1.1. FrameSequencePlayed Event 🔗
Objective
Verify that the SM can produce log records which contain correctly coded FrameSequencePlayed events per [SMPTE-430-5] .
Procedures
  1. Set up and play a show using the composition DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the playback is started.
  2. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  3. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Playout , Event Subtype FrameSequencePlayed .
  4. Verify that the FrameSequencePlayed record has correctly formatted parameters as defined in [SMPTE-430-5] .
  5. Failure to correctly record a FrameSequencePlayed shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.1.2. CPLStart Event 🔗
Objective
Verify that the SM can produce log records which contain correctly coded CPLStart events per [SMPTE-430-5] .
Procedures

The CPLStart and CPLEnd records are triggered by the first and last edit unit, respectively, of the CPL reproduced by the Test Subject. For example, in the case of an OMB with OBAE capability, the first and last edit units of the CPL are OBAE edit units, since picture edit units are not reproduced despite Main Picture assets being present in the CPL received by the OMB.

  1. Set up and play a show using the composition DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the playback is started.
  2. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  3. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Playout , Event Subtype CPLStart .
  4. Verify that the CPLStart record has correctly formatted parameters as defined in [SMPTE-430-5] .
  5. Failure to correctly record a CPLStart event shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.1.3. CPLEnd Event 🔗
Objective
Verify that the SM can produce log records which contain correctly coded CPLEnd events per [SMPTE-430-5] .
Procedures

The CPLStart and CPLEnd records are triggered by the first and last edit unit, respectively, of the CPL reproduced by the Test Subject. For example, in the case of an OMB with OBAE capability, the first and last edit units of the CPL are OBAE edit units, since picture edit units are not reproduced despite Main Picture assets being present in the CPL received by the OMB.

  1. Set up and play a show using the composition DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the playback is started.
  2. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  3. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Playout , Event Subtype CPLEnd .
  4. Verify that the CPLEnd record has correctly formatted parameters as defined in [SMPTE-430-5] .
  5. Failure to correctly record a CPLEnd event shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.1.4. PlayoutComplete Event 🔗
Objective
Verify that the SM can produce log records which contain correctly coded PlayoutComplete events per [SMPTE-430-5] .
Procedures
  1. Set up and play a show using the composition DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the playback is started.
  2. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  3. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Playout , Event Subtype PlayoutComplete .
  4. Verify that the PlayoutComplete record has correctly formatted parameters as defined in [SMPTE-430-5] .
  5. Failure to correctly record a PlayoutComplete shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.1.5. CPLCheck Event 🔗
Objective
Verify that the SM can produce log records which contain correctly coded CPLCheck events per [SMPTE-430-5] .
Procedures
  1. If present, delete the composition DCI 2K Sync Test (Encrypted) from the Test Subject.
  2. Ingest the composition DCI 2K Sync Test (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the ingest is started.
  3. Set up and play a show using the composition DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) .
  4. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  5. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 2, less one minute. Verify that the log contains at least one record of Class Security , Type Validation , Event Subtype CPLCheck .
  6. Verify that the CPLCheck record has correctly formatted parameters as defined in [SMPTE-430-5] .
  7. Failure to correctly record a CPLCheck event shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.1.6. KDMKeysReceived Event 🔗
Objective
Verify that the SM can produce log records which contain correctly coded KDMKeysReceived events per [SMPTE-430-5] .
Procedures
  1. Delete from the Test Subject any existing KDMs for the composition DCI 2K Sync Test (Encrypted) .
  2. Ingest the KDM KDM for DCI 2K Sync Test (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the ingest is started.
  3. Set up and play a show using the composition DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) .
  4. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  5. Using a Text Editor , examine the log report for events near or after the time recorded in Step 2. Verify that the log contains at least one record of Class Security , Type Key , Event Subtype KDMKeysReceived .
  6. Verify that the KDMKeysReceived record has correctly formatted parameters as defined in [SMPTE-430-5] .
  7. Failure to correctly record a KDMKeysReceived event shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
5.4.1.7. KDMDeleted Event 🔗
Objective
Verify that the SM can produce log records which contain correctly coded KDMDeleted events per [SMPTE-430-5] .
Procedures
  1. Set up and play a show using the composition DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the playback is started.
  2. Delete from the Test Subject any KDMs for the composition DCI 2K Sync Test (Encrypted) .
  3. Attempt to play the composition DCI 2K Sync Test (Encrypted) . Successful playback shall be cause to fail this test.
  4. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  5. Using a Text Editor , examine the log report for events near or after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Key , Event Subtype KDMDeleted .
  6. Verify that the KDMDeleted record has correctly formatted parameters as defined in [SMPTE-430-5] .
  7. Failure to correctly record a KDMDeleted event shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.1.8. FrameSequencePlayed Event (OBAE) 🔗
Objective
Verify that the IMBO or OMB can produce, for an OBAE presentation, log records which contain correctly coded FrameSequencePlayed events per [SMPTE-430-5] .
Procedures
  1. Set up and play a show using the composition DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the playback is started.
  2. Extract a security log from the IMBO or OMB that includes the range of time during which the above Steps were carried out.
  3. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Playout , Event Subtype FrameSequencePlayed associated with the OBAE essence in DCI 2K Sync Test (OBAE) (Encrypted) .
  4. Verify that the FrameSequencePlayed record has correctly recorded parameters as defined in [SMPTE-430-5] .
  5. Verify that the Parameters list of the FrameSequencePlayed record contains a name/value pair whose Name element contains the token OBAEMark , and whose Value element shall contain one of two tokens, either true or false , indicating that a forensic mark was or was not inserted during playout.
  6. Failure to correctly record a FrameSequencePlayed as detailed above shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.1.9. CPLStart Event (OBAE) 🔗
Objective
Verify that the OBAE-capable SM can produce log records which contain correctly coded CPLStart events per [SMPTE-430-5] .
Procedures

The CPLStart and CPLEnd records are triggered by the first and last edit unit, respectively, of the CPL reproduced by the Test Subject. For example, in the case of an OMB with OBAE capability, the first and last edit units of the CPL are OBAE edit units, since picture edit units are not reproduced despite Main Picture assets being present in the CPL received by the OMB.

  1. Set up and play a show using the composition DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the playback is started.
  2. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  3. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Playout , Event Subtype CPLStart .
  4. Verify that the CPLStart record has correctly formatted parameters as defined in [SMPTE-430-5] .
  5. Failure to correctly record a CPLStart event shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.1.10. CPLEnd Event (OBAE) 🔗
Objective
Verify that the OBAE-capable SM can produce log records which contain correctly coded CPLEnd events per [SMPTE-430-5] .
Procedures

The CPLStart and CPLEnd records are triggered by the first and last edit unit, respectively, of the CPL reproduced by the Test Subject. For example, in the case of an OMB with OBAE capability, the first and last edit units of the CPL are OBAE edit units, since picture edit units are not reproduced despite Main Picture assets being present in the CPL received by the OMB.

  1. Set up and play a show using the composition DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the playback is started.
  2. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  3. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Playout , Event Subtype CPLEnd .
  4. Verify that the CPLEnd record has correctly formatted parameters as defined in [SMPTE-430-5] .
  5. Failure to correctly record a CPLEnd event shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.1.11. PlayoutComplete Event (OBAE) 🔗
Objective
Verify that the OBAE-capable SM can produce log records which contain correctly coded PlayoutComplete events per [SMPTE-430-5] .
Procedures
  1. Set up and play a show using the composition DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the playback is started.
  2. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  3. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Playout , Event Subtype PlayoutComplete .
  4. Verify that the PlayoutComplete record has correctly formatted parameters as defined in [SMPTE-430-5] .
  5. Failure to correctly record a PlayoutComplete shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.1.12. CPLCheck Event (OBAE) 🔗
Objective
Verify that the OBAE-capable SM can produce log records which contain correctly coded CPLCheck events per [SMPTE-430-5] .
Procedures
  1. If present, delete the composition DCI 2K Sync Test (OBAE) (Encrypted) from the Test Subject.
  2. Ingest the composition DCI 2K Sync Test (OBAE) (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the ingest is started.
  3. Set up and play a show using the composition DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) .
  4. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  5. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 2, less one minute. Verify that the log contains at least one record of Class Security , Type Validation , Event Subtype CPLCheck .
  6. Verify that the CPLCheck record has correctly formatted parameters as defined in [SMPTE-430-5] .
  7. Failure to correctly record a CPLCheck event shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.1.13. KDMKeysReceived Event (OBAE) 🔗
Objective
Verify that the OBAE-capable SM can produce log records which contain correctly coded KDMKeysReceived events per [SMPTE-430-5] .
Procedures
  1. Delete from the Test Subject any existing KDMs for the composition DCI 2K Sync Test (OBAE) (Encrypted) .
  2. Ingest the KDM KDM for DCI 2K Sync Test (OBAE) (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the ingest is started.
  3. Set up and play a show using the composition DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) .
  4. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  5. Using a Text Editor , examine the log report for events near or after the time recorded in Step 2. Verify that the log contains at least one record of Class Security , Type Key , Event Subtype KDMKeysReceived .
  6. Verify that the KDMKeysReceived record has correctly formatted parameters as defined in [SMPTE-430-5] .
  7. Failure to correctly record a KDMKeysReceived event shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
20.4. OMB Confidence Sequence Pass/Fail —
5.4.1.14. KDMDeleted Event (OBAE) 🔗
Objective
Verify that the OBAE-capable SM can produce log records which contain correctly coded KDMDeleted events per [SMPTE-430-5] .
Procedures
  1. Set up and play a show using the composition DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) . With an Accurate Real-Time Clock , note the UTC time at the moment the playback is started.
  2. Delete from the Test Subject any KDMs for the composition DCI 2K Sync Test (OBAE) (Encrypted) .
  3. Attempt to play the composition DCI 2K Sync Test (OBAE) (Encrypted) . Successful playback shall be cause to fail this test.
  4. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  5. Using a Text Editor , examine the log report for events near or after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Key , Event Subtype KDMDeleted .
  6. Verify that the KDMDeleted record has correctly formatted parameters as defined in [SMPTE-430-5] .
  7. Failure to correctly record a KDMDeleted event shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
5.4.2. ASM and Operations Events 🔗
5.4.2.1. Deleted Section 🔗

The section "LinkOpened Event" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.4.2.2. Deleted Section 🔗

The section "LinkClosed Event" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.4.2.3. Deleted Section 🔗

The section "LinkException Event" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.4.2.4. Deleted Section 🔗

The section "LogTransfer Event" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.4.2.5. Deleted Section 🔗

The section "KeyTransfer Event" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

5.4.2.6. SPBStartup and SPBShutdown Events 🔗
Objective
Verify that the SM can produce log records which contain correctly coded SPBStartup and SPBShutdown events per [SMPTE-430-5] .
Procedures
If the Test Subject is a Media Block:
  1. Power up the Test Subject. With an Accurate Real-Time Clock , note the UTC time at the moment the power is applied.
  2. Wait for the system to become idle.
  3. Power down the Test Subject using the procedure recommended by the manufacturer. With an Accurate Real- Time Clock , note the UTC time at the moment the shutdown procedure is initiated.
  4. Wait for the system to power down completely.
  5. Power up the Test Subject. With an Accurate Real-Time Clock , note the UTC time at the moment the power is applied.
  6. Wait for the system to become idle.
  7. Interrupt line power to the Test Subject and associated suite equipment. With an Accurate Real-Time Clock , note the UTC time at the moment the power is removed. Note: If applicable, make sure that the projector lamp is off when interrupting power .
  8. Wait for the system to power down completely.
  9. Power up the Test Subject and associated suite equipment, wait for the system to become idle.
  10. Extract a security log report from the Test Subject that includes the range of time during which the above steps were carried out.
  11. Using a Text Editor , examine the log report for events recorded by the Test Subject. Verify that these events include at least one record of Class Security , Type Operations , Event Subtypes SPBStartup and SPBShutdown , for each of (a) between the times recorded in step 1 and step 5 and (b) after the time recorded in step 5.
  12. Verify that the SPBStartup and SPBShutdown records have correctly formatted parameters as defined in [SMPTE-430-5] .
  13. Failure to correctly record SPBStartup and SPBShutdown events shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.2.7. SPBOpen and SPBClose Events 🔗
Objective
Verify that the SM of a Media Block, integrated or married to an Imaging Device, can produce log records which contain correctly coded SPBOpen and SPBClose events per [SMPTE-430-5] .
Procedures
If the Test Subject is a Media Block integrated or married with an Imaging Device:
  1. Power up the Test Subject and associated suite equipment, with an Accurate Real-Time Clock , note the UTC time at the moment the power is applied. Wait for the system to become idle.
  2. Open a secure perimeter access door. Wait one minute, close the access door.
  3. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  4. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Operations , Event Subtypes SPBOpen and SPBClose .
  5. Verify that the SPBOpen and SPBClose records have correctly formatted parameters as defined in [SMPTE-430-5] .
  6. Failure to correctly record SPBOpen and SPBClose events shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.2.8. SPBClockAdjust Event 🔗
Objective
Verify that the SM can produce log records which contain correctly coded SPBClockAdjust events per [SMPTE-430-5] .
Procedures
If the Test Subject is a Media Block:
  1. Power up the Test Subject and associated suite equipment, with an Accurate Real-Time Clock , note the UTC time at the moment the power is applied. Wait for the system to become idle.
  2. Using the manufacturer's documented procedure, adjust the clock of the Test Subject.
  3. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  4. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Operations , Event Subtypes SPBClockAdjust .
  5. Verify that the SPBClockAdjust records have correctly formatted parameters as defined in [SMPTE-430-5] .
  6. Failure to correctly record a SPBClockAdjust event shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.2.9. SPBMarriage and SPBDivorce Events 🔗
Objective
Verify that the SM of a Media Block, married to an Imaging Device, can produce log records which contain correctly coded SPBMarriage and SPBDivorce events per [SMPTE-430-5] .
Procedures
If the Test Subject is a Media Block married with an Imaging Device:
  1. Power up the Test Subject and associated suite equipment, with an Accurate Real-Time Clock , note the UTC time at the moment the power is applied. Wait for the system to become idle.
  2. Using the manufacturer's documented procedure, divorce the Media Block from its Imaging Device SPB2.
  3. Using the manufacturer's documented procedure, remarry the Media Block to its Imaging Device SPB2.
  4. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  5. Using a Text Editor , examine the log report for events occurring after the time recorded in Step 1. Verify that the log contains at least one record of Class Security , Type Operations , Event Subtypes SPBMarriage and SPBDivorce .
  6. Verify that the SPBMarriage and SPBDivorce records have correctly formatted parameters as defined in [SMPTE-430-5] .
  7. Failure to correctly record SPBMarriage and SPBDivorce events shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
5.4.2.10. SPBSoftware Event 🔗
Objective
Verify that the SM can produce log records which contain correctly coded SPBSoftware events per [SMPTE-430-5] .
Procedures
If the Test Subject is a Media Block:
  1. Power up the Test Subject and associated suite equipment, with an Accurate Real-Time Clock , note the UTC time at the moment the power is applied. Wait for the system to become idle.
  2. Perform the following procedures:
    1. Using the manufacturer's documented procedure, perform a software installation on the Test Subject.
    2. Return the Test Subject to the idle state (reboot after software installation is acceptable).
    3. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
    4. Using a Text Editor , examine the log report for events corresponding to the above steps. Verify that the log contains at least one record of Class Security , Type Operations , Event Subtypes SPBSoftware .
    5. Verify that the SPBSoftware records have correctly formatted parameters as defined in [SMPTE-430-5] .
    6. Failure to correctly record a SPBSoftware event shall be cause to fail this test.
  3. Perform the following procedures:
    1. Attempt a software installation on the Test Subject using a procedure that will cause the update to fail in some fashion ( e.g. provide wrong signer for the update, incorrect message digest in module, consult with the manufacturer for additional assistance).
    2. Return the Test Subject to the idle state.
    3. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
    4. Using a Text Editor , examine the log report for events corresponding to the above steps. Verify that the log contains at least one record of Class Security , Type Operations , Event Subtypes SPBSoftware .
    5. Verify that the SPBSoftware records have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    6. Confirm the presence of a SoftwareFailure exception in the SPBSoftware log record. Record any additional parameters associated with the exception. A missing SoftwareFailure exception in the associated SPBSoftware log record shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
20.4. OMB Confidence Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
5.4.2.11. SPBSecurityAlert Event 🔗
Objective
The following does not apply to a Test Subject that is an Imaging Device SPB. Verify that, where the SM can produce SPBSecurityAlert log events, the respective log records contain correctly coded SPBSecurityAlert events per [SMPTE-430-5] .
Procedures

A SPBSecurityAlert record indicates an event that is not described by one of the other event record types defined in [SMPTE-430-5] . Each Test Subject must be evaluated to determine what conditions may result in a SPBSecurityAlert event being logged. Detailed instructions must be provided by the manufacturer, including any test jigs or applications that may be required to perform the test.

  1. Following the manufacturer's documented procedure, for each separately identified condition, configure the Test Subject and perform actions that will result in the logging of a SPBSecurityAlert event recording the condition.
  2. Extract a security log from the Test Subject that includes the range of time during which the above Step 1 was carried out.
  3. Using a Text Editor , examine the log report for events corresponding to the above Step 1. Verify that the log contains the expected number of records of Class Security , Type Operations , Event Subtypes SPBSecurityAlert . Verify that the SPBSecurityAlert records have correctly formatted parameters as defined in [SMPTE-430-5] .
  4. For each type of SPBSecurityAlert record, provide an explanation of the condition and any parameters that are recorded.
Supporting Materials
Reference Documents
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Data only —
20.2. OMB Test Sequence Data only —
21.2. Integrated IMBO Test Sequence Data only —

Chapter 6. Media Block 🔗

The Media Block (MB) is a Type 1 SPB comprising a Security Manager (SM) and the Media Decryptors (MD) for all essence types, plus, as required, Forensic Marker (FM) for image or sound and a Timed Text rendering engine (alpha-channel overlay).

6.1. Security Manager (SM) 🔗

Some of the procedures in this section require test content that is specifically malformed. In some implementations, these malformations may be caught and reported directly by the SMS without involving the SM. Because the purpose of the procedures is to assure that the SM demonstrates the required behavior, the manufacturer of the Test Subject may need to provide special test programs or special SMS testing modes to allow the malformed content to be applied directly to the SM.

6.1.1. Image Integrity Checking 🔗
Objective
  • Verify that the SM detects and logs playback restarts.
  • Verify that, for Image Track Files, the SM detects and logs deviations in the:
    • Sequence Number item of the Encrypted Triplet
    • TrackFile ID item of the Encrypted Triplet
    • Check Value of the Encrypted Source Value
    • MIC item of the Encrypted Triplet
Procedures
  1. Using manufacturer-supplied documentation and by inspection, record a list of means by which playback of a particular composition can be interrupted and restarted. Such means may include command pairs such as pause/play, stop/play, etc. For each of these means:
    1. Select for playback the composition DCI 2K StEM (Encrypted) keyed with KDM for 2K StEM (Encrypted) .
    2. Start playback, interrupt playback and restart playback
    3. Extract a security log from the Test Subject and using a Text Editor and identify the events associated with the playback.
    4. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    5. Confirm that there are at least 2 FrameSequencePlayed records for each track file included in the composition and that the FirstFrame and LastFrame parameter values reflect the interrupted playback.
    6. Confirm that there is no PlayoutComplete event associated with the interrupted playback.
  2. Start playback of the composition DCI 2K StEM (Encrypted) keyed with KDM for 2K StEM (Encrypted) and interrupt line power to the Test Subject before playback of the composition ends. Power up the Test Subject, wait for the system to become idle. Extract a security log from the Test Subject and using a Text Editor . Identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm that there are at least 1 FrameSequencePlayed record for each track file included in the composition and that the FirstFrame and LastFrame parameter values reflect the interrupted playback.
    3. Confirm that there is no PlayoutComplete event associated with the interrupted playback.
  3. Play back the composition DCI Malformed Test 1: Picture with Frame-out-of-order error (Encrypted) , keyed with KDM for DCI Malformed Test 1: Picture with Frame-out-of-order error (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a FrameSequenceError exception in the FrameSequencePlayed log record for the image track file. Record any additional parameters associated with the exception.
  4. Play back the composition DCI Malformed Test 5: DCP With an incorrect image TrackFile ID (Encrypted) , keyed with KDM for DCI Malformed Test 5: DCP With an incorrect image TrackFile ID (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a TrackFileIDError exception in the FrameSequencePlayed log record for the image track file. Record any additional parameters associated with the exception.
  5. Play back the composition DCI 2K Sync Test with KDM-Borne MIC Keys (Encrypted) , keyed with KDM with invalid MIC Key (Picture) for DCI 2K Sync Test with KDM-Borne MIC Keys (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a FrameMICError exception in the FrameSequencePlayed log record for the image track file. Record any additional parameters associated with the exception.
  6. Play back the composition DCI 2K Sync Test (Encrypted) , keyed with KDM with MIC Key (Picture) for DCI 2K Sync Test (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a FrameMICError exception in the FrameSequencePlayed log record for the image track file. Record any additional parameters associated with the exception.
  7. Play back the composition DCI Malformed Test 9: Picture with HMAC error in MXF Track File (Encrypted) , keyed with KDM for DCI Malformed Test 9: Picture with HMAC error in MXF Track File (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm that there is no FrameMICError exception in the FrameSequencePlayed log record for the image track file.
  8. Play back the composition DCI Malformed Test 11: Picture with Check Value error in MXF Track File (Encrypted) , keyed with KDM for DCI Malformed Test 11: Picture with Check Value error in MXF Track File (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a CheckValueError exception in the FrameSequencePlayed log record for the image track file. Record any additional parameters associated with the exception.
Failure of any of the above conditions is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.1.2. Sound Integrity Checking 🔗
Objective
Verify that, for Sound Track Files, the SM detects and logs deviations in the:
  • Sequence Number item of the Encrypted Triplet
  • TrackFile ID item of the Encrypted Triplet
  • Check Value of the Encrypted Source Value
  • MIC item of the Encrypted Triplet
Procedures
  1. Play back the composition DCI Malformed Test 2: Sound with Frame-out-of-order error (Encrypted) , keyed with KDM for DCI Malformed Test 2: Sound with Frame-out-of-order error (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a FrameSequenceError exception in the FrameSequencePlayed log record for the sound track file. Record any additional parameters associated with the exception.
  2. Play back the composition DCI Malformed Test 4: DCP With an incorrect audio TrackFile ID (Encrypted) , keyed with KDM for DCI Malformed Test 4: DCP With an incorrect audio TrackFile ID (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a TrackFileIDError exception in the FrameSequencePlayed log record for the sound track file. Record any additional parameters associated with the exception.
  3. Play back the composition DCI 2K Sync Test with KDM-Borne MIC Keys (Encrypted) , keyed with KDM with invalid MIC Key (Sound) for DCI 2K Sync Test with KDM-Borne MIC Keys (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a FrameMICError exception in the FrameSequencePlayed log record for the sound track file. Record any additional parameters associated with the exception.
  4. Play back the composition DCI 2K Sync Test (Encrypted) , keyed with KDM with MIC Key (Sound) for DCI 2K Sync Test (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a FrameMICError exception in the FrameSequencePlayed log record for the sound track file. Record any additional parameters associated with the exception.
  5. Play back the composition DCI Malformed Test 10: Sound with HMAC error in MXF Track File (Encrypted) , keyed with KDM for DCI Malformed Test 10: Sound with HMAC error in MXF Track File (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm that there is no FrameMICError exception in the FrameSequencePlayed log record for the sound track file.
  6. Play back the composition DCI Malformed Test 12: Sound with Check Value error in MXF Track File (Encrypted) , keyed with KDM for DCI Malformed Test 12: Sound with Check Value error in MXF Track File (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a CheckValueError exception in the FrameSequencePlayed log record for the sound track file. Record any additional parameters associated with the exception.
Failure of any of the above conditions is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.1.3. Deleted Section 🔗

The section "Restriction of Keying to Monitored Link Decryptors" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

6.1.4. Restriction of Keying to MD Type 🔗
Objective
Verify that keys are issued only to a Media Decryptor (MD) matching the key type as specified in the KDM per [SMPTE-430-1] .
Procedures
  1. Load the KDM KDM with mismatched keytype , which contains a valid decryption key for image, but the Key Type is mismatched.
  2. Load and attempt to play the composition DCI 2K StEM (Encrypted) . Successful playback shall be cause to fail this test.
  3. Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the operation and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of an associated FrameSequencePlayed log record that contains a KeyTypeError exception. Record any additional parameters associated with the exception. Failure to produce correct log records shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.1.5. Restriction of Keying to Valid CPLs 🔗
Objective
Verify that the SM validates CPLs and logs results as a prerequisite to preparing the suite for the associated composition playback.
Procedures
  1. Supply the CPL DCI Malformed Test 6: CPL with incorrect track file hashes (Encrypted) , keyed with KDM for DCI Malformed Test 6: CPL with incorrect track file hashes (Encrypted) , to the SM. Verify that the SM rejects the CPL. If the SM accepts the CPL, this is cause to fail this test.
  2. Attempt to start playback and verify that it is not possible. If playback starts, this is cause to fail this test.
  3. Extract a security log from the Test Subject and using a Text Editor , identify the CPLCheck event associated with the above operation and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Verify that the contentId element contains the Id of the CPL. Verify that the value of the SignerID parameter contains the Certificate Thumbprint of the certificate used to sign the CPL. Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of the CPL. Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a AssetHashError exception in the CPLCheck log record. Record any additional parameters associated with the exception. A missing AssetHashError exception shall be cause to fail this test.
  4. Supply the CPL DCI Malformed Test 7: CPL with an Invalid Signature (Encrypted) , keyed with KDM for DCI Malformed Test 7: CPL with an Invalid Signature (Encrypted) to the SM. Verify that the SM rejects the CPL. If the SM accepts the CPL, this is cause to fail this test.
  5. Attempt to start playback and verify that it is not possible. If playback starts, this is cause to fail this test.
  6. Extract a security log from the Test Subject and using a Text Editor , identify the CPLCheck event associated with the above operation and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Verify that the contentId element contains the Id of the CPL. Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of the CPL. Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a SignatureError exception in the CPLCheck log record. Record any additional parameters associated with the exception. A missing SignatureError exception shall be cause to fail this test.
  7. Supply the CPL DCI Malformed Test 13: CPL that references a non-existent track file (Encrypted) , keyed with KDM for DCI Malformed Test 13: CPL that references a non-existent track file (Encrypted) to the SM. Verify that the SM rejects the CPL. If the SM accepts the CPL, this is cause to fail this test.
  8. Attempt to start playback and verify that it is not possible. If playback starts, this is cause to fail this test.
  9. Extract a security log from the Test Subject and using a Text Editor , identify the CPLCheck event associated with the above operation and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Verify that the contentId element contains the Id of the CPL. Verify that the value of the SignerID parameter contains the Certificate Thumbprint of the certificate used to sign the CPL. Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of the CPL. Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a AssetMissingError exception in the CPLCheck log record. Record any additional parameters associated with the exception. A missing AssetMissingError exception shall be cause to fail this test.
  10. Supply the CPL DCI Malformed Test 14: CPL that does not conform to ST 429-7 (Encrypted) , keyed with KDM for DCI Malformed Test 14: CPL that does not conform to ST 429-7 (Encrypted) to the SM. Verify that the SM rejects the CPL. If the SM accepts the CPL, this is cause to fail this test.
  11. Attempt to start playback and verify that it is not possible. If playback starts, this is cause to fail this test.
  12. Extract a security log from the Test Subject and using a Text Editor , identify the CPLCheck event associated with the above operation and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a CPLFormatError exception in the CPLCheck log record. Record any additional parameters associated with the exception. A missing CPLFormatError exception shall be cause to fail this test.
  13. Supply the CPL DCI Malformed Test 15: CPL signed by a certificate not conforming to ST 430-2 (Encrypted) , keyed with KDM for DCI Malformed Test 15: CPL signed by a certificate not conforming to ST 430-2 (Encrypted) to the SM. Verify that the SM rejects the CPL. If the SM accepts the CPL, this is cause to fail this test.
  14. Attempt to start playback and verify that it is not possible. If playback starts, this is cause to fail this test.
  15. Extract a security log from the Test Subject and using a Text Editor , identify the CPLCheck event associated with the above operation and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Verify that the contentId element contains the Id of the CPL. Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of the CPL. Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a CertFormatError exception in the CPLCheck log record. Record any additional parameters associated with the exception. A missing CertFormatError exception shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
6.1.6. Deleted Section 🔗

The section "Remote SPB Integrity Monitoring" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

6.1.7. Deleted Section 🔗

The section "SPB Integrity Fault Consequences" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

6.1.8. Content Key Extension, End of Engagement 🔗
Objective
Verify that to avoid end of engagement issues, composition playout may extend beyond the end of the KDM's playout time window, if started within the KDM playout time window, by a maximum of 6 hours.
Procedures

This test will require KDMs that contain ContentKeysNotValidAfter elements set to a time in the near future. It is recommended that fresh KDMs be generated that will expire 30-60 minutes after beginning the test procedures. Refer to information provided in the relevant step to ensure that the applicable KDM is being used at the appropriate absolute time the step of the test is carried out.

The Test Operator is required to take into account any timezone offsets that may apply to the locality of the Test Subject and the representation of the ContentKeysNotValidAfter element of the KDM. For clarity it is recommended that a common representation be used.

The Security Manager's (SM) clock must be accurately set, to the extent possible, for successful execution of this test.

The CPLStart and CPLEnd records are triggered by the first and last edit unit, respectively, of the CPL reproduced by the Test Subject. For example, in the case of an OMB with OBAE capability, the first and last edit units of the CPL are OBAE edit units, since picture edit units are not reproduced despite Main Picture assets being present in the CPL received by the OMB.

  1. Using a Text Editor , open the KDM KDM for Past Time Window Extension (Encrypted) and note the value of the timestamp contained in the <ContentKeysNotValidAfter> element ( i.e. the KDM's end of validity timestamp). Note: Steps 2 and 3 must be commenced before the time recorded in this step .
  2. Load the composition End of Engagement -Past Time Window Extension (Encrypted) , keyed with KDM for Past Time Window Extension (Encrypted) . End of Engagement -Past Time Window Extension (Encrypted) is a composition which is 6 hours and 11 minutes in length.
  3. Within 5 minutes prior to the timestamp recorded in step 1, attempt to start playing End of Engagement -Past Time Window Extension (Encrypted) . Because the complete show extends beyond the 6 hours end of engagement extension window, the composition should not start playback. If the composition starts to playback, this is cause to fail this test.
  4. Using a Text Editor , open the KDM KDM for Within Time Window Extension (Encrypted) and note the value of the timestamp contained in the <ContentKeysNotValidAfter> element ( i.e. the KDM's end of validity timestamp). Note: Steps 5 and 6 must be commenced before the time recorded in this step .
  5. Load the composition End of Engagement - Within Time Window Extension (Encrypted) , keyed with KDM for Within Time Window Extension (Encrypted) . End of Engagement - Within Time Window Extension (Encrypted) has a duration of 5 hours, 59 minutes and 30 seconds.
  6. Within 5 minutes prior to the timestamp recorded in step 4, attempt to start playing End of Engagement - Within Time Window Extension (Encrypted) . The composition should start to playback and continue playing in its entirety. If the show fails to start or fails to playout completely, this is cause to fail this test.
    Note: The test operator does not have to be present for the entire playback. Sufficient proof of successful playback can be observed by examining the security log for complete FrameSequencePlayed , CPLEnd and PlayoutComplete events.
.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
6.1.9. ContentAuthenticator Element Check 🔗
Objective
  • Verify that the Test Subject checks that one of the certificates in the certificate chain supplied with the CPL has a certificate thumbprint that matches the value of the KDM <ContentAuthenticator> element.
  • Verify that the Test Subject checks that such certificate indicates only a "Content Signer (CS) role.
Procedures
For each of the malformations below, load the indicated CPL and KDM on to the Test Subject. Verify that the the KDM is not used to enable playback. A successful playback is cause to fail this test.
  1. Use the composition DCI 2K StEM (Encrypted) and supply the KDM KDM with invalid ContentAuthenticator . The KDM contains a <ContentAuthenticator> element having a certificate thumbprint value that does not match the thumbprint of one of the signer certificates in the certificate chain that signed the associated CPL.
  2. Use the composition DCI Malformed Test 16: CPL signed with No Role Certificate (Encrypted) and supply the KDM KDM for DCI Malformed Test 16: CPL signed with No Role Certificate (Encrypted) . The KDM contains a <ContentAuthenticator> element having a certificate thumbprint value that matches the thumbprint of one of the signer certificates in the certificate chain that signed the associated CPL but that certificate has no role.
  3. Use the composition DCI Malformed Test 17: CPL signed with Bad Role Certificate (Encrypted) and supply the KDM KDM for DCI Malformed Test 17: CPL signed with Bad Role Certificate (Encrypted) . The KDM contains a <ContentAuthenticator> element having a certificate thumbprint value that matches the thumbprint of one of the signer certificates in the certificate chain that signed the associated CPL but that certificate has a bad role (SM).
  4. Use the composition DCI Malformed Test 18: CPL signed with Extra Role Certificate (Encrypted) and supply the KDM KDM for DCI Malformed Test 18: KDM for CPL signed with Extra Role Certificate (Encrypted) . The KDM contains a <ContentAuthenticator> element having a certificate thumbprint value that matches the thumbprint of one of the signer certificates in the certificate chain that signed the associated CPL but that certificate has an extra role.
  5. Extract a security log from the Test Subject and using a Text Editor , identify the FrameSequencePlayed events associated with the above steps and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of FrameSequencePlayed log records that contain ContentAuthenticatorError exceptions. Record any additional parameters associated with the exception. A missing ContentAuthenticatorError exception in any of the associated FrameSequencePlayed log records shall be cause to fail this test. Only for the operation associated with step 2, a correctly recorded CPLCheck log record with a CertFormatError exception is an allowable substitute for a FrameSequencePlayed log record to satisfy the requirements of this step of the test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
6.1.10. KDM Date Check 🔗
Objective
Verify that the Test Subject checks that the playout date is within the time period defined by the KDM ContentKeysNotValidBefore and ContentKeysNotValidAfter elements.
Procedures
  1. Load the composition DCI 2K StEM (Encrypted) and KDM KDM that has expired , which contains a valid decryption keys, but the KDM has expired.
  2. Attempt to play the DCI 2K StEM (Encrypted) composition and record the result. Verify that the composition cannot be played. Successful playout is cause to fail this test.
  3. Load the composition DCI 2K StEM (Encrypted) and the KDM KDM with future validity period , which contains a valid decryption keys, but the KDM has is not yet valid.
  4. Attempt to play the DCI 2K StEM (Encrypted) composition and record the result. Verify that the composition cannot be played. Successful playout is cause to fail this test.
  5. Load the composition DCI 2K StEM (Encrypted) and KDM KDM that has recently expired , which contains a valid decryption keys, but the KDM has expired.
  6. Attempt to play the DCI 2K StEM (Encrypted) composition and record the result. Verify that the composition cannot be played. Successful playout is cause to fail this test.
  7. Load the composition DCI 2K StEM (Encrypted) and the KDM KDM with future validity period , which contains a valid decryption keys, but the KDM has is not yet valid.
  8. Attempt to play the DCI 2K StEM (Encrypted) composition and record the result. Verify that the composition cannot be played. Successful playout is cause to fail this test.
  9. Extract a security log from the Test Subject and using a Text Editor , identify the FrameSequencePlayed events associated with the above steps and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a FrameSequencePlayed log record that contains a ValidityWindowError exception. Record any additional parameters associated with the exception. A missing ValidityWindowError exception in any of the associated FrameSequencePlayed log records shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.1.11. KDM TDL Check 🔗
Objective
The following does not apply if a Special Auditorium Situation is enabled.

Verify that the Test Subject checks that the set of SPBs configured for playout is consistent with the TDL ( AuthorizedDeviceInfo element) in the controlling KDM.

Procedures
If the Test Subject is a Media Block that is a Companion SPB and is married (physically and electrically) to an Imaging Device SPB , perform each of the following steps. Before each step, delete all KDMs residing in the Test Subject. After completing the steps, extract a security log from the Test Subject and using a Text Editor :
  • Identify the FrameSequencePlayed record associated with the image track file produced during each step, and confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] .
  • If successful playback start is expected, confirm that the FrameSequencePlayed record contains a Parameter element with a Name equal to DownstreamDevice and a Value equal to the certificate thumbprint of the Imaging Device SPB.
  • If failed playback start is expected, confirm that the FrameSequencePlayed record contains a TDLError exception. Record all parameters associated with the exception.
Failure to produce correct log records, including missing required elements or incorrect parameters, shall be cause to fail this test.
  1. Load the KDM with Assume Trust TDL Entry for 2K StEM (Encrypted) , which is a KDM that carries only the "assume trust" certificate thumbprint. Attempt to play DCI 2K StEM (Encrypted) and record the result. If playback does not begin this is cause to fail this test.
  2. Load the KDM with Assume Trust and random TDL entries , which is KDM with a TDL that carries the "assume trust" certificate thumbprint and a single, randomly generated device list entry. Attempt to play DCI 2K StEM (Encrypted) and record the result. Successful start of playback is cause to fail this test.
  3. Load the KDM with random TDL entry , which contains a single, randomly generated device list entry. Attempt to play DCI 2K StEM (Encrypted) and record the result. Successful start of playback is cause to fail this test.
  4. Load the KDM with the SM alone on the TDL , which is a KDM with a TDL that contains only the certificate thumbprint of the SM Certificate of the Test Subject. Attempt to play DCI 2K StEM (Encrypted) and record the result. Successful start of playback is cause to fail the test.
  5. Load the KDM with the Imaging Device alone on the TDL , which is a KDM with a TDL that contains only the certificate thumbprint of the Imaging Device SPB certificate. Attempt to play DCI 2K StEM (Encrypted) and record the result. If playback does not begin this is cause to fail this test.
If the Test Subject is a Media Block that is permanently married to a Imaging Device SPB , perform each of the following steps. Before each step, delete all KDMs residing in the Test Subject. After completing the steps, extract a security log from the Test Subject and using a Text Editor :
  • Identify the FrameSequencePlayed record associated with the image track file produced during each step, and confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] .
  • If successful playback start is expected, confirm that the FrameSequencePlayed record does not contain a Parameter element with a Name equal to DownstreamDevice .
  • If failed playback start is expected, confirm that the FrameSequencePlayed record contains a TDLError exception. Record all parameters associated with the exception.
Failure to produce correct log records, including missing required elements or incorrect parameters, shall be cause to fail this test.
  1. Load the KDM with Assume Trust TDL Entry for 2K StEM (Encrypted) , which is a KDM that carries only the "assume trust" certificate thumbprint. Attempt to play DCI 2K StEM (Encrypted) and record the result. If playback does not begin this is cause to fail this test.
  2. Load the KDM with random TDL entry , which contains a single, randomly generated device list entry. Attempt to play DCI 2K StEM (Encrypted) and record the result. If playback does not begin this is cause to fail this test.
  3. Load the KDM with the SM alone on the TDL , which is a KDM with a TDL that contains only the certificate thumbprint of the SM Certificate of the Test Subject. Attempt to play DCI 2K StEM (Encrypted) and record the result. If playback does not begin this is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
6.1.12. Maximum Number of DCP Keys 🔗
Objective
Verify that the system supports playback of two compositions with up to 256 different essence encryption keys each
Procedures

The KDMs specified to be used in this test additionally have one of each type of forensic marking keys FMIK and FMAK. Receiving devices shall process such keys in accordance with the individual implementation, in a manner that will not affect the requirements related to the maximum number of content keys (MDIK and MDAK).

The CPLStart and CPLEnd records are triggered by the first and last edit unit, respectively, of the CPL reproduced by the Test Subject. For example, in the case of an OMB with OBAE capability, the first and last edit units of the CPL are OBAE edit units, since picture edit units are not reproduced despite Main Picture assets being present in the CPL received by the OMB.

  1. Load the compositions 128 Reel Composition, "A" Series and 128 Reel Composition, "B" Series on to the Test Subject.
  2. Create a show that contains 128 Reel Composition, "A" Series and 128 Reel Composition, "B" Series . Each composition contains 128 reels of plaintext picture and sound.
  3. Play the show. With an Accurate Real-Time Clock , note the UTC time at the moment playback started. Failure to play the complete show shall be cause to fail this test.
  4. Extract a security log from the Test Subject that includes the range of time during which Step 3 was carried out
  5. Using a Text Editor , locate the first CPLStart and last CPLEnd records that occurred after the time recorded in Step 3. Let Plaintext Time be the absolute difference between the TimeStamp values of the two records.
  6. Load the compositions 128 Reel Composition, "A" Series (Encrypted) and 128 Reel Composition, "B" Series (Encrypted) on to the Test Subject.
  7. Load the KDMs KDM for 128 Reel Composition, "A" Series (Encrypted) and KDM for 128 Reel Composition, "B" Series (Encrypted) on to the Test Subject.
  8. Create a show that contains 128 Reel Composition, "A" Series (Encrypted) and 128 Reel Composition, "B" Series (Encrypted) . Each composition contains 128 reels of encrypted picture and sound.
  9. Play the show. With an Accurate Real-Time Clock , note the UTC time at the moment playback started. Failure to play the complete show shall be cause to fail this test.
  10. The presence of any observable artifacts in the reproduced picture and/or sound shall be cause to fail this test.
  11. Extract a security log from the Test Subject that includes the range of time during which Step 9 was carried out.
  12. Using a Text Editor , locate the first CPLStart and last CPLEnd records that occurred after the time recorded in Step 9. Let Ciphertext Time be the absolute difference between the TimeStamp values of the two records.
  13. An absolute difference of more than 1 second between Ciphertext Time and Plaintext Time is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.1.13. CPL Id Check 🔗
Objective
Verify that the Test Subject checks that the KDM <CompositionPlaylistId> element matches the value of the CompositionPlaylistID field of KDM CipherData structure as specified in [SMPTE-430-1]
Procedures
  1. Load DCI 2K StEM (Encrypted) .
  2. load KDM with bad CipherData CompositionPlaylistId value , a KDM in which (i) the value of the CompositionPlaylistID field of the CipherData structure does not match the value of the <Id> element of DCI 2K StEM (Encrypted) and (ii) the value of the <CompositionPlaylistId> element matches the value of the CompositionPlaylist <Id> element of DCI 2K StEM (Encrypted) . Attempt to play DCI 2K StEM (Encrypted) . Successful playback is cause to fail this test.
  3. Delete KDM with bad CipherData CompositionPlaylistId value .
  4. Load KDM with bad CompositionPlaylistId value , a KDM in which (i) the value of the CompositionPlaylistID field of the CipherData structure matches the value of the <Id> element of DCI 2K StEM (Encrypted) and (ii) the value of the <CompositionPlaylistId> element does not match the value of the CompositionPlaylist <Id> element in DCI 2K StEM (Encrypted) . Attempt to play DCI 2K StEM (Encrypted) . Successful playback is cause to fail this test.
  5. Extract a security log from the Test Subject and using a Text Editor , identify the KDMKeysReceived events associated with the above steps and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a KDMFormatError exception in the KDMKeysReceived log record. Record any additional parameters associated with the exception. A missing KDMFormatError exception in any of the associated KDMKeysReceived log records shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.1.14. CPL Id Check (OBAE) 🔗
Objective
Verify that the Test Subject checks that the KDM <CompositionPlaylistId> element matches the value of the CompositionPlaylistId field of KDM CipherData structure as specified in [SMPTE-430-1] .
Procedures

If the Test Subject is an OMB, the KDM targeting the associated IMB is valid, i.e. it is an instance of KDM for 2K StEM (Encrypted) (OBAE) .

  1. Load DCI 2K StEM (OBAE) (Encrypted) .
  2. Load KDM with bad CipherData CompositionPlaylistId value (OBAE) , a KDM in which (i) the value of the CompositionPlaylistId field of the CipherData structure does not match the value of the <Id> element of DCI 2K StEM (OBAE) (Encrypted) and (ii) the value of the <CompositionPlaylistId> element matches the value of the CompositionPlaylist <Id> element of DCI 2K StEM (OBAE) (Encrypted) . Attempt to play DCI 2K StEM (OBAE) (Encrypted) . Successful playback is cause to fail this test.
  3. Delete KDM with bad CipherData CompositionPlaylistId value (OBAE) .
  4. Load KDM with bad CompositionPlaylistId value (OBAE) , a KDM in which (i) the value of the CompositionPlaylistId field of the CipherData structure matches the value of the <Id> element of DCI 2K StEM (OBAE) (Encrypted) and (ii) the value of the <CompositionPlaylistId> element does not match the value of the CompositionPlaylist <Id> element in DCI 2K StEM (OBAE) (Encrypted) . Attempt to play DCI 2K StEM (OBAE) (Encrypted) . Successful playback is cause to fail this test.
  5. Extract a security log from the Test Subject and using a Text Editor , identify the KDMKeysReceived events associated with the above steps and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a KDMFormatError exception in the KDMKeysReceived log record. Record any additional parameters associated with the exception. A missing KDMFormatError exception in any of the associated KDMKeysReceived log records shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.1.15. Restriction of Playback in Absence of Integrity Pack Metadata 🔗
Objective
Verify that playback of encrypted content is disallowed or terminated when integrity pack metadata is missing.
Procedures

For each of the rows of Table 6.1 , perform the following steps in order:

  1. If the Test Subject is not one of the Target Test Subject(s) , skip the row.
  2. Attempt playback of the Malformed Composition from its start using the associated KDM , and, with an Accurate Real-Time Clock , note the UTC time of the attempt.
  3. Confirm that either:
    1. no part of the Malformed Composition is played; or
    2. playback of the Malformed Composition stops no later than 61 seconds after playback starts.
  4. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out and, using a Text Editor , confirm that:
    1. all required elements of the security log have correctly formatted parameters as defined in [SMPTE-430-5] .
    2. there is exactly one FrameSequencePlayed log record for the associated Malformed Track File and that the record contains a single instance of the specified Exception Token .
    3. there is no PlayoutComplete event associated with the playback.

Failure of any part of any of the steps above shall be cause to fail this test.

Table 6.1 . List of Compositions with missing integrity pack items 🔗
Malformed Composition, Malformed Composition KDM and Malformed Track File Exception Token Target Test Subject(s)
m25_integrity_pict_mic_ct.cpl.xml
m25_integrity_pict_mic_ct.kdm.xml
m25_integrity_pict_mic_j2c_ct.mxf
FrameMICError IMB, IMBO
m27_integrity_pict_tfid_ct.cpl.xml
m27_integrity_pict_tfid_ct.cpl.xml
m27_integrity_pict_tfid_j2c_ct.mxf
TrackFileIDError IMB, IMBO
m26_integrity_pict_snum_ct.cpl.xml
m26_integrity_pict_snum_ct.kdm.xml
m26_integrity_pict_snum_j2c_ct.mxf
FrameSequenceError IMB, IMBO
m28_integrity_snd_mic_ct.cpl.xml
m28_integrity_snd_mic_ct.kdm.xml
m28_integrity_snd_mic_pcm_ct.mxf
FrameMICError IMB, IMBO
m30_integrity_snd_tfid_ct.cpl.xml
m30_integrity_snd_tfid_ct.kdm.xml
m30_integrity_snd_tfid_pcm_ct.mxf
TrackFileIDError IMB, IMBO
m29_integrity_snd_snum_ct.cpl.xml
m29_integrity_snd_snum_ct.kdm.xml
m29_integrity_snd_snum_pcm_ct.mxf
FrameSequenceError IMB, IMBO
m20_integrity_obae_ms_mic_ct.cpl.xml
m20_integrity_obae_ms_mic_ct.kdm.xml
m20_integrity_obae_ms_mic_pcm_ct.mxf
FrameMICError IMB, IMBO
m22_integrity_obae_ms_tfid_ct.cpl.xml
m22_integrity_obae_ms_tfid_ct.kdm.xml
m22_integrity_obae_ms_tfid_pcm_ct.mxf
TrackFileIDError IMB, IMBO
m21_integrity_obae_ms_snum_ct.cpl.xml
m21_integrity_obae_ms_snum_ct.kdm.xml
m21_integrity_obae_ms_snum_pcm_ct.mxf
FrameSequenceError IMB, IMBO
m19_integrity_obae_mic_ct.cpl.xml
m19_integrity_obae_mic_ct.kdm.xml
m19_integrity_obae_mic_obae_ct.mxf
FrameMICError OMB, IMBO
m24_integrity_obae_tfid_ct.cpl.xml
m24_integrity_obae_tfid_ct.kdm.xml
m24_integrity_obae_tfid_obae_ct.mxf
TrackFileIDError OMB, IMBO
m23_integrity_obae_snum_ct.cpl.xml
m23_integrity_obae_snum_ct.kdm.xml
m23_integrity_obae_snum_obae_ct.mxf
FrameSequenceError OMB, IMBO
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.1.16. Restriction of Keying to MDEK Type (OBAE) 🔗
Objective
Verify that a key is not issued to an OBAE media decryptor if the KeyType of the key is not equal to "MDEK" .
Procedures
  1. Load KDM with mismatched KeyType value (OBAE) .
  2. Load and attempt to play the composition DCI 2K StEM (OBAE) (Encrypted) . Successful playback shall be cause to fail this test.
  3. Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the operation and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of an associated FrameSequencePlayed log record that contains a KeyTypeError exception. Record any additional parameters associated with the exception. Failure to produce correct log records shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.1.17. OBAE Integrity Checking 🔗
Objective
Verify that, for OBAE Track Files, the SM detects and logs deviations in the:
  • Sequence Number item of the Encrypted Triplet
  • TrackFile ID item of the Encrypted Triplet
  • Check Value of the Encrypted Source Value
  • MIC item of the Encrypted Triplet
Procedures
  1. Play back the composition M40 OBAE DCP with Frame-out-of-order error (Encrypted) , keyed with KDM for M40 OBAE DCP with Frame-out-of-order error (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a FrameSequenceError exception in the FrameSequencePlayed log record for the OBAE track file. Record any additional parameters associated with the exception.
  2. Play back the composition M41 OBAE DCP with an incorrect TrackFile ID (Encrypted) , keyed with KDM for M41 OBAE DCP with an incorrect TrackFile ID (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a TrackFileIDError exception in the FrameSequencePlayed log record for the OBAE track file. Record any additional parameters associated with the exception.
  3. Play back the composition DCI 2K Sync Test with MIC Key (OBAE) (Encrypted) , keyed with KDM with invalid MIC Key for DCI 2K Sync Test with MIC Key (OBAE) (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a FrameMICError exception in the FrameSequencePlayed log record for the OBAE track file. Record any additional parameters associated with the exception.
  4. Play back the composition DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM with MIC Key for DCI 2K Sync Test (OBAE) (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a FrameMICError exception in the FrameSequencePlayed log record for the OBAE track file. Record any additional parameters associated with the exception.
  5. Play back the composition M44 OBAE DCP with HMAC error in MXF Track File (Encrypted) , keyed with KDM for M44 OBAE DCP with HMAC error in MXF Track File (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm that there is no FrameMICError exception in the FrameSequencePlayed log record for the OBAE track file.
  6. Play back the composition M43 OBAE DCP with Check Value error in MXF Track File (Encrypted) , keyed with KDM for M43 OBAE DCP with Check Value error in MXF Track File (Encrypted) . Extract a security log from the Test Subject and using a Text Editor , identify the events associated with the playback and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a CheckValueError exception in the FrameSequencePlayed log record for the OBAE track file. Record any additional parameters associated with the exception.
Failure of any of the above conditions is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.1.18. Content Key Extension, End of Engagement (OBAE) 🔗
Objective
Verify that, to avoid end of engagement issues, OBAE composition playout can extend beyond the end of the KDM's playout time window by a maximum of 6 hours as long as playback is started within the KDM playout time window.
Procedures

This test requires KDMs that contain ContentKeysNotValidAfter elements set to a time in the near future. It is recommended that fresh KDMs be generated that will expire 30-60 minutes after beginning the test procedures. Refer to information provided in the relevant step to ensure that the applicable KDM is being used at the appropriate absolute time the step of the test is carried out.

The Test Operator is required to take into account any timezone offsets that may apply to the locality of the Test Subject and the representation of the ContentKeysNotValidAfter element of the KDM. For clarity it is recommended that a common representation be used.

The Security Manager's (SM) clock must be accurately set, to the extent possible, for successful execution of this test.

The CPLStart and CPLEnd records are triggered by the first and last edit unit, respectively, of the CPL reproduced by the Test Subject. For example, in the case of an OMB with OBAE capability, the first and last edit units of the CPL are OBAE edit units, since picture edit units are not reproduced despite Main Picture assets being present in the CPL received by the OMB.

  1. Using a Text Editor , open the KDM KDM for Past Time Window Extension (OBAE) (Encrypted) and note the value of the timestamp contained in the <ContentKeysNotValidAfter> element ( i.e. the KDM's end of validity timestamp).

    Note: Steps 2 and 3 must be commenced before the time recorded in this step .

  2. Load the composition End of Engagement - Past Time Window Extension (OBAE) (Encrypted) , keyed with KDM for Past Time Window Extension (OBAE) (Encrypted) . The composition is 6 hours and 11 minutes in length.
  3. Within 5 minutes prior to the timestamp recorded in step 1, attempt to start playing End of Engagement - Past Time Window Extension (OBAE) (Encrypted) . Because the complete show extends beyond the 6 hours end of engagement extension window, the composition should not start playback. If the composition starts to playback, this is cause to fail this test.
  4. Using a Text Editor , open the KDM KDM for Within Time Window Extension (OBAE) (Encrypted) and note the value of the timestamp contained in the <ContentKeysNotValidAfter> element ( i.e. the KDM's end of validity timestamp). Note: Steps 5 and 6 must be commenced before the time recorded in this step .
  5. Load the composition End of Engagement - Within Time Window Extension (OBAE) (Encrypted) , keyed with KDM for Within Time Window Extension (OBAE) (Encrypted) . The composition has a duration of 5 hours, 59 minutes and 30 seconds.

  6. Within 5 minutes prior to the timestamp recorded in step 4, attempt to start playing End of Engagement - Within Time Window Extension (OBAE) (Encrypted) . The composition should start to playback and continue playing in its entirety. If the show fails to start or fails to playout completely, this is cause to fail this test.

    Note: The test operator does not have to be present for the entire playback. Sufficient proof of successful playback can be observed by examining the security log for complete FrameSequencePlayed , CPLEnd and PlayoutComplete events.

.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
20.4. OMB Confidence Sequence Pass/Fail —
6.1.19. Plurality of Media Block Identity Certificates 🔗
Objective
Verify that the Media Block supports one published identity certificate and one reserved identity certificate.
Procedures

For simplicty, this test procedure uses same OBAE content for all Media Blocks (IMB, integrated IMB, IMBO and OMB) since the objective is to merely to determine whether playback occurs, and not whether a complete presentation occurred.

  1. Obtain, from the manufacturer, the published and reserved identity certificates of the Test Subject, as defined in Section 9.5.1.3 of [DCI-DCSS] .
  2. Verify that the roles listed in the published identity certificate obtained in step 1 include SM but not RES ( [SMPTE-430-2] specifies roles found in certificates). Failure of this verification is cause to fail the test.
  3. Verify that the roles listed in the reserved identity certificate obtained in step 1 includes SM and RES. Failure of this verification is cause to fail the test.
  4. Load DCI 2K StEM (OBAE) (Encrypted) .
  5. Load KDM for 2K StEM (Encrypted) (OBAE) targeted at the published identity certificate obtained in step 1.
  6. Playback DCI 2K StEM (OBAE) (Encrypted) . Failure to playback is cause to fail this test.
  7. Delete KDM for 2K StEM (Encrypted) (OBAE) loaded in step 5.
  8. Load KDM for 2K StEM (Encrypted) (OBAE) targeted at the reserved identity certificate obtained in step 1.
  9. Playback DCI 2K StEM (OBAE) (Encrypted) . Failure to playback is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.1.20. Validity of SPB Certificates 🔗
Objective
Verify that the certificates of the SPB are valid.
Procedures
  1. Obtain, from the manufacturer, (i) the one or more X.509 digital leaf certificates associated with the Test Subject and (ii) the complete chain of signer certificates for each of the one or two leaf certificate, up to and including the manufacturer's self-signed root certificate.
  2. For each certificate, perform the following tests:
  3. For the complete chain of signer certificates, perform 2.1.17. Certificate Chains

Failure of any of these above conditions is cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
20.4. OMB Confidence Sequence Pass/Fail —
20.4. OMB Confidence Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
24.2. SDR Projector Test Sequence Pass/Fail —
24.4. SDR Projector Confidence Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
26.4. HDR Direct View Display Confidence Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
27.4. SDR Direct View Display Confidence Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
28.4. HDR Projector Confidence Sequence Pass/Fail —
6.1.21. Maximum Number of DCP Keys (OBAE) 🔗
Objective
Verify that the system supports playback of two compositions with up to 256 different essence encryption keys each
Procedures

The KDMs specified to be used in this test additionally have one of each type of forensic marking keys FMIK and FMAK. Receiving devices shall process such keys in accordance with the individual implementation, in a manner that will not affect the requirements related to the maximum number of content keys (MDIK and MDAK).

The CPLStart and CPLEnd records are triggered by the first and last edit unit, respectively, of the CPL reproduced by the Test Subject. For example, in the case of an OMB with OBAE capability, the first and last edit units of the CPL are OBAE edit units, since picture edit units are not reproduced despite Main Picture assets being present in the CPL received by the OMB.

  1. Load the compositions 128 Reel Composition, "A" Series (OBAE) and 128 Reel Composition, "B" Series (OBAE) on to the Test Subject.
  2. Create a show that contains 128 Reel Composition, "A" Series (OBAE) and 128 Reel Composition, "B" Series (OBAE) . Each composition contains 128 reels of plaintext content.
  3. Play the show. With an Accurate Real-Time Clock , note the UTC time at the moment playback started. Failure to play the complete show shall be cause to fail this test.
  4. Extract a security log from the Test Subject that includes the range of time during which Step 3 was carried out
  5. Using a Text Editor , locate the first CPLStart and last CPLEnd records that occurred after the time recorded in Step 3. Let Plaintext Time be the absolute difference between the TimeStamp values of the two records.
  6. Load the compositions 128 Reel Composition, "A" Series (OBAE) (Encrypted) and 128 Reel Composition, "B" Series (OBAE) (Encrypted) on to the Test Subject.
  7. Load the KDMs KDM for 128 Reel Composition, "A" Series (OBAE) (Encrypted) and KDM for 128 Reel Composition, "B" Series (OBAE) (Encrypted) on to the Test Subject.
  8. Create a show that contains 128 Reel Composition, "A" Series (OBAE) (Encrypted) and 128 Reel Composition, "B" Series (OBAE) (Encrypted) . Each composition contains 128 reels of encrypted content where 256 distinct cryptographic keys are used.
  9. Play the show. With an Accurate Real-Time Clock , note the UTC time at the moment playback started. Failure to play the complete show shall be cause to fail this test.
  10. The presence of any observable artifacts in the reproduced picture and/or sound shall be cause to fail this test.
  11. Extract a security log from the Test Subject that includes the range of time during which Step 9 was carried out.
  12. Using a Text Editor , locate the first CPLStart and last CPLEnd records that occurred after the time recorded in Step 9. Let Ciphertext Time be the absolute difference between the TimeStamp values of the two records.
  13. An absolute difference of more than 1 second between Ciphertext Time and Plaintext Time is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.1.22. Restriction of Keying to Valid CPLs (OBAE) 🔗
Objective
Verify that the OBAE-capable SM validates CPLs and logs results as a prerequisite to preparing the suite for the associated composition playback.
Procedures
  1. Supply the CPL DCI Malformed Test 6b: CPL with incorrect track file hashes (OBAE) (Encrypted) , keyed with KDM for DCI Malformed Test 6b: CPL with incorrect track file hashes (OBAE) (Encrypted) , to the SM. Verify that the SM rejects the CPL. If the SM accepts the CPL, this is cause to fail this test.
  2. Attempt to start playback and verify that it is not possible. If playback starts, this is cause to fail this test.
  3. Extract a security log from the Test Subject and using a Text Editor , identify the CPLCheck event associated with the above operation and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Verify that the contentId element contains the Id of the CPL. Verify that the value of the SignerID parameter contains the Certificate Thumbprint of the certificate used to sign the CPL. Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of the CPL. Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a AssetHashError exception in the CPLCheck log record. Record any additional parameters associated with the exception. A missing AssetHashError exception shall be cause to fail this test.
  4. Supply the CPL DCI Malformed Test 7b: CPL with an Invalid Signature (OBAE) (Encrypted) , keyed with KDM for DCI Malformed Test 7b: CPL with an Invalid Signature (OBAE) (Encrypted) to the SM. Verify that the SM rejects the CPL. If the SM accepts the CPL, this is cause to fail this test.
  5. Attempt to start playback and verify that it is not possible. If playback starts, this is cause to fail this test.
  6. Extract a security log from the Test Subject and using a Text Editor , identify the CPLCheck event associated with the above operation and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Verify that the contentId element contains the Id of the CPL. Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of the CPL. Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a SignatureError exception in the CPLCheck log record. Record any additional parameters associated with the exception. A missing SignatureError exception shall be cause to fail this test.
  7. Supply the CPL DCI Malformed Test 13b: CPL that references a non-existent track file (OBAE) (Encrypted) , keyed with KDM for DCI Malformed Test 13b: CPL that references a non-existent track file (OBAE) (Encrypted) to the SM. Verify that the SM rejects the CPL. If the SM accepts the CPL, this is cause to fail this test.
  8. Attempt to start playback and verify that it is not possible. If playback starts, this is cause to fail this test.
  9. Extract a security log from the Test Subject and using a Text Editor , identify the CPLCheck event associated with the above operation and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Verify that the contentId element contains the Id of the CPL. Verify that the value of the SignerID parameter contains the Certificate Thumbprint of the certificate used to sign the CPL. Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of the CPL. Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a AssetMissingError exception in the CPLCheck log record. Record any additional parameters associated with the exception. A missing AssetMissingError exception shall be cause to fail this test.
  10. Supply the CPL DCI Malformed Test 14b: CPL that does not conform to ST 429-7 (OBAE) (Encrypted) , keyed with KDM for DCI Malformed Test 14b: CPL that does not conform to ST 429-7 (OBAE) (Encrypted) to the SM. Verify that the SM rejects the CPL. If the SM accepts the CPL, this is cause to fail this test.
  11. Attempt to start playback and verify that it is not possible. If playback starts, this is cause to fail this test.
  12. Extract a security log from the Test Subject and using a Text Editor , identify the CPLCheck event associated with the above operation and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a CPLFormatError exception in the CPLCheck log record. Record any additional parameters associated with the exception. A missing CPLFormatError exception shall be cause to fail this test.
  13. Supply the CPL DCI Malformed Test 15b: CPL signed by a certificate not conforming to ST 430-2 (OBAE) (Encrypted) , keyed with KDM for DCI Malformed Test 15b: CPL signed by a certificate not conforming to ST 430-2 (OBAE) (Encrypted) to the SM. Verify that the SM rejects the CPL. If the SM accepts the CPL, this is cause to fail this test.
  14. Attempt to start playback and verify that it is not possible. If playback starts, this is cause to fail this test.
  15. Extract a security log from the Test Subject and using a Text Editor , identify the CPLCheck event associated with the above operation and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Verify that the contentId element contains the Id of the CPL. Verify that ReferencedIDs element contains a CompositionID parameter with a value that is the Id of the CPL. Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a CertFormatError exception in the CPLCheck log record. Record any additional parameters associated with the exception. A missing CertFormatError exception shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
20.4. OMB Confidence Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
6.1.23. ContentAuthenticator Element Check (OBAE) 🔗
Objective
  • Verify that the OBAE-capable Test Subject checks that one of the certificates in the certificate chain supplied with the CPL has a certificate thumbprint that matches the value of the KDM <ContentAuthenticator> element.
  • Verify that the OBAE-capable Test Subject checks that such certificate indicates only a "Content Signer (CS) role.
Procedures
For each of the malformations below, load the indicated CPL and KDM on to the Test Subject. Verify that the the KDM is not used to enable playback. A successful playback is cause to fail this test.
  1. Use the composition DCI 2K StEM (OBAE) (Encrypted) and supply the KDM KDM with invalid ContentAuthenticator (OBAE) . The KDM contains a <ContentAuthenticator> element having a certificate thumbprint value that does not match the thumbprint of one of the signer certificates in the certificate chain that signed the associated CPL.
  2. Use the composition DCI Malformed Test 16b: CPL signed with No Role Certificate (OBAE) (Encrypted) and supply the KDM KDM for DCI Malformed Test 16b: CPL signed with No Role Certificate (OBAE) (Encrypted) . The KDM contains a <ContentAuthenticator> element having a certificate thumbprint value that matches the thumbprint of one of the signer certificates in the certificate chain that signed the associated CPL but that certificate has no role.
  3. Use the composition DCI Malformed Test 17b: CPL signed with Bad Role Certificate (OBAE) (Encrypted) and supply the KDM KDM for DCI Malformed Test 17b: CPL signed with Bad Role Certificate (OBAE) (Encrypted) . The KDM contains a <ContentAuthenticator> element having a certificate thumbprint value that matches the thumbprint of one of the signer certificates in the certificate chain that signed the associated CPL but that certificate has a bad role (SM).
  4. Use the composition DCI Malformed Test 18b: CPL signed with Extra Role Certificate (OBAE) (Encrypted) and supply the KDM KDM for DCI Malformed Test 18b: KDM for CPL signed with Extra Role Certificate (OBAE) (Encrypted) . The KDM contains a <ContentAuthenticator> element having a certificate thumbprint value that matches the thumbprint of one of the signer certificates in the certificate chain that signed the associated CPL but that certificate has an extra role.
  5. Extract a security log from the Test Subject and using a Text Editor , identify the FrameSequencePlayed events associated with the above steps and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of FrameSequencePlayed log records that contain ContentAuthenticatorError exceptions. Record any additional parameters associated with the exception. A missing ContentAuthenticatorError exception in any of the associated FrameSequencePlayed log records shall be cause to fail this test. Only for the operation associated with step 2, a correctly recorded CPLCheck log record with a CertFormatError exception is an allowable substitute for a FrameSequencePlayed log record to satisfy the requirements of this step of the test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
20.4. OMB Confidence Sequence Pass/Fail —
6.1.24. KDM Date Check (OBAE) 🔗
Objective
Verify that the OBAE-capable Test Subject checks that the playout date is within the time period defined by the KDM ContentKeysNotValidBefore and ContentKeysNotValidAfter elements.
Procedures
  1. Load the composition DCI 2K StEM (OBAE) (Encrypted) and KDM KDM that has expired (OBAE) , which contains a valid decryption keys, but the KDM has expired.
  2. Attempt to play the DCI 2K StEM (OBAE) (Encrypted) composition and record the result. Verify that the composition cannot be played. Successful playout is cause to fail this test.
  3. Load the composition DCI 2K StEM (OBAE) (Encrypted) and the KDM KDM with future validity period (OBAE) , which contains a valid decryption keys, but the KDM has is not yet valid.
  4. Attempt to play the DCI 2K StEM (OBAE) (Encrypted) composition and record the result. Verify that the composition cannot be played. Successful playout is cause to fail this test.
  5. Load the composition DCI 2K StEM (OBAE) (Encrypted) and KDM KDM that has recently expired (OBAE) , which contains a valid decryption keys, but the KDM has expired.
  6. Attempt to play the DCI 2K StEM (OBAE) (Encrypted) composition and record the result. Verify that the composition cannot be played. Successful playout is cause to fail this test.
  7. Load the composition DCI 2K StEM (OBAE) (Encrypted) and the KDM KDM with future validity period (OBAE) , which contains a valid decryption keys, but the KDM has is not yet valid.
  8. Attempt to play the DCI 2K StEM (OBAE) (Encrypted) composition and record the result. Verify that the composition cannot be played. Successful playout is cause to fail this test.
  9. Extract a security log from the Test Subject and using a Text Editor , identify the FrameSequencePlayed events associated with the above steps and:
    1. Confirm that all required elements have correctly formatted parameters as defined in [SMPTE-430-5] . Missing required elements or incorrect parameters shall be cause to fail this test.
    2. Confirm the presence of a FrameSequencePlayed log record that contains a ValidityWindowError exception. Record any additional parameters associated with the exception. A missing ValidityWindowError exception in any of the associated FrameSequencePlayed log records shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —

6.2. Link Encryption (LE) 🔗

6.2.1. Deleted Section 🔗

The section "LDB Trust" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

6.2.2. Deleted Section 🔗

The section "Special Auditorium Situation Operations" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

6.2.3. Deleted Section 🔗

The section "LE Key Usage" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

6.2.4. Deleted Section 🔗

The section "MB Link Encryption" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

6.3. Clocks and Time 🔗

This section describes general requirements concerning the time awareness of the components of the theater system. All procedures are applicable to the Security Manager, with the notable exception of section 6.3.2 , which is applicable to all SPBs of Type 1.

6.3.1. Clock Adjustment 🔗
Objective
  • Verify that in order to maintain synchronization between auditoriums, exhibitors are able to adjust a SM's time by a maximum of +/- 6 minutes within any calendar year.
  • Verify that the SM time adjustments are logged events.
Procedures

The following procedures are likely to fail if the Test Subject has had its time adjusted since manufacture. The current time may not be centered on the adjustment range zero point. Any such adjustments, however, will be evidenced in the security log and by examining the relevant TimeOffset elements, the zero point can be derived and the time set accordingly. If necessary, contact the manufacturer for assistance in determining and setting the time to the center of the range of adjustment for the current calendar year.

  1. Select for playback the composition DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) .
  2. Play back the composition and at the moment the last frame of picture is reproduced, record the UTC time as provided by an Accurate Real-Time Clock .
  3. Attempt to advance the time of the SM by 6 minutes. Record whether the adjustment was successful and the UTC time at the moment of adjustment. Failure to successfully adjust the time is cause to fail this test.
  4. Repeat Steps 1 and 2.
  5. Attempt to advance the time of the SM by 5 seconds. Record whether the adjustment was successful and the UTC time at the moment of adjustment. If the time can be successfully adjusted, this is cause to fail this test.
  6. Return the time to the zero point, i.e. retard by the total amount successfully advanced in Steps 3 and 5.
  7. Attempt to retard the time of the SM by 6 minutes. Record whether the adjustment was successful and the UTC time at the moment of adjustment. Failure to successfully adjust the time is cause to fail this test.
  8. Repeat Steps 1 and 2.
  9. Attempt to retard the time of the SM by 5 seconds. Record whether the adjustment was successful and the UTC time at the moment of adjustment. If the time can be successfully adjusted, this is cause to fail this test.
  10. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  11. Locate a FrameSequencePlayed event caused by Step 2. Subtract the value of the time recorded in Step 2 (UTC time) from the TimeStamp from the LogRecord (System time). Record this time as the delta of System time to UTC time for the unadjusted state.
  12. Locate the SPBClockAdjust event from Step 3 and confirm that the TimeStamp contains a value which is the time recorded in Step 3 (UTC time) + the delta from Step 11 + 6 minutes.
  13. Locate the SPBClockAdjust event from Step 7 and confirm that the TimeStamp contains a value which is the time recorded in Step 7 (UTC time) + the delta from Step 11 - 6 minutes.
  14. Locate the SPBClockAdjust event from Step 5 and confirm the presence of an Exception with a name of AdjustmentRangeError . Confirm that the TimeStamp contains a value as follows:
    T log = T step5 + T step11 + T offset
    where:
    T log is the Timestampof the log event
    T step5 is the time record in Step 5 (UTC time)
    T step11 is the delta from Step 11
    T offset is 6 minutes
    The value of the TimeOffset parameter shall be ignored.
  15. Locate the SPBClockAdjust event from Step 9 and confirm the presence of an Exception with a name of AdjustmentRangeError . Confirm that the TimeStamp contains a value as follows:
    T log = T step9 + T step11 - T offset
    where:
    T log is the Timestampof the log event
    T step9 is the time record in Step 9 (UTC time)
    T step11 is the delta from Step 11
    T offset is 6 minutes
    The value of the TimeOffset parameter shall be ignored.
  16. Locate a FrameSequencePlayed event caused by Step 4. Confirm that the TimeStamp contains a value which is the time recorded in Step 4 (UTC time) + the delta from Step 11 + 6 minutes.
  17. Locate a FrameSequencePlayed event caused by Step 8. Confirm that the TimeStamp contains a value which is the time recorded in Step 8 (UTC time) + the delta from Step 11 - 6 minutes.
  18. Incorrect or missing LogRecord elements for Steps 11 through 17 shall be cause to fail this test. Note: The TimeStamp values will have an accuracy that depends on various factors such as system responsiveness, test operator acuity, etc, and are essentially approximate. The intent is to verify that the TimeStamp values indeed reflect the time adjustments .
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
6.3.2. SPB Type 1 Clock Battery 🔗
Objective
Verify that the Type 1 SPB clock's battery is changeable without losing track of proper time.
Procedures
In the case where the Test Subject must be returned to the manufacturer for battery replacement ( i.e. field replacement of the battery is not possible), the remainder of this procedure shall be ignored and the reported result of this procedure shall be "N/A".

The phrase "record synchronized accurate time" used below means that the Test Operator records the value of the Accurate Real-Time Clock so as to determine a range of predictable deltas between the value of the Accurate Real-Time Clock and the timestamp in the log record that corresponds to an event. It is not important that the two times be equal, but that the difference be predictable to within a range that accommodates both variances in the responsiveness of the Test Subject for time stamping the logged operation and the accuracy of the Test Operator. Note: Each end of the range of the deltas is extended by an additional 2 seconds to allow for minor resolution inaccuracies of the testing methodology.

  1. Perform the following actions:
    1. Adjust the clock of the Test Subject +2 seconds, record synchronized accurate time.
    2. Adjust the clock -2 seconds, record synchronized accurate time.
  2. Repeat step 1 four times.
  3. Perform the battery replacement procedure per the manufacturer's instructions.
  4. Perform the following actions:
    1. Adjust the clock +2 seconds, record synchronized accurate time.
    2. Adjust the clock -2 seconds, record synchronized accurate time.
  5. Extract a log report, or transfer the log records over ASM, report for a time period that includes the times during which steps 1-4 were performed.
  6. The absence of a log record for any of the clock adjustments made by the above steps shall be cause to fail this test.
  7. For each of the five repetitions of step 1a, subtract 2 seconds from the event timestamp to compensate for the 2 seconds added to the SM clock. Compute the delta, in seconds, between the recorded synchronized accurate time and the logged time for the event. Assign the label of 1a min to the minimum delta in the set. Assign the label of 1a max to the maximum delta in the set.
  8. For each of the five repetitions of step 1b, compute the delta, in seconds, between the recorded synchronized accurate time and the logged time for the event. No adjustment to the event timestamps is required as the clock has been returned to its original setting. Assign the label of 1b min to the minimum delta in the set. Assign the label of 1b max to the maximum delta in the set.
  9. For the event in step 4a, subtract 2 seconds from the event timestamp to compensate for the 2 seconds added to the SM clock. Compute the delta, in seconds, between the recorded synchronized accurate time and the logged time for the event and record the value as 4a . A value of 4a that is less than 1a min - 2 seconds is cause to fail the test. A value of 4a that is greater than 1a max + 2 seconds is cause to fail the test.
  10. For the event in step 4b, compute the delta, in seconds, between the recorded synchronized accurate time and the logged time for the event and record the value as 4b . A value of 4b that is less than 1b min - 2 seconds is cause to fail the test. A value of 4b that is greater than 1b max + 2 seconds is cause to fail the test.
Supporting Materials
Reference Documents
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.3.3. Clock Resolution 🔗
Objective
Verify that the SM clock has a resolution to one second.
Procedures
  1. Setup and play back a show containing the composition 64 Reel Composition, 1 Second Reels (Encrypted) , keyed with KDM for 64 1 second reel Composition (Encrypted) . This composition contains 64 reels of encrypted essence, each with a duration of one (1) second.
  2. Examine the log records produced by the above playback. If the time stamps of the log entries are recorded to one (1) second resolution, it can be deduced that the SM clock has a resolution of at least one second. Failure to meet this requirement is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.3.4. Clock Resolution (OMB) 🔗
Objective
Verify that the OMB clock has a resolution to one second.
Procedures
  1. Setup and play back a show containing the composition 64 Reel Composition, 1 Second Reels (OBAE) (Encrypted) , keyed with KDM for 64 1 second reel Composition (OBAE) (Encrypted) . This composition contains 64 reels of encrypted essence, each with a duration of one (1) second.
  2. Examine the log records produced by the above playback. If the time stamps of the log entries are recorded to one (1) second resolution, it can be deduced that the OMB clock has a resolution of at least one second. Failure to meet this requirement is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
6.3.5. Clock Adjustment (OMB) 🔗
Objective
  • Verify that in order to maintain synchronization between auditoriums, exhibitors are able to adjust an OMB's time by a maximum of +/- 6 minutes within any calendar year.
  • Verify that the OMB time adjustments are logged events.
Procedures

The following procedures are likely to fail if the Test Subject has had its time adjusted since manufacture. The current time may not be centered on the adjustment range zero point. Any such adjustments, however, will be evidenced in the security log and by examining the relevant TimeOffset elements, the zero point can be derived and the time set accordingly. If necessary, contact the manufacturer for assistance in determining and setting the time to the center of the range of adjustment for the current calendar year.

  1. Select for playback the composition DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) .
  2. Play back the composition and at the moment the last frame of picture is reproduced, record the UTC time as provided by an Accurate Real-Time Clock .
  3. Attempt to advance the time of the OMB by 6 minutes. Record whether the adjustment was successful and the UTC time at the moment of adjustment. Failure to successfully adjust the time is cause to fail this test.
  4. Repeat Steps 1 and 2.
  5. Attempt to advance the time of the OMB by 5 seconds. Record whether the adjustment was successful and the UTC time at the moment of adjustment. If the time can be successfully adjusted, this is cause to fail this test.
  6. Return the time to the zero point, i.e. retard by the total amount successfully advanced in Steps 3 and 5.
  7. Attempt to retard the time of the OMB by 6 minutes. Record whether the adjustment was successful and the UTC time at the moment of adjustment. Failure to successfully adjust the time is cause to fail this test.
  8. Repeat Steps 1 and 2.
  9. Attempt to retard the time of the OMB by 5 seconds. Record whether the adjustment was successful and the UTC time at the moment of adjustment. If the time can be successfully adjusted, this is cause to fail this test.
  10. Extract a security log from the Test Subject that includes the range of time during which the above Steps were carried out.
  11. Locate a FrameSequencePlayed event caused by Step 2. Subtract the value of the time recorded in Step 2 (UTC time) from the TimeStamp from the LogRecord (System time). Record this time as the delta of System time to UTC time for the unadjusted state.
  12. Locate the SPBClockAdjust event from Step 3 and confirm that the TimeStamp contains a value which is the time recorded in Step 3 (UTC time) + the delta from Step 11 + 6 minutes.
  13. Locate the SPBClockAdjust event from Step 7 and confirm that the TimeStamp contains a value which is the time recorded in Step 7 (UTC time) + the delta from Step 11 - 6 minutes.
  14. Locate the SPBClockAdjust event from Step 5 and confirm the presence of an Exception with a name of AdjustmentRangeError . Confirm that the TimeStamp contains a value as follows:
    T log = T step5 + T step11 + T offset
    where:
    T log is the Timestampof the log event
    T step5 is the time record in Step 5 (UTC time)
    T step11 is the delta from Step 11
    T offset is 6 minutes
    The value of the TimeOffset parameter shall be ignored.
  15. Locate the SPBClockAdjust event from Step 9 and confirm the presence of an Exception with a name of AdjustmentRangeError . Confirm that the TimeStamp contains a value as follows:
    T log = T step9 + T step11 - T offset
    where:
    T log is the Timestampof the log event
    T step9 is the time record in Step 9 (UTC time)
    T step11 is the delta from Step 11
    T offset is 6 minutes
    The value of the TimeOffset parameter shall be ignored.
  16. Locate a FrameSequencePlayed event caused by Step 4. Confirm that the TimeStamp contains a value which is the time recorded in Step 4 (UTC time) + the delta from Step 11 + 6 minutes.
  17. Locate a FrameSequencePlayed event caused by Step 8. Confirm that the TimeStamp contains a value which is the time recorded in Step 8 (UTC time) + the delta from Step 11 - 6 minutes.
  18. Incorrect or missing LogRecord elements for Steps 11 through 17 shall be cause to fail this test. Note: The TimeStamp values will have an accuracy that depends on various factors such as system responsiveness, test operator acuity, etc, and are essentially approximate. The intent is to verify that the TimeStamp values indeed reflect the time adjustments .
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
20.4. OMB Confidence Sequence Pass/Fail —

6.4. Forensic Marking (FM) 🔗

6.4.1. FM Application Constraints 🔗
Objective
  • Verify that FM is not applied to non-encrypted audio or image content.
  • Verify that FM is not applied to Track Files that are not encrypted in case portions of a composition are encrypted and other portions are not.
  • Verify that event log records reflect the FM state.
Procedures
  1. Play back the DCP 2K FM Application Constraints (Encrypted) , keyed with KDM for 2K FM Application Constraints (Encrypted) and present the reproduced image and each of the 16 channels of sound to the appropriate Forensic Marking (FM) detector. With an Accurate Real-Time Clock , note the UTC time at the moment playback is started. This package has a CPL that selects between encrypted and plaintext, image and sound track files in a specific order.
  2. Verify that the FM detectors report the following status for the presentation: Note: Each segment of the presentation is approximately 35 minutes long and contains slates at the head and tail.
    1. The first segment of the presentation should indicate both image FM and sound FM are absent.
    2. The second segment of the presentation should indicate image FM is present and sound FM is absent.
    3. The third segment of the presentation should indicate image FM is absent and sound FM is present.
    4. The last segment of the presentation should indicate both image FM and sound FM are present.
    Any discrepancy between the expected and reported FM states is cause to fail this test.
  3. Extract a security log from the Test Subject that includes the range of time during which step 1 was carried out.
  4. Using a Text Editor , locate the FrameSequencePlayed records that correspond to the encrypted track files played during the presentation segments and:
    1. Verify there are no FrameSequencePlayed records corresponding to the first segment of the presentation (plaintext track files do not generate these records).
    2. Verify that FrameSequencePlayed records corresponding to the second segment of the presentation contain values of the ImageMark parameter equal to "true" and do not contain an AudioMark parameter.
    3. Verify that FrameSequencePlayed records corresponding to the third segment of the presentation contain values of the AudioMark parameter equal to "true" and do not contain an ImageMark parameter.
    4. For the FrameSequencePlayed records corresponding to the last segment of the presentation:
      1. Verify that records associated with image track files contain one ImageMark parameter with value "true" and do not contain an AudioMark parameter; and
      2. verify that records associated with audio track files contain one AudioMark parameter with value "true" and do not contain an ImageMark parameter
      Failure of any these verifications is cause to fail this test.
    Note: the equipment manufacturer is required to provide a suitable FM decoder ( i.e. , software and hardware).
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.4.2. Granularity of FM Control 🔗
Objective
  • Verify that "No FM mark" states are capable of being independently controlled, for audio and image, via appropriate use of the ForensicMarkFlagList element of the KDM for audio and image Track Files.
  • Verify that the ForensicMarkFlagList element of the KDM and thus the "no FM mark" state applies to the entire CPL/composition, according to the associated KDM.
  • Verify that the "no FM mark" state does not apply to any other composition, even if the other composition is part of the same showing ( i.e. , same Show Playlist).
  • Verify that event log records reflect the FM state.
Procedures
  1. Build a show playlist out of the following four compositions, in the order listed:
    1. 2K FM Control Granularity - No FM (Encrypted) , keyed with KDM for 2K FM Control Granularity - No FM (Encrypted) .
    2. 2K FM Control Granularity - Image Only FM (Encrypted) , keyed with KDM for 2K FM Control Granularity - Image Only FM (Encrypted) .
    3. 2K FM Control Granularity - Sound Only FM (Encrypted) , keyed with KDM for 2K FM Control Granularity - Sound Only FM (Encrypted) .
    4. 2K FM Control Granularity - Image and Sound FM (Encrypted) , keyed with KDM for 2K FM Control Granularity - Image and Sound FM (Encrypted) .
  2. Play back the show, and present the reproduced image and each of the 16 channels of sound to the appropriate Forensic Marking (FM) detector. With an Accurate Real-Time Clock , note the UTC time at the moment playback is started.
  3. Verify that the FM detectors report the following status for the presentation:
    1. 2K FM Control Granularity - No FM (Encrypted) : No image FM and no audio FM for the whole composition.
    2. 2K FM Control Granularity - Image Only FM (Encrypted) : Image FM present, but no audio FM, for the whole composition.
    3. 2K FM Control Granularity - Sound Only FM (Encrypted) : No image FM, but audio FM present, for the whole composition.
    4. 2K FM Control Granularity - Image and Sound FM (Encrypted) : Image FM and audio FM present for the whole composition.
    Any discrepancy between the expected and reported FM states is cause to fail this test.
  4. Extract a security log from the Test Subject that includes the range of time during which step 2 was carried out.
  5. Using a Text Editor , locate FrameSequencePlayed records corresponding to the playback and:
    1. For the FrameSequencePlayed records corresponding to the playback of 2K FM Control Granularity - No FM (Encrypted) :
      1. Verify that records associated with image track files contain one ImageMark parameter with value "false" and do not contain an AudioMark parameter; and
      2. verify that records associated with audio track files contain one AudioMark parameter with value "false" and do not contain an ImageMark parameter.
    2. For the FrameSequencePlayed records corresponding to the playback of 2K FM Control Granularity - Image Only FM (Encrypted) :
      1. Verify that records associated with image track files contain one ImageMark parameter with value "true" and do not contain an AudioMark parameter; and
      2. verify that records associated with audio track files contain one AudioMark parameter with value "false" and do not contain an ImageMark parameter.
    3. For the FrameSequencePlayed records corresponding to the playback of 2K FM Control Granularity - Sound Only FM (Encrypted) :
      1. Verify that records associated with image track files contain one ImageMark parameter with value "false" and do not contain an AudioMark parameter; and
      2. verify that records associated with audio track files contain one AudioMark parameter with value "true" and do not contain an ImageMark parameter.
    4. For the FrameSequencePlayed records corresponding to the playback of 2K FM Control Granularity - Image and Sound FM (Encrypted) :
      1. Verify that records associated with image track files contain one ImageMark parameter with value "true" and do not contain an AudioMark parameter; and
      2. verify that records associated with audio track files contain one AudioMark parameter with value "true" and do not contain an ImageMark parameter.
    Failure of any these verifications is cause to fail this test.

Note: the equipment manufacturer is required to provide a suitable FM decoder ( i.e. , software and hardware).

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.4.3. FM Payload 🔗
Objective
  • Verify that the Forensic Marking data payload contains both time stamp and location data.
  • Verify that every 15 minutes, 24 hours per day, 366 days/year are time stamped (will repeat annually).
  • Verify that the correct number of bits is allocated for the time stamp and location data.
  • Verify that the entire Forensic Marking data payload is included in each five minute segment.
  • Verify that recovery is possible with a 30-minute content sample for positive identification.
Procedures
  1. Determine, from the manufacturer, if the location data allows 524,288 (19 bits) or 1,048,576 (20 bits) distinct values.
  2. Setup and play a show using the composition 2K FM Payload (Encrypted) , keyed with KDM for KDM for 2K FM Payload (Encrypted) .
  3. Play a section 30 minutes in length and use appropriate image and audio FM detectors to extract the data payload of the Forensic Marking.
  4. Verify that the Forensic Marking decoder indicates that a "positive identification" has been made.
  5. Verify that the Forensic Marking decoder reports that the following data is contained within both image and each of the 16 audio channels:
    1. a 16-bit time stamp value.
    2. a location value whose number of bits matches that determined in Step (1).
  6. Verify that two or three sequential time stamps have been recovered during the 30 minute content sample.
Failure to verify any of the above conditions shall be cause to fail this test.

An assessment of whether any allowed value for the time stamp and location data can be included in each 5 minute segments is impractical. For example, veryifying that all specified timestamp values are allowed would require testing to continue for a full calendar year. Instead a design review verifies that all specified timestamp and location values can be carried in the Forensic Marking.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
24.2. SDR Projector Test Sequence Pass/Fail —
24.4. SDR Projector Confidence Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
26.4. HDR Direct View Display Confidence Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
27.4. SDR Direct View Display Confidence Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
28.4. HDR Projector Confidence Sequence Pass/Fail —
6.4.4. FM Audio Bypass 🔗
Objective
  • Verify that the Media Block does not alter the audio content essence when forensic marking is disabled using the KDM ForensicMarkFlagList "no FM mark" or "selective audio FM mark" commands.
Procedures
  1. Load and playback in their entirety the following CPLs using the associated KDM. For each, capture all 16 audio channels output from the Media Block using a Digital Audio Recorder in such a way that the captured audio signal is bit-for-bit identical to the output audio signal.
    1. Binary Audio Forensic Marking Bypass Test (Encrypted) and KDM for Binary Audio Forensic Marking Test (Encrypted)
    2. Binary Audio Forensic Marking Bypass Test (Encrypted) and KDM for Binary Selective Audio Forensic Marking Test (Encrypted)
  2. Using Sound Editor or equivalent software, verify that, for each audio channel captured in Step 1.a, the sequence of captured audio samples is bit-for-bit identical to a continuous sequence of an equal number of audio samples from the corresponding audio channel from the source sound track file. Any discrepancy is cause to fail this test.
  3. Using Sound Editor or equivalent software, verify that, for each of audio channels 7-16 captured in Step 1.b, the sequence of captured audio samples is bit-for-bit identical to a continuous sequence of an equal number of audio samples from the corresponding audio channel from the source sound track file. Any discrepancy is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.4.5. Selective Audio FM Control 🔗
Objective
  • Verify that the forensic marking "selective audio FM mark" and "no FM mark" states can be commanded by the ForensicMarkFlagList element of the KDM that enables playout.
  • Verify that when commanded, the "no FM mark" state shall apply to the entire encrypted DCP. The "no FM mark" state shall not apply to any other DCP, even if the other DCP is part of the same showing ( i.e. , same Show Playlist).
  • Verify that if both the "no FM mark" and "selective audio FM mark" are present in the KDM used to enable the selective audio FM mark command, the "selective audio FM mark" will override the "no FM mark" command.
  • Verify that only one ForensicMarkFlagList URI of the form http://www.dcimovies.com/430-1/2006/KDM#mrkflg-audio-disable-above-channel-XX (where XX is a value in the set {01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16 ... 99}) is allowed in the KDM used to enable the selective audio FM mark command.
Procedures
  1. Build a show playlist out of the following four compositions, keyed with their KDMs, in the order listed Note: The KDM KDM for Selective Audio FM - Not Above Channel 6 (Encrypted) contains both a "selective audio FM mark" and a "no FM mark" URI in the ForensicMarkFlagList .
  2. Play back the show, and present the reproduced sound to the appropriate Forensic Marking (FM) detector. With an Accurate Real-Time Clock , note the UTC time at the moment playback is started.
  3. Verify that the FM detectors report the following status for the presentation:
    1. Selective Audio FM - No FM (Encrypted) : No audio FM for any of the 16 audio channels, for the whole composition.
    2. Selective Audio FM - Not Above Channel 6 (Encrypted) : Audio FM present on channels 1 through 6 inclusive, and absent on channels 7 through 16 inclusive, for the whole composition.
    3. Selective Audio FM - Not Above Channel 8 (Encrypted) : Audio FM present on channels 1 through 8 inclusive, and absent on channels 9 through 16 inclusive, for the whole composition.
    4. Selective Audio FM - All FM (Encrypted) : Audio FM present, on all 16 channels, for the whole composition.
    Any discrepancy between the expected and reported FM states is cause to fail this test.
  4. Extract a security log from the Test Subject that includes the range of time during which step 2 was carried out.
  5. Using a Text Editor , locate FrameSequencePlayed records corresponding to the playback and:
    1. For the FrameSequencePlayed records corresponding to the playback of Selective Audio FM - No FM (Encrypted) : Verify that records associated with audio track files contain one AudioMark parameter with value "false" and do not contain an ImageMark parameter.
    2. For the FrameSequencePlayed records corresponding to the playback of Selective Audio FM - Not Above Channel 6 (Encrypted) : Verify that records associated with audio track files contain one AudioMark parameter with value "true" and do not contain an ImageMark parameter.
    3. For the FrameSequencePlayed records corresponding to the playback of Selective Audio FM - Not Above Channel 8 (Encrypted) : Verify that records associated with audio track files contain one AudioMark parameter with value "true" and do not contain an ImageMark parameter.
    4. For the FrameSequencePlayed records corresponding to the playback of Selective Audio FM - All FM (Encrypted) : Verify that records associated with audio track files contain one AudioMark parameter with value "true" and do not contain an ImageMark parameter.
    Failure of any these verifications is cause to fail this test.
  6. Build a show playlist out of the following four compositions, keyed with their KDMs, in the order listed Note: The KDM KDM for Selective Audio FM - Not Above Channel 17 (Encrypted) contains both a "selective audio FM mark" and a "no FM mark" URI in the ForensicMarkFlagList .
  7. Play back the show, and present the reproduced sound to the appropriate Forensic Marking (FM) detector. With an Accurate Real-Time Clock , note the UTC time at the moment playback is started.
  8. Verify that the FM detectors report the following status for the presentation:
    1. Selective Audio FM - All FM (Encrypted) : Audio FM present, on all 16 channels, for the whole composition.
    2. Selective Audio FM - Not Above Channel 10 (Encrypted) : Audio FM present on channels 1 through 10 inclusive, and absent on channels 11 through 16 inclusive, for the whole composition.
    3. Selective Audio FM - Not Above Channel 17 (Encrypted) : Audio FM present, on all 16 channels, for the whole composition.
    4. Selective Audio FM - No FM (Encrypted) : No audio FM for any of the 16 audio channels, for the whole composition.
    Any discrepancy between the expected and reported FM states is cause to fail this test.
  9. Extract a security log from the Test Subject that includes the range of time during which step 7 was carried out.
  10. Using a Text Editor , locate FrameSequencePlayed records corresponding to the playback and:
    1. For the FrameSequencePlayed records corresponding to the playback of Selective Audio FM - All FM (Encrypted) : Verify that records associated with audio track files contain one AudioMark parameter with value "true" and do not contain an ImageMark parameter.
    2. For the FrameSequencePlayed records corresponding to the playback of Selective Audio FM - Not Above Channel 10 (Encrypted) : Verify that records associated with audio track files contain one AudioMark parameter with value "true" and do not contain an ImageMark parameter.
    3. For the FrameSequencePlayed records corresponding to the playback of Selective Audio FM - Not Above Channel 17 (Encrypted) : Verify that records associated with audio track files contain one AudioMark parameter with value "true" and do not contain an ImageMark parameter.
    4. For the FrameSequencePlayed records corresponding to the playback of Selective Audio FM - No FM (Encrypted) : Verify that records associated with audio track files contain one AudioMark parameter with value "false" and do not contain an ImageMark parameter.
    Failure of any these verifications is cause to fail this test.
  11. Set up a show using the composition DCI 2K StEM (Encrypted) , keyed with the KDM KDM with two selective audio FM mark URIs .
  12. Attempt to start playback and record the result. Successful start of playback is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.4.6. FM Application Constraints (OBAE) 🔗
Objective
  • Verify that FM is not applied to non-encrypted OBAE or image content.
  • Verify that FM is not applied to Track Files that are not encrypted in case portions of a composition are encrypted and other portions are not.
  • Verify that event log records reflect the FM state.
Procedures
  1. Play back the DCP 2K FM Application Constraints (OBAE) (Encrypted) , keyed with KDM for 2K FM Application Constraints (OBAE) and present the reproduced image and OBAE-rendered audio channels to the appropriate Forensic Marking (FM) detector. With an Accurate Real-Time Clock , note the UTC time at the moment playback is started. This package has a CPL that selects between encrypted and plaintext, image and OBAE track files in a specific order.
  2. Verify that the FM detectors report the following status for the presentation: Note: Each segment of the presentation is approximately 35 minutes long and contains slates at the head and tail.
    1. The first segment of the presentation should indicate both image FM and OBAE FM are absent.
    2. The second segment of the presentation should indicate image FM is present and OBAE FM is absent.
    3. The third segment of the presentation should indicate image FM is absent and OBAE FM is present.
    4. The last segment of the presentation should indicate both image FM and OBAE FM are present.
    Any discrepancy between the expected and reported FM states is cause to fail this test.
  3. Extract a security log from the Test Subject that includes the range of time during which step 1 was carried out.
  4. Using a Text Editor , locate the FrameSequencePlayed records that correspond to the encrypted track files played during the presentation segments and:
    1. Verify there are no FrameSequencePlayed records corresponding to the first segment of the presentation (plaintext track files do not generate these records).
    2. Verify that FrameSequencePlayed records corresponding to the second segment of the presentation contain values of the ImageMark parameter equal to "true" and do not contain an OBAEMark parameter.
    3. Verify that FrameSequencePlayed records corresponding to the third segment of the presentation contain values of the OBAEMark parameter equal to "true" and do not contain an ImageMark parameter.
    4. For the FrameSequencePlayed records corresponding to the last segment of the presentation:
      1. Verify that records associated with image track files contain one ImageMark parameter with value "true" and do not contain an OBAEMark parameter; and
      2. verify that records associated with OBAE track files contain one OBAEMark parameter with value "true" and do not contain an ImageMark parameter
      Failure of any these verifications is cause to fail this test.
    Note: the equipment manufacturer is required to provide a suitable FM decoder ( i.e. , software and hardware).
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.4.7. Granularity of FM Control (OBAE) 🔗
Objective
  • Verify that the ForensicMarkFlagList element of the KDM:
    • controls the application of forensic marking independently for OBAE and image essence kinds;
    • applies to the entire composition; and
    • applies exclusively to the Composition targeted by the KDM and no other composition, even if the other composition is part of the same show ( i.e. , same Show Playlist).
  • Verify that event log records reflect the application of the ForensicMarkFlagList element of the KDM.
Procedures
  1. Build a show playlist out of the following four compositions, in the order listed:
    1. 2K FM Control Granularity - No FM (OBAE) (Encrypted) , keyed with KDM for 2K FM Control Granularity - No FM (OBAE) .
    2. 2K FM Control Granularity - Image Only FM (OBAE) (Encrypted) , keyed with KDM for 2K FM Control Granularity - Image Only FM (OBAE) .
    3. 2K FM Control Granularity - OBAE Only FM (OBAE) (Encrypted) , keyed with KDM for 2K FM Control Granularity - OBAE Only FM (OBAE) .
    4. 2K FM Control Granularity - Image and OBAE FM (OBAE) (Encrypted) , keyed with KDM for 2K FM Control Granularity - Image and OBAE FM (OBAE) .
  2. Play back the show, and present the reproduced image and all OBAE-rendered audio channels to the appropriate Forensic Marking (FM) detector. With an Accurate Real-Time Clock , note the UTC time at the moment playback is started.
  3. Verify that the FM detectors report the following status for the presentation:
    1. 2K FM Control Granularity - No FM (OBAE) (Encrypted) : No image FM and no OBAE FM for the whole composition.
    2. 2K FM Control Granularity - Image Only FM (OBAE) (Encrypted) : Image FM present, but no OBAE FM, for the whole composition.
    3. 2K FM Control Granularity - OBAE Only FM (OBAE) (Encrypted) : No image FM, but OBAE FM present, for the whole composition.
    4. 2K FM Control Granularity - Image and OBAE FM (OBAE) (Encrypted) : Image FM and OBAE FM present for the whole composition.
    Any discrepancy between the expected and reported FM states is cause to fail this test.
  4. Extract a security log from the Test Subject that includes the range of time during which step 2 was carried out.
  5. Using a Text Editor , locate FrameSequencePlayed records corresponding to the playback and:
    1. For the FrameSequencePlayed records corresponding to the playback of 2K FM Control Granularity - No FM (OBAE) (Encrypted) :
      1. Verify that records associated with image track files contain one ImageMark parameter with value "false" and do not contain an OBAEMark parameter; and
      2. verify that records associated with OBAE track files contain one OBAEMark parameter with value "false" and do not contain an ImageMark parameter.
    2. For the FrameSequencePlayed records corresponding to the playback of 2K FM Control Granularity - Image Only FM (OBAE) (Encrypted) :
      1. Verify that records associated with image track files contain one ImageMark parameter with value "true" and do not contain an OBAEMark parameter; and
      2. verify that records associated with OBAE track files contain one OBAEMark parameter with value "false" and do not contain an ImageMark parameter.
    3. For the FrameSequencePlayed records corresponding to the playback of 2K FM Control Granularity - OBAE Only FM (OBAE) (Encrypted) :
      1. Verify that records associated with image track files contain one ImageMark parameter with value "false" and do not contain an OBAEMark parameter; and
      2. verify that records associated with OBAE track files contain one OBAEMark parameter with value "true" and do not contain an ImageMark parameter.
    4. For the FrameSequencePlayed records corresponding to the playback of 2K FM Control Granularity - Image and OBAE FM (OBAE) (Encrypted) :
      1. Verify that records associated with image track files contain one ImageMark parameter with value "true" and do not contain an OBAEMark parameter; and
      2. verify that records associated with OBAE track files contain one OBAEMark parameter with value "true" and do not contain an ImageMark parameter.
    Failure of any these verifications is cause to fail this test.

Note: the equipment manufacturer is required to provide a suitable FM decoder ( i.e. , software and hardware).

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.4.8. FM Payload (OBAE) 🔗
Objective
  • Verify that the Forensic Marking data payload for OBAE essence contains both time stamp and location data.
  • Verify that every 15 minutes, 24 hours per day, 366 days/year are time stamped (will repeat annually).
  • Verify that the correct number of bits is allocated for the time stamp and location data.
  • Verify that the entire Forensic Marking data payload is included in each five minute segment.
  • Verify that recovery is possible with a 30-minute content sample for positive identification.
  • Verify that recovery is possible with a range of OBAE rendering configurations.
Procedures
Perform the following steps:
  1. Determine, from the manufacturer, if the location data allows 524,288 (19 bits) or 1,048,576 (20 bits) distinct values.
  2. Setup a show using the composition 2K FM Payload (OBAE) (Encrypted) , keyed with KDM for 2K FM Payload (OBAE) (Encrypted) .
  3. Setup the Test Subject with the maximum number of rendered channels supported by the system.
  4. Perform the following steps:
    1. Play a section 30 minutes in length and use appropriate OBAE FM detectors to extract the data payload of the Forensic Marking.
    2. Verify that the Forensic Marking decoder indicates that a "positive identification" has been made.
    3. Verify that the Forensic Marking decoder reports that the following data is contained within each of the rendered audio channels:
      1. a 16-bit time stamp value.
      2. a location value whose number of bits matches that determined in Step (1).
    4. Verify that two or three sequential time stamps have been recovered during the 30 minute content sample.
Failure to verify any of the above conditions shall be cause to fail this test.

An assessment of whether any allowed value for the time stamp and location data can be included in each 5 minute segments is impractical. For example, veryifying that all specified timestamp values are allowed would require testing to continue for a full calendar year. Instead a design review verifies that all specified timestamp and location values can be carried in the Forensic Marking.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
20.4. OMB Confidence Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
6.4.9. FM Audio Bypass (OBAE) 🔗
Objective
Verify that the Media Block does not alter the OBAE content essence when forensic marking is disabled using the KDM ForensicMarkFlagList "no FM mark" commands.
Procedures
  1. Setup the Test Subject with the maximum number of rendered channels supported by the system.
  2. Load and playback in their entirety the following CPLs using the associated KDM. For each, capture all rendered channels output from the Media Block using a Digital Audio Recorder in such a way that the captured audio signal is bit-for-bit identical to the output audio signal.
    1. 2K FM Payload (OBAE) (Encrypted) and KDM for 2K FM Payload (OBAE) with FM Bypass (Encrypted) , where forensic marking application to the OBAE essence is disabled using the "no FM mark" flag; and
    2. 2K FM Payload (plaintext OBAE) (Encrypted) and KDM for 2K FM Payload (plaintext OBAE) (Encrypted) , where forensic marking is not applied to the OBAE essence since it is plaintext.
  3. Using Sound Editor or equivalent software, verify that, for each audio channel captured in Step 2, the sequence of captured audio samples is bit-for-bit identical between Steps 2.a and 2.b. Any discrepancy is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —

6.5. Image Reproduction 🔗

6.5.1. Playback of Image Only Material 🔗
Objective
Verify that the theatre system is capable of playing back content that consists of image only, i.e. , has no corresponding audio or other track.
Procedures
Play back the DCP DCI NIST Frame no sound files . This package comprises image only. Verify that the image is displayed correctly. Failure to display the image is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.5.2. Decoder Requirements 🔗
Objective
  • Verify that the image decoder meets all requirements for JPEG 2000 image decoder presented in [DCI-DCSS] , Section 4.3.2
  • Verify that the decoder decodes each color component at 12 bits per sample, with equal color/component bandwidth, and does not subsample chroma ( i.e. , does not generate any 4:2:2 signal or similar), except as permitted by [DCI-DCSS] , Section 2.1.1.4
  • For 2K decoders, verify that it shall decode 2K data for every frame in a 4K distribution.
  • For 4K decoders, verify that it shall decode 4K data for every frame in a 4K distribution.
Procedures
  1. Verify that the decoder output conforms to the following image specifications:
    1. 2K = 2048 x 1080 at 24 fps
    2. 2K = 2048 x 1080 at 48 fps
    3. 4K = 4096 x 2160 at 24 fps
    To verify this, build and play a single show containing the compositions DCI 2K Sync Test (2K@24fps), DCI 2K Sync Test (48fps) (2K@48fps) and 4K Sync Test (4K@24fps). Verify that playback is successful and that image and audio are properly reproduced as described below.
    The test images used in the referenced compositions are similar for each of the 2K and 4K variants. In many cases, the features as they appear in the 2K image are simply scaled to create the 4K image. The description of the features of the 2k variant follows. Note that failure language declared in the 2k variant description will be modified later in this procedure to describe compliant display of the image on 24 fps 4K and 48 fps 2K displays.
    In the image descriptions that follow, the term "source pixel" is used to define the respective image feature in terms of the input signal. The Imaging Device may have a different resolution than the image, in which case a given input -- the source pixel -- may be mapped to some number of display pixels other than one, and may also contribute to shading on adjacent pixels. For example, a line that is one source pixel in width in the 2K image should appear two pixels in witdh on a 4K display. Similarly, a line that is one source pixel in width in the 4K image will likely appear diminished -- perhaps significantly -- on a 2K display, and will perhaps not be centered on a particular line of the Imaging Device's pixels.
    1. For the DCI 2K Sync Test composition (2K@24fps), locate and confirm the appearance of the following features of the test image:
      1. A yellow reticle defines the area of the 1:1.85 aspect ratio (1998 x 1080). The lines comprising the reticle are one source pixel in width. Small, outward facing arrows of matching color indicate the reticle position for the case where some occlusion prevents display of the horizontal lines ( i.e. , the top-most or bottommost lines of the image.) Failure to display the full reticle shall be cause to fail the test.
      2. A green reticle defines the area of the 1:2.39 aspect ratio (2048 x 858). The lines comprising the reticle are one source pixel in width. Small, outward facing arrows of matching color indicate the reticle position for the case where some occlusion prevents display of the vertical lines ( i.e. , the left-most or right-most lines of the image.) Failure to display the full reticle shall be cause to fail the test.
      3. A non-antialiased circle is placed in the center of the image. The source pixels comprising the circle are either ref-white or background-gray. The circle should appear to have equal height and width. Distortion of the circle geometry shall be cause to fail the test.
      4. To the left of the circle are six patches, in two rows of three. From left to right, top to bottom, the patches are designated P1, P2, P3, P4, P5, P6. (See Figure 6.1 below for a graphical definition of the panel designations.)
        1. Pattern P1 is a pair of grayscale concentric squares having two different luminances. The outer square is dark gray (12-bit X′Y′Z′ code values 122,128,125). The inner square is absolute black (12-bit X′Y′Z′ code values 0,0,0).
        2. Pattern P2 is a set of sixty (60) horizontal lines, each line being one source pixel in height, alternating red-green-blue, from top to bottom. Failure to display the correct colors and number of lines shall be cause to fail the test.
        3. Pattern P3 is a set of thirty (30) horizontal lines, each line being two source pixels in height, alternating red-green-blue, from top to bottom. Failure to display the correct colors and number of lines shall be cause to fail the test.
        4. Pattern P4 is a 60 x 60 "checkerboard" array of black and white areas. The size of each black or white area is one source pixel. Failure to display the pattern with uniform color, contrast and area size shall be cause to fail the test.
        5. Pattern P5 is a set of sixty (60) vertical lines, each line being one source pixel in width, alternating red-green-blue, from left to right. Failure to display the correct colors and number of lines shall be cause to fail the test.
        6. Pattern P6 is a set of thirty (30) vertical lines, each line being two source pixels in width, alternating red-green-blue, from left to right. Failure to display the correct colors and number of lines shall be cause to fail the test.
      5. To the right of the circle are six patches, in two rows of three. From left to right, top to bottom, the patches are designated P7, P8, P9, P10, P11, P12.
        1. Pattern P7 is a set of thirty (30) horizontal lines, each line being two source pixels in height, alternating black-white, from top to bottom. Failure to display the correct colors and number of lines shall be cause to fail the test.
        2. Pattern P8 is a set of sixty (60) horizontal lines, each line being one source pixel in height, alternating black-white, from top to bottom. Failure to display the correct colors and number of lines shall be cause to fail the test.
        3. Pattern P9 is a pair of grayscale concentric squares having two different luminances. The outer square is reference white (12-bit X′Y′Z′ code values (3794, 3960, 3890)). The inner square is absolute white (12-bit X′Y′Z′ code values (4095,4095,4095)). Note that the square having absolute white color will have red hue.
        4. Pattern P10 is a set of thirty (30) vertical lines, each line being two source pixels in width, alternating black-white, from left to right. Failure to display the correct colors and number of lines shall be cause to fail the test.
        5. Pattern P11 is a set of sixty (60) vertical lines, each line being one source pixel in width, alternating black-white, from left to right. Failure to display the correct colors and number of lines shall be cause to fail the test.
        6. Pattern P12 is a 30 x 30 "checkerboard" array of black and white areas. The size of each black or white area is two source pixels square. Failure to display the pattern with uniform color and area size shall be cause to fail the test.
      6. Below the circle is a set of twenty (20) rectangular grayscale patches, in two centered horizontal rows of ten (10) patches each. Each patch has a distinct luminance, which are defined in [SMPTE-431-2] . No two adjacent patches should appear to have the same luminance. Failure to display twenty distinct patches shall be cause to fail the test.
    2. For the 4K Sync Test composition (4K@24fps), locate and confirm the appearance of the features of the test image as described for the DCI 2K Sync Test composition, with the following exceptions:
      1. Pattern P2 is a set of one hundred twenty (120) horizontal lines, each line being one source pixel in height, alternating red-green-blue, From top to bottom. When displayed on a 2K display, no pass/fail criteria shall be applied. Failure to display the correct colors and number of lines shall be cause to fail the test.
      2. Pattern P3 is a set of sixty (60) horizontal lines, each line being two source pixels in height, alternating red-green-blue, From top to bottom. When displayed on a 2K display, this feature will appear as pattern P2 in the 2K test frame. Failure to display the correct colors and number of lines shall be cause to fail the test.
      3. Pattern P4 is a 120 x 120 "checkerboard" array of black and white areas. The size of each black or white area is one source pixel. When displayed on a 2K display, this feature will appear as a unform (but perhaps variegated) gray field. Failure to display the pattern with uniform color, contrast and area size shall be cause to fail the test.
      4. Pattern P5 is a set of one hundred twenty (120) vertical lines, each line being one source pixel in width, alternating red-green-blue, From left to right. When displayed on a 2K display, no pass/fail criteria shall be applied. Failure to display the correct colors and number of lines shall be cause to fail the test.
      5. Pattern P6 is a set of sixty (60) vertical lines, each line being two source pixels in width, alternating redgreen- blue, from left to right. When displayed on a 2K display, this feature will appear as pattern P5 in the 2K test frame. Failure to display the correct colors and number of lines shall be cause to fail the test.
      6. Pattern P7 is a set of sixty (60) horizontal lines, each line being two source pixels in height, alternating black-white, from top to bottom. When displayed on a 2K display, this feature will appear as pattern P8 in the 2K test frame. Failure to display the correct colors and number of lines shall be cause to fail the test.
      7. Pattern P8 is a set of one hundred twenty (120) horizontal lines, each line being one source pixel in height, alternating black-white, from top to bottom. When displayed on a 2K display, no pass/fail criteria shall be applied. Failure to display the correct colors and number of lines shall be cause to fail the test.
      8. Pattern P10 is a set of sixty (60) vertical lines, each line being two source pixels in width, alternating black- white, from left to right. When displayed on a 2K display, this feature will appear as pattern P11 in the 2K test frame. Failure to display the correct colors and number of lines shall be cause to fail the test.
      9. Pattern P11 is a set of one hundred twenty (120) vertical lines, each line being one source pixel in width, alternating black-white, from left to right. When displayed on a 2K display, no pass/fail criteria shall be applied. Failure to display the correct colors and number of lines shall be cause to fail the test.
      10. Pattern P12 is a 60 x 60 "checkerboard" array of black and white areas. The size of each black or white area is two source pixels square. Failure to display the pattern with uniform color and area size shall be cause to fail the test.
    3. For the DCI 2K Sync Test (48fps) composition (2K@48fps), locate and confirm the appearance of the features of the test image as described for the DCI 2K Sync Test composition, with the following exceptions:
      1. In the case where the MB provides image data to the projector via dual 1.5 Gb/s (or single 3 Gb/s) SDI link, [DCI-DCSS] , Section 2.1.1.4 allows chroma subsampling on 48 fps images ( i.e. 4:2:2). In this case, patch P5 of the 2K test image is expected to be displayed with chroma blending. Patch P3 may display chroma blending, depending on the coincidence of the 2X horizontal source pixels and the subsampling algorithm. Patch P6 is expected to be reproduced discretely, with no visible chroma blending. No blending shall be visible for any of the patches P7, P8, P10 and P11. The number of lines displayed in patterns P7 and P10 shall be thirty (30). The number of lines displayed in patterns P8 and P11 shall be sixty (60). Failure to display the correct number of lines in each of the panels P7, P8, P10 and P11 shall be cause to fail the test. Appearance of chroma blending deviating from the above shall be cause to fail the test.
  2. Verify that the decoder outputs 12-bit X′Y′Z′ color:
    1. To test for 12 bit color reproduction play back the composition DCI 2K Moving Gradient . This clip contains a special moving pattern to reveal usage of all 12 bits. The pattern contains three vertical bands, each 250 horizontal pixels in width, corresponding to 12, 11 and 10 bit representations of a sine wave that advances in value by 1 degree per pixel. The bands are labeled with the 12 bit region on the left, 11 bit region in the center and 10 bit region on the right of the screen. Examine the image for artifacts such as contouring or vertical striations. Any such noticeable artifacts in the 12 bit region of the pattern is cause to fail this test. The 11 and 10 bit regions are provided for reference.
  3. To test for X′Y′Z′ color reproduction: Using a DCI Projector , properly calibrated for Luminance and Color Calibration and a Spectroradiometer , perform the following steps:
    1. For each of the 12 Color Accuracy color patch code values referenced in [SMPTE-431-2] , Table A.4, display the given X′Y′Z′ code values. This may be achieved by displaying a suitable test file or by delivering the appropriate signal to an external interface ( e.g. Dual-Link HD-SDI). Measure and record the displayed Luminance and Color Coordinates for each of the Color Accuracy patches.
    2. Play back the composition Color Accuracy Series and measure and record the displayed Luminance and Color Coordinates for each of the Color Accuracy patches.
    3. For each of the the corresponding reference and decoded values recorded in steps i and ii, calculate the x and y delta values and record them.
    If any of the values recorded in step iii exceed the tolerances defined in [SMPTE-431-2] , Table A, Section 7.9 this is cause to fail this test.
  4. For 4K decoders, verify that it shall decode 4K data for every frame in a 4K distribution, or for 2K decoders, verify that it shall decode 2K data for every frame in a 4K distribution. To test this perform the following procedure:
    1. Play back the composition 2K DCI Maximum Bitrate Composition (Encrypted) , keyed with KDM for 2K Maximum Bitrate Composition (Encrypted) . This composition contains a codestream at the maximum allowable bitrate of an image with a burned in counter, incremented by one with every frame. The projected image must be filmed with a suitable camera and then be viewed in slow motion to verify that no counter numbers are skipped. Failure to observe all the numbered frames shall be cause to fail this test. Verify that the projected image contains a clearly visible, regular pattern that does not change over time (except for the burned in counter). If any other artifacts are noted ( e.g. flickering or similar) this is cause to fail this test.
    2. Play back the composition 4K DCI Maximum Bitrate Composition (Encrypted) , keyed with KDM for 4K Maximum Bitrate Composition (Encrypted) . This composition contains a codestream at the maximum allowable bitrate of an image with a burned in counter, incremented by one with every frame. The projected image must be filmed with a suitable camera and then be viewed in slow motion to verify that no counter numbers are skipped. Failure to observe all the numbered frames shall be cause to fail this test. Verify that the projected image contains a clearly visible, regular pattern that does not change over time (except for the burned in counter). If any other artifacts are noted ( e.g. flickering or similar) this is cause to fail this test.
Test pattern containing 12 distinct areas labeled P1 through P12
Figure 6.1 . Standard Frame Panel Designations 🔗
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —

6.6. Audio Reproduction 🔗

6.6.1. Digital Audio Interfaces 🔗
Objective
Verify that the Media Block has a digital audio output interface with the capacity for delivering 16 channels of digital audio at 24-bit 48 kHz or (optionally) 96 kHz, and follows the [AES3-2003] recommended practice for serial transmission format for two-channel linearly represented digital audio data.
Procedures
  1. Play the composition DCI 1-16 Numbered Channel Identification which contains spoken identification for each of the 16 audio channels and verify correct output. Failure to confirm correct reproduction on any channel is cause to fail this test.
  2. Play the composition DCI NIST Frame with Pink Noise which contains 16 channels of Pink Noise at 48kHz sample rate and verify:
    1. 48kHz AES3 signal at all outputs.
    2. Pink noise bandwidth to 22kHz.
    3. 24 active bits on analyzer.
      Failure to confirm above conditions a, b and c, is cause to fail this test.
  3. If the Test Subject supports playback of 96 kHz audio, play the composition DCI NIST Frame with Pink Noise (96 kHz) which contains 16 channels of Pink Noise at 96kHz sample rate and verify:
    1. 96kHz AES3 signal at all outputs.
    2. Pink noise bandwidth to 44kHz.
    3. 24 active bits on analyzer.
    Failure to confirm above conditions a, b and c, is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.6.2. Audio Sample Rate Conversion 🔗
Objective
If it supports playback of 96 kHz audio, verify that the Test Subject has the capability of performing Sample Rate Conversion (SRC) when needed.
Procedures
Only applies to a Test Subject that supports playback of 96 kHz audio.
  1. Play back the DCP DCI NIST Frame with 1 kHz tone (-20 dB fs, 96kHz) . Enable SRC on the system, select an output rate of 48kHz. With an AES analyzer, confirm that each of the AES-3 outputs are producing an AES signal with a 48kHz sample rate. Any other measured output sample rate is cause to fail this test.
  2. Play back the DCP DCI NIST Frame with 1 kHz tone (-20 dB fs) . Enable SRC on the system, select an output rate of 96kHz. With an AES analyzer, confirm that each of the AES-3 outputs are producing an AES signal with a 96kHz sample rate. Any other measured output sample rate is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.6.3. Audio Delay Setup 🔗
Objective
Verify that the system provides a method for adjusting the delay of the audio signal relative to the image. It must be possible to offset audio +/-200 ms in 10 ms increments.
Procedures
  1. Connect channel 1 of the oscilloscope to the analog center channel output of the sound equipment.
  2. Connect channel 2 of the oscilloscope to a photodiode that is placed in front of the screen of the Imaging Device, where the flashing rectangle is located.
  3. Perform the following steps:
    1. Play back the composition DCI 2K Sync Test . This composition contains short beeps (one frame in length) and a white flashing rectangle at the bottom of the screen, synchronized to the beeps.
    2. Measure the delay between the light pulse and the audio pulse. This will depend on a combination of many factors such as the image processing delay of the imaging device, sound processing delay in the sound equipment, and digital signal transmission delays (buffering of data). Record the timing with zero offset applied to the unit under test. Use this nominal figure as the reference point for the following steps.
    3. Set the offset to -200 ms and verify that the delay observed at the oscilloscope corresponds is consistent with the nominal figure minus 200 ms. Failure to meet this requirement is cause to fail this test.
    4. Set the offset to +200 ms and verify that the delay observed at the oscilloscope corresponds is consistent with the nominal figure plus 200 ms. Failure to meet this requirement is cause to fail this test.
    5. Set the offset to -190 ms and verify that the delay observed at the oscilloscope corresponds is consistent with the nominal figure minus 190 ms. Failure to meet this requirement is cause to fail this test.
    6. Set the offset to +190 ms and verify that the delay observed at the oscilloscope corresponds is consistent with the nominal figure plus 190 ms. Failure to meet this requirement is cause to fail this test.
    7. Set the offset to -10 ms and verify that the delay observed at the oscilloscope corresponds is consistent with the nominal figure minus 10 ms. Failure to meet this requirement is cause to fail this test.
    8. Set the offset to +10 ms and verify that the delay observed at the oscilloscope corresponds is consistent with the nominal figure plus 10 ms. Failure to meet this requirement is cause to fail this test.
  4. Repeat the above test, but this time for 48 fps (use the composition DCI 2K Sync Test (48fps) ). Record the results obtained.
The image below shows what a typical measurement is expected to look like. The upper trace shows the light output of the Imaging Device, measured by means of the photo diode. The photo diode signal is shown inverted, i.e. , low means high light output. The lower trace shows the analog center channel output of the Media Block after D/A conversion from the AES-EBU signal.
Oscilloscope screen displaying an upper trace that shows the light output of the Imaging Device and a lower trace that shows the analog center channel output of the Media Block after D/A conversion from the AES-EBU signal
Figure 6.2 . Audio Delay Timing 🔗
Warning: the optical flashes generated during this test can cause physiological reactions in some people. People who are sensitive to such optical stimuli should not view the test material.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.6.4. Click Free Splicing of Audio Track Files 🔗
Objective

Verify that the playback system allows click free splicing of the audio track files.

Note: Playback of this test must be done in a properly equipped and set up movie theater, at reference level, i.e. , fader setting 7.0 for Dolby and compatibles or fader setting 0 dB for Sony and compatibles. A single channel of pink noise at -20dBFS should produce a Sound Pressure Level (SPL) of 85dBc, from any of the front loudspeakers, at the monitoring position. Monitoring by means of smaller monitor boxes or headphones is not sufficient.

Procedures

Play back DCP for Audio Tone Multi-Reel (Encrypted) , which contains a sequence of audio track files arranged such that no discontinuity exists at the splice points.

Any audible snap, crackle, pop or other unpleasant artifact at any splice point shall be cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —

6.7. Timed Text Reproduction 🔗

6.7.1. Media Block Overlay 🔗
Objective
Verify that the Test Subject renders Timed Text essence correctly.
Procedures
  1. Using an Imaging Device that does not provide an internal subtitle rendering capability (or one in which subtitle rendering capability is disabled), load and play back each of the compositions:
    1. 2K Scope Subtitle Test (Encrypted) , keyed with KDM for 2K Scope Subtitle Test (Encrypted) .
    2. 2K Flat Subtitle Test (Encrypted) , keyed with KDM for 2K Flat Subtitle Test (Encrypted) .
    3. 2K Full Subtitle Test (Encrypted) , keyed with KDM for 2K Full Subtitle Test (Encrypted) .
    4. 4K Scope Subtitle Test (Encrypted) , keyed with KDM for 4K Scope Subtitle Test (Encrypted) .
    5. 4K Flat Subtitle Test (Encrypted) , keyed with KDM for 4K Flat Subtitle Test (Encrypted) .
    6. 4K Full Subtitle Test (Encrypted) , keyed with KDM for 4K Full Subtitle Test (Encrypted) .
    7. 2K 48fps Scope Subtitle Test (Encrypted) , keyed with KDM for 2K 48fps Scope Subtitle Test (Encrypted) .
    8. 2K 48fps Flat Subtitle Test (Encrypted) , keyed with KDM for 2K 48fps Flat Subtitle Test (Encrypted) .
    9. 2K 48fps Full Subtitle Test (Encrypted) , keyed with KDM for 2K 48fps Full Subtitle Test (Encrypted) .
  2. Refer to Appendix I. Subtitle Test Evaluation and Pass/Fail Criteria and for each scene in each composition, record the state of compliance with the basic and specific pass/fail criteria listed therein. Failure of any compliance criterion is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.7.2. Deleted Section 🔗

The section "Timed Text Synchronization" was deleted. The section number is maintained here to preserve the numbering of subsequent sections

6.7.3. Deleted Section 🔗

The section "Support for Multiple Captions" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

6.7.4. Default Timed Text Font 🔗
Objective

Only applies to a Test Subject that implements an alpha channel overlay module, a subpicture renderer (a module that converts the subpicture file into a baseband image file with an alpha channel) and a Timed Text renderer (a module that converts Timed Text data into a baseband image file with an alpha channel).

Verify that the Test Subject provides a default font to be used in the case where no font files are supplied with the DCP.

Procedures
  1. Load and play the composition DCI Malformed Test 8: DCP with timed text and a missing font .
  2. Verify that the timed text instances contain multiple lines of text.
  3. Failure to correctly display multiple lines of text shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
24.2. SDR Projector Test Sequence Pass/Fail —
6.7.5. Deleted Section 🔗

The section "Support for Subpicture Display" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

6.7.6. Timed Text Decryption 🔗
Objective
Verify that an SM can play a composition that contains encrypted timed text essence.
Procedures
  1. Load the composition DCI 2K Sync test with Subtitles (Encrypted) and KDM KDM for DCI 2K Sync Test with Subtitles (Encrypted) .
  2. Play the composition DCI 2K Sync test with Subtitles (Encrypted) .
  3. Verify that the timed text appears on screen as indicated by the main picture.
  4. Failure to correctly display multiple lines of text shall be cause to fail the test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —

6.8. OBAE Reproduction 🔗

6.8.1. Click Free Splicing of OBAE Track Files 🔗
Objective

Verify that the playback system allows click free splicing of OBAE track files.

Playback of this test must be done in a theatrical environment calibrated and setup for OBAE reproduction. Monitoring by means of smaller monitor boxes or headphones is not sufficient.

Procedures
  1. Setup the OBAE Sound System with the maximum number of rendered channels supported by the system.
  2. Play back DCP for OBAE Tone Multi-Reel (Encrypted) , which contains a sequence of OBAE Track Files arranged such that no discontinuity exists at the splice points.

Any audible snap, crackle, pop or other unpleasant artifact at any splice point shall be cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.8.2. OBAE Delay Setup 🔗
Objective
Verify that the system provides a method for adjusting the delay of rendered OBAE essence relative to the image. It must be possible to offset audio +/-200 ms in 10 ms increments.
Procedures
  1. Connect channel 1 of the oscilloscope to the analog center channel output of the sound equipment.
  2. Connect channel 2 of the oscilloscope to a photodiode that is placed in front of the screen of the Imaging Device, where the flashing rectangle is located.
  3. Perform the following steps:
    1. Play back the composition DCI 2K Sync Test (OBAE) . This composition contains short beeps (one frame in length) and a white flashing rectangle at the bottom of the screen, synchronized to the beeps.
    2. Measure the delay between the light pulse and the audio pulse. This will depend on a combination of many factors such as the image processing delay of the imaging device, sound processing delay in the sound equipment, and digital signal transmission delays (buffering of data). Record the timing with zero offset applied to the unit under test. Use this nominal figure as the reference point for the following steps.
    3. Set the offset to -200 ms and verify that the delay observed at the oscilloscope corresponds is consistent with the nominal figure minus 200 ms. Failure to meet this requirement is cause to fail this test.
    4. Set the offset to +200 ms and verify that the delay observed at the oscilloscope corresponds is consistent with the nominal figure plus 200 ms. Failure to meet this requirement is cause to fail this test.
    5. Set the offset to -190 ms and verify that the delay observed at the oscilloscope corresponds is consistent with the nominal figure minus 190 ms. Failure to meet this requirement is cause to fail this test.
    6. Set the offset to +190 ms and verify that the delay observed at the oscilloscope corresponds is consistent with the nominal figure plus 190 ms. Failure to meet this requirement is cause to fail this test.
    7. Set the offset to -10 ms and verify that the delay observed at the oscilloscope corresponds is consistent with the nominal figure minus 10 ms. Failure to meet this requirement is cause to fail this test.
    8. Set the offset to +10 ms and verify that the delay observed at the oscilloscope corresponds is consistent with the nominal figure plus 10 ms. Failure to meet this requirement is cause to fail this test.
  4. Repeat the above test, but this time for 48 fps (use the composition DCI 2K Sync Test (48fps) ). Record the results obtained.

Figure 6.2 shows what a typical measurement is expected to look like. The upper trace shows the light output of the Imaging Device, measured by means of the photo diode. The photo diode signal is shown inverted, i.e. , low means high light output. The lower trace shows the analog center channel output.

The optical flashes generated during this test can cause physiological reactions in some people. People who are sensitive to such optical stimuli should not view the test material.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.8.3. Maximum Bitrate OBAE 🔗
Objective

Verify that the playback system supports playback of OBAE content that consists of maximum size frames, as defined in [SMPTE-429-18] .

Procedures
Perform the following steps:
  1. Select and play Maximum Bitrate OBAE (Encrypted) keyed with KDM for Maximum Bitrate OBAE (Encrypted) .
  2. Select and play Maximum Bitrate OBAE 48 fps (Encrypted) keyed with KDM for Maximum Bitrate OBAE 48 fps (Encrypted) .
Any audible artifact, interruption in playback or inability to start playback is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
6.8.4. OBAE Rendering Expectations 🔗
Objective

Verify that the OBAE Sound System meets acoustic rendering expectations.

Procedures
Perform the following steps:
  1. Configure the OBAE Sound System according to J.2. Configuration .
  2. Playback OBAE Rendering Expectations in its entirety, subject to the requirements specified at J.3. Requirements . Deviation from any of these requirements is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —

Chapter 7. Imaging Device 🔗

7.1. Test Environment for Image Measurements 🔗

7.1.1 General 🔗

When making image measurements on any Imaging Device:

  • All required setup and calibration procedures, as recommended by the manufacturer, shall be carried out or verified prior to all measurements.

  • Stray light on the screen shall be minimized. The room lights in test environment shall be turned off, with the exception of the minimal lighting provided for working or safety reasons. The use of black nonreflective surfaces with recessed lighting is encouraged.

    Note that, outside of the Test Environment, e.g. in exhibition theaters or review rooms, safety regulations and the placement of exit lights or access lights can result in a higher ambient light level.

  • Unless otherwise specified or required:
    • the distance between the front of the Spectroradiometer lens and the screen shall be equal to 1.6 times the height of the screen; and
    • the position of the Spectroradiometer shall be equidistant from the left and right edges of the screen.
    • the position of the Spectroradiometer shall be equidistant from the top and bottom edges of the screen.
    In all cases the location of the Spectroradiometer shall be appropriate for the Spectroradiometer that is used and for the test being conducted.

7.1.2 Projector 🔗

With the Projector turned off or the douser closed, the level of ambient light reflected by the screen shall be:

  • less than 0.01 cd/m² for an SDR Projector; and
  • less than 0.0005 cd/m² for an HDR Projector.

The screen shall be non-specular and equally reflective over the entire visible spectrum. The screen should have variable black masking, adjustable to tightly frame the projected image (at a minimum, this should include the 1.85:1 and 2.39:1 image formats).

When making image measurements on a Projector:

  • The Projector shall be turned on (including the lamp) and allowed to thermally stabilize for 20 to 30 minutes prior to all measurements.
  • Unless specified otherwise, the douser shall be open from beginning to end of each test procedure.

7.5.13. Projector Test Environment records information about the test environment in which projector test procedures were conducted.

7.1.3 Direct View Display 🔗

With the Direct View Display turned off, the level of ambient light reflected by the screen shall be less than 0.0005 cd/m².

The Direct View Display shall be turned on and allowed to thermally stabilize for 20 to 30 minutes prior to all measurements.

7.5.30. Direct View Display Test Environment records information about the test environment in which the test procedures were conducted.

7.1.4 Stereoscopic Measurements 🔗

When performing stereoscopic measurements:

  • The Imaging Device shall be enabled for stereoscopic presentations.
  • The stereoscopic glasses shall be enabled, if they are active glasses.

7.2. SPB Type 2 🔗

7.2.1. Projector and Direct View Display Physical Protection 🔗
Objective
  • Verify that the projector's or direct view display's companion SPB (MB) and its plaintext image interfaces are physically inside of, or otherwise mechanically connected to, the type 2 SPB.
  • Verify that SPB type 2 protection requirements are provided by the Projector or Direct View SPB.
Procedures
  • If the Test Subject is a Projector:
    1. By physical examination and using documentation provided by the manufacturer, determine the physical perimeter that provides the type 2 SPB protection for the Projector. Verify that the type 2 SPB provides a hard, opaque physical security perimeter that surrounds the electronics and prevents access to internal circuitry.
      Failure of this verification is cause to fail this test.
  • If the Test Subject is a Projector or a Direct View Display:
    By physical examination and using documentation provided by the manufacturer:
    1. Locate, and for each of any removable access covers and/or doors of the type 2 SPB intended for Security Servicing ( i.e. , openings that enable access to Security-Sensitive Signals), record whether they are protected by either (1) mechanical locks employing physical or logical keys and tamper-evident seals ( e.g. , evidence tape or holographic seals), or (2) pick resistant locks employing physical or logical keys.
      The absence of protection as required on any of these security access covers or doors is cause to fail this test.
    2. Locate the companion SPB's and type 2 SPB's Security Sensitive Signals. Verify that:
      1. Security Sensitive Signals are not accessible via (i) any removable access covers and/or doors other than those located in step 2, (ii) any ventilation holes or other openings; and
      2. Access to Security Sensitive Signals and circuits would cause permanent and easily visible damage. Failure of either of these verifications is cause to fail this test.
    3. Locate the Companion SPB (MB). Verify that the Companion SPB is entirely enclosed within, or mechanically connected to, the SPB type 2 enclosure.
      Failure to meet this requirement is cause to fail this test.
  • If the Test Subject is a Direct View Display:
    1. By physical examination and using documentation provided by the manufacturer, verify that:
      1. The physical intrusion barrier presented by the light emitting front surface of the Direct View Display's Cabinets or Modules is not penetrate-able without permanently destroying the proper operation of a Cabinet and/or Module penetrated, and leaving permanent and easily visible damage.
      2. Cabinets and/or Modules are mechanically interlocked to each other directly and/or via the supporting frame structure such that any separation that would enable access to internal signals causes permanent and easily visible damage.
      3. Access to light emitting (pixel generating) component electrical signals from the surface of the screen is limited to individual component pins, and there is no access to signals that would constitute a portion of the picture image beyond the pixel by pixel level.
    Failure to meet any of these requirements is cause to fail this test.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.2.2. Projector and Direct View Display Security Servicing 🔗
Objective
  • Verify that the projector or direct view display SPB implements a "security access opening" event signal to the companion SPB.
  • Verify that playback terminates and/or is not permitted if the security access opening event is active, or a front removable module has been removed.
Procedures
  • If the Test Subject is a Projector or Direct View Display:
    By physical examination and using documentation provided by the manufacturer, locate each of the type 2 SPB access door and/or panel openings intended for Security Servicing ( i.e. , openings that enable access to Security- Sensitive Signals). Execute the following tests 1-4 for each opening found, and record the results.
    1. Play back the DCP DCI 2K StEM .
    2. Open the SPB access door/panel and observe that playback terminates. If playback does not terminate, this is cause to fail this test.
    3. Attempt to start playback with the door/panel open. If playback starts, this is cause to fail this test.
    4. Close the opening and examine the logs from the SPB's companion SPB and verify that an "SPBOpen" event was created for each time a door/panel was opened, and an "SPBClose" event was created for each closure. If any log record is missing, this is cause to fail this test.
  • If the Test Subject is a Direct View Display:
    With the exception of step 6(c), the following tests may be verified by physical examination of the direct view display's type 2 SPB and using documentation provided by the manufacturer:
    1. Noting the servicing method exception defined for step 6 below: Identify and document each distinct method that can be used for replacing (disassembly and reassembly, etc.) a Cabinet or Module. For each method that exposes Security-Sensitive Signals, verify that:
      1. a security access opening event is triggered, and
      2. playback is prevented while the security access opening event is active.
        Failure of either of the above requirements is cause to fail this test. (It is allowed for one security access opening event to be triggered in the course of simultaneously replacing multiple Cabinets and/or Modules as part of a single servicing event.)
    2. For Cabinets having front removable Modules designed for non-security servicing ( i.e. , designed for Module replacement without triggering a security access opening event), verify that the removal of any front-serviceable Module:
      1. exposes only those pixel signals accessible via the electrical connection(s) associated with the Module removed and does not otherwise expose Security-Sensitive Signals or compromise the SPB type 2 perimeter. Note that signaling multiplexing may have a multiplier effect that exposes signals associated with other Modules via the connection(s); this is allowed, but must be considered in step (c) below. Display Security Servicing
        Failure to meet this requirement is cause to fail this test.
      2. is detected and prevents playback of an encrypted composition.
        Failure to meet this requirement is cause to fail this test.
      3. Quantity over 15 ( i.e. , removal of more than 15 modules), or a quantity that exposes pixel signals constituting more than 5% of the screen area, whichever is less within any 8 hour period, shall trigger a security access opening event.
        To execute this step:
        1. calculate the minimum number of Modules required to expose pixel signals constituting more than 5% of the screen area, considering the multiplier effect noted in (a). If the number is less than 16, record this number as MaxNumber, otherwise set MaxNumber to 16.
        2. determine a Module removal selection sequence for removing a quantity of (MaxNumber + 1) of Modules which are most likely to stress the Imaging Device's opening detection design.
        3. Recording a test start time as "T0", begin removing and replacing Modules in the sequence order determined in step (ii) until an access opening event has been triggered, or 16 Modules have been removed and replaced. Record this quantity.
        4. Following the manufacturers requirements, clear (reset) the access opening event. After 7 hours and 55 minutes from T0 of step (iii), remove and replace the next Module in sequence. Verify that a security access opening event has been triggered.
        A quantity recorded in step (iii) of not less than MaxNumber is cause to fail this test. Failure of a security access opening event to trigger for step (iv) is cause to fail this test.
    3. For each occurrence of a security access opening event of tests 4, 5 and 6, verify that:
      1. clearing (resetting) of the alarm event requires the use of a physical key or entry of a code,
      2. SPBOpen and SPBClose events are logged for each occurrence.
      Failure of either of the above requirements is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
24.4. SDR Projector Confidence Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
26.4. HDR Direct View Display Confidence Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
27.4. SDR Direct View Display Confidence Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
28.4. HDR Projector Confidence Sequence Pass/Fail —
7.2.3. Deleted Section 🔗

The section "SPB2 Requirements" was deleted. The section number is maintained here to preserve the numbering of subsequent sections

7.2.4. Deleted Section 🔗

The section "SPB2 Secure Silicon Requirements" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.2.5. Deleted Section 🔗

The section "SPB2 Tamper Evidence" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.2.6. SPB2 Secure Silicon Field Replacement 🔗
Objective
Verify that the secure silicon device, contained within a SPB Type 2, is not field serviceable (though it may be field replaceable). Verify that it is not accessible during normal SPB Type 2 operation or non-security-related servicing.
Procedures
By careful optical and physical examination, verify that the secure silicon device contained within a SPB Type 2
  1. is not field serviceable (but may be field replaceable), i.e. , there are no provisions for direct access to the SPB Type 2 secure silicon circuitry.
  2. is not accessible during normal SPB Type 2 operation or non-security-related servicing, i.e. , is mounted in a special compartment separated from areas accessible during operations or normal servicing. If the SPB2 secure silicon device is accessible during non-security servicing or normal operations, this shall be cause to fail this test.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.2.7. Systems without Electronic Marriage 🔗
Objective
Verify that in the configuration of a permanently married companion SPB (MB), the companion SPB is not field replaceable and requires the Imaging Device SPB and companion SPB system to both be replaced in the event of an SPB failure.
Procedures
Verify that the companion SPB Type 1 is not field- replaceable. Careful optical and physical inspection is necessary for this. Any deviation from these requirements is cause to fail this test.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.2.8. Electronic Marriage Break Key Retaining 🔗
Objective
Verify that breaking the marriage between the Imaging Device and its companion SPB (MB) does not zeroize the Imaging Device SPB type 2 long term identity keys (RSA private keys).
Procedures
(Only applies to systems that implement an Electronic Marriage, i.e. , those that have field replaceable MBs.)
  1. Using procedures and tools provided by the manufacturer of the Imaging Device, obtain the device certificate representing the identity of the SPB type 2 in PEM encoded format.
  2. Using the procedure illustrated in Section 2.1.11 , record the public key thumbprint of the certificate obtained in the above step.
  3. Intentionally break the marriage and remarry the systems (this may require support by the manufacturer).
  4. Using the same procedure as described in steps 1 and 2, verify that the public key in the certificate supplied by the Imaging Device is the same as before the remarriage. Mismatching public key thumbprints are cause to fail this test.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —

7.3. Companion SPB Type 1 🔗

7.3.1. Deleted Section 🔗

The section "Projector Companion SPB Location" was deleted. The section number is maintained here to preserve the numbering of subsequent sections

7.3.2. Companion SPBs with Electronic Marriage 🔗
Objective
This test only applies to field replaceable companion SPBs (MB) that implement electronic marriage functions.
  • Verify that as part of the installation, or reinstallation, ( i.e. , mechanical connection to the Imaging Device and electrical initiation) an electrical and logical marriage of the companion SPB (MB) with the Imaging Device SPB is performed.
  • Verify that upon initiation of the marriage a "SPBMarriage" log record is written (per [SMPTE-430-5] ) and that the record contains all required data.
  • Verify that upon break of the marriage a "SPBDivorce" log record is written (per [SMPTE-430-5] ) and that the record contains all required data.
Procedures
  1. Verify system is functional prior to breaking the marriage. This can be achieved by loading and successfully playing the composition DCI 2K Sync Test (Encrypted) .
  2. Power down the system, locate the field-replaceable companion SPB (MB), break the marriage by disconnecting and/or removing the SPB.
  3. Replace and reconnect the companion SPB, power up the system, examine the logs and verify that a "SPBDivorce" log record has been written. Absence of this entry is cause to fail this test.
  4. Verify the following are contained in the SPBDivorce record:
    1. The DeviceSourceID element contains the Certificate Thumbprint of the companion SPB.
    2. The DeviceConnectedID element contains the Certificate Thumbprint of the Imaging Device SPB2.
    3. The log entry contains an AuthId record.
    Failure to meet requirements a, b and c above is cause to fail this test.
  5. Setup a show with composition from Step 1. Verify that the system does not play the composition. Failure to meet this requirement is cause to fail this test.
  6. Perform the marriage installation procedure and repeat Step 1 to verify that the system is now capable of playout. Failure to meet this requirement is cause to fail this test.
  7. Examine the logs and verify that a "SPBMarriage" log entry has been written. Absence of this entry is cause to fail this test.
  8. Verify the following are contained in the SPBMarriage record:
    1. The DeviceSourceID element contains the Certificate Thumbprint of the companion SPB.
    2. The DeviceConnectedID element contains the Certificate Thumbprint of the Imaging Device SPB2.
    3. The log entry contains an AuthId record.
      Failure to meet requirements a, b and c above is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
7.3.3. Companion SPB Marriage Break Key Retaining 🔗
Objective
Verify that breaking the marriage between the Media Block (MB) companion SPB (Type 1) and the Imaging Device SPB (type 2) does not zeroize the MB's long term identity keys (RSA private keys).
Procedures

This section only applies to systems that implement an Electronic Marriage, i.e. , those that have field replaceable companion MBs.

In the case of an MB that is married to an Imaging Device SPB and implements dual certificates as defined in Section 9.5.1.2 of [DCI-DCSS] :
  1. Set up and play a show using the composition DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) .
  2. Extract a signed [SMPTE-430-5] security log report from the Test Subject that includes the range of time during which the above step was carried out.
  3. Using the procedures illustrated in Section 3.1.3 , use the checksig program to verify the signature of the log report collected in step 2. Note: Depending on the order of the certificates contained in the log report, the dsig_cert.py program may need to be used to re-order the certificates for the checksig program.
  4. Using the procedures illustrated in Section 3.1.3.1 , extract the certificates in the signing chain of the log report collected in step 2. Note: This may be accomplished using the dsig_extract.py program.
  5. Using the procedures illustrated in Section C.2 , use the dc-thumbprint program to calculate the thumbprint of the Log Signer Certificate that signed the log report collected in step 2. Record the value of the calculated thumbprint.
  6. Intentionally break the marriage and remarry the companion SPB and the Imaging Device SPB (this may require support by the manufacturer).
  7. Repeat steps 1 and 2 using the same composition and KDM as before. Failure to successfully play content or retrieve a log report after remarriage is cause to fail this test.
  8. Repeat step 3 using the log report collected after remarriage. Failure to successfully verify the signature is cause to fail this test.
  9. Repeat steps 4 and 5 using the log report collected after remarriage. Confirm that the Log Signer Certificate public key thumbprint calculated after remarriage matches the one from step 5. Mismatching Log Signer Certificate public key thumbprints are cause to fail this test.
In the case of an MB that is married to a Imaging Device SPB and implements a single certificate as defined in Section 9.5.1.1 of [DCI-DCSS] :
  1. Set up and play a show using the composition DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) .
  2. Extract a signed [SMPTE-430-5] security log report from the Test Subject that includes the range of time during which the above step was carried out.
  3. Using the procedures illustrated in Section 3.1.3 , use the checksig program to verify the signature of the log report collected in step 2. Note: Depending on the order of the certificates contained in the log report, the dsig_cert.py program may need to be used to re-order the certificates for the checksig program.
  4. Using the procedures illustrated in Section 3.1.3.1 , extract the certificates in the signing chain of the log report collected in step 2. Note: This may be accomplished using the dsig_extract.py program.
  5. Using the procedures illustrated in Section C.2 , use the dc-thumbprint program to calculate the thumbprint of the certificate that signed the log report collected in step 2. Record the value of the calculated thumbprint.
  6. Intentionally break the marriage and remarry the companion SPB and the Imaging Device SPB (this may require support by the manufacturer).
  7. Repeat steps 1 and 2 using the same composition and KDM as before. Failure to successfully play content or retrieve a log report after remarriage is cause to fail this test.
  8. Repeat step 3 using the log report collected after remarriage. Failure to successfully verify the signature is cause to fail this test.
  9. Repeat steps 4 and 5 using the log report collected after remarriage. Confirm that the certificate thumbprint calculated after remarriage matches the one from step 5. Mismatching public key thumbprints are cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
7.3.4. Deleted Section 🔗

The section "Remote SPB Clock Adjustment" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.4. Link Decryptor Block 🔗

7.4.1. Deleted Section 🔗

The section "LDB without Electronic Marriage" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.4.2. Deleted Section 🔗

The section "LDB TLS Session Constraints" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.4.3. Deleted Section 🔗

The section "LDB Time-Awareness" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.4.4. Deleted Section 🔗

The section "LDB ASM Conformity" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.4.5. Deleted Section 🔗

The section "LDB Key Storage" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.4.6. Deleted Section 🔗

The section "LDB Key Purging" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.4.7. Deleted Section 🔗

The section "LDB Logging" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.5. Image Reproduction 🔗

7.5.1. Deleted Section 🔗

The section "Projector Overlay" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.5.2. Deleted Section 🔗

The section "Projector Lens" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.5.3. Imaging Device Pixel Count/Structure 🔗
Objective
Verify that the sampling structure of the displayed picture array (pixel count of the imaging device) is equal that of the respective specified image containers (either 4096 x 2160 or 2048 x 1080).
Procedures
Note: Prior to performing the following procedures, it is necessary to verify that any electronic rescaling of the image is fully disabled. This may include turning off resizing, keystone correction, filters and/or other related processes.
  • For 2K Projectors: Display the test composition Pixel Structure Pattern S 2k Verify that the complete set of 16x16 and 8x8 pixel blocks is displayed.
  • For 4K Projectors and Direct View Displays: Display the test pattern Pixel Structure Pattern S 4k . Verify that the complete set of 16x16 pixel blocks is displayed.
Deviation from the expected image is cause to fail this test. The figures below illustrate the features of the pixel array test pattern. The 2k pattern consists of a 128 x 67 grid of 16 x 16 pixel blocks as illustrated in Figure 7.1 . A single-pixel white border surrounds the pattern. Each 16 x 16 block contains a horizontal and vertical location index encoded as a 8-bit binary ladder, with the MSb being at the top or left side of the vertical and horizontal ladders, respectively. The example below shows a block with index X =81, Y = 37 . The pixel at location 0,0 in the block is located at pixel x = 1296 = X * 16, y = 592 = Y * 16 on the screen. The bottom 8 pixels of the 2k pattern consist of similar, un-indexed 8 x 8 patterns as illustrated in Figure 7.2 .

The 4k pattern consists of a 256 x 135 grid of 16 x 16 pixel arrays. A single-pixel white border surrounds the pattern.

Within each block, color-coded bands mark pixel positions. The bands may have North, South, East or West orientation (the example blocks have South orientation). Pixel positions are coded left to right (top to bottom for East and West orientations) with the following color sequence: brown, red, orange, yellow, green, blue, violet, gray.

Note: North, South, East and West orientations are provided in the test materials set to support investigation of anomalies.

16⨯16 pixel block that contains color-coded bands to mark pixel positions and horizontal and vertical location index encoded as a 8-bit binary ladder
Figure 7.1 . Pixel Structure 16 x 16 Array 🔗
8⨯8 pixel block that color-coded bands to mark pixel positions
Figure 7.2 . Pixel Structure 8 x 8 Array 🔗
Warning: the patterns displayed during this test can cause vertigo in some people. People who are sensitive to such optical stimuli should not view the test material.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
24.4. SDR Projector Confidence Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
26.4. HDR Direct View Display Confidence Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
27.4. SDR Direct View Display Confidence Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
28.4. HDR Projector Confidence Sequence Pass/Fail —
7.5.4. Deleted Section 🔗

The section "Projector Spatial Resolution and Frame Rate Conversion" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.5.5. Deleted Section 🔗

The section "White Point Luminance and Uniformity" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.5.6. Deleted Section 🔗

The section "White Point Chromaticity and Uniformity" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.5.7. Deleted Section 🔗

The section "Sequential Contrast" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

7.5.8. SDR Intra-frame Contrast 🔗
Objective
Verify that the Imaging Device maintains white and black luminance when a non-uniform picture is presented.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Display the checkerboard test pattern Intra-Frame Contrast Sequence .
  3. Measure L WL , L WR , L KL and L KR according to:
    • the checkerboard luminance & contrast (n×m) procedure at [ICDM IDMS] , if the Test Subject is a Direct View Display; or
    • the checkerboard contrast ratio procedure at [ICDM IDMS] , if the Test Subject is a Projector; or
  4. Verify that:
    • if the Test Subject is a Direct View Display, L WL and L WR are each equal to 48.0 ± 3.5 cd/m², and L KL and L KR are each within the range [0.01, 0.024] cd/m²; or
    • if the Test Subject is a Projector, L WL and L WR are each equal to 48.0 ± 3.5 cd/m², and L KL and L KR each do not exceed 0.52 cd/m².

Any verification that fails is cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.5.9. Grayscale Tracking 🔗
Objective
Using the black-to-white gray and the black-to-dark gray step-scale test patterns, verify that the entire step-scale appears neutral without any visible color non-uniformity or non-monotonic luminance steps in the test pattern.
Procedures
Note: Prior to taking measurements, ensure that the test environment requirements detailed in Section 7.1 have been performed.
  1. Power-down the Test Subject. Alternatively, the douser can be closed if the Test Subject is a Projector.
  2. Use a Spectroradiometer to measure and record the Luminance of the ambient light reflected from the screen.
  3. Power-up the Test Subject. Alternatively, the douser can be open if the Test Subject is a Projector.
  4. Display no image or display black code values, and, using a Spectroradiometer , measure and record the Luminance of the light reflected from the screen.
  5. Play back the DCP DCI White Steps (black-to-white gray step-scale test pattern).
  6. For each of the ten steps of the pattern listed in Table A-2 of [SMPTE-431-2] , measure and record the Output Luminance and Chromaticity Coordinates with a Spectroradiometer .
  7. The entire step-scale should appear neutral without any visible color non-uniformity or non-monotonic luminance steps in the test pattern. Record the presence of any perceived deviation from a neutral scale.
  8. Play back the DCP DCI Gray Steps (black-to-dark gray step-scale test pattern).
  9. For each of the ten steps of the pattern listed in Table A-3 of [SMPTE-431-2] , measure and record the Luminance and Chromaticity Coordinates with a Spectroradiometer .
  10. The entire step-scale should appear neutral without any visible color non-uniformity or non-monotonic luminance steps in the test pattern. Record the presence of any perceived deviation from a neutral scale.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Data only —
26.2. HDR Direct View Display Test Sequence Data only —
27.2. SDR Direct View Display Test Sequence Data only —
28.2. HDR Projector Test Sequence Data only —
7.5.10. SDR Contouring 🔗
Objective
Confirm the Imaging Device exhibits no visible contouring when presenting an SDR composition.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Play back SDR Dark Gray Scale and measure, using a a Spectroradiometer , the luminance L i at the center of the screen of each full-screen gray patch.
  3. Calculate the set of second approximate derivatives from the set of measurements { L i } according to the slope monotonicity of gray scale procedure at [ICDM IDMS] .
  4. Verify that all the second approximate derivatives are greater than 0.

Any verification that fails is cause to fail this test.

Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.5.11. SDR Transfer Function 🔗
Objective
Verify that the correct SDR transfer function is used by the imaging device.
Procedures
Note: Prior to taking measurements, ensure that the setup and test environment requirements detailed in Section 7.1 have been performed.
  1. Display 2K Full SDR Black and, using a Spectroradiometer , measure the output luminance to a precision of 1 mcd/m², and record the result as the screen black level .
  2. Play back the DCP DCI White Steps .
  3. For each of the ten steps of the pattern listed in Table A-2 of [SMPTE-431-2] , measure the output luminance with a Spectroradiometer , subtract the screen black level obtained in step (1), and verify that the result is within the tolerance specified in Table 7.5 .
  4. Play back the DCP DCI Gray Steps .
  5. For each of the ten steps of the pattern listed in Table A-3 of [SMPTE-431-2] , measure the output luminance with a Spectroradiometer , subtract the screen black level obtained in step (1), and verify that the result is within the tolerance specified in Table 7.5 .

Any verification that fails is cause to fail this test.

Table 7.5 .11(a) Black-to-white gray step-scale test pattern nominal luminance values 🔗
Step Number Nominal Luminance above the Screen Black Level (cd/m²) Tolerance
1 0.121 ±5%
2 0.731 ±5%
3 2.098 ±3%
4 4.432 ±3%
5 7.917 ±3%
6 12.718 ±3%
7 18.988 ±3%
8 26.870 ±3%
9 36.497 ±3%
10 47.999 ±3%
Table 7.5 .11(b) Black-to-dark gray step-scale test pattern nominal luminance values 🔗
Step Number Nominal Luminance above the Screen Black Level (cd/m²) Tolerance
1 0.006 ±20%
2 0.038 ±5%
3 0.111 ±5%
4 0.234 ±5%
5 0.418 ±5%
6 0.670 ±5%
7 1.002 ±3%
8 1.418 ±3%
9 1.928 ±3%
10 2.531 ±3%
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.5.12. SDR Color Accuracy 🔗
Objective
Verify that all colors are accurately reproduced within the tolerances as specified in [SMPTE-431-2] .
Procedures
  1. Setup the Imaging Device and test environment according to 7.1. Test Environment for Image Measurements .
  2. Using Color Accuracy Series , measure and record the luminance and chromaticity coordinates for the following patches, according to the full-screen arbitrary color (R, G, B) procedure at [ICDM IDMS] :
    • Red-1
    • Green-1
    • Blue-1
  3. Verify that the measured chromaticity coordinates for each of the patches are equal to the Red , Green and Blue reference values for Color Accuracy that are specified at [SMPTE-431-2] , Table A.1, within review room tolerances.
  4. Verify that the measured luminance for each of the patches is ±3% of the Output Luminance values specified at [SMPTE-431-2] , Table A.4.

Any measurement outside of specified tolerances is caused to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.5.13. Projector Test Environment 🔗
Objective
Record information about the test environment in which the reported projector measurements were made.
Procedures
  1. Record the distance between the front of the projector lens and the center of the screen.
  2. Record the approximate vertical angle of incidence of the front of the projector lens to the center of the screen.
  3. Record the approximate horizontal angle of incidence of the front of the projector lens to the center of the screen.
  4. Record the distance between the front of the Spectroradiometer lens and the center of the screen.
  5. Record the approximate vertical angle of incidence of the front of the Spectroradiometer lens to the center of the screen.
  6. Record the approximate horizontal angle of incidence of the front of the Spectroradiometer lens to the center of the screen.
  7. Record the size of the screen.
  8. Record the approximate gain of the screen.
  9. Record the perforation configuration of the screen.
  10. With the projector lamp switched off (or doused), record the luminance at the center of the screen in units of Cd/m 2.
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail All data recorded per the test procedure
28.2. HDR Projector Test Sequence Pass/Fail All data recorded per the test procedure
7.5.14. HDR White Luminance and Chromaticity 🔗
Objective
Verify that the luminance and chromaticity of HDR white are within tolerances:
  • at the center of the Imaging Device; and
  • at the edges of the Imaging Device.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Display the white frame of HDR Sequential Contrast and Uniformity Sequence .
  3. Measure the luminance and chromaticity coordinates according to the full-screen arbitrary color (R, G, B) procedure at [ICDM IDMS] .
  4. Verify that the measured luminance and chromaticity coordinates are within the center luminance and center chromaticity tolerances, respectively, specified for specified at Table 7.5 for the Test Subject. Any measurement outside of the specified tolerances is caused to fail this test.
  5. Measure the luminance nonuniformity 𝒩 and maximum chromaticity difference Δ u ′ v ′ according to the sampled vantage-point uniformity procedure at [ICDM IDMS] .
  6. Verify that 𝒩 and Δ u ′ v ′ do not exceed their respective maximum values specified at Table 7.5 for the Test Subject.

Any verification that fails is cause to fail this test.

Table 7.5 .14(a) HDR White (Peak) 🔗
Parameter Test Subject
Projector Direct View Display
Center luminance (cd/m²) 299.6 ± 18 299.6 ± 9
Center chrominance ( x , y ) (0.3127 ± 0.002, 0.3290 ± 0.002)
Table 7.5 .14(b) HDR White (Angular Nonuniformity) 🔗
Parameter Test Subject
Projector Direct View Display
Maximum 𝒩 15% 6%
Maximum Δ u ′ v ′ 0.0182
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.5.15. SDR White Luminance and Chromaticity 🔗
Objective
Verify that the luminance and chromaticity of SDR white are within tolerances:
  • at the center of the Imaging Device; and
  • at the edges of the Imaging Device.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed. For the remainder of this test procedure, the Spectroradiometer shall be positioned as specified at 7.1.1 General , disregarding positioning recommendations made at [ICDM IDMS] .
  2. Display the white frame of Sequential Contrast and Uniformity Sequence .
  3. Measure the luminance and chromaticity coordinates according to the full-screen arbitrary color (R, G, B) procedure at [ICDM IDMS] .
  4. Verify that the measured luminance and chromaticity coordinates are within the center luminance and center chromaticity tolerances, respectively, specified for specified at Table 7.5 for the Test Subject. Any measurement outside of the specified tolerances is caused to fail this test.
  5. Measure the luminance nonuniformity 𝒩 and maximum chromaticity difference Δ u ′ v ′ according to the sampled vantage-point uniformity procedure at [ICDM IDMS] .
  6. Verify that 𝒩 and Δ u ′ v ′ do not exceed their respective maximum values specified at Table 7.5 for the Test Subject.

Any verification that fails is cause to fail this test.

Table 7.5 .15(a) SDR White (Peak) 🔗
Parameter Test Subject
Projector Direct View Display
Center luminance (cd/m²) 48.0 ± 3.5
Center chrominance ( x , y ) (0.314 ± 0.002, 0.351 ± 0.002)
Table 7.5 .15(b) SDR White (Angular Nonuniformity) 🔗
Parameter Test Subject
Projector Direct View Display
Maximum 𝒩 20% 6%
Maximum Δ u ′ v ′ 0.0171
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.5.16. HDR Color Luminance and Chromaticity 🔗
Objective
Confirm that HDR color reproduction, as measured at the center of the Imaging Device, is within tolerances.
Procedures
  1. Setup the Imaging Device and test environment according to 7.1. Test Environment for Image Measurements .
  2. Using HDR Color Accuracy Series , measure and record the luminance and chromaticity coordinates for the following Patch Code Values, according to the full-screen arbitrary color (R, G, B) procedure at [ICDM IDMS] :
    • Red-1
    • Green-1
    • Blue-1
  3. Verify that the measured chromaticity coordinates for Red-1 , Green-1 and Blue-1 are equal to the reference values for Color Accuracy that are specified at [DCI-HDR] , within the review room tolerances corresponding to the Test Subject.
  4. Verify that the measured luminance for Red-1 , Green-1 and Blue-1 are within the tolerances specified at Table 7.5 .

Any measurement outside of specified tolerances is caused to fail this test.

Table 7.5 .16 Target HDR color luminances and chromaticities 🔗
Patch Nominal values (cd/m²) Tolerances
Projector Direct View Display
Red-1 68.13 ±6% ±3%
Green-1 207.35
Blue-1 23.86
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.5.17. HDR Minimum Active Black Level 🔗
Objective
Confirm that the minimum active black level as measured in the center of the Imaging Device is within tolerances.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Display the black frame of HDR Sequential Contrast and Uniformity Sequence .
  3. Measure the luminance according to the full-screen black procedure at [ICDM IDMS] .
  4. Verify that each measured luminance is equal to the nominal value for Minimum Active Black Level specified at [DCI-HDR] , within the review room tolerances corresponding to the Test Subject. Any measurement outside of the specified tolerances is caused to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.5.18. SDR Inactive Black Level (Direct View Display) 🔗
Objective
  1. Verify that pixels outside the decoded image area are not emitting any light.
  2. Verify that pixels outside the area specified by the MainPictureActiveArea item of the CPL metadata are not emitting any light.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. For each of the following test materials, display the material and verify by visual inspection that: (a) registration marks are visible and (b) pixels outside the rectangular area delineated by the registration marks are not emitting any light: Any verification that fails is cause to fail this test.
  3. For each of the following test materials, display the material and verify by visual inspection that: (a) registration marks are visible and (b) no red pixels are visible: Any verification that fails is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
7.5.19. Horizontal and Vertical Full Screen Off-Axis Uniformity (Direct View Display) 🔗
Objective
Verify the full screen off-axis uniformity performance of the Imaging Device.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Display the white frame from Sequential Contrast and Uniformity Sequence and, for each of the angular positions specified in Table 7.1 :
    • measure the luminance change ratio according to the viewing-angle luminance change ratio procedure at [ICDM IDMS] .
    • measure the viewing-angle color variation according to the viewing-angle color variation procedure at [ICDM IDMS] .
  3. Verify that each of the measured luminance change ratio and viewing-angle color variation satisfy the tolerance specified at Table 7.1 .

Any verification that fails is cause to fail this test.

Table 7.1 . Measurement positions and tolerances for horizontal and vertical full screen off-axis performance measurements 🔗
Angular positions Luminance change ratio tolerance Viewing-angle color variation tolerance
+10° vertically (up) Full Screen Vertical Off-Axis Luminance Uniformity at [DV-ADD] Full Screen Vertical Off-Axis White Chromaticity Uniformity at [DV-ADD]
-35° vertically (down)
-60° horizontally (left) Full Screen Horizontal Off-Axis Luminance Uniformity at [DV-ADD] Full Screen Horizontal Off-Axis White Chromaticity Uniformity at [DV-ADD]
+60° horizontally (right)
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
7.5.20. Stereoscopic Extinction Ratio 🔗
Objective
Confirm that, when reproducing stereoscopic presentations, the Imaging Device achieves the required minimum extinction ratio.
Procedures

This test procedure only applies to a Test Subject that supports stereoscopic presentations.

  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Using Stereoscopic SDR Contrast Test Patterns , measure the extinction ratios χ sys𝔏 and χ sysℜ according to the stereoscopic extinction ratio & crosstalk procedure at [ICDM IDMS] .
  3. Verify that χ sys𝔏 and χ sysℜ each equals or exceeds the Tolerance for the Stereoscopic Extinction Ratio specified at [DV-ADD] .

Any verification that fails is cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
7.5.21. SDR Stereoscopic Peak White Luminance 🔗
Objective
Confirm that, when reproducing stereoscopic presentations, the Imaging Device achieves the required SDR peak white luminance.
Procedures

This test procedure only applies to a Test Subject that supports SDR stereoscopic presentations.

  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Using Stereoscopic SDR Contrast Test Patterns , measure the average stereo luminance L ave according to the stereoscopic luminance & luminance difference procedure at [ICDM IDMS] .
  3. Verify that L ave is within the tolerances for the Stereoscopic Peak White Luminance specified at [DV-ADD] .

Any verification that fails is cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
7.5.22. Surface Reflectivity (Direct View Display) 🔗
Objective
  • Verify that the diffuse surface reflectivity of the imaging device is within limits
  • Verify that the specular surface reflectivity of the imaging device is within limits
Procedures

If the measurement device or procedure reports the diffuse reflectivity at different optical wavelengths, the weighted average using the CIE Y Color Matching Function shall be used to combine different values at different wavelengths into a single diffuse reflectivity value that is photometrically weighted.

  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. With the Imaging Device turned off, measure the reflectance with specular excluded , ρ θ/de , according to the sampling-sphere implementation (specular excluded) procedure at [ICDM IDMS] .
  3. Verify that ρ θ/de is less than or equal to the Diffuse Reflectivity specified at [DV-ADD] .
  4. With the Imaging Device turned off, measure the reflectance , ρ 8/di , according to the sampling-sphere implementation procedure at [ICDM IDMS] .
  5. Verify that ρ 8/di - ρ θ/de is less than or equal to the Spectral Reflectivity specified at [DV-ADD] .

Any verification that fails is cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
7.5.23. Vignetting (Direct View Display) 🔗
Objective
Verify that the imaging device does not exhbit vignetting.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Using the full-frame white target from Sequential Contrast and Uniformity Sequence , measure the nonuniformity 𝒩 according to the sampled uniformity procedure at [ICDM IDMS] .
  3. Verify that 𝒩 meets the tolerance for the Full-Screen Sampled Nonuniformity specified at [DV-ADD] .

Any verification that fails is cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
7.5.24. SDR Stereoscopic Minimum Active Black Level 🔗
Objective
Confirm that the stereoscopic display system achieves the required SDR minimum active black level.
Procedures

This test procedure only applies to a Test Subject that supports SDR stereoscopic presentations.

  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Using Stereoscopic SDR Contrast Test Patterns , measure the left eye black level, L 𝔏KK , and the right eye black level, R 𝔏KK , according to the stereoscopic contrast ratio procedure at [ICDM IDMS] .
  3. Verify that both L 𝔏KK and R 𝔏KK are within the limits for the Stereoscopic Minimum Active Black Level specified at [DV-ADD] .

Any verification that fails is cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
7.5.25. Image Upscaling Artifacts 🔗
Objective
Confirm that the imaging system does not exhibit upscaling artifacts.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Display 4K Scaling Test Patterns .
  3. Verify that, when viewed from a distance of one screen height from the imaging device, the displayed image appear as illustrated at Figure A.2.254 and is free of artifacts, including spatial discontinuity artifacts (jaggies), ringing artifacts and aliasing artifacts, as illustrated in Figure 7.25(a) , Figure 7.25(b) and Figure 7.25(c) .

Any verification that fails is cause to fail this test.

Zone plate image exhibiting aliasing artifacts.
Figure 7.25(a) . Sample aliasing artifacts 🔗
Gray square exhibiting ringing artifacts.
Figure 7.25(b) . Sample ringing artifacts 🔗
Thin colorful lines exhibiting discontinuity artifacts (jaggies).
Figure 7.25(c) . Sample spatial discontinuities (jaggies) 🔗
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
7.5.26. SDR Stereoscopic Color Accuracy 🔗
Objective
Verify that, when reproducing a stereoscopic presentation, the Imaging Device reproduces colors within the tolerances specified in [SMPTE-431-2] .
Procedures
  1. Setup the Imaging Device and test environment according to 7.1. Test Environment for Image Measurements .
  2. Using Steroscopic Color Accuracy Series , measure and record the luminance and chromaticity coordinates for the following patches, according to the full-screen arbitrary color (R, G, B) procedure at [ICDM IDMS] :
    • Red-1
    • Green-1
    • Blue-1
  3. Verify that the measured chromaticity coordinates for each of the patches are equal to the Red , Green and Blue reference values for Color Accuracy that are specified at [SMPTE-431-2] , Table A.1, within review room tolerances.
  4. Verify that the measured luminance for each of the patches is ±3% of the Output Luminance values specified at [SMPTE-431-2] , Table A.4.

Any measurement outside of specified tolerances is caused to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
7.5.27. Sub-pixel Spatial Coincidence (Direct View Display) 🔗
Objective
Verify that the spatial arrangement of the color primary elements do not introduce objectionable geometric anomalies such as fringing artifacts.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Using 4K White Lines , verify that no color fringing artifacts are visible. Figure 7.5 illustrates one example of fringing artifacts where a nominally vertical white line appears, as seen from the normal seating area, as disjointed line segments of varying colors.

Any verification that fails is cause to fail this test.

Vertical continuous cyan line segment surrounded left and right by disjointed red line segments.
Figure 7.5 .27 Illustration of a fringing artifact (not to scale) 🔗
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
7.5.28. HDR Transfer Function 🔗
Objective
Verify that the correct HDR transfer function is used by the Imaging Device.
Procedures
Note: Prior to taking measurements, ensure that the setup and test environment requirements detailed in Section 7.1 have been performed.
  1. Play back the DCP DCI HDR White Steps .
  2. For each of the ten steps of Table 3 at [DCI-HDR] , measure the output luminance with a Spectroradiometer and verify that the result is within the tolerance specified in Table 7.5 .
  3. Play back the DCP DCI HDR Gray Steps .
  4. For each of the ten steps of Table 4 at [DCI-HDR] , measure the output luminance with a Spectroradiometer and verify that the result is within the tolerance specified in Table 7.5 .

Any verification that fails is cause to fail this test.

Table 7.5 .28(a) HDR black-to-white gray step-scale test pattern nominal luminance values 🔗
Step Number Nominal Luminance (cd/m²) Tolerance
Projector Direct View Display
1 0.50 ±5% ±12%
2 1.00 ±5% ±12%
3 2.00 ±3% ±6%
4 5.00 ±3% ±6%
5 9.99 ±3% ±6%
6 20.00 ±3% ±6%
7 50.01 ±3% ±6%
8 100.10 ±3% ±6%
9 200.21 ±3% ±6%
10 299.64 ±3% ±6%
Table 7.5 .28(b) HDR black-to-dark gray step-scale test pattern nominal luminance values 🔗
Step Number Nominal Luminance (cd/m²) Tolerance
Projector Direct View Display
1 0.0050 ±20% ±20%
2 0.0075 ±20% ±20%
3 0.0100 ±20% ±20%
4 0.0151 ±20% ±20%
5 0.0202 ±5% ±12%
6 0.0352 ±5% ±12%
7 0.0501 ±5% ±12%
8 0.0752 ±5% ±12%
9 0.0998 ±5% ±12%
10 0.1997 ±5% ±12%
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.5.29. SDR Minimum Active Black Level 🔗
Objective
Verify that the Imaging Device achieves the required minimum luminance when presented with an SDR full black signal.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. For each of the following test materials, display the material and measure the luminance according to the full-screen black procedure at [ICDM IDMS] :
  3. Verify that the measured luminance is within the range:
    • [0.01, 0.024] cd/m², if the Test Subject is a Direct View Display; or
    • [0.01, 0.032] cd/m², if the Test Subject is a Projector.

Any verification that fails is cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.5.30. Direct View Display Test Environment 🔗
Objective
Record information about the test environment in which the reported Direct View Display measurements were made.
Procedures
  1. Setup the test environment as specified in 7.1. Test Environment for Image Measurements .
  2. Record the height and width of the Direct View Display in units of meters.
  3. Record the number of modules that comprise the Direct View Display, in both the horizontal and vertical directions.
  4. With the Direct View Display switched off, record, in units of cd/m², the luminance at the center of the Direct View Display.

Failure to record any data is cause to fail this test.

Supporting Materials
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail All data recorded per the test procedure
27.2. SDR Direct View Display Test Sequence Pass/Fail All data recorded per the test procedure
7.5.31. Automatic SDR/HDR mode switching 🔗
Objective
Verify that the projection system automatically switches between SDR and HDR presentation.
Procedures
  1. Setup the test environment as specified in 7.1. Test Environment for Image Measurements .
  2. Build a show playlist out of the following compositions, in the order listed and without any automation or configuration related to HDR and SDR presentation:
    1. SDR Detection
    2. HDR Detection
    3. SDR Detection
  3. Play back the show, and measure and record the luminance for each of the SDR dark , SDR light , HDR dark and HDR light patches according to the full-screen arbitrary color (R, G, B) procedure at [ICDM IDMS] .
  4. Build a show playlist out of the following compositions, in the order listed and without any automation or configuration related to HDR and SDR presentation:
    1. HDR Detection
    2. SDR Detection
    3. HDR Detection
  5. Play back the show, and measure and record the luminance for each of the SDR dark , SDR light , HDR dark and HDR light patches according to the full-screen arbitrary color (R, G, B) procedure at [ICDM IDMS] .
  6. Verify that, in all cases, the measured luminance for the patches are within the allowable luminance ranges specified at Table 7.5 .

Any verification that fails is cause to fail this test.

Table 7.5 .31 Target SDR and HDR luminances 🔗
Patch Allowable luminance range (cd/m²)
Projector Direct View Display
SDR dark [0.01, 0.032] [0.01, 0.024]
SDR light 15.20 ± 0.46
HDR dark 0.005 ± 0.001
HDR light 299.6 ± 18 299.6 ± 9
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.5.32. HDR Inactive Black Level (Direct View Display) 🔗
Objective
  1. Verify that pixels outside the decoded image area are not emitting any light.
  2. Verify that pixels outside the area specified by the MainPictureActiveArea item of the CPL metadata are not emitting any light.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. For each of the following test materials, display the material and verify by visual inspection that: (a) registration marks are visible and (b) pixels outside the rectangular area delineated by the registration marks are not emitting any light: Any verification that fails is cause to fail this test.
  3. For each of the following test materials, display the material and verify by visual inspection that: (a) registration marks are visible and (b) no red pixels are visible: Any verification that fails is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
7.5.33. Image Frame Rates 🔗
Objective
Verify that the Imaging Device displays every frame at all required frame rates.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Play each of the following compositions in turn:
    1. If the Test Subject is an SDR Projector:
    2. For all other Test Subjects:
  3. For each of the compositions played above, and as illustrated at Figure 7.5 , verify that:
    • the movement of the pendulum is smooth and uninterrupted;
    • the timecode is displayed at the bottom of the frame matches the one displayed at the top right of the frame;
    • for 4K compositions, the word 4K is displayed at the center of the image;
    • the words "left" and "right" are heard through the Sound System as the pendulum reaches the extreme left and right of its trajectory, respectively; and
    • the following words appear: 1 , 2 , 3 , 4 , 5 , even and odd .

Any verification that fails is cause to fail this test.

Figure 7.5 .33. Location of the elements displayed when testing image frame rates (not to scale) 🔗
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
24.2. SDR Projector Test Sequence Pass/Fail —
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —
7.5.34. Stereoscopic Image Frame Rates 🔗
Objective
Verify that, for stereoscopic presentations, the Imaging Device displays every frame at all required frame rates.
Procedures

This test procedure only applies to Test Subject that support stereoscopic presentations.

  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Play each of the following compositions in turn:
  3. For each of the compositions played above, and as illustrated at Figure 7.5 , verify that:
    • the movement of the pendulum is smooth and uninterrupted;
    • the pendulum pops out of the screen;
    • the timecode is displayed at the bottom of the frame matches the one displayed at the top right of the frame;
    • the words "left" and "right" are heard through the Sound System as the pendulum reaches the extreme left and right of its trajectory, respectively;
    • the words left and right appear only in the left and right eye, respectively; and
    • the following words appear: 1 , 2 , 3 , 4 , 5 , even and odd .

Any verification that fails is cause to fail this test.

Figure 7.5 .34. Location of the elements displayed when testing stereoscopic image frame rates (not to scale) 🔗
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
27.2. SDR Direct View Display Test Sequence Pass/Fail —
7.5.35. HDR Contouring 🔗
Objective
Confirm the Imaging Device exhibits no visible contouring when presenting an HDR composition.
Procedures
  1. Ensure that the Imaging Device setup and test environment requirements detailed in 7.1. Test Environment for Image Measurements have been performed.
  2. Play back HDR Dark Gray Scale and measure, using a a Spectroradiometer , the luminance L i at the center of the screen of each full-screen gray patch.
  3. Calculate the set of second approximate derivatives from the set of measurements { L i } according to the slope monotonicity of gray scale procedure at [ICDM IDMS] .
  4. Verify that all the second approximate derivatives are greater than 0.

Any verification that fails is cause to fail this test.

Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
26.2. HDR Direct View Display Test Sequence Pass/Fail —
28.2. HDR Projector Test Sequence Pass/Fail —

Chapter 8. Screen Management System 🔗

A Screen Management System (SMS) (or Theater Management System (TMS)) is responsible for providing the operator's interface for ingest, scheduling, reporting, etc. In this document the term SMS will be used exclusively, although the same test procedures can apply to a TMS that is able to directly manage a suite of equipment for a screen.

The SMS is not hosted on secure hardware ( i.e. , it is not required to be within an SPB).

8.1. Ingest and Storage 🔗

8.1.1. Storage System Ingest Interface 🔗
Objective

Verify that the system provides an interface to the storage system, for DCP ingest, that is Ethernet, 1Gb/s or better, over copper (1000Base-T) or fiber (1000Base-FX), as described in [IEEE-802-3] , running the TCP/IP protocol.

Procedures
  1. Use a computer with the appropriate interface cards, e.g. , 1000Base-T copper Ethernet and network analysis tools such as Wireshark installed, to tap the ingest interface.
  2. Ingest DCI 2K StEM Test Sequence (Encrypted) and verify that the packets can be read by the computer that runs the network analysis tools. Failure to observe the packets contained in the DCP is cause to fail this test.
  3. Verify that the data packets read are valid TCP/IP data packets. Use of any other protocol to ingest the DCP is cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
15.2. Integrated IMB Test Sequence Pass/Fail — 21.2. Integrated IMBO Test Sequence Pass/Fail —
Sequence Type Measured Data
8.1.2. Storage System Capacity 🔗
Objective
Verify that the storage system available to the SMS has a capacity of at least 1TByte of content.
Procedures
Verify that the storage system has the capacity to hold at least 1TByte of content. This can be done in three ways:
  1. Verify by using the specification of the manufacturer.
  2. Examine the capacity of the file system representing the storage system, and verify that there is enough available storage to hold 1 TByte of content data. Use appropriate file system tools to perform this task.
  3. Measure the storage capacity by copying 1TByte of content to the storage and verifying that no content has been purged by playing back all content.
If the capacity of the storage system is less than 1TByte, this is cause to fail this test.
Supporting Materials
Reference Documents
Consolidated Test Sequences
15.2. Integrated IMB Test Sequence Pass/Fail — 21.2. Integrated IMBO Test Sequence Pass/Fail —
Sequence Type Measured Data
8.1.3. Storage System Redundancy 🔗
Objective
Verify that the storage system available to the SMS provides redundancy in the case of a drive failure.
Procedures
Verify the existence and functionality of an appropriate RAID configuration by performing the following:
  1. Ingest the composition DCI 2K StEM (Encrypted) i.e. , load it into the storage system.
  2. Power down the system.
  3. Disconnect one drive of the RAID configuration.
  4. Re-power the system.
  5. Set up and play a show that contains the composition DCI 2K StEM (Encrypted) , keyed with KDM for 2K StEM (Encrypted) and verify that playback is successful, i.e. , playback can be started, is not interrupted and does not show any picture or sound artifacts. Unsuccessful playback is cause to fail this test.
  6. Power down the system and reconnect the drive that was disconnected in step 3.
  7. Repower the system and perform any necessary manufacturer-specified procedures to restore the RAID configuration to normal.
  8. Repeat steps 2 through 7 for all other drives contained in the storage system.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
8.1.4. Storage System Performance 🔗
Objective
Verify that the storage system available to the SMS is able to sustain a minimum peak data rate of 307 MBit/sec to allow for uninterrupted digital cinema playback.
Procedures
  1. Setup and play the composition 2K DCI Maximum Bitrate Composition (Encrypted) , keyed with KDM for 2K Maximum Bitrate Composition (Encrypted) . This composition starts with a count to check synchronization between picture and sound. 10 minutes of an image with minimal compression and 16 audio channels (each 24 bit per sample, 96 kHz) follows, then a second synchronization count. The content between the synchronization counts will require the maximum allowable data rate for successful reproduction.
  2. Verify that playback is successful, i.e. , playback can be started, is not interrupted and does not show any picture or sound artifacts. Unsuccessful playback is cause to fail this test.
  3. Extract the logs from the Test Subject and examine the associated FrameSequencePlayed and PlayoutComplete events recorded during the playback for complete and successful reproduction. Any exceptions or missing FrameSequencePlayed or PlayoutComplete events are cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
8.1.5. Deleted Section 🔗

The section "Storage System Redundancy (OBAE)" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

8.1.6. Storage System Performance (OBAE) 🔗
Objective
Verify that the storage system available to the OBAE-capable SMS allows uninterrupted playback of maximum bitrate content.
Procedures
  1. Setup and play the composition 2K DCI Maximum Bitrate Composition (OBAE) (Encrypted) , keyed with KDM for 2K DCI Maximum Bitrate Composition (OBAE) (Encrypted) . This composition requires the maximum allowable data rate for successful reproduction.
  2. Verify that playback is successful, i.e. , playback can be started, is not interrupted and does not show any picture or sound artifacts. Unsuccessful playback is cause to fail this test.
  3. Extract the logs from the Test Subject and examine the associated FrameSequencePlayed and PlayoutComplete events recorded during the playback for complete and successful reproduction. Any exceptions or missing FrameSequencePlayed or PlayoutComplete events are cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —

8.2. Screen Management System 🔗

8.2.1. Deleted Section 🔗

The section "Screen Management System" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

8.2.2. Show Playlist Creation 🔗
Objective
  • Verify that the SMS provides the necessary functions for managing Composition Play Lists (CPLs) and for assembling them into shows (SPL creation).
  • Verify that the SMS allows only authorized persons to build a Show Playlist (SPL).
Procedures
  1. Ingest the composition DCI 2K StEM into the system.
  2. Using the system, locate the composition DCI 2K StEM .
  3. Create a new Show Play List (SPL) and add DCI 2K StEM twice to the show. The two instances of DCI 2K StEM are herein referred to as DCI 2K StEM X and DCI 2K StEM Y.
  4. Ingest the composition DCI 2K StEM (Encrypted) and the KDM KDM for 2K StEM (Encrypted) into the system.
  5. Using the system, locate the composition DCI 2K StEM (Encrypted) .
  6. Append the composition DCI 2K StEM (Encrypted) to the end of the show.
  7. In the show, move the composition DCI 2K StEM (Encrypted) in between DCI 2K StEM X and DCI 2K StEM Y.
  8. Ingest DCI Black Spacer - 5 seconds and insert it between each of the compositions in the show.
  9. Start playback and verify that the presentation proceeds as expected and the inserted black frames and silence are presented correctly.
  10. Attempt to delete each of the compositions DCI 2K StEM , DCI 2K StEM (Encrypted) and DCI Black Spacer - 5 seconds from system storage. The system is required to warn that the content is part of a current show and not allow deletion.
  11. Wait until playback is completed.
  12. Remove DCI 2K StEM X from the show.
  13. Attempt to delete DCI 2K StEM from storage. It is expected that the SMS warns the user that this composition is part of an SPL.
  14. Delete the show then delete DCI 2K StEM and DCI 2K StEM (Encrypted) . It is expected that this operation succeeds.
  15. Verify that the aforementioned compositions have been removed.
  16. Verify that the above functions for assembling content into an SPL are executable with an easy to use graphical user interface.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Data only —
21.2. Integrated IMBO Test Sequence Data only —
8.2.3. Show Playlist Format 🔗
Objective
Verify that the SMS supports the required Show Playlist Format.
Procedures
  1. Export the Show Playlist (SPL) to external media.
  2. Use the software command schema-check to verify that the SPL exported in the above step is well formed XML. XML format errors are cause to fail this test. An example is shown below. 
$ schema-check <input-file> 
schema
validation
successful
Supporting Materials
Reference Documents
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
8.2.4. Deleted Section 🔗

The section "KDM Validity Checks" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

8.2.5. Automation Control and Interfaces 🔗
Objective
Verify that the SMS supports theater automation interface via any one or more of:
  • contact closures (general purpose I/O)
  • serial data interface
  • network ( e.g. , Ethernet)
Procedures
  1. Configure an automation test setup that allows the Test Subject to signal an event using a visible state change ( e.g. an L.E.D.), and allows the Test Subject to be signalled via external stimulus ( e.g. , an SPST switch).
  2. Verify that the Test Subject can change the state of the event indicator at pre-determined times using the playlist. Failure to meet this requirement shall be cause to fail this test.
  3. Verify that playback of a playlist on the Test Subject can be started by external stimulus. Failure to meet this requirement shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
8.2.6. Interrupt Free Playback 🔗
Objective
Verify that the system can play a sequence of CPLs (a Show Playlist) without noticeable interruptions such as unexpected pauses or visual or audible artifacts.
Procedures
To verify that playback is possible without any interruptions:
  1. Assemble a show containing the compositions 4K DCI NIST Frame with silence , DCI 5.1 Channel Identification DCI 2K Sync test with Subtitles (Encrypted) and DCI 2K StEM (Encrypted) , keyed with KDM for DCI 2K Sync Test with Subtitles (Encrypted) and KDM for 2K StEM (Encrypted)
  2. Play back the show. Verify that playback succeeds and is completed without any image or sound distortions and without any interruption. Incomplete or interrupted playback or the presence of distortions or artifacts shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
8.2.7. Artifact Free Transition of Image Format 🔗
Objective
Verify artifact free transition between differing pixel array sizes.
Procedures
To verify that mode transitions do not cause any artifacts:
  1. Assemble a Show that contains 3 repetitions of the following 2 compositions DCI 2K Image with Frame Number Burn In (Flat) , which contains two reels of 1.85:1 content, followed by DCI 2K Image with Frame Number Burn In (Scope) , which contains two reels of 2.39:1 content.
  2. Start playback and observe the projected image. Transitions between reels and compositions are announced visually by means of a burned-in counter. Verify that for all transitions, no visible artifacts, e.g. , rolling, flashes, distorted images etc, are visible, and that every frame is displayed correctly on each outgoing and incoming transition. If any visible artifact is present or any incoming or outgoing frame is not displayed, this is cause to fail the test. Note: Use of a camera to shoot the display off screen to confirm display of all frames can be helpful in this test .
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
8.2.8. Restarting Playback 🔗
Objective
Verify that power failures cause the system to enter a stable stop/idle condition and that the system provides the ability to restart playback at a point prior to a power interruption.
Procedures
  1. Load DCI 2K Image with Frame Number Burn In (Encrypted) and KDM for DCI 2K Image with Frame Number Burn In (Encrypted) , then assemble and start a show.
  2. Interrupt the presentation by interrupting the Test Subject's power supply. If possible, a projector power supply should not be interrupted as this may cause overheating and damage the projector.
  3. Re-establish power and verify that the system enters a stable stop/idle state. Failure to meet this requirement is cause to fail this test.
  4. Verify that the system notifies the user that the last playback was abnormally interrupted, and offers the possibility of restarting the show. Failure to meet this requirement is cause to fail this test.
  5. Attempt to restart the presentation at a point prior to the power interruption and verify that the restart was successful. Failure to meet this requirement is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
8.2.9. SMS User Accounts 🔗
Objective
Verify that the SMS supports multiple levels of user accounts.
Procedures
  1. Study the user manual to discover factory-created account names and passwords.
  2. If required by the system, create the necessary operating accounts.
  3. Return the system to the "logged out" state.
  4. For each account, log on to the system using the account information and note the privileges available to the account user ( e.g. , run show, load content, create account, etc.). Failure of the system to provide privilege separation using distinct user accounts is cause to fail this test.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail Record the available operator roles (names) and whether locally-defined accounts can be created.
21.2. Integrated IMBO Test Sequence Pass/Fail Record the available operator roles (names) and whether locally-defined accounts can be created.
8.2.10. SMS Operator Identification 🔗
Objective
Verify that the security system requires the SMS and SMS operator to be identified to the Security Manager.
Procedures
  1. List all the methods available to the Test Subject that can cause playback of a composition or show. This could include any preset or created user accounts/logins to the SMS/TMS, direct command, e.g. , by front panel controls or automation inputs and events initiated by an automatic scheduler. Manufacturer-supplied documentation, including manuals, may be consulted to assist with this step.
  2. For each of the cases from the list created in Step 1, cause the composition DCI 2K StEM (Encrypted) , or a show that contains it, to play back. Record the time of day at the end of each playback.
  3. Retrieve the audit logs from the system.
  4. By using the time values recorded in Step 2, for each of the cases from the list created in Step 1:
    1. Locate the corresponding FrameSequencePlayed playout events.
    2. Verify that there is a FrameSequencePlayed event for both audio and image and that they each contain a parameter named AuthId with a value that is not absent.
    3. Record each AuthId value. Any missing AuthId parameter or any AuthId parameter that has a value that is unpopulated is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
8.2.11. SMS Identity and Certificate 🔗
Objective
  • Verify that the SMS carries a [SMPTE-430-2] compliant digital certificate that identifies the SMS entity.
  • Verify that the SMS certificate indicates either the SMS role, or the TMS role, unless the SMS is contained within an SPB meeting the protection requirements for any other designated roles.
Procedures
  1. Obtain the SMS certificate (and chain if available):
    • If the SMS communicates with the SM via a network accessible to test equipment, use network analysis tools ( e.g. , Wireshark) to monitor the packets exchanged between the SMS and SM and extract the leaf certificate and, if present, the associated signing certificate(s). If signing certificates are not present, obtain them from the manufacturer.
    • If network monitoring is not possible, obtain the complete certificate chain from the manufacturer.
  2. Extract the Subject Common Name field from the leaf certificate collected in step 1. Failure for the Common Name to include either the SMS role, or the TMS role, is cause to fail the test.
  3. Verify that the Subject Common Name field of the leaf certificate collected in step 1 contains the serial number of the Test Subject. Additional identifying information may be present. Failure of this verification is cause to fail the test.
  4. Verify that information identifying the make and model of the Test Subject is carried in the Subject field of the certificate collected in step 1. Additional identifying information may be present. Failure of this verification is cause to fail the test.
  5. Verify that either the make, model and serial number of the Test Subject, or information that is unambiguously traceable by the manufacturer to the Subject field from the leaf certificate obtained in step 1, is clearly placed on the exterior of the device containing the Test Subject. Failure of this verification is cause to fail the test.
Supporting Materials
Reference Documents
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
8.2.12. Content Keys and TDL check 🔗
Objective
  1. Verify that the SMS, working with the security infrastructure, checks that, prior to initiating playback of a Show Playlist (scheduled exhibition), (i) all content keys required for the playback of the Show Playlist are available and valid, and (ii) the suite equipment to be used or the playback of is disallowed when the Show Playlist KDM's TDL is included on empty, and allowed when the TDL. KDM's TDL is Assume Trust.
  2. Verify that the SMS does this check for every composition individually.
Procedures
With the test materials specified below, perform the following procedures:
  1. Try to assemble and play a show using DCI 2K StEM (Encrypted) without providing a KDM. If playback begins this is cause to fail this test.
  2. Try to assemble and play a show using DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) and DCI 2K StEM (Encrypted) , keyed with KDM with incorrect message digest in that order. The KDM KDM with incorrect message digest is invalid (wrong signature/hash error). If playback begins this is cause to fail this test.
  3. Try to assemble and play a show using DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) and DCI 2K StEM (Encrypted) , keyed with KDM that has expired which contains an expired time window. If playback begins this is cause to fail this test.
  4. Try to assemble and play a show using DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) and DCI 2K StEM (Encrypted) , keyed with KDM with future validity period which contains a time window in the future. If playback begins this is cause to fail this test.
  5. Try to assemble and play a show using DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) and DCI 2K StEM (Encrypted) , keyed with KDM with invalid XML which contains an XML malformation. If playback begins this is cause to fail this test.
  6. Try to assemble and play a show using DCI 2K Sync Test (Encrypted) , with KDM for DCI 2K Sync Test (Encrypted) and DCI 2K StEM (Encrypted) , keyed with KDM with empty TDL , which is a KDM that does not list any trusted devices in its TDL. If playback begins this is cause to fail this test.
  7. Try to assemble and play a show using DCI 2K Sync Test (Encrypted) , keyed with KDM for DCI 2K Sync Test (Encrypted) and DCI 2K StEM (Encrypted) , keyed with KDM with Assume Trust TDL Entry for 2K StEM (Encrypted) , which is a KDM that carries only the "assume trust" empty-string thumbprint. Attempt to play the composition and record the result. If playback does not begin this is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
8.2.13. Content Keys and TDL check (OBAE) 🔗
Objective
  1. Verify that the SMS checks that, prior to initiating playback of a Show Playlist that contains OBAE content, (i) all content keys required for the playback of the Show Playlist are available and valid, and (ii) the suite equipment to be used for the playback of is disallowed when the Show Playlist KDM's TDL is included on empty, and allowed when the TDL. KDM's TDL is Assume Trust.
  2. Verify that the SMS does this check for every composition individually.

Two instances of each KDM listed below are needed if the Test Subject is an OMB: one instance of each KDM for the IMB and one instance of each KDM for the OMB.

Procedures
With the test materials specified below, perform the following procedures:
  1. Try to assemble and play a show using DCI 2K StEM (OBAE) (Encrypted) without providing a KDM. If playback begins this is cause to fail this test.
  2. Try to assemble and play a show using DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) and DCI 2K StEM (OBAE) (Encrypted) , keyed with KDM with incorrect message digest (OBAE) in that order. If playback begins this is cause to fail this test.
  3. Try to assemble and play a show using DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) and DCI 2K StEM (OBAE) (Encrypted) , keyed with KDM that has expired (OBAE) . If playback begins this is cause to fail this test.
  4. Try to assemble and play a show using DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) and DCI 2K StEM (OBAE) (Encrypted) , keyed with KDM with future validity period (OBAE) . If playback begins this is cause to fail this test.
  5. Try to assemble and play a show using DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) and DCI 2K StEM (OBAE) (Encrypted) , keyed with KDM with invalid XML (OBAE) . If playback begins this is cause to fail this test.
  6. Try to assemble and play a show using DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) and DCI 2K StEM (OBAE) (Encrypted) , keyed with KDM with empty TDL (OBAE) . If playback begins this is cause to fail this test.
  7. Try to assemble and play a show using DCI 2K Sync Test (OBAE) (Encrypted) , keyed with KDM for DCI 2K Sync Test (OBAE) (Encrypted) and DCI 2K StEM (OBAE) (Encrypted) , keyed with KDM with Assume Trust TDL Entry (OBAE) . If playback does not begin this is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
20.4. OMB Confidence Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
8.2.14. KDM Content Keys Check 🔗
Objective
Verify that the SMS checks that, prior to initiating playback of a Show Playlist, content keys carried in the KDM associated with a CPL included in the Show Playlist match exactly those content keys used by the CPL.
Procedures

For each of the rows of Table 8.2 , create a Show Playlist with the Composition and attempt to play it using the Malformed KDM . If playback begins this is cause to fail this test.

Table 8.2 .14. List of Compositions and associated KDMs with mismatched content keys 🔗
Composition Malformed KDM
sync_test_with_subs_ct.cpl.xml m0100_missing_key_pict.kdm.xml
sync_test_with_subs_ct.cpl.xml m0102_missing_key_snd.kdm.xml
sync_test_with_subs_ct.cpl.xml m0104_missing_key_sub.kdm.xml
2K_sync_test_with_subs_obae_ct.cpl.xml m0106_missing_key_pict_obae.kdm.xml
2K_sync_test_with_subs_obae_ct.cpl.xml m0108_missing_key_snd_obae.kdm.xml
2K_sync_test_with_subs_obae_ct.cpl.xml m0110_missing_key_sub_obae.kdm.xml
2K_sync_test_with_subs_obae_ct.cpl.xml m0112_missing_key_obae_obae.kdm.xml
Supporting Materials
Reference Documents
Test Equipment
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
8.2.15. Validity of SMS Certificates 🔗
Objective
Verify that the SMS certificates are valid.
Procedures
  1. Obtain the SMS certificate (and chain if available):
    • If the SMS communicates with the SM via a network accessible to test equipment, use network analysis tools ( e.g. , Wireshark) to monitor the packets exchanged between the SMS and SM and extract the leaf certificate and, if present, the associated signing certificate(s). If signing certificates are not present, obtain them from the manufacturer.
    • If network monitoring is not possible, obtain the complete certificate chain from the manufacturer.
  2. For each certificate, perform the following tests:
  3. For the complete chain of signer certificates, perform 2.1.17. Certificate Chains

Failure of any of these above conditions is cause to fail this test.

Supporting Materials
Reference Documents
Test Equipment
Consolidated Test Sequences
Sequence Type Measured Data
15.2. Integrated IMB Test Sequence Pass/Fail —
15.4. Integrated IMB Confidence Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
21.4. Integrated IMBO Confidence Sequence Pass/Fail —
8.2.16. Interrupt Free Playback (OBAE) 🔗
Objective
Verify that the OBAE-capable system can play a sequence of CPLs (a Show Playlist) without noticeable interruptions such as unexpected pauses or visual or audible artifacts.
Procedures
To verify that playback is possible without any interruptions:
  1. Assemble a show containing the compositions:
  2. Play back the show. Verify that playback succeeds and is completed without any image or sound distortions and without any interruption. Incomplete or interrupted playback or the presence of distortions or artifacts shall be cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
8.2.17. Restarting Playback (OBAE) 🔗
Objective
Verify that power failures cause the system to enter a stable stop/idle condition and that the OBAE-capable system provides the ability to restart playback at a point prior to a power interruption.
Procedures
  1. Load DCI 2K Image with Frame Number Burn In (OBAE) (Encrypted) and KDM for DCI 2K Image with Frame Number Burn In (OBAE) (Encrypted) , then assemble and start a show.
  2. Interrupt the presentation by interrupting the Test Subject's power supply. If possible, a projector power supply should not be interrupted as this may cause overheating and damage the projector.
  3. Re-establish power and verify that the system enters a stable stop/idle state. Failure to meet this requirement is cause to fail this test.
  4. Verify that the system notifies the user that the last playback was abnormally interrupted, and offers the possibility of restarting the show. Failure to meet this requirement is cause to fail this test.
  5. Attempt to restart the presentation at a point prior to the power interruption and verify that the restart was successful. Failure to meet this requirement is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —
21.2. Integrated IMBO Test Sequence Pass/Fail —
8.2.18. Show Playlist Creation (OBAE) 🔗
Objective
  • Verify that the OBAE-capable SMS provides the necessary functions for managing Composition Play Lists (CPLs) and for assembling them into shows (SPL creation).
  • Verify that the OBAE-capable SMS allows only authorized persons to build a Show Playlist (SPL).
Procedures
  1. Ingest the composition DCI 2K StEM (OBAE) into the system.
  2. Using the system, locate the composition DCI 2K StEM (OBAE) .
  3. Create a new Show Play List (SPL) and add DCI 2K StEM (OBAE) twice to the show. The two instances of DCI 2K StEM (OBAE) are herein referred to as DCI 2K StEM (OBAE) X and DCI 2K StEM (OBAE) Y.
  4. Ingest the composition DCI 2K StEM (OBAE) (Encrypted) and the KDM KDM for 2K StEM (Encrypted) (OBAE) into the system.
  5. Using the system, locate the composition DCI 2K StEM (OBAE) (Encrypted) .
  6. Append the composition DCI 2K StEM (OBAE) (Encrypted) to the end of the show.
  7. In the show, move the composition DCI 2K StEM (OBAE) (Encrypted) in between DCI 2K StEM (OBAE) X and DCI 2K StEM (OBAE) Y.
  8. Ingest DCI Black Spacer - 5 seconds and insert it between each of the compositions in the show.
  9. Start playback and verify that the presentation proceeds as expected and the inserted black frames and silence are presented correctly.
  10. Attempt to delete each of the compositions DCI 2K StEM (OBAE) , DCI 2K StEM (Encrypted) and DCI Black Spacer - 5 seconds from system storage. The system is required to warn that the content is part of a current show and not allow deletion.
  11. Wait until playback is completed.
  12. Remove DCI 2K StEM (OBAE) X from the show.
  13. Attempt to delete DCI 2K StEM (OBAE) from storage. It is expected that the SMS warns the user that this composition is part of an SPL.
  14. Delete the show then delete DCI 2K StEM (OBAE) and DCI 2K StEM (OBAE) (Encrypted) . It is expected that this operation succeeds.
  15. Verify that the aforementioned compositions have been removed.
  16. Verify that the above functions for assembling content into an SPL are executable with an easy to use graphical user interface.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Data only —
21.2. Integrated IMBO Test Sequence Data only —
8.2.19. Deleted Section 🔗

The section "Automation Control and Interfaces (OBAE)" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

8.2.20. SMS Operator Identification (OBAE) 🔗
Objective
Verify that the security system requires the SMS and SMS operator to be identified to the OBAE-capable Security Manager.
Procedures
  1. List all the methods available to the Test Subject that can cause playback of a composition or show. This could include any preset or created user accounts/logins to the SMS/TMS, direct command, e.g. , by front panel controls or automation inputs and events initiated by an automatic scheduler. Manufacturer-supplied documentation, including manuals, may be consulted to assist with this step.
  2. For each of the cases from the list created in Step 1, cause the composition DCI 2K StEM (OBAE) (Encrypted) , or a show that contains it, to play back. Record the time of day at the end of each playback.
  3. Retrieve the audit logs from the system.
  4. By using the time values recorded in Step 2, for each of the cases from the list created in Step 1:
    1. Locate the corresponding FrameSequencePlayed playout events.
    2. Verify that there is a FrameSequencePlayed event for both audio and image and that they each contain a parameter named AuthId with a value that is not absent.
    3. Record each AuthId value. Any missing AuthId parameter or any AuthId parameter that has a value that is unpopulated is cause to fail this test.
Supporting Materials
Reference Documents
Test Materials
Consolidated Test Sequences
Sequence Type Measured Data
20.2. OMB Test Sequence Pass/Fail —

Part II. Design Evaluation Guidelines 🔗

Chapter 9. FIPS Requirements for a Type 1 SPB 🔗

Type 1 Secure Processing Blocks (SPB) are required by DCI to conform to a U.S. National Institute of Standards and Technology (NIST) FIPS 140 version in effect at the time of DCI compliance testing. Testing for compliance with FIPS 140 is performed by independent CMVP testing laboratories accredited by NIST NVLAP.

In May 2019, NIST announced the plan and schedule to migrate the security requirements for cryptographic modules from FIPS 140-2 to FIPS 140-3 . In order to simplify accommodation of this Chapter 9. FIPS Requirements for a Type 1 SPB for FIPS 140-2 and FIPS 140-3 (and references to these documents throughout the CTP), FIPS 140-2 and FIPS 140-3 references have been revised to refer generically to FIPS 140 , unless otherwise noted.

The testing program, known as the Cryptographic Module Validation Program (CMVP), is a joint effort of NIST's Computer Systems Laboratory (CSL) and the Communications Security Establishment (CSE) of the Government of Canada. More information about CMVP can be found on the NIST web site at http://csrc.nist.gov/groups/STM/. To be compliant with the DCI System Specification, a Type 1 SPB device must be tested by an accredited CMVP testing laboratory, the resulting documentation must be submitted to NIST/CSE for examination, and a validation certificate must be issued by NIST/CSE. Throughout this document, the term "FIPS 140-2 testing" will refer to this entire process.

FIPS 140 testing is very thorough but also very selective. To determine whether Type 1 SPB meets the DCI requirements, the documents prepared for and presented to the CMVP testing laboratory by the manufacturer must be reviewed by an examiner as guided by the requirements presented in this chapter. This chapter will briefly explain the FIPS testing process and the documentation that is produced. A procedure will be presented that will guide the examiner through the task of evaluating a FIPS 140 test report and determining the DCI compliance status of the respective Test Subject.

9.1. FIPS Testing Procedures 🔗

This section will explain the process of obtaining a FIPS 140 validation certificate from NIST/CSE. This information is intended to guide the examiner in understanding the documentation that will be produced in that process. This information is not exhaustive and is not intended to guide a manufacturer in obtaining a validation certificate. The following sub-sections illustrate the tasks in a typical validation process.

Accredited CMVP Testing Laboratory
FIPS 140 testing is performed by an accredited CMVP testing laboratory. This CMVP testing laboratory will assist the manufacturer in preparing the required documentation and will test sample devices for conformance to the documentation. The CMVP testing laboratory may help the manufacturer resolve compliance issues in the design, but this help is limited to comments on proposed designs, actual design participation may not occur. The documentation and test reports may be submitted to NIST/CSE by the CMVP testing laboratory or the manufacturer.

NIST makes available the list of accredited CMVP testing laboratories on the agency web site (see http://csrc.nist.gov/groups/STM/ testing_labs/index.html). Any of the testing laboratories can be used, but some restrictions may apply. For example, a laboratory that is owned by the Test Subject manufacturer or one that contributed to the design of the Test Subject will be disqualified from testing that Test Subject. More information about CMVP testing laboratories and CMVP testing laboratory selection can be found in Frequently Asked Questions for the Cryptographic Module Validation Program (http://csrc.nist.gov/groups/STM/cmvp/documents/ CMVPFAQ.pdf).

The FIPS 140 validation test report prepared by the CMVP testing laboratory is a proprietary and closely controlled document. The manufacturer must ensure that it has permission to disclose the test report to the Testing Organization.

Standards and Supporting Documentation
The manufacturer must obtain and understand all of the NIST documentation that is relevant to the FIPS 140 testing process. In addition to the documentation about the validation process itself, the manufacturer will also need documentation which addresses the requirements for particular algorithms implemented in the device.
Security Element Documentation
All design elements which are addressed by FIPS 140 , e.g. , cryptographic algorithms and Critical Security Parameters (CSP), must be documented and tested according to CMVP procedures. The manufacturer must work with the CMVP testing laboratory to identify all such design features and prepare the required documentation.
Design Modification
The Cryptographic Algorithm Validation Program (CAVP) and CMVP validation testing processes may require design modifications to the cryptographic module hardware, software, firmware, or documentation. The CMVP testing laboratory performing the validation testing identifies the compliance issues, but does not design or redesign the cryptographic module with the manufacturer, or for the manufacturer.

The manufacturer is responsible for implementing a compliant design, and submitting required testing evidence to the CMVP testing laboratory for review and testing

Test Subject Instrumentation
Where it is not possible to test a particular subsystem from outside the module ( e.g. , the seed method for a random number generator), the manufacturer must provide the instrumentation necessary to allow the CMVP testing laboratory to test the subsystem. A simulator may be used, for example, to prove the correct functioning of microcode for an ASIC or FPGA.

Additionally, the manufacturer may be required to develop test jigs to facilitate the error injection process; for example, to simulate tamper events and other hardware failures.

Operational Testing
The CMVP testing laboratory exercises the cryptographic module through all major states, including error states, while monitoring all external ports and interfaces using manufacturer testing tools and equipment. This may require the ability to manipulate program execution and record the contents of memory, thus requiring instrumentation as described above.
Report Submission
Upon successful completion of the validation testing (no failed test assertions exist), the CMVP testing laboratory submits a FIPS 140-2 validation report to the CMVP for certification. CMVP personnel examine the submission for correctness, sending any necessary requests for clarification to the CMVP testing laboratory. The submission may be rejected, in which case the manufacturer and CMVP testing laboratory must work to resolve the issue(s) raised and re-submit the validation report. Once the submission is accepted by CMVP, a certificate is issued for the cryptographic module.

The CMVP maintains a list of all cryptographic modules validated to FIPS 140 requirements. This list is published online at http://csrc.nist.gov/groups/STM/cmvp/validation.html. The CMVP also maintains a list of cryptographic modules currently undergoing FIPS 140 testing (a listing on the CMVP pre-validation website does not equate to having a FIPS 140-2 validation). The pre-validation list is at http://csrc.nist.gov/groups/STM/cmvp/inprocess.html.

Maintenance
Changes to the module design require re-validation. The effort required to validate an updated design may be small if the design changes are minor.

9.2. Submitted Materials 🔗

The CMVP testing laboratory will review and analyze design materials during the validation testing process. The following list shows the documents generally expected to be submitted.

  • Master Components List (bill of materials); All items submitted as test evidence to the CMVP testing laboratory ( e.g. , software, firmware, hardware, source code, documentation, etc.) must be specified on the Master Components List, along with a unique identifier and version
  • Production grade samples of the cryptographic module (minimum of five for Level 3)
  • Security policy
  • Data sheets for hardware components
  • Listing of all significant information flows
  • Finite state model
  • Clearly annotated source code
  • Functional specifications
  • Block diagrams
  • Schematics
  • VHDL for custom components
  • Software design documentation (such as an API or developers guide)
  • Mechanical drawings & assembly drawings (approximately to scale)
  • Printed circuit board layout drawings
  • Cryptographic Key and Critical Security Parameter documentation
  • Delivery and operations procedures
  • Cryptographic Officer & User guidance
  • Configuration management specification
  • Operational testing plan(s), and associated testing equipment
  • Rationale for exclusion of any components from the security requirements of FIPS 140
  • Proof of conformance to FCC Part 15, Subpart B Class A requirements
  • CAVP Algorithm validation certificates for all implemented Approved cryptographic algorithms
  • Documentation detailing the correspondence of all security rules to the implementation

9.3. CMVP Testing Laboratory Reports 🔗

A FIPS 140 validation test report is created by CMVP testing laboratory engineers for submission to CMVP. The report details the documentation received and the test engineer's evaluation of the implementation's fidelity to the documentation and FIPS 140 requirements. The module tested receives a FIPS 140 validation certificate (i.e., either [FIPS-140-2] or [FIPS-140-3] ) once the CMVP reviews and approves the test report.

9.4. Interpreting FIPS Test Reports 🔗

The CMVP testing laboratory assessments contained within a FIPS 140 validation test report address each of the applicable "TE" requirements corresponding to the eleven areas specified in the FIPS 140 Derived Test Requirements (DTR). These requirements instruct the tester as to what he or she must do in order to test the cryptographic module with respect to the given assertion (which is a statement that must be true for the module to satisfy the requirement of a given area at a given level).

For each applicable FIPS 140 "TE", the tester's assessment includes:

  • A statement that the tester verified the requirement was satisfied, or that the requirement is not applicable
  • Details on how the tester verified the requirement ( e.g. through documentation review, source code analysis, physical attack, operational testing, etc.).
  • References to supporting design documentation and other test evidence
  • References to algorithm standards and CAVP validation certificates as applicable

The Testing Organization must obtain an official copy of the FIPS 140 validation test report directly from the CMVP testing laboratory that performed the testing. The Test Operator must verify that the name of the cryptographic module and version (software, hardware, firmware) under review are identical to the versions reviewed for the FIPS 140 validation certificate, and supporting CAVP algorithm validation certificate(s).

To confirm whether the cryptographic module satisfies the DCI requirements, the Test Operator must review the "TE" assessments (and associated references as needed) that are relevant to corresponding DCI requirements (the specific assessments are located below with the respective DCI requirements. The functionality described must be consistent with the observed implementation.

9.5. DCI Requirements for FIPS Modules 🔗

Each of the subsections below describes a DCI requirement that must be proven by examining the FIPS 140 validation report. For each requirement, observe the design of the respective system element (with the aid of the Test Subject Representative) and record whether or not the design meets the requirement.

9.5.1. SM Operating Environment 🔗
Objective

Verify that the Security Manager (SM) operating environment is limited to the FIPS 140 "limited operational" or "non-modifiable operational" environment category.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
9.5.2. Deleted Section 🔗

The section "LE Key Generation" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

9.5.3. SPB Type 1 Tamper Responsiveness 🔗
Objective

For components of the system designated Type 1 SPB , verify the following:

  1. That SPBs with access doors or removable covers are monitored 24/7 to assure that in the event of intrusion via such openings the SPB terminates all activity and zeroizes all Critical Security Parameters (CSPs) (see [DCI-DCSS] , Section 9.5.2.6).
  2. That if the SPB requires a power source to accomplish tamper detection and response, it must zeroize its CSPs prior to any situation arising where such power source may not be available.
  3. That log records are not purged in the event of intrusion or other tamper detection
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
9.5.4. Deleted Section 🔗

The section "Security Design Description Requirements" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

9.5.5. Deleted Section 🔗

The section "SPB1 Tamper Resistance" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

9.5.6. SPB Type 1 FIPS Requirements 🔗
Objective

For components of the system designated Type 1 SPB , verify the following: the component meets and is certified for the requirements of FIPS 140 Level 3 in all areas except those subject to the exceptions or additional notes as specified in [DCI-DCSS] , Section 9.5.2.5.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
9.5.7. Deleted Section 🔗

The section "SPB1 Secure Silicon FIPS Requirements" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

9.5.8. Asymmetric Key Generation 🔗
Objective

For components of the system designated Type 1 SPB , verify that keys are generated as specified in [RFC-3447] and per the requirements of FIPS 140 "Cryptographic Key Management" and the [DCI-DCSS] , Section 9.5.2.5.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
9.5.9. Critical Security Parameter Protection 🔗
Objective

Verify that the following Critical Security Parameters (CSPs) receive Secure Processing Block (SPB) Type 1 protection, whenever they exist outside of their originally encrypted state, in accordance with IPS-140 and the requirements of [DCI-DCSS] , Section 9.5.2.5:

  1. Device Private Keys - RSA private key that devices use to prove their identity and facilitate secure Transport Layer Security (TLS) communications.
  2. Content Encryption Keys - Key Delivery Message (KDM) AES keys that protect content.
  3. Content Integrity Keys - HMAC-SHA-1 keys that protect the integrity of compressed content (integrity pack check parameters).
  4. This step has been deleted
  5. This step has been deleted
  6. TLS secrets - These are transient keys/parameters used or generated in support of TLS and Auditorium Security Messaging (ASM). This step has been deleted
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
9.5.10. Deleted Section 🔗

The section "SPB 1 Firmware Modifications" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

9.5.11. Degraded mode(s) of operation prohibited 🔗
Objective

This procedure is applicable only to FIPS-140-3 certification.

Verify that degraded mode(s) of operation, as defined in FIPS-140-3 , are not implemented.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
9.5.12. Control output inhibition 🔗
Objective

This procedure is applicable only to FIPS-140-3 certification.

Verify that the SPB Type 1 inhibits its control output interface during each error state, as specified in FIPS-140-3 .

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
9.5.13. Maintenance role/interface prohibited 🔗
Objective

This procedure is applicable only to FIPS-140-3 certification.

Verify that a maintenance role/interface, as defined in FIPS-140-3 , is not implemented.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
9.5.14. Self-initiated cryptographic output capability 🔗
Objective

This procedure is applicable only to FIPS-140-3 certification.

Verify that, if the SPB Type 1 supports "self-initiated cryptographic output capability," that a User Role and/or Crypto Officer Role is required to support the AuthorityID requirements of DCI-DCSS, 9.4.2.5 .

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
9.5.15. Self-initiated cryptographic output capability 🔗
Objective

This procedure is applicable only to FIPS-140-3 certification.

Verify the strength and hardness of SPB Type 1 physical security enclosure material(s) are sustained over the SPB Type 1's range of operation, storage, and distribution by review of design documentation. Verify that destructive physical attacks performed on SPB-1 at nominal temperature(s) verified the strength and hardness of SPB Type 1 physical security enclosure material(s).

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
9.5.16. Periodic self-tests 🔗
Objective

This procedure is applicable only to FIPS-140-3 certification.

Verify that the specified Security Policy maximum time between periodic self-tests, as defined in FIPS-140-3 , is not more than one week.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail

Chapter 10. DCI Requirements Review 🔗

Like the previous chapter, this chapter contains procedures for evaluating system design for fidelity to DCI requirements that cannot be tested by direct examination of a finished product. These requirements are different though, because they are not proven by the FIPS 140 certification process. The process of proving these requirements is the same, however. Documentation must be produced and Test Subjects must be instrumented to give the examiner all necessary information to evaluate the design. Manufacturers must produce proof in the form of design documentation for each of the appicable requirement specified in this Chapter. To see which requirements are relevant to a particular Test Subject consult the Design Review sections of Part III. Consolidated Test Procedures .)

To complete a compliance evaluation using the requirements in this section, the examiner must be presented with the documentation detailed below. The examiner must also have access to a Test Sample (a production-grade sample of the system, conforming to the operational capabilities of the Design Review sequence being used). Wherever possible, the examiner should confirm that the documentation matches the Test Sample.

10.1. Type 1 SPB Documentation 🔗

For a Type 1 SPB, it should be possible to validate the requirements in this chapter using much of the test material produced for the FIPS 140 test. It may be necessary for the manufacturer to provide additional information in the case where a requirement is not provable using documentation prepared with only the FIPS 140 test in mind. Manufacturers are encouraged to consider the objectives of this chapter when preparing material for the FIPS 140 test of a Type 1 SPB.

The following documents (repeated from Chapter 9 ) are examples of the types of documentation that will be useful when proving compliance with the requirements presented in this chapter:

  • Master Components List (bill of materials); All items submitted as test evidence to the Testing Organization ( e.g. , software, firmware, hardware, source code, documentation, etc.) must be specified on the Master Components List, along with a unique identifier and version
  • Security policy
  • Data sheets for hardware components
  • Listing of all significant information flows
  • Finite state model
  • Clearly annotated source code
  • Functional specifications
  • Block diagrams
  • Schematics
  • Software design documentation (such as an API or developers guide)
  • Mechanical drawings & assembly drawings (approximately to scale)
  • Printed circuit board layout drawings
  • Cryptographic Key and Critical Security Parameter documentation
  • Delivery and operations procedures
  • Cryptographic Officer & User guidance
  • Configuration management specification
  • Operational testing plan(s), and associated testing equipment
  • Documentation detailing the correspondence of all security rules to the implementation

10.2. Type 2 SPB Documentation 🔗

For a Type 2 SPB, it is necessary to produce documentation to validate the requirements in this chapter. Because a Type 2 SPB is not required to undergo FIPS 140 testing, this documentation will be produced only for the purpose of this DCI compliance test. Note that the documentation need not cover aspects of the design that are not the subject of the requirements.

The following documentation must be supplied:

  • Block diagrams showing chassis partitions, major components, locations of security components, security parameters and security related information flows.
  • Descriptions and functions of all electronic interfaces and user interfaces, for both security and non-security operations. (Proprietary details of non-security related interfaces are not required, however enough information must be supplied to allow the examiner to prove that all security-related interfaces have been fully documented).
  • User and maintenance manual information relating to security, i.e. installation and operation details including user and maintenance roles for electronic access and detailed declarations of capabilities for each role. Also include check lists or instructions from user or maintenance documentation that contain information suggesting security-related instructions, recommended practices, etc. for users and maintenance personel.
  • Analysis of user and maintenance role capabilities reconciled against DCI requirements for "non-security" vs. "security" related access and maintenance.
  • Finite state model, limited to SPB-2 security functional operation (including interaction with the companion type-1 SPB, as applicable).

In addition to the above, any documentation that can be used to prove that the design meets a particular requirement should be provided.

10.3. Forensic Mark IP Disclosure 🔗

For a Test Subject which implements Forensic Marking (FM), it will be necessary to provide, in addition to the documentation listed above, an intellectual property disclosure statement which describes any claims on intellectual property that the manufacturer intends to make on the FM algorithm.

10.4. DCI Requirements for Security Modules 🔗

Each of the subsections below describes a DCI requirement that must be proven by examining the manufacturer's documentation.

10.4.1. Theater System Reliability 🔗
Objective
  • Record Verify that the calculated Mean Time Between Failure (MTBF) for the design. There are no Pass/Fail criteria for this value. Test Subject, as reported by the manufacturer, is not less than 10,000 hours.
  • Record Verify that the calculated Mean Time Between Failure (MTBF) to Repair (MTR) for the design. There Test Subject, as reported by the manufacturer, does not exceed 2 hours. The MTR does not include transit time, i.e., all parts and tools are no Pass/Fail criteria for this value. assumed to be immediately at hand.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
24.3. SDR Projector Design Review Pass/Fail
26.3. HDR Direct View Display Design Review Pass/Fail
27.3. SDR Direct View Display Design Review Pass/Fail
28.3. HDR Projector Design Review Pass/Fail
10.4.2. Theater System Storage Security 🔗
Objective
  • Verify that image and audio essence on storage devices retains its original AES encryption, if present during ingest.
  • Verify that decrypted plaintext (image or audio) essence is never stored on the storage system.
  • Verify that with the exception of subtitle essence, encrypted essence files are decrypted only in real-time during playback.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.3. Security Devices Self-Test Capabilities Deleted Section 🔗
Objective Verify that (to the extent possible) all security devices are designed with self-test capability

The section "Security Devices Self-Test Capabilities" was deleted. The section number is maintained here to announce failures and take themselves out preserve the numbering of service. Supporting Materials Reference Documents DCI-DCSS, 9.4.1 Consolidated Test Sequences Sequence Type 15.3. Integrated IMB Design Review Pass/Fail 20.3. OMB Design Review Pass/Fail 21.3. Integrated IMBO Design Review Pass/Fail 24.3. SDR Projector Design Review Pass/Fail 26.3. HDR Direct View Display Design Review Pass/Fail 27.3. SDR Direct View Display Design Review Pass/Fail 28.3. HDR Projector Design Review Pass/Fail subsequent sections.

10.4.4. Security Entity Physical Protection 🔗
Objective
Verify that the following Security Entities (SE) are contained within Type 1 SPBs:
  • Security Manager (SM)
  • Media Decryptor (MD)
  • Forensic Marker (FM)
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.5. Secure SMS-SM Communication 🔗
Objective

Does not apply to an SMS that is permanently integrated.

Verify that the SMS communicates with the SM under its control using:

  • TLS 1.0, 1.2 or 1.3; and
  • a TCP port other than 1173. the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA , as defined in [RFC-3268] , when TLS 1.0 is used.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.6. Location of Security Manager 🔗
Objective
Using the definition of a Security Manager (SM) and its functions specified in Sections 9.4.2.4, 9.4.3.5, 9.6.1 and 9.6.1.2 of [DCI-DCSS] :
  • Verify that each Media Block (MB) contains all the functions of exactly one SM.
  • Verify that no SM function is implemented outside the Secure Processing Block Type 1 (SPB Type 1) boundaries of an MB.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.7. Deleted Section 🔗

The section "SM Usage of OS Security Features" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.8. Deleted Section 🔗

The section "Secure Remote SPB-SM Communications" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.9. Playback Preparation Deleted Section 🔗
Objective Verify that the SM prepares the security system for playout within 30 minutes prior

The section "Playback Preparation" was deleted. The section number is maintained here to showtime. Supporting Materials Reference Documents DCI-DCSS, 9.4.3.5 Consolidated Test Sequences Sequence Type 15.3. Integrated IMB Design Review Pass/Fail 20.3. OMB Design Review Pass/Fail 21.3. Integrated IMBO Design Review Pass/Fail preserve the numbering of subsequent sections.

10.4.10. Deleted Section 🔗

The section "Special Auditorium Situation Detection" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.11. Prevention of Keying of Compromised SPBs Deleted Section 🔗
Objective Verify that

The section "Prevention of Keying of Compromised SPBs" was deleted. The section number is maintained here to preserve the SM precludes delivery numbering of keys or content to, or play back on, devices reporting a Security Alert. Supporting Materials Reference Documents DCI-DCSS, 9.4.3.5 Consolidated Test Sequences Sequence Type 15.3. Integrated IMB Design Review Pass/Fail 20.3. OMB Design Review Pass/Fail 21.3. Integrated IMBO Design Review Pass/Fail subsequent sections.

10.4.12. Deleted Section 🔗

The section "SPB Authentication" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.13. TLS Session Key Refreshes 🔗

The section "TLS Session Key Refreshes" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.14. LE Key Issuance 🔗

The section "LE Key Issuance" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.15. Maximum Key Validity Period 🔗

The section "Maximum Key Validity Period" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.16. KDM Purge upon Expiry 🔗
Objective
Verify that the Security Manager (SM) deletes from its storage a Key Delivery Message (KDM) (and associated keys) no later than 10 minutes after its playout time window has expired (passed), unless playout is started within the KDM playout time window but the playout time window expires before the end of playout. In the latter case, verify that the SM deletes from its storage the KDM (and associated keys) no later than 10 minutes after (i) the end of the show or (ii) the end of the six (6) hour period following the end of the KDM playout time window, whichever comes first.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.17. Key Usage Time Window Deleted Section 🔗
Objective Verify that the Security Manager (SM) enforces the playback time window specified in the Key Delivery Message (KDM) by delivering content keys to Media Decryptors (MD) along with usage periods fully contained within the KDM validity time window. An exception to this requirement may be made when playout

The section "Key Usage Time Window" was deleted. The section number is started within the KDM playout time window, but the playout time window expires before the end of playout. In this case the show may playout beyond maintained here to preserve the playout time window by a maximum numbering of six (6) hours. Supporting Materials Reference Documents DCI-DCSS, 9.4.3.5 Consolidated Test Sequences Sequence Type 15.3. Integrated IMB Design Review Pass/Fail 20.3. OMB Design Review Pass/Fail 21.3. Integrated IMBO Design Review Pass/Fail subsequent sections

10.4.18. Imaging Device Secure Silicon Device 🔗
Objective
Verify that the Imaging Device SPB includes a secure silicon host device (see Section 9.4.3.6.1 of [DCI-DCSS] ) that contains the SPB's digital certificate.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
24.3. SDR Projector Design Review Pass/Fail
26.3. HDR Direct View Display Design Review Pass/Fail
27.3. SDR Direct View Display Design Review Pass/Fail
28.3. HDR Projector Design Review Pass/Fail
10.4.19. Access to Imaging Device Image Signals 🔗
Objective
Verify that the Imaging Device SPB design does not allow physical access to signals running between the companion SPB and the Imaging Device SPB without breaking the marriage.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
24.3. SDR Projector Design Review Pass/Fail
26.3. HDR Direct View Display Design Review Pass/Fail
27.3. SDR Direct View Display Design Review Pass/Fail
28.3. HDR Projector Design Review Pass/Fail
10.4.20. Systems with Electronic Marriage 🔗
Objective
Verify that an electronic marriage is planned upon installation of a MB Imaging Device pair. Verify that this physical/ electrical connection is battery-backed and monitored 24/7 by the companion SPB and, if broken, shall require a reinstallation (re-marriage) process.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
24.3. SDR Projector Design Review Pass/Fail
26.3. HDR Direct View Display Design Review Pass/Fail
27.3. SDR Direct View Display Design Review Pass/Fail
28.3. HDR Projector Design Review Pass/Fail
10.4.21. Systems Without Electronic Marriage 🔗
Objective

Verify that in the configuration of a permanently married companion SPB (MB) the companion SPB is not field replaceable and require the Imaging Device SPB and companion SPB system to both be replaced in the event of an SPB failure.

If the companion SPB is a MB with single certificate implementation as defined in Section 9.5.1.1 of [DCI-DCSS] , verify that the system contains exactly one leaf certificate.

If the companion SPB is a MB with dual certificate implementation as defined in Section 9.5.1.2 of [DCI-DCSS] , verify that the system contains exactly two leaf certificates.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
24.3. SDR Projector Design Review Pass/Fail
26.3. HDR Direct View Display Design Review Pass/Fail
27.3. SDR Direct View Display Design Review Pass/Fail
28.3. HDR Projector Design Review Pass/Fail
10.4.22. Clock Date-Time-Range 🔗
Objective
Verify that the MB clock has a Date-Time range of at least 20 years.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.23. Clock Setup 🔗
Objective
Verify that the SM clock is set by the manufacturer to within one second of UTC by means of a national time standard (such as WWV).
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.24. Clock Stability 🔗
Objective
If the device is an SM, verify that the clock stability requirement of +/- 30 seconds per month is met.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.25. Repair and Renewal of SPBs 🔗
Objective
Verify that an SPB cannot be repaired or renewed without direct manufacturer action.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
24.3. SDR Projector Design Review Pass/Fail
26.3. HDR Direct View Display Design Review Pass/Fail
27.3. SDR Direct View Display Design Review Pass/Fail
28.3. HDR Projector Design Review Pass/Fail
10.4.26. SPB2 Protected Devices 🔗
Objective

Verify that Type 2 SPB surrounds the following sub-systems:

  1. security environment consisting of a secure silicon chip; input/output signals to the secure silicon chip and the Imaging Device SPB; perimeter access panel monitoring
  2. the Imaging Device image signal processing environment

Verify through physical inspection that a sample device contains the above listed sub-systems in a manner consistent with the documentation.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
24.3. SDR Projector Design Review Pass/Fail
26.3. HDR Direct View Display Design Review Pass/Fail
27.3. SDR Direct View Display Design Review Pass/Fail
28.3. HDR Projector Design Review Pass/Fail
10.4.27. Clock Continuity 🔗
Objective

Verify that the clock is tamper-proof and thereafter may not be reset.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.28. TLS Endpoints Deleted Section 🔗
Objective

Verify that all TLS end points are within The section "TLS Endpoints" was deleted. The section number is maintained here to preserve the physical protection perimeter numbering of the associated SPB. subsequent sections.

Supporting Materials Reference Documents DCI-DCSS, 9.4.5.1 Consolidated Test Sequences Sequence Type 15.3. Integrated IMB Design Review Pass/Fail 20.3. OMB Design Review Pass/Fail 21.3. Integrated IMBO Design Review Pass/Fail
10.4.29. Deleted Section 🔗

The section "Implementation of RRPs" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.30. Deleted Section 🔗

The section "SMS and SPB Authentication and ITM Transport Layer" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.31. Deleted Section 🔗

The section "Idempotency of ITM RRPs" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.32. RRP Synchronism Deleted Section 🔗
Objective

Verify that RRP protocols are synchronous: each pairing must opened and closed before a new RRP The section "RRP Synchronism" was deleted. The section number is opened between any two devices. Nested transactions (in which one end point must communicate with another end point while maintained here to preserve the first waits) are allowed. numbering of subsequent sections.

Supporting Materials Reference Documents DCI-DCSS, 9.4.5.2.3 Consolidated Test Sequences Sequence Type 15.3. Integrated IMB Design Review Pass/Fail 20.3. OMB Design Review Pass/Fail 21.3. Integrated IMBO Design Review Pass/Fail
10.4.33. TLS Mode Bypass Prohibition Deleted Section 🔗
Objective

Verify that except where noted in The section "TLS Mode Bypass Prohibition" was deleted. The section number is maintained here to preserve the [DCI-DCSS] , non-TLS security communications are not used, and that production Digital Cinema security equipment has no provisions for performing security functions in a TLS "bypass" mode. numbering of subsequent sections.

Supporting Materials Reference Documents DCI-DCSS, 9.4.5.2.3 Consolidated Test Sequences Sequence Type 15.3. Integrated IMB Design Review Pass/Fail 20.3. OMB Design Review Pass/Fail 21.3. Integrated IMBO Design Review Pass/Fail
10.4.34. Deleted Section 🔗

The section "RRP Broadcast Prohibition" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.35. Implementation of Proprietary ITMs Deleted Section 🔗
Objective

Verify that any proprietary ITM implemented by equipment suppliers do not communicate over TCP or UDP port 1173, and that such ITMs do not communicate information that The section "Implementation of Proprietary ITMs" was deleted. The section number is maintained here to preserve the subject numbering of any [SMPTE-430-6] commands. subsequent sections.

Supporting Materials Reference Documents DCI-DCSS, 9.4.5.2.3 SMPTE-430-6 Consolidated Test Sequences Sequence Type 15.3. Integrated IMB Design Review Pass/Fail 20.3. OMB Design Review Pass/Fail 21.3. Integrated IMBO Design Review Pass/Fail
10.4.36. Deleted Section 🔗

The section "RRP Initiator" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.37. Deleted Section 🔗

The section "SPB TLS Session Partners" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.38. Deleted Section 🔗

The section "SM TLS Session Partners" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.39. RRP "Busy" and Unsupported Types Deleted Section 🔗
Objective

Verify that unless otherwise noted, an RRP response is allowed to be busy or an unsupported message type The section "RRP 'Busy' and that such a response Unsupported Types" was deleted. The section number is not an error event. maintained here to preserve the numbering of subsequent sections.

Supporting Materials Reference Documents DCI-DCSS, 9.4.5.2.3 Consolidated Test Sequences Sequence Type 15.3. Integrated IMB Design Review Pass/Fail 20.3. OMB Design Review Pass/Fail 21.3. Integrated IMBO Design Review Pass/Fail
10.4.40. RRP Operational Messages Deleted Section 🔗
Objective Verify that Intra-theater Message (ITM) Request-Response Pairs (RRP) category 1 operational messages are transported using: TLS 1.0, 1.2 or 1.3; and a TCP port other than 1173. Supporting Materials Reference Documents [RFC-2246] [RFC-2246] [RFC-8446] DCI-DCSS, 9.4.2.5, 9.4.5.2.4, 9.4.5.2.3.(9) Consolidated Test Sequences Sequence Type 15.3. Integrated IMB Design Review Pass/Fail 20.3. OMB Design Review Pass/Fail 21.3. Integrated IMBO Design Review Pass/Fail

The section "RRP Operational Messages" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.41. Deleted Section 🔗

The section "FM Generic Inserter Requirements" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.42. FM Algorithm General Requirements 🔗
Objective

For a Forensic Marking (FM) embedder:

  1. Verify that single distribution inventory is supported by the FM algorithm.
  2. Verify by examination of the FM embedder intellectual property disclosure that the terms and conditions of use for the FM algorithm are reasonable and non-discriminatory (RAND).
  3. Verify that detection can be performed by the manufacturer or the Rights Owner at the Rights Owner's premises.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.43. FM Insertion Requirements 🔗
Objective
  • Verify that audio (main sound and OBAE, as applicable) and image FM insertion is a real-time ( i.e. , show playback time), in-line process performed in the associated MB, and has a reasonable computational process.
  • Verify that audio (main sound and OBAE, as applicable) and image FM is applied at the earliest point after decryption and prior to the essence being present on any data bus outside the MB.
  • Verify that all FM inserters insert a unique 19-bit or 20-bit "location" Forensic Marking Identification (FMID) that is permanently associated with the associated MB.
  • Verify that all FM inserters insert a 16-bit time stamp that increments by 1 every 15 minutes and resets to zero once per year.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.44. IFM Visual Transparency 🔗
Objective

Verify that IFM is visually transparent to the critical viewer in butterfly tests for motion image content.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.45. IFM Robustness 🔗
Objective

Verify that IFM resists/survives video processing attacks (such as digital-to-analog conversions, including multiple D-A/A-D conversions), re-sampling and re-quantization (including dithering and recompression), common signal enhancements to image contrast and color, resizing, letterboxing, aperture control, low-pass filtering, anti-aliasing, brick wall filtering, digital video noise reduction filtering, frame-swapping, compression, arbitrary scaling (aspect ratio is not necessarily constant), cropping, overwriting, addition of noise and other transformations. Verify that IFM survives collusion (the combining of multiple videos in the attempt to make a different fingerprint or to remove it), format conversion, the changing of frequencies and spatial resolution (among, for example, NTSC, PAL and SECAM, into another and vice versa), horizontal and vertical shifting and camcorder capture and low bit rate compression ( e.g. , 500 Kbps H264, 1.1 Mbps MPEG-1).

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.46. AFM Inaudibility 🔗
Objective

Verify that AFM is inaudible in critical listening A/B tests

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.47. AFM Robustness 🔗
Objective

Verify that AFM resists/survives multiple D/A and A/D conversions, radio frequency or infrared transmissions within the theater, any combination and down conversion of captured channels, re-sampling of channels, time compression/ expansion with pitch shift and pitch preserved, linear speed changes within 10% and pitch-invariant time scaling within 4%. Verify that AFM resists/survives data reduction coding, nonlinear amplitude compression, additive or multiplicative noise frequency response distortion such as equalization, addition of echo, band-pass filtering, flutter and wow and overdubbing.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.48. FM Control Instance 🔗
Objective

Verify that the SM is solely responsible for control of FM marking processes ( i.e. , "on/off") for the auditorium it is installed in and command and control of this function is only via the KDM indicator per [SMPTE-430-1] .

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.49. Deleted Section 🔗

The section "SE Time Stamping" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.50. Deleted Section 🔗

The section "SE Log Authoring" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.51. SPB Log Storage Requirements 🔗
Objective

Verify that log records stored in SPBs are stored in non-volatile memory and are not purge-able. Verify that data is overwritten beginning with the oldest data as new log data is accumulated. Verify that no log records are overwritten unless collected by the SM..

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.52. Deleted Section 🔗

The section "Remote SPB Log Storage Requirements" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.53. MB Log Storage Capabilities 🔗
Objective

Verify that the SM is capable of storing at least 12 months of typical log data accumulation for the auditorium in which it is installed.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.54. Deleted Section 🔗

The section "Logging for Standalone Systems" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.55. Logging of Failed Procedures Deleted Section 🔗
Objective

Verify that failure or refusal The section "Logging of logged events Failed Procedures" was deleted. The section number is also a logged event (as applicable). maintained here to preserve the numbering of subsequent sections.

Supporting Materials Reference Documents DCI-DCSS, 9.4.6.3.7, 9.4.6.3.8, 9.4.6.3.10 Consolidated Test Sequences Sequence Type 15.3. Integrated IMB Design Review Pass/Fail 20.3. OMB Design Review Pass/Fail 21.3. Integrated IMBO Design Review Pass/Fail
10.4.56. SPB Log Failure 🔗
Objective

Verify that behavior of security devices (SPB or SE) is specified and designed to immediately terminate operation, and requires replacement, upon any failure of its secure logging operation.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.57. Log Purging in Failed SPBs 🔗
Objective

Verify that resident log records in failed SPBs (and their contained SEs) are not purge-able except by authorized repair centers, which are capable of securely recovering such log records.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.58. MB Tasks 🔗
Objective
  • Verify that, if included as part of the MB design, decryption and forensic marking of image essence is performed within the SPB boundary of the MB, and that the resulting image signal is passed to the Imaging Device SPB, as appropriate.
  • Verify that, if included as part of the MB design, decryption and forensic marking of audio essence is performed within the SPB boundary of the MB, and that the resulting audio signal is passed to external components.
  • Verify that, if included as part of the MB design, decryption, rendering and forensic marking of OBAE essence is performed within the SPB boundary of the MB, and that the resulting audio signal is passed to external components.
  • Verify that, if included as part of the MB design, decryption of subtitle essence is performed within the SPB boundary of the MB, and that the resulting plaintext essence is passed to external components.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.59. Type 1 SPB RSA Private Keys 🔗
Objective
  • Verify that RSA private keys in a Type 1 SPB which constitute the subject of any certificate having an SM or LS role are (1) generated within the secure silicon device, (2) whether encrypted or not do not exist outside of the secure silicon device and (3) are not accessible to any process external to the secure silicon device.
  • Verify that the entropy source (seed) used in the generation of the above RSA keys (1) is fully contained within the MB's SPB Type 1 and is not dependent on or influenced by any parameter or value external to the SPB, (2) does not enable the export of any information about the seed from the SPB.
  • Verify that the CipherValue elements of the KDM's AuthenticatedPrivate element are decrypted by and within the secure silicon device.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.60. Content Keys Outside Secure Silicon 🔗
Objective

Verify that once decrypted from the KDM (and except when being used during playback) content keys are either cached within the secure silicon IC, or protected by AES key wrapping per [NIST-800-38F] when cached externally to secure silicon within the Media Block.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.61. Prohibition of SPB Type 1 Field Serviceability 🔗
Objective

Verify that SPBs of Type 1 are not field serviceable ( e.g. , SPB Type 1 maintenance access doors shall not be open-able in the field).

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.62. Use of Software Protection Methods 🔗
Objective

Verify that software protection methods are not used to protect CSPs or content essence

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.63. TMS Role 🔗
Objective

Verify that in the event that Exhibition command and control designs include the TMS as a device that interfaces with the SMs, such a TMS is viewed by the security system as an SMS, and carries a digital certificate and follows all other SMS behavior, TLS and ITM communications requirements.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.64. D-Cinema Security Parameter Protection 🔗
Objective

Verify that the following Digital Cinema Security Parameters (DCSPs) receive SPB Type 1 protection, whenever they exist outside of their originally encrypted state:

  1. Watermarking or Fingerprinting command and control - Any of the parameters or keys used in a particular Forensic Marking process.
  2. Logged Data - All log event data and associated parameters constituting a log record or report.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.65. RSA Key Entropy 🔗
Objective

Verify that the mechanism used to generate RSA key pairs must have at least 128-bits of entropy (unpredictability).

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.66. Preloaded Symmetric Key Entropy 🔗
Objective

Verify that AES or TDES symmetric keys pre-loaded into a device are generated with a high quality random number generator with at least 128 bits of entropy (112 bits for TDES).

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.67. MD Media Block Caching of Keys 🔗
Objective

Verify that the Media Decryptor Block is capable of securely caching at least 512 keys keys.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.68. SPB Type 1 Firmware Modifications 🔗
Objective

Verify the following:

  1. The device is designed such that the firmware cannot be modified without the knowledge and permission of the original manufacturer.
  2. The device's firmware modification procedure requires a digital certificate per [SMPTE-430-2] that identifies the authority figure responsible for making the firmware change.
  3. The device logs firmware change information including timestamp, version and operator identity
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.69. SPB Type 1 Log Retention 🔗
Objective

Verify that log records are not purged from a Type 1 SPB in the event of intrusion or other tamper detection.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.70. Deleted Section 🔗

The section "ASM Get Time Frequency" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.71. Deleted Section 🔗

The section "SPB2 Log Memory Availability" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.72. SPB Secure Silicon Requirements 🔗
Objective

Verify that the SPB's Secure Silicon device meets FIPS 140 level 3 "Physical Security" area requirements as defined for "single-chip cryptographic modules". Failure of this verification is cause to fail this test.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.73. SPB Type 1 Battery Life 🔗
Objective
  • Verify that the Type 1 SPB clock's battery has a life of at least 5 years under normal operating conditions
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.74. Companion SPB Retrieve Imaging Device Cert 🔗
Objective

Only applies to a Test Subject that is a Companion SPB (SM).

Verify that the Test Subject retrieves the Imaging Device SPB certificate over the marriage connection.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.75. Log Collection for Married MB 🔗
Objective

Verify that, when integrated within an Imaging Device as a companion SPB, or permanently married to the Imaging Device, the MB provides 24/7 log recording support, and storage of all log records associated with the Imaging Device SPB.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.76. Companion SPB Single Purpose Requirement 🔗
Objective

The following applies only to Test Subjects that are Companion SPBs, i.e. MB designed to operate with an integrated Imaging Device.

Verify that the Test Subject does not operate unless integrated with an Imaging Device SPB. In particular,

  • if the Test Subject is a MB, verify that the Test Subject cannot perform any composition decryption function unless integrated within and married to an Imaging Device SPB.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.77. Deleted Section 🔗

The section "Standalone MB Single Purpose Requirement" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.78. Imaging Device SPB Log Reporting Requirements 🔗
Objective

Verify that the Imaging Device SPB sends log event data across the marriage electrical interface for retention by the companion SPB, as specified in Table 19 of [DCI-DCSS] .

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
24.3. SDR Projector Design Review Pass/Fail
26.3. HDR Direct View Display Design Review Pass/Fail
27.3. SDR Direct View Display Design Review Pass/Fail
28.3. HDR Projector Design Review Pass/Fail
10.4.79. TLS RSA Requirement 🔗
Objective

Verify that the Test Subject, for The section "TLS RSA Requirement" was deleted. The section number is maintained here to preserve the purpose numbering of ASM communications, only supports the TLS CipherSuite "TLS_RSA_WITH_AES_128_CBC_SHA" as specified in [SMPTE-430-6] . subsequent sections.

Supporting Materials Reference Documents DCI-DCSS, 9.4.5.2.4 Consolidated Test Sequences Sequence Type 15.3. Integrated IMB Design Review Pass/Fail 20.3. OMB Design Review Pass/Fail 21.3. Integrated IMBO Design Review Pass/Fail
10.4.80. TLS Authentication of Dual Certificate SM 🔗
Objective

Only applies if the SM uses dual certificates and the SMS is not permanently integrated.

Verify that if the Test Subject's SMS establishes the TLS session with the SM (SM is the TLS server) presents the SM Certificate (SM Cert) shall be presented by to the SM. Verify that if SMS when the Test Subject's SM SMS establishes the a TLS session with SMS (SMS is the TLS server) the Log Signer Certificate (LS Cert) shall be presented by the SM.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.81. Constrained OMB Processing Capability 🔗
Objective

Verify that an OMB does not :

  • Process or generate any Auditorium Security Messages (ASM) or use "port 1173"; Support link encryption;
  • Attempt to authenticate other SPBs;
  • Attempt to interface or communicate with any other SPB (Imaging Device or other MB), except to accept non-security messaging; and
  • Process essence other than the following:
    • Object-Based Audio Essence (OBAE) as defined in Section 3.3 of [DCI-DCSS] ; or
    • Auxiliary Data (AD) essence as defined in [SMPTE-429-14] , subject to the constraints of Section 9.4.2.7 at [DCI-DCSS] .
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
20.3. OMB Design Review Pass/Fail
10.4.82. Export of KDM-Borne Keys 🔗
Objective

Verify that under no circumstances does the SM export any KDM-borne key from the SM's SPB.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
15.3. Integrated IMB Design Review Pass/Fail
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.83. Encrypted Auxiliary Data Processing Deleted Section 🔗
Objective

If the MB under test can decrypt The section "Encrypted Auxiliary Data as defined by [SMPTE-429-14] : Verify that each such decryption takes place only within the MB, and uses only an MDX1 KeyType that Processing" was deleted. The section number is delivered within a KDM. Verify that the MB does not process maintained here to preserve the MDX2 KeyType. Supporting Materials Reference Documents DCI-DCSS, 9.4.2.7, 9.4.3.6.4 SMPTE-429-14 numbering of subsequent sections.

10.4.84. Deleted Section 🔗

The section "OBAE Addendum" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

10.4.85. OBAE FM Robustness 🔗
Objective
  • Verify that forensic marking applied to OBAE essence resists/survives multiple D/A and A/D conversions, radio frequency or infrared transmissions within the theater, any combination and down conversion of captured channels, resampling of channels, time compression/expansion with pitch shift and pitch preserved, linear speed changes within 10% and pitch-invariant time scaling within 4%.
  • Verify that forensic marking applied to OBAE essence resists/survives data reduction coding, nonlinear amplitude compression, additive or multiplicative noise frequency response distortion such as equalization, addition of echo, band-pass filtering, flutter and wow and overdubbing.
Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail
10.4.86. OBAE FM Inaudibility 🔗
Objective

Verify that forensic marking applied to OBAE essence is inaudible in critical listening A/B tests.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
20.3. OMB Design Review Pass/Fail
21.3. Integrated IMBO Design Review Pass/Fail

10.5. DCI Requirements for Imaging Devices 🔗

Each of the subsections below describes a DCI requirement that shall be verified by examining the manufacturer's documentation.

10.5.1. Pixel Visibility (Direct View Display) 🔗
Objective

Verify, according to the following steps, that the display pixel density of the imaging device is equal to or greater than 60 display pixels per degree when viewed at 1.6 screen heights:

  1. Based on manufacturer's information, determine the number of display pixels R h of the imaging device in the vertical direction when displaying the 4096x2160 DCI container. The term display pixel is defined at [DV-ADD] .
  2. Compute the pixel density at viewing distance of 1.6 screen heights P 1.6 according to the equation
    P 1.6 = 1 / arctan(1 / (1.6 · R h ))
    where arctan() is the inverse-tangent function that returns units of degrees, i.e. arctan(1) = 45 degrees.
  3. A value P 1.6 smaller than 60 display pixels per degree is cause to fail this test.

The nominal average human vision performance called 20/20 vision corresponds to the ability to resolve 30 cycles per degree. On an imaging device the minimum pixel density that can show 30 cycles per degree is 60 pixels per degree.

Supporting Materials
Reference Documents
Consolidated Test Sequences
Sequence Type
26.3. HDR Direct View Display Design Review Pass/Fail
27.3. SDR Direct View Display Design Review Pass/Fail

Part III. Consolidated Test Procedures 🔗

The chapters in this part contain Test Sequences and a standardized Test Report for testing Digital Cinema equipment. Each Test Sequence subjects a Test Subject to a set of Tests selected from Part I. Procedural Tests and Part II. Design Evaluation Guidelines .

The Test Subject is specified at the opening of each Test Sequence chapter and at Table 11.2 . Each Test Subject comprises a single certificated device .

Chapter 11. Testing Policy and Reporting 🔗

11.1. Test Reports 🔗

A Test Report consists of information about a Test Session recorded as specified in Table 11.1 . All fields shall be filled in.

Each certificated device listed on line 9 of a Test Report, with the exception of an SMS, shall be a DCI compliant certificated device as defined below.

NOTE 1: Certificated devices listed on line 9 of a Test Report might have achieved DCI compliance against different versions of the CTP.

EXAMPLE 1: An IMB that achieved DCI-compliance per CTP 1.3 can be used when performing Chapter 24. SDR Projector Consolidated Test Sequence in this version of the CTP.

For a permanently married Imaging Device, line 9 of a Test Report shall identify the Imaging Device and companion device (per [DCI-DCSS] , Section 9.4.3.6.6).

For an integrated SMS, line 9 of a Test Report shall identify the SMS and IMB (per [DCI-DCSS] , Section 9.4.2.5, first bullet).

To assure clarity, line 9 of a Test Report shall include the text "permanently married" or "permanently integrated" as applicable.

Table 11.1 . Test Session Data 🔗
1. Reporting date
2. Test Start Date
3. CTP version
4. Name of Testing Organization
5. Address of Testing Organization
6. Name of Test Operator
7. Test location (if not at Testing Organization's site)
8. Name of Test Subject Representative
9. Address of Test Subject Representative
10. Make and model of Test Subject (to be included on the DCI listing hot link)
11. Serial and model numbers identifying each of the participating certificated devices, including software and/or firmware version numbers as applicable.
12. Test sequence performed (select one) ☐ Chapter 15. Integrated IMB Consolidated Test Sequence
☐ Chapter 20. OMB Consolidated Test Sequence
☐ Chapter 21. Integrated IMBO Consolidated Test Sequence
☐ Chapter 24. SDR Projector Consolidated Test Sequence
☐ Chapter 26. HDR Direct View Display Consolidated Test Sequence
☐ Chapter 27. SDR Direct View Display Consolidated Test Sequence
☐ Chapter 28. HDR Projector Consolidated Test Sequence
13. Test status (select one) ☐ Pass
☐ Fail
14. Sequences performed (select one) ☐ Test Sequence and Design Review
☐ Confidence Sequence (Confidence Retest)

A Test Session is the collection of Test Results gathered by subjecting a set of certificated devices to one of the Test Sequences listed in Table 11.2 , with the set of certificated devices including at least those required by the Test Sequence. A certificated device is defined by the combination of its manufacturer, product name and model/version number.

NOTE 2: the set of certificated devices used for a Test Session cannot change, e.g., the same IMB is used for all tests specified in a Test Session against Chapter 24. SDR Projector Consolidated Test Sequence .

NOTE 3: two IMBs with different model/version number are not the same IMB when creating a Test Session.

Table 11.2 . Test Sequences 🔗
Test sequence Test subject Certificated device that comprise the Test subject Certificated devices required to perform the Test Sequence
Chapter 15. Integrated IMB Consolidated Test Sequence Integrated IMB IMB Imaging Device, IMB, SMS
Chapter 20. OMB Consolidated Test Sequence Outboard Media Block OMB Imaging Device, OMB, IMB, SMS
Chapter 21. Integrated IMBO Consolidated Test Sequence Integrated IMBO IMBO Imaging Device, IMBO, SMS
Chapter 24. SDR Projector Consolidated Test Sequence Projector Projector Projector, IMB or IMBO, SMS
Chapter 26. HDR Direct View Display Consolidated Test Sequence Direct View Display Direct View Display Direct View Display, IMB or IMBO, SMS
Chapter 27. SDR Direct View Display Consolidated Test Sequence Direct View Display Direct View Display Direct View Display, IMB or IMBO, SMS
Chapter 28. HDR Projector Consolidated Test Sequence Projector Projector Projector, IMB or IMBO, SMS

A Test Result is the outcome of evaluating a set of certificated devices against the steps and requirements of a single Test specified in this version of the CTP. Each Test specifies the type of test result generated, either PASS, FAIL or measured data.

A Test Result may, at the discretion of the Testing Organization, be reused across multiple Test Sessions, and thus different Test Sequences, if and only if (a) the underlying test is identical and (b) the set of certificated devices subjected to the Test are identical. The Testing Organization is required to attest that both conditions (a) and (b) are met.

NOTE 4: The above constraints require the supplier(s) of each certificated device to present to the Testing Organization the Test Results to be reused.

EXAMPLE 2: the Test Result obtained by subjecting an SMS to 8.1.1. Storage System Ingest Interface in the course of performing a Test Session against Chapter 15. Integrated IMB Consolidated Test Sequence can be reused when subjecting the same SMS (as defined by its manufacturer, product name and model/version number) to the same test procedure in the course of performing a Test Session against Chapter 21. Integrated IMBO Consolidated Test Sequence .

EXAMPLE 3: the Test Result obtained by subjecting an IMB to 5.1.1. SPB Digital Certificate as specified in CTP 1.2.1 cannot be reused when subjecting the same IMB against the same test procedure in this version of CTP since 5.1.1. SPB Digital Certificate is not identical in both versions of the CTP.

The status of the Test Session is PASS if none of the test results is FAIL; the status of the Test Session is FAIL otherwise.

The certificated device that comprises a Test Subject of a Test Session whose status is PASS is a “DCI compliant certificated device”.

NOTE 5: A “DCI compliant certificated device” is defined in the context of a specific Test Session, i.e., for a particular set of certificated devices and set of tests defined in a specific version of the CTP. As such, while the certificated device remains DCI-compliant in perpetuity within that context, not all Test Results associated with the DCI compliant certificated device can necessarily be reused in all future Test Sessions in which the certificated device is involved, as described in this section.

11.2. Testing Policy 🔗

11.2.1. Definitions 🔗
Non-Programmable Related Components (NPRC)
Any non-programmable devices that do not affect compliance of the current DCSS, e.g., nonprogrammable integrated circuits, resistors, capacitors, transistors, inductors, lamps, fans, displays, power supplies, switches, connectors, fuses, passive components, mechanical components, etc.
11.2.2. Combining Devices into Families 🔗

An entity may aggregate some of its products that only have different NPRC s into a family group by attesting to the similarity of that family group in a letter, signed by a person who has authority to bind the entity under test to the terms of said letter. The letter shall be sent to the contracted licensed test entity and to DCI at dci.info@dcimovies.com.

The letter, which will be attached to the detailed report of the tested device, will clearly and comprehensively provide detailed information and justification as described below:

  • Clear justification for combining various products into a family group.
  • Itemized model number and description of the product tested and each of the products proposed to be in the same family group.
  • Clear itemized differences between each product model in a proposed family group.
  • Attest that all SPB-1 electrical, mechanical, and data-protocol interfaces and behavior are identical among all models of the proposed family group.
  • Attest that all implementations of SPB-2 normative device requirements are identical among all models of the proposed family group.

Further, the form specified in Table 11.3 shall be attached to the letter to identify the general family group information. This form will be published with the summary report of the tested device on the DCI Compliant Family Groups web site page.

Table 11.3 . General family group information 🔗
Manufacturer
Testament Submission Date
Equipment Tested
Family Item 0 Make
Model
Version
Family Item 1 Make
Model
Version
Family Item 2 Make
Model
Version
(add items as needed)
Printed Name
Job Title
Signature
11.2.3. Equipment Component Failures during Testing 🔗
11.2.3.1. Failures within the Test Subject 🔗

If any NPRC s fail within a Test Subject during CTP testing, the components may be replaced with equivalent units (having identical technical specifications) and testing resumed from a test point before any anomalous behavior was first observed. In order to assure compliance, the DCI licensed entity will determine the appropriate resumption point and continue testing all procedures thereafter in numerical order.

If any programmable components (e.g., FPGAs) fail within a Test Subject during CTP testing and it can be shown rigorously by the manufacturer that a completely identical component with identical programming is available (same component, version and programming), the programmable component may be replaced with the identical component and testing resumed from a test point before any anomalous behavior was first observed. In order to assure compliance, the DCI licensed entity will determine the appropriate resumption point and continue testing all procedures thereafter in numerical order.

It is recognized that when an SPB-1 or SPB-2 is replaced, the private key will necessarily change. However, the certificate formulation (e.g., digest method, subject name component values (O, OU), subject name CN roles, RSA, key length, extensions, etc.) will need to be identical to that of the certificate in the original SPB so as to result in the same system behavior.

11.2.3.2. Failures of Devices Connected to the Test Subject 🔗

Any device that fails during CTP testing that is connected to the Test Subject may be repaired and then verified as to its correct behavior. If correct behavior is verified, testing may resume from a test point before any anomalous behavior was first observed.

11.2.4. Changes to Previously DCI CTP Compliant Devices 🔗
11.2.4.1. General 🔗

Once compliance has been established for a particular device model per this specification, all product changes shall maintain compliance with the [DCI-DCSS] and this specification. Product changes may require retesting to ensure continued compliance. For the avoidance of doubt, no retesting is required if there are no product changes.

11.2.4.2. SPB Type 1 (SPB-1) Devices 🔗

Changes of any kind may require retesting of the SPB-1 device for FIPS 140 compliance by a Cryptographic Module Validation Program (CMVP) testing laboratory. The extent of retesting of FIPS compliance shall be at the determination of the CMVP testing laboratory. Device manufacturers shall notify DCI at dci.info@dcimovies.com of all SPB-1 upgrades prior to deployment, identifying all relevant component version numbers.

11.2.4.3. NPRC 🔗

Replacing NPRC s with technically equivalent components will not require retesting.

11.2.4.4. Software/Firmware and Confidence Retesting 🔗

All changes to software and firmware shall maintain compliance with the [DCI-DCSS] and this specification. Device manufacturers shall notify DCI at dci.info@dcimovies.com of all upgrades prior to deployment, identifying all relevant component version numbers.

Changes to software or firmware shall require Confidence Retesting by a licensed DCI test entity on a “three-year or four-upgrade cycle” if either

  1. one, two or three upgrades are deployed within three years of the CTP compliance date, the device shall undergo a Confidence Retest prior to its third-year anniversary date; or
  2. a fourth upgrade is intended to be deployed within three years of the CTP compliance date, the device shall undergo a Confidence Retest with the cumulative changes of all four upgrades installed prior to the deployment of that fourth upgrade.

Any Confidence Retest of updated software or firmware shall be conducted against the version of this specification in force as of the date the device is submitted for Confidence Retest, subject to the following exceptions.

To minimize barriers to upgrades, SPB devices that are already listed on the Compliant Equipment page of the DCI website may be excused from CTP tests associated with the bullets below for purposes of a Confidence Retest:

Confidence Retests have been selected to assure that software/firmware changes have not impacted critical security functionality. Hardware, integrated circuit, FIPS related issues, etc., are addressed by Sections 11.2.4.2. SPB Type 1 (SPB-1) Devices and 11.2.4.3. NPRC .

Chapter 12. Deleted Chapter 🔗

The chapter "Digital Cinema Package (DCP) Consolidated Test Sequence" was deleted. The chapter number is maintained here to preserve the numbering of subsequent sections.

Chapter 13. Deleted Chapter 🔗

The chapter "Digital Cinema Server Consolidated Test Sequence" was deleted. The chapter number is maintained here to preserve the numbering of subsequent sections.

Chapter 14. Deleted Chapter 🔗

The chapter "Standalone D-Cinema Projector Consolidated Test Sequence" was deleted. The chapter number is maintained here to preserve the numbering of subsequent sections.

Chapter 15. Integrated IMB Consolidated Test Sequence 🔗

15.1. Overview 🔗

The test sequence defined in this chapter is intended to be used to test a integrated Image Media Block (IMB) as the Test Subject. The configuration and architecture of the system may vary, but the test sequence requires that the system consists of at least a light processing system including electronic and optical components (Projector), an Image Media Block (containing a Security Manager, Media Decryptor, etc.), and a Screen Management Server (SMS). For the purpose of this test, the Test Operator may substitute a Theater Management Server (TMS) for the SMS if it implements the required functionality. Wherever a test procedure refers to an SMS, the equivalent TMS may also be used.

For the purpose of compliance testing as defined in this Chapter, the spatial resolution of the projector shall be no less than that of the Media Block.

Before performing the test sequence provided below, the Test Operator should read and understand the documentation provided with the Test Subject. If adequate documentation is not available, a Test Subject Representative should be available to provide assistance during the test session.

15.2. Integrated IMB Test Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 3.5.1. KDM NonCriticalExtensions Element
2 3.5.2. ETM IssueDate Field Check
3 3.5.4. Structure ID Check
4 3.5.5. Certificate Thumbprint Check
5 3.5.7. KeyInfo Field Check
6 3.5.8. KDM Malformations
7 3.5.9. KDM Signature
8 5.1.1. SPB Digital Certificate
9 5.3.2.1. Log Structure
10 5.3.2.3. Log Sequence Numbers
11 5.3.2.6. Log Report Signature Validity
12 5.4.1.1. FrameSequencePlayed Event
13 5.4.1.2. CPLStart Event
14 5.4.1.3. CPLEnd Event
15 5.4.1.4. PlayoutComplete Event
16 5.4.1.5. CPLCheck Event
17 5.4.1.6. KDMKeysReceived Event
18 5.4.1.7. KDMDeleted Event
19 5.4.2.6. SPBStartup and SPBShutdown Events
20 5.4.2.7. SPBOpen and SPBClose Events
21 5.4.2.8. SPBClockAdjust Event
22 5.4.2.9. SPBMarriage and SPBDivorce Events
23 5.4.2.10. SPBSoftware Event
24 5.4.2.11. SPBSecurityAlert Event (data only)
25 6.1.1. Image Integrity Checking
26 6.1.2. Sound Integrity Checking
27 6.1.4. Restriction of Keying to MD Type
28 6.1.5. Restriction of Keying to Valid CPLs
29 6.1.8. Content Key Extension, End of Engagement
30 6.1.9. ContentAuthenticator Element Check
31 6.1.10. KDM Date Check
32 6.1.11. KDM TDL Check
33 6.1.12. Maximum Number of DCP Keys
34 6.1.13. CPL Id Check
35 6.1.15. Restriction of Playback in Absence of Integrity Pack Metadata
36 6.1.19. Plurality of Media Block Identity Certificates
37 6.1.20. Validity of SPB Certificates
38 6.3.1. Clock Adjustment
39 6.3.2. SPB Type 1 Clock Battery
40 6.3.3. Clock Resolution
41 6.4.1. FM Application Constraints
42 6.4.2. Granularity of FM Control
43 6.4.3. FM Payload
44 6.4.4. FM Audio Bypass
45 6.4.5. Selective Audio FM Control
46 6.5.1. Playback of Image Only Material
47 6.5.2. Decoder Requirements
48 6.6.1. Digital Audio Interfaces
49 6.6.2. Audio Sample Rate Conversion
50 6.6.3. Audio Delay Setup
51 6.6.4. Click Free Splicing of Audio Track Files
52 6.7.1. Media Block Overlay
53 6.7.4. Default Timed Text Font
54 6.7.6. Timed Text Decryption
55 7.3.2. Companion SPBs with Electronic Marriage
56 7.3.3. Companion SPB Marriage Break Key Retaining
57 8.1.1. Storage System Ingest Interface 58 8.1.2. Storage System Capacity 59 8.1.3. Storage System Redundancy
60 58 8.1.4. Storage System Performance
61 59 8.2.2. Show Playlist Creation (data only)
62 60 8.2.3. Show Playlist Format
63 61 8.2.5. Automation Control and Interfaces
64 62 8.2.6. Interrupt Free Playback
65 63 8.2.7. Artifact Free Transition of Image Format
66 64 8.2.8. Restarting Playback
67 65 8.2.9. SMS User Accounts
68 66 8.2.10. SMS Operator Identification
69 67 8.2.11. SMS Identity and Certificate
70 68 8.2.12. Content Keys and TDL check
71 69 8.2.14. KDM Content Keys Check
72 70 8.2.15. Validity of SMS Certificates

15.3. Integrated IMB Design Review 🔗

For each requirement listed in the table below, prove that the system design meets the requirement by identifying the software or hardware mechanism that implements the requirement and analyzing the design to assure that the requirement has been met, subject to stipulated conditions. If a proof cannot be made, the design will be considered non-compliant with regard to the requirement. To perform this analysis the examiner will require access to exhibit documents (system design artifacts) such as schematic diagrams, implementation source code, unit test source code, state diagrams, design notes, etc. See Chapter 9: FIPS Requirements for a Type 1 SPB and Chapter 10: DCI Requirements Review for more information.

For each requirement, the examiner must record the identifiers of the exhibits consulted in proving the requirement, including applicable version identifiers, section or sheet numbers, grid identifiers, etc., and the examiner must record Pass or Fail to indicate whether or not the requirement has been met by the design. The examiner may also record any notes relevant to interpreting the exhibits and to the determination of the compliance status.

Step Procedure Pass Fail Exhibit Identifiers
1 9.5.1. SM Operating Environment
2 9.5.3. SPB Type 1 Tamper Responsiveness
3 9.5.6. SPB Type 1 FIPS Requirements
4 9.5.8. Asymmetric Key Generation
5 9.5.9. Critical Security Parameter Protection
6 9.5.11. Degraded mode(s) of operation prohibited
7 9.5.12. Control output inhibition
8 9.5.13. Maintenance role/interface prohibited
9 9.5.14. Self-initiated cryptographic output capability
10 9.5.15. Self-initiated cryptographic output capability
11 9.5.16. Periodic self-tests
12 10.4.1. Theater System Reliability
13 10.4.2. Theater System Storage Security
14 10.4.3. Security Devices Self-Test Capabilities 15 10.4.4. Security Entity Physical Protection
16 15 10.4.5. Secure SMS-SM Communication
17 16 10.4.6. Location of Security Manager
18 10.4.9. Playback Preparation 19 10.4.11. Prevention of Keying of Compromised SPBs 20 17 10.4.16. KDM Purge upon Expiry
21 10.4.17. Key Usage Time Window 22 18 10.4.22. Clock Date-Time-Range
23 19 10.4.23. Clock Setup
24 20 10.4.24. Clock Stability
25 21 10.4.25. Repair and Renewal of SPBs
26 22 10.4.27. Clock Continuity
27 10.4.28. TLS Endpoints 28 10.4.32. RRP Synchronism 29 10.4.33. TLS Mode Bypass Prohibition 30 10.4.35. Implementation of Proprietary ITMs 31 10.4.39. RRP "Busy" and Unsupported Types 32 10.4.40. RRP Operational Messages 33 23 10.4.42. FM Algorithm General Requirements
34 24 10.4.43. FM Insertion Requirements
35 25 10.4.44. IFM Visual Transparency
36 26 10.4.45. IFM Robustness
37 27 10.4.46. AFM Inaudibility
38 28 10.4.47. AFM Robustness
39 29 10.4.48. FM Control Instance
40 30 10.4.51. SPB Log Storage Requirements
41 31 10.4.53. MB Log Storage Capabilities
42 10.4.55. Logging of Failed Procedures 43 32 10.4.56. SPB Log Failure
44 33 10.4.57. Log Purging in Failed SPBs
45 34 10.4.58. MB Tasks
46 35 10.4.59. Type 1 SPB RSA Private Keys
47 36 10.4.60. Content Keys Outside Secure Silicon
48 37 10.4.61. Prohibition of SPB Type 1 Field Serviceability
49 38 10.4.62. Use of Software Protection Methods
50 39 10.4.63. TMS Role
51 40 10.4.64. D-Cinema Security Parameter Protection
52 41 10.4.65. RSA Key Entropy
53 42 10.4.66. Preloaded Symmetric Key Entropy
54 43 10.4.67. MD Media Block Caching of Keys
55 44 10.4.68. SPB Type 1 Firmware Modifications
56 45 10.4.69. SPB Type 1 Log Retention
57 46 10.4.72. SPB Secure Silicon Requirements
58 47 10.4.73. SPB Type 1 Battery Life
59 48 10.4.74. Companion SPB Retrieve Imaging Device Cert
60 49 10.4.75. Log Collection for Married MB
61 50 10.4.76. Companion SPB Single Purpose Requirement
62 10.4.79. TLS RSA Requirement 63 51 10.4.80. TLS Authentication of Dual Certificate SM
64 52 10.4.82. Export of KDM-Borne Keys

15.4. Integrated IMB Confidence Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 5.1.1. SPB Digital Certificate
2 5.4.1.6. KDMKeysReceived Event
3 5.4.2.10. SPBSoftware Event
4 6.1.5. Restriction of Keying to Valid CPLs
5 6.1.8. Content Key Extension, End of Engagement
6 6.1.9. ContentAuthenticator Element Check
7 6.1.11. KDM TDL Check
8 6.1.20. Validity of SPB Certificates
9 6.3.1. Clock Adjustment
10 6.4.3. FM Payload
11 7.3.2. Companion SPBs with Electronic Marriage
12 7.3.3. Companion SPB Marriage Break Key Retaining
13 8.2.7. Artifact Free Transition of Image Format
14 8.2.11. SMS Identity and Certificate
15 8.2.12. Content Keys and TDL check
16 8.2.15. Validity of SMS Certificates

Chapter 16. Deleted Chapter 🔗

The chapter "Link Decryptor/Encryptor Consolidated Test Sequence" was deleted. The chapter number is maintained here to preserve the numbering of subsequent sections.

Chapter 17. Deleted Chapter 🔗

The chapter "Digital Cinema Server Consolidated Confidence Sequence" was deleted. The chapter number is maintained here to preserve the numbering of subsequent sections.

Chapter 18. Deleted Chapter 🔗

The chapter "Standalone D-Cinema Projector Consolidated Test Sequence" was deleted. The chapter number is maintained here to preserve the numbering of subsequent sections.

Chapter 19. Deleted Chapter 🔗

The chapter "Integrated IMB Consolidated Confidence Sequence" was moved to 15.4. Integrated IMB Confidence Sequence . The chapter number is maintained here to preserve the numbering of subsequent sections.

Chapter 20. OMB Consolidated Test Sequence 🔗

20.1. Overview 🔗

The test sequence defined in this chapter is intended to be used to test an Outboard Media Block (OMB) as the Test Subject. The configuration and architecture of the system may vary, but the test sequence requires that the system consists of at least an OMB, Projector, IMB and SMS. For the purpose of this test, the Test Operator may substitute a Theater Management Server/System (TMS) for the SMS if it implements the required functionality. Wherever a test procedure refers to an SMS, the equivalent TMS may also be used.

Digital cinema systems that include an OMB operate in Multiple Media Block (MMB) mode, wherein the SMS is responsible for managing playout processes of the OMB and IMB, and the IMB provides synchronization to the OMB. The IMB must also be able to play only a portion of the total content in a composition, as the OMB will be handling some of the content. Thus, the IMB and SMS must be "MMB Capable" to function within a MMB architecture. This Chapter contains specific tests for the IMB and SMS to test for this capability.

Before performing the test sequence provided below, the Test Operator should read and understand the documentation provided with the Test Subject. If adequate documentation is not available, a Test Subject Representative should be available to provide assistance during the test session.

20.2. OMB Test Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 3.5.10. KDM NonCriticalExtensions Element (OBAE)
2 3.5.11. ETM IssueDate Field Check (OBAE)
3 3.5.12. Structure ID Check (OBAE)
4 3.5.13. Certificate Thumbprint Check (OBAE)
5 3.5.14. KeyInfo Field Check (OBAE)
6 3.5.15. KDM Malformations (OBAE)
7 3.5.16. KDM Signature (OBAE)
8 5.1.1. SPB Digital Certificate
9 5.3.2.1. Log Structure
10 5.3.2.7. Log Sequence Numbers (OBAE)
11 5.3.2.8. Log Report Signature Validity (OBAE)
12 5.4.1.8. FrameSequencePlayed Event (OBAE)
13 5.4.1.9. CPLStart Event (OBAE)
14 5.4.1.10. CPLEnd Event (OBAE)
15 5.4.1.11. PlayoutComplete Event (OBAE)
16 5.4.1.12. CPLCheck Event (OBAE)
17 5.4.1.13. KDMKeysReceived Event (OBAE)
18 5.4.1.14. KDMDeleted Event (OBAE)
19 5.4.2.6. SPBStartup and SPBShutdown Events
20 5.4.2.8. SPBClockAdjust Event
21 5.4.2.10. SPBSoftware Event
22 5.4.2.11. SPBSecurityAlert Event (data only)
23 6.1.14. CPL Id Check (OBAE)
24 6.1.15. Restriction of Playback in Absence of Integrity Pack Metadata
25 6.1.16. Restriction of Keying to MDEK Type (OBAE)
26 6.1.17. OBAE Integrity Checking
27 6.1.18. Content Key Extension, End of Engagement (OBAE)
28 6.1.19. Plurality of Media Block Identity Certificates
29 6.1.20. Validity of SPB Certificates
30 6.1.21. Maximum Number of DCP Keys (OBAE)
31 6.1.22. Restriction of Keying to Valid CPLs (OBAE)
32 6.1.23. ContentAuthenticator Element Check (OBAE)
33 6.1.24. KDM Date Check (OBAE)
34 6.3.1. Clock Adjustment
35 6.3.2. SPB Type 1 Clock Battery
36 6.3.4. Clock Resolution (OMB)
37 6.3.5. Clock Adjustment (OMB)
38 6.4.6. FM Application Constraints (OBAE)
39 6.4.7. Granularity of FM Control (OBAE)
40 6.4.8. FM Payload (OBAE)
41 6.4.9. FM Audio Bypass (OBAE)
42 6.5.1. Playback of Image Only Material
43 6.8.1. Click Free Splicing of OBAE Track Files
44 6.8.2. OBAE Delay Setup
45 6.8.3. Maximum Bitrate OBAE
46 6.8.4. OBAE Rendering Expectations
47 8.1.6. Storage System Performance (OBAE)
48 8.2.13. Content Keys and TDL check (OBAE)
49 8.2.14. KDM Content Keys Check
50 8.2.16. Interrupt Free Playback (OBAE)
51 8.2.17. Restarting Playback (OBAE)
52 8.2.18. Show Playlist Creation (OBAE) (data only)
53 8.2.20. SMS Operator Identification (OBAE)

20.3. OMB Design Review 🔗

For each requirement listed in the table below, prove that the system design meets the requirement by identifying the software or hardware mechanism that implements the requirement and analyzing the design to assure that the requirement has been met, subject to stipulated conditions. If a proof cannot be made, the design will be considered non-compliant with regard to the requirement. To perform this analysis the examiner will require access to exhibit documents (system design artifacts) such as schematic diagrams, implementation source code, unit test source code, state diagrams, design notes, etc. See Chapter 9: FIPS Requirements for a Type 1 SPB and Chapter 10: DCI Requirements Review for more information.

For each requirement, the examiner must record the identifiers of the exhibits consulted in proving the requirement, including applicable version identifiers, section or sheet numbers, grid identifiers, etc., and the examiner must record Pass or Fail to indicate whether or not the requirement has been met by the design. The examiner may also record any notes relevant to interpreting the exhibits and to the determination of the compliance status

Step Procedure Pass Fail Exhibit Identifiers
1 9.5.1. SM Operating Environment
2 9.5.3. SPB Type 1 Tamper Responsiveness
3 9.5.6. SPB Type 1 FIPS Requirements
4 9.5.8. Asymmetric Key Generation
5 9.5.9. Critical Security Parameter Protection
6 9.5.11. Degraded mode(s) of operation prohibited
7 9.5.12. Control output inhibition
8 9.5.13. Maintenance role/interface prohibited
9 9.5.14. Self-initiated cryptographic output capability
10 9.5.15. Self-initiated cryptographic output capability
11 9.5.16. Periodic self-tests
12 10.4.1. Theater System Reliability
13 10.4.2. Theater System Storage Security
14 10.4.3. Security Devices Self-Test Capabilities 15 10.4.4. Security Entity Physical Protection
16 15 10.4.5. Secure SMS-SM Communication
17 16 10.4.6. Location of Security Manager
18 10.4.9. Playback Preparation 19 10.4.11. Prevention of Keying of Compromised SPBs 20 17 10.4.16. KDM Purge upon Expiry
21 10.4.17. Key Usage Time Window 22 18 10.4.22. Clock Date-Time-Range
23 19 10.4.23. Clock Setup
24 20 10.4.24. Clock Stability
25 21 10.4.25. Repair and Renewal of SPBs
26 22 10.4.27. Clock Continuity
27 10.4.28. TLS Endpoints 28 10.4.32. RRP Synchronism 29 10.4.33. TLS Mode Bypass Prohibition 30 10.4.35. Implementation of Proprietary ITMs 31 10.4.39. RRP "Busy" and Unsupported Types 32 10.4.40. RRP Operational Messages 33 23 10.4.42. FM Algorithm General Requirements
34 24 10.4.43. FM Insertion Requirements
35 25 10.4.48. FM Control Instance
36 26 10.4.51. SPB Log Storage Requirements
37 27 10.4.53. MB Log Storage Capabilities
38 10.4.55. Logging of Failed Procedures 39 28 10.4.56. SPB Log Failure
40 29 10.4.57. Log Purging in Failed SPBs
41 30 10.4.58. MB Tasks
42 31 10.4.59. Type 1 SPB RSA Private Keys
43 32 10.4.60. Content Keys Outside Secure Silicon
44 33 10.4.61. Prohibition of SPB Type 1 Field Serviceability
45 34 10.4.62. Use of Software Protection Methods
46 35 10.4.63. TMS Role
47 36 10.4.64. D-Cinema Security Parameter Protection
48 37 10.4.65. RSA Key Entropy
49 38 10.4.66. Preloaded Symmetric Key Entropy
50 39 10.4.67. MD Media Block Caching of Keys
51 40 10.4.68. SPB Type 1 Firmware Modifications
52 41 10.4.69. SPB Type 1 Log Retention
53 42 10.4.72. SPB Secure Silicon Requirements
54 43 10.4.73. SPB Type 1 Battery Life
55 10.4.79. TLS RSA Requirement 56 44 10.4.80. TLS Authentication of Dual Certificate SM
57 45 10.4.81. Constrained OMB Processing Capability
58 46 10.4.82. Export of KDM-Borne Keys
59 47 10.4.85. OBAE FM Robustness
60 48 10.4.86. OBAE FM Inaudibility

20.4. OMB Confidence Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 5.1.1. SPB Digital Certificate
2 5.4.1.13. KDMKeysReceived Event (OBAE)
3 5.4.2.10. SPBSoftware Event
4 6.1.18. Content Key Extension, End of Engagement (OBAE)
5 6.1.20. Validity of SPB Certificates
6 6.1.20. Validity of SPB Certificates
7 6.1.22. Restriction of Keying to Valid CPLs (OBAE)
8 6.1.23. ContentAuthenticator Element Check (OBAE)
9 6.3.5. Clock Adjustment (OMB)
10 6.4.8. FM Payload (OBAE)
11 8.2.13. Content Keys and TDL check (OBAE)

Chapter 21. Integrated IMBO Consolidated Test Sequence 🔗

21.1. Overview 🔗

The test sequence defined in this chapter is intended to be used to test an integrated Image Media Block with OMB functions (IMBO) as the Test Subject. The configuration and architecture of the system may vary, but the test sequence requires that the system consists of at least a light processing system including electronic and optical components (Projector), an IMBO (containing a Security Manager, Media Decryptors, image, main sound and OBAE sound processing, etc.), and a Screen Management Server/System (SMS). For the purpose of this test, the Test Operator may substitute a Theater Management Server/System (TMS) for the SMS if it implements the required functionality. Wherever a test procedure refers to an SMS, the equivalent TMS may also be used.

For the purpose of compliance testing as defined in this Chapter, the spatial resolution of the projector shall be no less than that of the Media Block.

Before performing the test sequence provided below, the Test Operator should read and understand the documentation provided with the Test Subject. If adequate documentation is not available, a Test Subject Representative should be available to provide assistance during the test session.

21.2. Integrated IMBO Test Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 3.5.1. KDM NonCriticalExtensions Element
2 3.5.2. ETM IssueDate Field Check
3 3.5.4. Structure ID Check
4 3.5.5. Certificate Thumbprint Check
5 3.5.7. KeyInfo Field Check
6 3.5.8. KDM Malformations
7 3.5.9. KDM Signature
8 5.1.1. SPB Digital Certificate
9 5.3.2.1. Log Structure
10 5.3.2.3. Log Sequence Numbers
11 5.3.2.6. Log Report Signature Validity
12 5.4.1.1. FrameSequencePlayed Event
13 5.4.1.2. CPLStart Event
14 5.4.1.3. CPLEnd Event
15 5.4.1.4. PlayoutComplete Event
16 5.4.1.5. CPLCheck Event
17 5.4.1.6. KDMKeysReceived Event
18 5.4.1.7. KDMDeleted Event
19 5.4.1.8. FrameSequencePlayed Event (OBAE)
20 5.4.1.9. CPLStart Event (OBAE)
21 5.4.1.10. CPLEnd Event (OBAE)
22 5.4.1.11. PlayoutComplete Event (OBAE)
23 5.4.1.12. CPLCheck Event (OBAE)
24 5.4.2.6. SPBStartup and SPBShutdown Events
25 5.4.2.7. SPBOpen and SPBClose Events
26 5.4.2.8. SPBClockAdjust Event
27 5.4.2.9. SPBMarriage and SPBDivorce Events
28 5.4.2.10. SPBSoftware Event
29 5.4.2.11. SPBSecurityAlert Event (data only)
30 6.1.1. Image Integrity Checking
31 6.1.2. Sound Integrity Checking
32 6.1.4. Restriction of Keying to MD Type
33 6.1.5. Restriction of Keying to Valid CPLs
34 6.1.8. Content Key Extension, End of Engagement
35 6.1.9. ContentAuthenticator Element Check
36 6.1.10. KDM Date Check
37 6.1.11. KDM TDL Check
38 6.1.12. Maximum Number of DCP Keys
39 6.1.13. CPL Id Check
40 6.1.14. CPL Id Check (OBAE)
41 6.1.15. Restriction of Playback in Absence of Integrity Pack Metadata
42 6.1.16. Restriction of Keying to MDEK Type (OBAE)
43 6.1.17. OBAE Integrity Checking
44 6.1.19. Plurality of Media Block Identity Certificates
45 6.1.20. Validity of SPB Certificates
46 6.1.21. Maximum Number of DCP Keys (OBAE)
47 6.1.22. Restriction of Keying to Valid CPLs (OBAE)
48 6.3.1. Clock Adjustment
49 6.3.2. SPB Type 1 Clock Battery
50 6.3.3. Clock Resolution
51 6.4.1. FM Application Constraints
52 6.4.2. Granularity of FM Control
53 6.4.3. FM Payload
54 6.4.4. FM Audio Bypass
55 6.4.5. Selective Audio FM Control
56 6.4.6. FM Application Constraints (OBAE)
57 6.4.7. Granularity of FM Control (OBAE)
58 6.4.8. FM Payload (OBAE)
59 6.4.9. FM Audio Bypass (OBAE)
60 6.5.1. Playback of Image Only Material
61 6.5.2. Decoder Requirements
62 6.6.1. Digital Audio Interfaces
63 6.6.2. Audio Sample Rate Conversion
64 6.6.3. Audio Delay Setup
65 6.6.4. Click Free Splicing of Audio Track Files
66 6.7.1. Media Block Overlay
67 6.7.4. Default Timed Text Font
68 6.7.6. Timed Text Decryption
69 6.8.1. Click Free Splicing of OBAE Track Files
70 6.8.2. OBAE Delay Setup
71 6.8.3. Maximum Bitrate OBAE
72 6.8.4. OBAE Rendering Expectations
73 7.3.2. Companion SPBs with Electronic Marriage
74 7.3.3. Companion SPB Marriage Break Key Retaining
75 8.1.1. Storage System Ingest Interface 76 8.1.2. Storage System Capacity 77 8.1.3. Storage System Redundancy
78 76 8.1.4. Storage System Performance
79 77 8.1.6. Storage System Performance (OBAE)
80 78 8.2.2. Show Playlist Creation (data only)
81 79 8.2.3. Show Playlist Format
82 80 8.2.5. Automation Control and Interfaces
83 81 8.2.6. Interrupt Free Playback
84 82 8.2.7. Artifact Free Transition of Image Format
85 83 8.2.8. Restarting Playback
86 84 8.2.9. SMS User Accounts
87 85 8.2.10. SMS Operator Identification
88 86 8.2.11. SMS Identity and Certificate
89 87 8.2.12. Content Keys and TDL check
90 88 8.2.13. Content Keys and TDL check (OBAE)
91 89 8.2.14. KDM Content Keys Check
92 90 8.2.15. Validity of SMS Certificates
93 91 8.2.16. Interrupt Free Playback (OBAE)
94 92 8.2.17. Restarting Playback (OBAE)
95 93 8.2.18. Show Playlist Creation (OBAE) (data only)

21.3. Integrated IMBO Design Review 🔗

For each requirement listed in the table below, prove that the system design meets the requirement by identifying the software or hardware mechanism that implements the requirement and analyzing the design to assure that the requirement has been met, subject to stipulated conditions. If a proof cannot be made, the design will be considered non-compliant with regard to the requirement. To perform this analysis the examiner will require access to exhibit documents (system design artifacts) such as schematic diagrams, implementation source code, unit test source code, state diagrams, design notes, etc. See Chapter 9: FIPS Requirements for a Type 1 SPB and Chapter 10: DCI Requirements Review for more information.

For each requirement, the examiner must record the identifiers of the exhibits consulted in proving the requirement, including applicable version identifiers, section or sheet numbers, grid identifiers, etc., and the examiner must record Pass or Fail to indicate whether or not the requirement has been met by the design. The examiner may also record any notes relevant to interpreting the exhibits and to the determination of the compliance status

Step Procedure Pass Fail Exhibit Identifiers
1 9.5.1. SM Operating Environment
2 9.5.3. SPB Type 1 Tamper Responsiveness
3 9.5.6. SPB Type 1 FIPS Requirements
4 9.5.8. Asymmetric Key Generation
5 9.5.9. Critical Security Parameter Protection
6 9.5.11. Degraded mode(s) of operation prohibited
7 9.5.12. Control output inhibition
8 9.5.13. Maintenance role/interface prohibited
9 9.5.14. Self-initiated cryptographic output capability
10 9.5.15. Self-initiated cryptographic output capability
11 9.5.16. Periodic self-tests
12 10.4.1. Theater System Reliability
13 10.4.2. Theater System Storage Security
14 10.4.3. Security Devices Self-Test Capabilities 15 10.4.4. Security Entity Physical Protection
16 15 10.4.5. Secure SMS-SM Communication
17 16 10.4.6. Location of Security Manager
18 10.4.9. Playback Preparation 19 10.4.11. Prevention of Keying of Compromised SPBs 20 17 10.4.16. KDM Purge upon Expiry
21 10.4.17. Key Usage Time Window 22 18 10.4.22. Clock Date-Time-Range
23 19 10.4.23. Clock Setup
24 20 10.4.24. Clock Stability
25 21 10.4.25. Repair and Renewal of SPBs
26 22 10.4.27. Clock Continuity
27 10.4.28. TLS Endpoints 28 10.4.32. RRP Synchronism 29 10.4.33. TLS Mode Bypass Prohibition 30 10.4.35. Implementation of Proprietary ITMs 31 10.4.39. RRP "Busy" and Unsupported Types 32 10.4.40. RRP Operational Messages 33 23 10.4.42. FM Algorithm General Requirements
34 24 10.4.43. FM Insertion Requirements
35 25 10.4.44. IFM Visual Transparency
36 26 10.4.45. IFM Robustness
37 27 10.4.46. AFM Inaudibility
38 28 10.4.47. AFM Robustness
39 29 10.4.48. FM Control Instance
40 30 10.4.51. SPB Log Storage Requirements
41 31 10.4.53. MB Log Storage Capabilities
42 10.4.55. Logging of Failed Procedures 43 32 10.4.56. SPB Log Failure
44 33 10.4.57. Log Purging in Failed SPBs
45 34 10.4.58. MB Tasks
46 35 10.4.59. Type 1 SPB RSA Private Keys
47 36 10.4.60. Content Keys Outside Secure Silicon
48 37 10.4.61. Prohibition of SPB Type 1 Field Serviceability
49 38 10.4.62. Use of Software Protection Methods
50 39 10.4.63. TMS Role
51 40 10.4.64. D-Cinema Security Parameter Protection
52 41 10.4.65. RSA Key Entropy
53 42 10.4.66. Preloaded Symmetric Key Entropy
54 43 10.4.67. MD Media Block Caching of Keys
55 44 10.4.68. SPB Type 1 Firmware Modifications
56 45 10.4.69. SPB Type 1 Log Retention
57 46 10.4.72. SPB Secure Silicon Requirements
58 47 10.4.73. SPB Type 1 Battery Life
59 48 10.4.74. Companion SPB Retrieve Imaging Device Cert
60 49 10.4.75. Log Collection for Married MB
61 50 10.4.76. Companion SPB Single Purpose Requirement
62 10.4.79. TLS RSA Requirement 63 51 10.4.80. TLS Authentication of Dual Certificate SM
64 52 10.4.82. Export of KDM-Borne Keys
65 53 10.4.85. OBAE FM Robustness
66 54 10.4.86. OBAE FM Inaudibility

21.4. Integrated IMBO Confidence Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 5.1.1. SPB Digital Certificate
2 5.4.1.6. KDMKeysReceived Event
3 5.4.2.10. SPBSoftware Event
4 6.1.5. Restriction of Keying to Valid CPLs
5 6.1.8. Content Key Extension, End of Engagement
6 6.1.9. ContentAuthenticator Element Check
7 6.1.11. KDM TDL Check
8 6.1.20. Validity of SPB Certificates
9 6.1.22. Restriction of Keying to Valid CPLs (OBAE)
10 6.3.1. Clock Adjustment
11 6.4.3. FM Payload
12 6.4.8. FM Payload (OBAE)
13 7.3.2. Companion SPBs with Electronic Marriage
14 8.2.7. Artifact Free Transition of Image Format
15 8.2.11. SMS Identity and Certificate
16 8.2.12. Content Keys and TDL check
17 8.2.13. Content Keys and TDL check (OBAE)
18 8.2.15. Validity of SMS Certificates

Chapter 22. Deleted Chapter 🔗

The chapter "OMB Consolidated Confidence Sequence" was moved to 20.4. OMB Confidence Sequence . The chapter number is maintained here to preserve the numbering of subsequent sections.

Chapter 23. Deleted Chapter 🔗

The chapter "Integrated IMBO Consolidated Confidence Sequence" was moved to 21.4. Integrated IMBO Confidence Sequence . The chapter number is maintained here to preserve the numbering of subsequent sections.

Chapter 24. SDR Projector Consolidated Test Sequence 🔗

24.1. Overview 🔗

The Test Subject of the Test Sequence defined in this chapter is a Projector that supports SDR presentations. The configuration and architecture of the system may vary, but the test sequence requires that the system consists of at least a light processing system including electronic and optical components (Projector), an IMB or IMBO (containing a Security Manager, Media Decryptor, etc.), and an SMS. For the purpose of this test, the Test Operator may substitute a Theater Management Server/System (TMS) for the SMS if it implements the required functionality. Wherever a test procedure refers to an SMS, the equivalent TMS may also be used.

For the purpose of compliance testing as defined in this Chapter, the spatial resolution of the projector shall be no less than that of the Media Block.

Before performing the test sequence provided below, the Test Operator should read and understand the documentation provided with the Test Subject. If adequate documentation is not available, a Test Subject Representative should be available to provide assistance during the test session.

24.2. SDR Projector Test Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 5.1.1. SPB Digital Certificate
2 6.1.20. Validity of SPB Certificates
3 6.4.3. FM Payload
4 6.7.4. Default Timed Text Font
5 7.2.1. Projector and Direct View Display Physical Protection
6 7.2.2. Projector and Direct View Display Security Servicing
7 7.2.6. SPB2 Secure Silicon Field Replacement
8 7.2.7. Systems without Electronic Marriage
9 7.2.8. Electronic Marriage Break Key Retaining
10 7.5.3. Imaging Device Pixel Count/Structure
11 7.5.8. SDR Intra-frame Contrast
12 7.5.9. Grayscale Tracking (data only)
13 7.5.10. SDR Contouring
14 7.5.11. SDR Transfer Function
15 7.5.12. SDR Color Accuracy
16 7.5.13. Projector Test Environment
17 7.5.15. SDR White Luminance and Chromaticity
18 7.5.29. SDR Minimum Active Black Level
19 7.5.33. Image Frame Rates

24.3. SDR Projector Design Review 🔗

For each requirement listed in the table below, prove that the system design meets the requirement by identifying the software or hardware mechanism that implements the requirement and analyzing the design to assure that the requirement has been met, subject to stipulated conditions. If a proof cannot be made, the design will be considered non-compliant with regard to the requirement. To perform this analysis the examiner will require access to exhibit documents (system design artifacts) such as schematic diagrams, implementation source code, unit test source code, state diagrams, design notes, etc. See Chapter 9: FIPS Requirements for a Type 1 SPB and Chapter 10: DCI Requirements Review for more information.

For each requirement, the examiner must record the identifiers of the exhibits consulted in proving the requirement, including applicable version identifiers, section or sheet numbers, grid identifiers, etc., and the examiner must record Pass or Fail to indicate whether or not the requirement has been met by the design. The examiner may also record any notes relevant to interpreting the exhibits and to the determination of the compliance status

Step Procedure Pass Fail Exhibit Identifiers
1 10.4.1. Theater System Reliability
2 10.4.3. Security Devices Self-Test Capabilities 3 10.4.18. Imaging Device Secure Silicon Device
4 3 10.4.19. Access to Imaging Device Image Signals
5 4 10.4.20. Systems with Electronic Marriage
6 5 10.4.21. Systems Without Electronic Marriage
7 6 10.4.25. Repair and Renewal of SPBs
8 7 10.4.26. SPB2 Protected Devices
9 8 10.4.78. Imaging Device SPB Log Reporting Requirements

24.4. SDR Projector Confidence Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 5.1.1. SPB Digital Certificate
2 6.1.20. Validity of SPB Certificates
3 6.4.3. FM Payload
4 7.2.2. Projector and Direct View Display Security Servicing
5 7.5.3. Imaging Device Pixel Count/Structure

Chapter 25. Deleted Chapter 🔗

The chapter "Projector Consolidated Confidence Sequence" was moved to 24.4. SDR Projector Confidence Sequence . The chapter number is maintained here to preserve the numbering of subsequent sections.

Chapter 26. HDR Direct View Display Consolidated Test Sequence 🔗

26.1. Overview 🔗

The Test Subject of the Test Sequence defined in this chapter is a Direct View Display that supports both SDR and HDR presentations. The configuration and architecture of the system may vary, but the test sequence requires that the system consists of at least a light processing system including electronic and optical components (Direct View Display), an IMB or IMBO (containing a Security Manager, Media Decryptor, etc.), and a Screen Management Server (SMS). For the purpose of this test, the Test Operator may substitute a Theater Management Server (TMS) for the SMS if it implements the required functionality. Wherever a test procedure refers to an SMS, the equivalent TMS may also be used.

For the purpose of compliance testing as defined in this Chapter, the spatial resolution of the direct view display shall be no less than that of the Media Block.

Before performing the test sequence provided below, the Test Operator should read and understand the documentation provided with the Test Subject. If adequate documentation is not available, a Test Subject Representative should be available to provide assistance during the test session.

26.2. HDR Direct View Display Test Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 5.1.1. SPB Digital Certificate
2 6.1.20. Validity of SPB Certificates
3 6.4.3. FM Payload
4 7.2.1. Projector and Direct View Display Physical Protection
5 7.2.2. Projector and Direct View Display Security Servicing
6 7.2.6. SPB2 Secure Silicon Field Replacement
7 7.2.7. Systems without Electronic Marriage
8 7.2.8. Electronic Marriage Break Key Retaining
9 7.5.3. Imaging Device Pixel Count/Structure
10 7.5.8. SDR Intra-frame Contrast
11 7.5.9. Grayscale Tracking (data only)
12 7.5.10. SDR Contouring
13 7.5.11. SDR Transfer Function
14 7.5.12. SDR Color Accuracy
15 7.5.14. HDR White Luminance and Chromaticity
16 7.5.15. SDR White Luminance and Chromaticity
17 7.5.16. HDR Color Luminance and Chromaticity
18 7.5.17. HDR Minimum Active Black Level
19 7.5.18. SDR Inactive Black Level (Direct View Display)
20 7.5.19. Horizontal and Vertical Full Screen Off-Axis Uniformity (Direct View Display)
21 7.5.20. Stereoscopic Extinction Ratio
22 7.5.21. SDR Stereoscopic Peak White Luminance
23 7.5.22. Surface Reflectivity (Direct View Display)
24 7.5.23. Vignetting (Direct View Display)
25 7.5.24. SDR Stereoscopic Minimum Active Black Level
26 7.5.25. Image Upscaling Artifacts
27 7.5.26. SDR Stereoscopic Color Accuracy
28 7.5.27. Sub-pixel Spatial Coincidence (Direct View Display)
29 7.5.28. HDR Transfer Function
30 7.5.29. SDR Minimum Active Black Level
31 7.5.30. Direct View Display Test Environment
32 7.5.31. Automatic SDR/HDR mode switching
33 7.5.32. HDR Inactive Black Level (Direct View Display)
34 7.5.33. Image Frame Rates
35 7.5.34. Stereoscopic Image Frame Rates
36 7.5.35. HDR Contouring

26.3. HDR Direct View Display Design Review 🔗

For each requirement listed in the table below, prove that the system design meets the requirement by identifying the software or hardware mechanism that implements the requirement and analyzing the design to assure that the requirement has been met, subject to stipulated conditions. If a proof cannot be made, the design will be considered non-compliant with regard to the requirement. To perform this analysis the examiner will require access to exhibit documents (system design artifacts) such as schematic diagrams, implementation source code, unit test source code, state diagrams, design notes, etc. See Chapter 9: FIPS Requirements fora Type 1 SPB and Chapter 10: DCI Requirements Review for more information.

For each requirement, the examiner must record the identifiers of the exhibits consulted in proving the requirement, including applicable version identifiers, section or sheet numbers, grid identifiers, etc., and the examiner must record Pass or Fail to indicate whether or not the requirement has been met by the design. The examiner may also record any notes relevant to interpreting the exhibits and to the determination of the compliance status.

Step Procedure Pass Fail Exhibit Identifiers
1 10.4.1. Theater System Reliability
2 10.4.3. Security Devices Self-Test Capabilities 3 10.4.18. Imaging Device Secure Silicon Device
4 3 10.4.19. Access to Imaging Device Image Signals
5 4 10.4.20. Systems with Electronic Marriage
6 5 10.4.21. Systems Without Electronic Marriage
7 6 10.4.25. Repair and Renewal of SPBs
8 7 10.4.26. SPB2 Protected Devices
9 8 10.4.78. Imaging Device SPB Log Reporting Requirements
10 9 10.5.1. Pixel Visibility (Direct View Display)

26.4. HDR Direct View Display Confidence Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 5.1.1. SPB Digital Certificate
2 6.1.20. Validity of SPB Certificates
3 6.4.3. FM Payload
4 7.2.2. Projector and Direct View Display Security Servicing
5 7.5.3. Imaging Device Pixel Count/Structure

Chapter 27. SDR Direct View Display Consolidated Test Sequence 🔗

27.1. Overview 🔗

The Test Subject of the Test Sequence defined in this chapter is a Direct View Display that supports SDR presentations. The configuration and architecture of the system may vary, but the test sequence requires that the system consists of at least a light processing system including electronic and optical components (Direct View Display), an IMB or IMBO (containing a Security Manager, Media Decryptor, etc.), and a Screen Management Server (SMS). For the purpose of this test, the Test Operator may substitute a Theater Management Server (TMS) for the SMS if it implements the required functionality. Wherever a test procedure refers to an SMS, the equivalent TMS may also be used.

For the purpose of compliance testing as defined in this Chapter, the spatial resolution of the direct view display shall be no less than that of the Media Block.

Before performing the test sequence provided below, the Test Operator should read and understand the documentation provided with the Test Subject. If adequate documentation is not available, a Test Subject Representative should be available to provide assistance during the test session.

27.2. SDR Direct View Display Test Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 5.1.1. SPB Digital Certificate
2 6.1.20. Validity of SPB Certificates
3 6.4.3. FM Payload
4 7.2.1. Projector and Direct View Display Physical Protection
5 7.2.2. Projector and Direct View Display Security Servicing
6 7.2.6. SPB2 Secure Silicon Field Replacement
7 7.2.7. Systems without Electronic Marriage
8 7.2.8. Electronic Marriage Break Key Retaining
9 7.5.3. Imaging Device Pixel Count/Structure
10 7.5.8. SDR Intra-frame Contrast
11 7.5.9. Grayscale Tracking (data only)
12 7.5.10. SDR Contouring
13 7.5.11. SDR Transfer Function
14 7.5.12. SDR Color Accuracy
15 7.5.15. SDR White Luminance and Chromaticity
16 7.5.18. SDR Inactive Black Level (Direct View Display)
17 7.5.19. Horizontal and Vertical Full Screen Off-Axis Uniformity (Direct View Display)
18 7.5.20. Stereoscopic Extinction Ratio
19 7.5.21. SDR Stereoscopic Peak White Luminance
20 7.5.22. Surface Reflectivity (Direct View Display)
21 7.5.23. Vignetting (Direct View Display)
22 7.5.24. SDR Stereoscopic Minimum Active Black Level
23 7.5.25. Image Upscaling Artifacts
24 7.5.26. SDR Stereoscopic Color Accuracy
25 7.5.27. Sub-pixel Spatial Coincidence (Direct View Display)
26 7.5.29. SDR Minimum Active Black Level
27 7.5.30. Direct View Display Test Environment
28 7.5.33. Image Frame Rates
29 7.5.34. Stereoscopic Image Frame Rates

27.3. SDR Direct View Display Design Review 🔗

For each requirement listed in the table below, prove that the system design meets the requirement by identifying the software or hardware mechanism that implements the requirement and analyzing the design to assure that the requirement has been met, subject to stipulated conditions. If a proof cannot be made, the design will be considered non-compliant with regard to the requirement. To perform this analysis the examiner will require access to exhibit documents (system design artifacts) such as schematic diagrams, implementation source code, unit test source code, state diagrams, design notes, etc. See Chapter 9: FIPS Requirements fora Type 1 SPB and Chapter 10: DCI Requirements Review for more information.

For each requirement, the examiner must record the identifiers of the exhibits consulted in proving the requirement, including applicable version identifiers, section or sheet numbers, grid identifiers, etc., and the examiner must record Pass or Fail to indicate whether or not the requirement has been met by the design. The examiner may also record any notes relevant to interpreting the exhibits and to the determination of the compliance status.

Step Procedure Pass Fail Exhibit Identifiers
1 10.4.1. Theater System Reliability
2 10.4.3. Security Devices Self-Test Capabilities 3 10.4.18. Imaging Device Secure Silicon Device
4 3 10.4.19. Access to Imaging Device Image Signals
5 4 10.4.20. Systems with Electronic Marriage
6 5 10.4.21. Systems Without Electronic Marriage
7 6 10.4.25. Repair and Renewal of SPBs
8 7 10.4.26. SPB2 Protected Devices
9 8 10.4.78. Imaging Device SPB Log Reporting Requirements
10 9 10.5.1. Pixel Visibility (Direct View Display)

27.4. SDR Direct View Display Confidence Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 5.1.1. SPB Digital Certificate
2 6.1.20. Validity of SPB Certificates
3 6.4.3. FM Payload
4 7.2.2. Projector and Direct View Display Security Servicing
5 7.5.3. Imaging Device Pixel Count/Structure

Chapter 28. HDR Projector Consolidated Test Sequence 🔗

28.1. Overview 🔗

The Test Subject of the Test Sequence defined in this chapter is a Projector that supports both SDR and HDR presentations. The configuration and architecture of the system may vary, but the test sequence requires that the system consists of at least a light processing system including electronic and optical components (Projector), an IMB or IMBO (containing a Security Manager, Media Decryptor, etc.), and an SMS. For the purpose of this test, the Test Operator may substitute a Theater Management Server/System (TMS) for the SMS if it implements the required functionality. Wherever a test procedure refers to an SMS, the equivalent TMS may also be used.

For the purpose of compliance testing as defined in this Chapter, the spatial resolution of the projector shall be no less than that of the Media Block.

Before performing the test sequence provided below, the Test Operator should read and understand the documentation provided with the Test Subject. If adequate documentation is not available, a Test Subject Representative should be available to provide assistance during the test session.

28.2. HDR Projector Test Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 5.1.1. SPB Digital Certificate
2 6.1.20. Validity of SPB Certificates
3 6.4.3. FM Payload
4 7.2.1. Projector and Direct View Display Physical Protection
5 7.2.2. Projector and Direct View Display Security Servicing
6 7.2.6. SPB2 Secure Silicon Field Replacement
7 7.2.7. Systems without Electronic Marriage
8 7.2.8. Electronic Marriage Break Key Retaining
9 7.5.3. Imaging Device Pixel Count/Structure
10 7.5.8. SDR Intra-frame Contrast
11 7.5.9. Grayscale Tracking (data only)
12 7.5.10. SDR Contouring
13 7.5.11. SDR Transfer Function
14 7.5.12. SDR Color Accuracy
15 7.5.13. Projector Test Environment
16 7.5.14. HDR White Luminance and Chromaticity
17 7.5.15. SDR White Luminance and Chromaticity
18 7.5.16. HDR Color Luminance and Chromaticity
19 7.5.17. HDR Minimum Active Black Level
20 7.5.28. HDR Transfer Function
21 7.5.29. SDR Minimum Active Black Level
22 7.5.31. Automatic SDR/HDR mode switching
23 7.5.33. Image Frame Rates
24 7.5.35. HDR Contouring

28.3. HDR Projector Design Review 🔗

For each requirement listed in the table below, prove that the system design meets the requirement by identifying the software or hardware mechanism that implements the requirement and analyzing the design to assure that the requirement has been met, subject to stipulated conditions. If a proof cannot be made, the design will be considered non-compliant with regard to the requirement. To perform this analysis the examiner will require access to exhibit documents (system design artifacts) such as schematic diagrams, implementation source code, unit test source code, state diagrams, design notes, etc. See Chapter 9: FIPS Requirements for a Type 1 SPB and Chapter 10: DCI Requirements Review for more information.

For each requirement, the examiner must record the identifiers of the exhibits consulted in proving the requirement, including applicable version identifiers, section or sheet numbers, grid identifiers, etc., and the examiner must record Pass or Fail to indicate whether or not the requirement has been met by the design. The examiner may also record any notes relevant to interpreting the exhibits and to the determination of the compliance status

Step Procedure Pass Fail Exhibit Identifiers
1 10.4.1. Theater System Reliability
2 10.4.3. Security Devices Self-Test Capabilities 3 10.4.18. Imaging Device Secure Silicon Device
4 3 10.4.19. Access to Imaging Device Image Signals
5 4 10.4.20. Systems with Electronic Marriage
6 5 10.4.21. Systems Without Electronic Marriage
7 6 10.4.25. Repair and Renewal of SPBs
8 7 10.4.26. SPB2 Protected Devices
9 8 10.4.78. Imaging Device SPB Log Reporting Requirements

28.4. HDR Projector Confidence Sequence 🔗

For each row of the table below, perform the procedure specified in the Procedure column, subject to all conditions specified in the Condition column. Indicate the status of the test in the Pass or Fail column, unless the test is specified as data only . Any marks in greyed-out fields indicate a test failure. Report any information listed in the Measured Data column. The Test Operator may record any additional observations.

Step Procedure Pass Fail Measured data
1 5.1.1. SPB Digital Certificate
2 6.1.20. Validity of SPB Certificates
3 6.4.3. FM Payload
4 7.2.2. Projector and Direct View Display Security Servicing
5 7.5.3. Imaging Device Pixel Count/Structure

Appendix A. Test Materials 🔗

A.1. Overview 🔗

To facilitate consistent testing of d-cinema equipment, a set of reference files has been produced to be used as directed in the respective test procedures. These materials are described in detail in this Appendix with the intention that the materials can be re-created from the descriptions and used to achieve testing results equivalent to those achieved with the original reference files.

The test material described below consists of digital certificates, Key Delivery Messages (KDM) and D-Cinema Packages (DCP). A DCP can be further deconstructed as a set of Track Files, Composition Playlists and related file descriptions. Some Track Files will be encrypted.

Because the identity of a Test Subject cannot be known until the device has been manufactured, it is not possible to create reference KDM files in advance. It is therefore necessary to divide the test material into two categories: common-use reference material and per-device reference material. Common-use reference material can be created once and used without limit on any compliant system. Per-device reference material must be created for each Test Subject, with foreknowledge of the date and time of the test session.

Two additional categories of reference material exist: compliant and intentionally non-compliant. Most of the material will be "golden" reference files, intended to be entirely compliant with the relevant specifications. Other files, however, will be intentionally broken to allow testing of error detection and recovery mechanisms.

A.2. Images 🔗

A.2.1. Introduction 🔗

This section defines a set of MXF picture track files. For each track file, a description is given which details the images encoded in the file. The image track files will be combined with sound files to make complete compositions (see Section A.4 ).

A.2.2. Sync Count 🔗

Type
MXF j2c
Filename
sync_count_j2c_pt.mxf
Description
MXF track file containing five seconds (120 frames) of plain frames followed by a ten second countdown and five seconds of plain frames. The countdown consists of ten identical one-second count segments, from 9-0. Each count segment consists of twenty- four frames of the respective digit for the count period. The first frame of each count segment will have a punch set to indicate sync. The example image below shows the first frame of the fourth count period, which contains the number 6 (six).
Conforms to
Meta
Duration
00:00:20:00
PixelArraySize
2048x1080
EditRate
24/1
Example test pattern for the first frame of the fourth count period, which displays the number 6
Figure A.2.2 . Sync Count 🔗

A.2.3. Sync Count (Encrypted) 🔗

Type
MXF j2c
Filename
sync_count_j2c_ct.mxf
Description
Encrypted MXF track file, contents are identical to Section A.2.2: Sync Count .
Conforms to
Meta
Encryption
AES-128
Duration
00:00:20:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.4. 4K Sync Count 🔗

Type
MXF j2c
Filename
4K_sync_count_j2c_pt.mxf
Description
4K Resolution MXF track file, contents are identical to Section A.2.2: Sync Count .
Conforms to
Meta
Duration
00:00:20:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.5. Sync Count, 48fps 🔗

Type
MXF j2c
Filename
sync_count_48fps_j2c_pt.mxf
Description
48fps MXF track file containing five seconds (240 frames) of plain frames followed by a ten second countdown and five seconds of plain frames. The countdown consists of ten identical one- second count segments, from 9-0. Each count segment consists of forty- eight frames of the respective digit for the count period. The first two frames of each count segment will have a punch set to indicate sync.
Conforms to
Meta
Duration
00:20:00
PixelArraySize
2048x1080
EditRate
48/1

A.2.6. Channel I.D. 5.1 🔗

Type
MXF j2c
Filename
channel_id_51_j2c_pt.mxf
Description
MXF track file containing five seconds (120 frames) of plain frames followed by a thirty second audio channel identification set and five seconds of plain frames. The audio channel identification set consists of six identical five second identifier segments having the following consecutively displayed labels: Left, Center, Right, Left Surround, Right Surround, LFE. Each channel identifier segment consists of five seconds (120 frames) of the respective label.
Conforms to
Meta
Duration
00:00:40:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.7. Channel I.D. 1-16 🔗

Type
MXF j2c
Filename
channel_id_01-16_j2c_pt.mxf
Description
MXF track file containing two seconds (48 frames) of plain frames followed by an eighty second audio channel identification set and two seconds of plain frames. The audio channel identification set consists of sixteen identical five-second identifier segments displaying consecutively numbered channel labels: 1, 2, 3, 4, etc. through 16. Each channel identifier segment consists of five seconds (120 frames) of the respective label.
Conforms to
Meta
Duration
00:01:24:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.8. "NIST" 2K Test Pattern 🔗

Type
MXF j2c
Filename
nist_2k_test_pattern_j2c_pt.mxf
Description
MXF track file containing the "DCI NIST" pattern created during original DCI research project. The pattern (shown below) includes geometric dimensions, color chips, dimensional patterns, a grayscale gradient and full-color photographic images. The track file contains 30 seconds (720 frames) of this image. Note: This image was obtained during the initial DCI study effort. It is used in the CTP because it is familiar to many in the d- cinema industry. The edge offset reticles are not accurate, however they are not used by any CTP procedure .
Conforms to
Meta
Duration
00:00:30:00
PixelArraySize
2048x1080
EditRate
24/1
Test pattern that includes geometric dimensions, color chips, dimensional patterns, a grayscale gradient and full-color photographic images of two people's faces
Figure A.2.8 . "NIST" 2K Test Pattern 🔗

A.2.9. "NIST" 4K Test Pattern 🔗

Type
MXF j2c
Filename
4K_nist_test_pattern_j2c_pt.mxf
Description
4K Resolution MXF track file containing the "DCI NIST" pattern as shown in Section A.2.8: "NIST" 2K Test Pattern. The track file contains 30 seconds (720 frames) of this image. Note: This image was obtained during the initial DCI study effort. It is used in the CTP because it is familiar to many in the d-cinema industry. The edge offset reticles are not accurate, however they are not used by any CTP procedure .
Conforms to
Meta
Duration
00:00:30:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.10. Black to Gray Step Series 🔗

Type
MXF j2c
Filename
gray_step_j2c_pt.mxf
Description
MXF track file containing five seconds (120 frames) of a chart showing all gray step values for the Black to Gray values in Section 7.5.9: Grayscale Tracking . This is followed by 1 minute of each of the 10 values as a full frame.
Conforms to
Meta
Duration
00:11:05:00
PixelArraySize
2048x1080
EditRate
24/1
Test pattern showing then gray step values, from black to gray
Figure A.2.10 . Black to Gray Step Series 🔗

A.2.11. Black to White Step Series 🔗

Type
MXF j2c
Filename
white_step_j2c_pt.mxf
Description
MXF track file containing five seconds (120 frames) of a chart showing all gray step values for the Black to White values in Section 7.5.9: Grayscale Tracking . This is followed by 1 minute of each of the 10 values as a full frame.
Conforms to
Meta
Duration
00:11:05:00
PixelArraySize
2048x1080
EditRate
24/1
Test pattern showing ten gray step values, from black to white
Figure A.2.11 . Black to White Step Series 🔗

A.2.12. Color Accuracy Series 🔗

Type
MXF j2c
Filename
color_accuracy_j2c_pt.mxf
Description
MXF track file containing five seconds (120 frames) of a chart showing all color values for the test in Section 7.5.12: Color Accuracy . This is followed by 1 minute of each of the 12 color values as a full frame.
Conforms to
Meta
Duration
00:12:05:00
PixelArraySize
2048x1080
EditRate
24/1
Test pattern showing twelve color swatches
Figure A.2.12 . Color Accuracy Series 🔗

A.2.13. 4K Color Accuracy Series 🔗

Type
MXF j2c
Filename
4K_color_accuracy_j2c_pt.mxf
Description
MXF track file containing the 4K version of the Color Accuracy Series shown in Section A.2.12: Color Accuracy Series.
Conforms to
Meta
Duration
12:05:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.14. Black (Empty Frame) 🔗

Type
MXF j2c
Filename
black_j2c_pt.mxf
Description
MXF track file containing 30 seconds (720 frames) of black (all pixels zero).
Conforms to
Meta
Duration
00:00:30:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.15. White (White Frame) 🔗

Type
MXF j2c
Filename
white_j2c_pt.mxf
Description
MXF track file containing 30 seconds (720 frames) of white.
Conforms to
Meta
Duration
00:00:30:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.16. Intra-Frame Contrast Sequence 🔗

Type
MXF j2c
Filename
2K_checkerboard_j2c_pt.mxf
Description
MXF track file containing alternating checkerboard patterns and an aiming target.
Conforms to
Meta
Duration
00:00:30:00
PixelArraySize
2048x1080
EditRate
24/1
Test pattern displaying 16 aiming targets
Figure A.2.16 . Intra-Frame Contrast Sequence 🔗

A.2.17. Sequential Contrast Sequence 🔗

Type
MXF j2c
Filename
2K_sequential_contrast_j2c_pt.mxf
Description
MXF track file containing black, white and aiming target frames.
Conforms to
Meta
Duration
00:00:30:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.18. 2K Picture Track File, Maximum Bitrate 🔗

Type
MXF j2c
Filename
2K_max_bitrate_j2c_ct.mxf
Description
Encrypted MXF track file containing a count to check synchronization between picture and sound, 10 minutes (14,400 frames) of a frame that has a large file size (1,281,818 bytes) and a second sync count.
Conforms to
Meta
Encryption
AES-128
Duration
00:10:40:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.19. 4K Picture Track File, Maximum Bitrate 🔗

Type
MXF j2c
Filename
4K_max_bitrate_j2c_ct.mxf
Description
Encrypted MXF track file containing a count to check synchronization between picture and sound, 10 minutes (14,400 frames) of a frame that has a large file size (1,299,183 bytes) and a second sync count.
Conforms to
Meta
Encryption
AES-128
Duration
00:10:40:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.20. DCI Numbered Frame Sequence 🔗

Type
MXF j2c
Filename
frame_num_burn_in_j2c_pt.mxf
Description
MXF track file containing a sequence of the "DCI NIST" frame that has an overlay of two identical visible number fields. The five digit field contains 00000 in the first frame of the file, with each consecutive frame increasing the count by 1. The last frame will be numbered 07199.
Conforms to
Meta
Duration
00:05:00:00
PixelArraySize
2048x1080
EditRate
24/1
Test pattern displaying a frame counter
Figure A.2.20 . DCI Numbered Frame Sequence 🔗

A.2.21. DCI Numbered Frame Sequence (Encrypted) 🔗

Type
MXF j2c
Filename
frame_num_burn_in_j2c_ct.mxf
Description
MXF track file containing a sequence of the "DCI NIST" frame that has an overlay of two identical visible number fields. The five digit field contains 00000 in the first frame of the file, with each consecutive frame increasing the count by 1. The last frame will be numbered 07199.
Conforms to
Meta
Encryption
AES-128
Duration
00:05:00:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.22. DCI Scope Transition Sequence 🔗

Type
MXF j2c
Filename
transition-scope_j2c_pt.mxf
Description
MXF track file containing a sequence of Scope format (A.R. 2.39:1) plain frames, and the label "Scope Transition Test Sequence (2048 x 858)". Each of the first 24 frames of the sequence have two identical overlays displaying a number from 001 through 024. Each of the last 24 frames of the sequence have two identical overlays displaying a number from 024 through 001.
Conforms to
Meta
Duration
00:10:00
PixelArraySize
2048x858
EditRate
24/1

A.2.23. DCI Flat Transition Sequence 🔗

Type
MXF j2c
Filename
transition-flat_j2c_pt.mxf
Description
MXF track file containing a sequence of Flat format (A.R. 1.85:1) plain frames, and the label "Flat Transition Test Sequence (1998 x 1024)". Each of the first 24 frames of the sequence have two identical overlays displaying a number from 001 through 024. Each of the last 24 frames of the sequence have two identical overlays displaying a number from 024 through 001.
Conforms to
Meta
Duration
00:10:00
PixelArraySize
1998x1080
EditRate
24/1

A.2.24. StEM 2K 🔗

Type
MXF j2c
Filename
StEM_2K_j2c_pt.mxf
Description
MXF track file containing the complete DCI StEM Mini Movie.
Conforms to
Meta
Duration
11:31:21
PixelArraySize
2048x858
EditRate
24/1

A.2.25. StEM 2K (Encrypted) 🔗

Type
MXF j2c
Filename
StEM_2K_j2c_ct.mxf
Description
Encrypted MXF track file containing the complete DCI StEM Mini Movie.
Conforms to
Meta
Encryption
AES-128
Duration
11:31:21
PixelArraySize
2048x858
EditRate
24/1

A.2.26. StEM 2K Multi-Reel A (Encrypted) 🔗

Type
MXF j2c multi
Filename
StEM_2K_j2c_multi_A_ct_<segment>.mxf
Description
A set of encrypted MXF track files containing 2k image essence for the DCI StEM Mini Movie. 128 files, each with a duration of 5 seconds.
Conforms to
Meta
SegmentCount
128
Encryption
AES-128
SegmentDuration
00:05:00
Duration
00:10:40:00
PixelArraySize
2048x858
EditRate
24/1

A.2.27. StEM 2K Multi-Reel B (Encrypted) 🔗

Type
MXF j2c multi
Filename
StEM_2K_j2c_multi_B_ct_<segment>.mxf
Description
A set of encrypted MXF track files containing 2k image essence for the DCI StEM Mini Movie. Identical to StEM_2K_j2c_multi_A_ct
Conforms to
Meta
SegmentCount
128
Encryption
AES-128
SegmentDuration
00:05:00
Duration
00:10:40:00
PixelArraySize
2048x858
EditRate
24/1

A.2.28. StEM 2K Multi-Reel A 🔗

Type
MXF j2c multi
Filename
StEM_2K_j2c_multi_A_pt_<segment>.mxf
Description
A set of plaintext MXF track files containing 2k image essence for the DCI StEM Mini Movie. 128 files, each with a duration of 5 seconds.
Conforms to
Meta
SegmentCount
128
SegmentDuration
00:05:00
Duration
00:10:40:00
PixelArraySize
2048x858
EditRate
24/1

A.2.29. StEM 2K Multi-Reel B 🔗

Type
MXF j2c multi
Filename
StEM_2K_j2c_multi_B_pt_<segment>.mxf
Description
A set of plaintext MXF track files containing 2k image essence for the DCI StEM Mini Movie. Identical to StEM_2K_j2c_multi_A_pt
Conforms to
Meta
SegmentCount
128
SegmentDuration
00:05:00
Duration
00:10:40:00
PixelArraySize
2048x858
EditRate
24/1

A.2.30. StEM 2K 48 fps 🔗

Type
MXF j2c
Filename
StEM_2K_48fps_j2c_pt.mxf
Description
MXF track file containing a 48 fps DCI StEM Mini Movie clip.
Conforms to
Meta
Duration
00:51:46
PixelArraySize
2048x858
EditRate
48/1

A.2.31. pixel_structure_N_2k_j2c_pt 🔗

Type
MXF j2c
Filename
pixel_structure_N_2k_j2c_pt.mxf
Description
See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Meta
Duration
00:00:10:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.32. pixel_structure_S_2k_j2c_pt 🔗

Type
MXF j2c
Filename
pixel_structure_S_2k_j2c_pt.mxf
Description
See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Meta
Duration
00:00:10:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.33. pixel_structure_E_2k_j2c_pt 🔗

Type
MXF j2c
Filename
pixel_structure_E_2k_j2c_pt.mxf
Description
See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Meta
Duration
00:00:10:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.34. pixel_structure_W_2k_j2c_pt 🔗

Type
MXF j2c
Filename
pixel_structure_W_2k_j2c_pt.mxf
Description
See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Meta
Duration
00:00:10:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.35. pixel_structure_N_4k_j2c_pt 🔗

Type
MXF j2c
Filename
pixel_structure_N_4k_j2c_pt.mxf
Description
See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Meta
Duration
00:00:10:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.36. pixel_structure_S_4k_j2c_pt 🔗

Type
MXF j2c
Filename
pixel_structure_S_4k_j2c_pt.mxf
Description
See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Meta
Duration
00:00:10:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.37. pixel_structure_E_4k_j2c_pt 🔗

Type
MXF j2c
Filename
pixel_structure_E_4k_j2c_pt.mxf
Description
See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Meta
Duration
00:00:10:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.38. pixel_structure_W_4k_j2c_pt 🔗

Type
MXF j2c
Filename
pixel_structure_W_4k_j2c_pt.mxf
Description
See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Meta
Duration
00:00:10:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.39. FM Constraints Begin (Encrypted) 🔗

Type
MXF j2c
Filename
fm_constraints_begin_j2c_ct.mxf
Description
Encrypted MXF track file with 10 seconds of slate reading "Begin Detection" and 5 seconds of black.
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
2048x858
EditRate
24/1
Test pattern with the text: Begin Detection
Figure A.2.39 . FM Constraints Begin (Encrypted) 🔗

A.2.40. FM Constraints Begin (Plaintext) 🔗

Type
MXF j2c
Filename
fm_constraints_begin_j2c_pt.mxf
Description
Plaintext MXF track file with 10 seconds of slate reading "Begin Detection" and 5 seconds of black.
Conforms to
Meta
Duration
00:00:15:00
PixelArraySize
2048x858
EditRate
24/1

A.2.41. FM Constraints End (Encrypted) 🔗

Type
MXF j2c
Filename
fm_constraints_end_j2c_ct.mxf
Description
Encrypted MXF track file with 10 seconds of slate reading "End Detection" and 5 seconds of black.
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
2048x858
EditRate
24/1

A.2.42. FM Constraints End (Plaintext) 🔗

Type
MXF j2c
Filename
fm_constraints_end_j2c_pt.mxf
Description
Plaintext MXF track file with 10 seconds of slate reading "End Detection" and 5 seconds of black.
Conforms to
Meta
Duration
00:00:15:00
PixelArraySize
2048x858
EditRate
24/1

A.2.43. 2K FM Control Granularity Begin (Encrypted) 🔗

Type
MXF j2c
Filename
2K_fm_control_granularity_begin_j2c_ct.mxf
Description
Encrypted MXF track file with 10 seconds of slate reading "Begin Detection" and 5 seconds of black.
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
2048x858
EditRate
24/1

A.2.44. Deleted Section 🔗

The section "2K FM Control Granularity Begin" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.2.45. 2K FM Control Granularity End (Encrypted) 🔗

Type
MXF j2c
Filename
2K_fm_control_granularity_end_j2c_ct.mxf
Description
Encrypted MXF track file with 10 seconds of slate reading "End Detection" and 5 seconds of black.
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
2048x858
EditRate
24/1

A.2.46. Deleted Section 🔗

The section "2K FM Control Granularity End" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.2.47. 2K FM Payload Begin (Encrypted) 🔗

Type
MXF j2c
Filename
2K_fm_payload_begin_j2c_ct.mxf
Description
Encrypted MXF track file with 10 seconds of slate reading "Begin Detection" and 5 seconds of black.
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
2048x858
EditRate
24/1

A.2.48. 2K FM Payload End (Encrypted) 🔗

Type
MXF j2c
Filename
2K_fm_payload_end_j2c_ct.mxf
Description
Encrypted MXF track file with 10 seconds of slate reading "End Detection" and 5 seconds of black.
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
2048x858
EditRate
24/1

A.2.49. Binary Audio FM Bypass 🔗

Type
MXF j2c
Filename
binary_audio_fm_bypass_j2c_pt.mxf
Description
Plaintext MXF track file with 10 minutes of slate reading "Binary Audio FM Bypass".
Conforms to
Meta
Duration
00:10:00:00
PixelArraySize
2048x858
EditRate
24/1

A.2.50. Selective FM Begin 🔗

Type
MXF j2c
Filename
selective_fm_begin_j2c_pt.mxf
Description
Plaintext MXF track file with 10 seconds of slate reading "Begin Detection" and 5 seconds of black.
Conforms to
Meta
Duration
00:00:15:00
PixelArraySize
2048x858
EditRate
24/1

A.2.51. Selective FM End 🔗

Type
MXF j2c
Filename
selective_fm_end_j2c_pt.mxf
Description
Plaintext MXF track file with 10 seconds of slate reading "End Detection" and 5 seconds of black.
Conforms to
Meta
Duration
00:00:15:00
PixelArraySize
2048x858
EditRate
24/1

A.2.52. Timed Text Example with Missing Font 🔗

Type
MXF text
Filename
std_ctp_text_no_font_pt.mxf
Description
MXF track file containing timed text using an OpenType font.
Conforms to
Malformations
The font shall not be present in the track file.
Meta
Duration
00:01:00:00
EditRate
24/1

A.2.53. DCI_gradient_step_s_white_j2c_pt 🔗

Type
MXF j2c
Filename
DCI_gradient_step_s_white_j2c_pt.mxf
Description
See Section 6.5.2: Decoder Requirements for description.
Conforms to
Meta
Duration
00:00:16:16
PixelArraySize
2048x1080
EditRate
24/1
Test pattern that consists of alternating light-dark columns
Figure A.2.53 . DCI_gradient_step_s_white_j2c_pt 🔗

A.2.54. Deleted Section 🔗

The section "DCI_gradient_step_s_color_j2c_pt" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.2.55. Deleted Section 🔗

The section "Timed Text Example with Font" was deleted. The section number is maintained here to preserve the numbering of subsequent sections

A.2.56. Deleted Section 🔗

The section "Timed Text Example with PNG" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.2.57. Sync Count Text 🔗

Type
MXF text
Filename
sync_count_tt_pt.mxf
Description
MXF track file containing timed text using a font and images.
Conforms to
Meta
Duration
00:00:22:00
EditRate
24/1

A.2.58. Sync Count Text (Encrypted) 🔗

Type
MXF text
Filename
sync_count_tt_ct.mxf
Description
Encrypted MXF track file containing timed text using a font and images.
Conforms to
Meta
Duration
00:00:22:00
Encryption
AES-128
EditRate
24/1

A.2.59. subtitle background 🔗

Type
MXF j2c
Filename
subtitle_background_j2c_pt.mxf
Conforms to
Meta
Duration
00:01:00:00
PixelArraySize
2048x858
EditRate
24/1

A.2.60. Deleted Section 🔗

The section "Plain_Frame_nosub_j2c_ct" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.2.61. m01 Picture Frame Out Of Order (Encrypted) 🔗

Type
MXF j2c
Filename
m01_pict_frame_oo_j2c_ct.mxf
Description
Encrypted MXF track file containing the first 5 seconds (120 frames) of the NIST test pattern. The order of the first two frames has been deliberately swapped.
Conforms to
Malformations
The first two image frames of the track file have been swapped.
Meta
Encryption
AES-128
Duration
00:00:05:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.62. m03 Sound Splice 🔗

Type
MXF j2c
Filename
m03_snd_splc_j2c_pt.mxf
Description
MXF track file containing one minute (1440 frames) of plain frames with the label "m03 Sound Splice Test".
Conforms to
Meta
Duration
00:01:00:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.63. m05 Picture Track File With Wrong TrackFile ID (Encrypted) 🔗

Type
MXF j2c
Filename
m05_pict_wrong_file_j2c_ct.mxf
Description
MXF track file in which the integrity pack of the 7th frame has the TrackFile ID replaced with a different value.
Conforms to
Meta
Encryption
AES-128
Duration
00:00:05:00
PixelArraySize
2048x1080
EditRate
24/1
CiphertextHeader
yes

A.2.64. m09 Picture track file with bad HMAC (Encrypted) 🔗

Type
MXF j2c
Filename
m09_pict_bad_hmac_j2c_ct.mxf
Description
Picture track file in which one of the HMAC values for a single frame has been changed.
Conforms to
Malformations
The file contains a replacement EKLV packet for the seventh frame (index 6). The replacement packet is taken from another track file having a different PackageUID but encrypted with the same symmetric key.
Meta
Encryption
AES-128
Duration
00:00:05:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.65. m11 Picture With Bad Check Value (Encrypted) 🔗

Type
MXF j2c
Filename
m11_pict_bad_chuk_j2c_ct.mxf
Description
MXF track file containing one EKLV packet with an invalid Check Value.
Conforms to
Meta
Encryption
AES-128
Duration
00:00:05:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.66. 2K Scope Subtitle Test Background - Reel 1 🔗

Type
MXF j2c
Filename
sub_test_2K_scope_00_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:14:00
PixelArraySize
2048x858
EditRate
24/1

A.2.67. 2K Scope Subtitle Test Background - Reel 2 🔗

Type
MXF j2c
Filename
sub_test_2K_scope_01_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:40:00
PixelArraySize
2048x858
EditRate
24/1

A.2.68. 2K Scope Subtitle Test Background - Reel 3 🔗

Type
MXF j2c
Filename
sub_test_2K_scope_02_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:52:00
PixelArraySize
2048x858
EditRate
24/1

A.2.69. 2K Scope Subtitle Test Background - Reel 4 🔗

Type
MXF j2c
Filename
sub_test_2K_scope_03_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:20:00
PixelArraySize
2048x858
EditRate
24/1

A.2.70. 2K Scope Subtitle Test Background - Reel 5 🔗

Type
MXF j2c
Filename
sub_test_2K_scope_04_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
2048x858
EditRate
24/1

A.2.71. 2K Scope Subtitle Test Background - Reel 6 🔗

Type
MXF j2c
Filename
sub_test_2K_scope_05_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
2048x858
EditRate
24/1

A.2.72. 2K Scope Subtitle Test Background - Reel 7 🔗

Type
MXF j2c
Filename
sub_test_2K_scope_06_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:31:00
PixelArraySize
2048x858
EditRate
24/1

A.2.73. 2K Scope Subtitle Test Background - Reel 8 🔗

Type
MXF j2c
Filename
sub_test_2K_scope_07_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
2048x858
EditRate
24/1

A.2.74. 2K Scope Subtitle Test Background - Reel 9 🔗

Type
MXF j2c
Filename
sub_test_2K_scope_08_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:45:00
PixelArraySize
2048x858
EditRate
24/1

A.2.75. 2K Scope Subtitle Test Background - Reel 10 🔗

Type
MXF j2c
Filename
sub_test_2K_scope_09_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:30:00
PixelArraySize
2048x858
EditRate
24/1

A.2.76. 4K Scope Subtitle Test Background - Reel 1 🔗

Type
MXF j2c
Filename
sub_test_4K_scope_00_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:14:00
PixelArraySize
4096x1716
EditRate
24/1

A.2.77. 4K Scope Subtitle Test Background - Reel 2 🔗

Type
MXF j2c
Filename
sub_test_4K_scope_01_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:40:00
PixelArraySize
4096x1716
EditRate
24/1

A.2.78. 4K Scope Subtitle Test Background - Reel 3 🔗

Type
MXF j2c
Filename
sub_test_4K_scope_02_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:52:00
PixelArraySize
4096x1716
EditRate
24/1

A.2.79. 4K Scope Subtitle Test Background - Reel 4 🔗

Type
MXF j2c
Filename
sub_test_4K_scope_03_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:20:00
PixelArraySize
4096x1716
EditRate
24/1

A.2.80. 4K Scope Subtitle Test Background - Reel 5 🔗

Type
MXF j2c
Filename
sub_test_4K_scope_04_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
4096x1716
EditRate
24/1

A.2.81. 4K Scope Subtitle Test Background - Reel 6 🔗

Type
MXF j2c
Filename
sub_test_4K_scope_05_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
4096x1716
EditRate
24/1

A.2.82. 4K Scope Subtitle Test Background - Reel 7 🔗

Type
MXF j2c
Filename
sub_test_4K_scope_06_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:31:00
PixelArraySize
4096x1716
EditRate
24/1

A.2.83. 4K Scope Subtitle Test Background - Reel 8 🔗

Type
MXF j2c
Filename
sub_test_4K_scope_07_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
4096x1716
EditRate
24/1

A.2.84. 4K Scope Subtitle Test Background - Reel 9 🔗

Type
MXF j2c
Filename
sub_test_4K_scope_08_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:45:00
PixelArraySize
4096x1716
EditRate
24/1

A.2.85. 4K Scope Subtitle Test Background - Reel 10 🔗

Type
MXF j2c
Filename
sub_test_4K_scope_09_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:30:00
PixelArraySize
4096x1716
EditRate
24/1

A.2.86. 2K 48fps Scope Subtitle Test Background - Reel 1 🔗

Type
MXF j2c
Filename
sub_test_48fps_scope_00_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:14:00
PixelArraySize
2048x858
EditRate
48/1

A.2.87. 2K 48fps Scope Subtitle Test Background - Reel 2 🔗

Type
MXF j2c
Filename
sub_test_48fps_scope_01_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:40:00
PixelArraySize
2048x858
EditRate
48/1

A.2.88. 2K 48fps Scope Subtitle Test Background - Reel 3 🔗

Type
MXF j2c
Filename
sub_test_48fps_scope_02_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:52:00
PixelArraySize
2048x858
EditRate
48/1

A.2.89. 2K 48fps Scope Subtitle Test Background - Reel 4 🔗

Type
MXF j2c
Filename
sub_test_48fps_scope_03_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:20:00
PixelArraySize
2048x858
EditRate
48/1

A.2.90. 2K 48fps Scope Subtitle Test Background - Reel 5 🔗

Type
MXF j2c
Filename
sub_test_48fps_scope_04_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
2048x858
EditRate
48/1

A.2.91. 2K 48fps Scope Subtitle Test Background - Reel 6 🔗

Type
MXF j2c
Filename
sub_test_48fps_scope_05_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
2048x858
EditRate
48/1

A.2.92. 2K 48fps Scope Subtitle Test Background - Reel 7 🔗

Type
MXF j2c
Filename
sub_test_48fps_scope_06_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:31:00
PixelArraySize
2048x858
EditRate
48/1

A.2.93. 2K 48fps Scope Subtitle Test Background - Reel 8 🔗

Type
MXF j2c
Filename
sub_test_48fps_scope_07_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
2048x858
EditRate
48/1

A.2.94. 2K 48fps Scope Subtitle Test Background - Reel 9 🔗

Type
MXF j2c
Filename
sub_test_48fps_scope_08_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:45:00
PixelArraySize
2048x858
EditRate
48/1

A.2.95. 2K 48fps Scope Subtitle Test Background - Reel 10 🔗

Type
MXF j2c
Filename
sub_test_48fps_scope_09_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:30:00
PixelArraySize
2048x858
EditRate
48/1

A.2.96. 2K Flat Subtitle Test Background - Reel 1 🔗

Type
MXF j2c
Filename
sub_test_2K_flat_00_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:14:00
PixelArraySize
1998x1080
EditRate
24/1

A.2.97. 2K Flat Subtitle Test Background - Reel 2 🔗

Type
MXF j2c
Filename
sub_test_2K_flat_01_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:40:00
PixelArraySize
1998x1080
EditRate
24/1

A.2.98. 2K Flat Subtitle Test Background - Reel 3 🔗

Type
MXF j2c
Filename
sub_test_2K_flat_02_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:52:00
PixelArraySize
1998x1080
EditRate
24/1

A.2.99. 2K Flat Subtitle Test Background - Reel 4 🔗

Type
MXF j2c
Filename
sub_test_2K_flat_03_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:20:00
PixelArraySize
1998x1080
EditRate
24/1

A.2.100. 2K Flat Subtitle Test Background - Reel 5 🔗

Type
MXF j2c
Filename
sub_test_2K_flat_04_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
1998x1080
EditRate
24/1

A.2.101. 2K Flat Subtitle Test Background - Reel 6 🔗

Type
MXF j2c
Filename
sub_test_2K_flat_05_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
1998x1080
EditRate
24/1

A.2.102. 2K Flat Subtitle Test Background - Reel 7 🔗

Type
MXF j2c
Filename
sub_test_2K_flat_06_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:31:00
PixelArraySize
1998x1080
EditRate
24/1

A.2.103. 2K Flat Subtitle Test Background - Reel 8 🔗

Type
MXF j2c
Filename
sub_test_2K_flat_07_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
1998x1080
EditRate
24/1

A.2.104. 2K Flat Subtitle Test Background - Reel 9 🔗

Type
MXF j2c
Filename
sub_test_2K_flat_08_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:45:00
PixelArraySize
1998x1080
EditRate
24/1

A.2.105. 2K Flat Subtitle Test Background - Reel 10 🔗

Type
MXF j2c
Filename
sub_test_2K_flat_09_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:30:00
PixelArraySize
1998x1080
EditRate
24/1

A.2.106. 4K Flat Subtitle Test Background - Reel 1 🔗

Type
MXF j2c
Filename
sub_test_4K_flat_00_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:14:00
PixelArraySize
3996x2160
EditRate
24/1

A.2.107. 4K Flat Subtitle Test Background - Reel 2 🔗

Type
MXF j2c
Filename
sub_test_4K_flat_01_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:40:00
PixelArraySize
3996x2160
EditRate
24/1

A.2.108. 4K Flat Subtitle Test Background - Reel 3 🔗

Type
MXF j2c
Filename
sub_test_4K_flat_02_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:52:00
PixelArraySize
3996x2160
EditRate
24/1

A.2.109. 4K Flat Subtitle Test Background - Reel 4 🔗

Type
MXF j2c
Filename
sub_test_4K_flat_03_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:20:00
PixelArraySize
3996x2160
EditRate
24/1

A.2.110. 4K Flat Subtitle Test Background - Reel 5 🔗

Type
MXF j2c
Filename
sub_test_4K_flat_04_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
3996x2160
EditRate
24/1

A.2.111. 4K Flat Subtitle Test Background - Reel 6 🔗

Type
MXF j2c
Filename
sub_test_4K_flat_05_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
3996x2160
EditRate
24/1

A.2.112. 4K Flat Subtitle Test Background - Reel 7 🔗

Type
MXF j2c
Filename
sub_test_4K_flat_06_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:31:00
PixelArraySize
3996x2160
EditRate
24/1

A.2.113. 4K Flat Subtitle Test Background - Reel 8 🔗

Type
MXF j2c
Filename
sub_test_4K_flat_07_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
3996x2160
EditRate
24/1

A.2.114. 4K Flat Subtitle Test Background - Reel 9 🔗

Type
MXF j2c
Filename
sub_test_4K_flat_08_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:45:00
PixelArraySize
3996x2160
EditRate
24/1

A.2.115. 4K Flat Subtitle Test Background - Reel 10 🔗

Type
MXF j2c
Filename
sub_test_4K_flat_09_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:30:00
PixelArraySize
3996x2160
EditRate
24/1

A.2.116. 2K 48fps Flat Subtitle Test Background - Reel 1 🔗

Type
MXF j2c
Filename
sub_test_48fps_flat_00_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:14:00
PixelArraySize
1998x1080
EditRate
48/1

A.2.117. 2K 48fps Flat Subtitle Test Background - Reel 2 🔗

Type
MXF j2c
Filename
sub_test_48fps_flat_01_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:40:00
PixelArraySize
1998x1080
EditRate
48/1

A.2.118. 2K 48fps Flat Subtitle Test Background - Reel 3 🔗

Type
MXF j2c
Filename
sub_test_48fps_flat_02_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:52:00
PixelArraySize
1998x1080
EditRate
48/1

A.2.119. 2K 48fps Flat Subtitle Test Background - Reel 4 🔗

Type
MXF j2c
Filename
sub_test_48fps_flat_03_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:20:00
PixelArraySize
1998x1080
EditRate
48/1

A.2.120. 2K 48fps Flat Subtitle Test Background - Reel 5 🔗

Type
MXF j2c
Filename
sub_test_48fps_flat_04_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
1998x1080
EditRate
48/1

A.2.121. 2K 48fps Flat Subtitle Test Background - Reel 6 🔗

Type
MXF j2c
Filename
sub_test_48fps_flat_05_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
1998x1080
EditRate
48/1

A.2.122. 2K 48fps Flat Subtitle Test Background - Reel 7 🔗

Type
MXF j2c
Filename
sub_test_48fps_flat_06_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:31:00
PixelArraySize
1998x1080
EditRate
48/1

A.2.123. 2K 48fps Flat Subtitle Test Background - Reel 8 🔗

Type
MXF j2c
Filename
sub_test_48fps_flat_07_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
1998x1080
EditRate
48/1

A.2.124. 2K 48fps Flat Subtitle Test Background - Reel 9 🔗

Type
MXF j2c
Filename
sub_test_48fps_flat_08_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:45:00
PixelArraySize
2048x858
EditRate
48/1

A.2.125. 2K 48fps Flat Subtitle Test Background - Reel 10 🔗

Type
MXF j2c
Filename
sub_test_48fps_flat_09_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:30:00
PixelArraySize
2048x858
EditRate
48/1

A.2.126. 2K Full Subtitle Test Background - Reel 1 🔗

Type
MXF j2c
Filename
sub_test_2K_full_00_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:14:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.127. 2K Full Subtitle Test Background - Reel 2 🔗

Type
MXF j2c
Filename
sub_test_2K_full_01_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:40:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.128. 2K Full Subtitle Test Background - Reel 3 🔗

Type
MXF j2c
Filename
sub_test_2K_full_02_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:52:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.129. 2K Full Subtitle Test Background - Reel 4 🔗

Type
MXF j2c
Filename
sub_test_2K_full_03_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:20:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.130. 2K Full Subtitle Test Background - Reel 5 🔗

Type
MXF j2c
Filename
sub_test_2K_full_04_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.131. 2K Full Subtitle Test Background - Reel 6 🔗

Type
MXF j2c
Filename
sub_test_2K_full_05_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.132. 2K Full Subtitle Test Background - Reel 7 🔗

Type
MXF j2c
Filename
sub_test_2K_full_06_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:31:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.133. 2K Full Subtitle Test Background - Reel 8 🔗

Type
MXF j2c
Filename
sub_test_2K_full_07_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.134. 2K Full Subtitle Test Background - Reel 9 🔗

Type
MXF j2c
Filename
sub_test_2K_full_08_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:45:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.135. 2K Full Subtitle Test Background - Reel 10 🔗

Type
MXF j2c
Filename
sub_test_2K_full_09_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:30:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.136. 4K Full Subtitle Test Background - Reel 1 🔗

Type
MXF j2c
Filename
sub_test_4K_full_00_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:14:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.137. 4K Full Subtitle Test Background - Reel 2 🔗

Type
MXF j2c
Filename
sub_test_4K_full_01_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:40:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.138. 4K Full Subtitle Test Background - Reel 3 🔗

Type
MXF j2c
Filename
sub_test_4K_full_02_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:52:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.139. 4K Full Subtitle Test Background - Reel 4 🔗

Type
MXF j2c
Filename
sub_test_4K_full_03_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:20:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.140. 4K Full Subtitle Test Background - Reel 5 🔗

Type
MXF j2c
Filename
sub_test_4K_full_04_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.141. 4K Full Subtitle Test Background - Reel 6 🔗

Type
MXF j2c
Filename
sub_test_4K_full_05_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.142. 4K Full Subtitle Test Background - Reel 7 🔗

Type
MXF j2c
Filename
sub_test_4K_full_06_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:31:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.143. 4K Full Subtitle Test Background - Reel 8 🔗

Type
MXF j2c
Filename
sub_test_4K_full_07_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.144. 4K Full Subtitle Test Background - Reel 9 🔗

Type
MXF j2c
Filename
sub_test_4K_full_08_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:45:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.145. 4K Full Subtitle Test Background - Reel 10 🔗

Type
MXF j2c
Filename
sub_test_4K_full_09_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:30:00
PixelArraySize
4096x2160
EditRate
24/1

A.2.146. 2K 48fps Full Subtitle Test Background - Reel 1 🔗

Type
MXF j2c
Filename
sub_test_48fps_full_00_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:14:00
PixelArraySize
2048x1080
EditRate
48/1

A.2.147. 2K 48fps Full Subtitle Test Background - Reel 2 🔗

Type
MXF j2c
Filename
sub_test_48fps_full_01_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:40:00
PixelArraySize
2048x1080
EditRate
48/1

A.2.148. 2K 48fps Full Subtitle Test Background - Reel 3 🔗

Type
MXF j2c
Filename
sub_test_48fps_full_02_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:52:00
PixelArraySize
2048x1080
EditRate
48/1

A.2.149. 2K 48fps Full Subtitle Test Background - Reel 4 🔗

Type
MXF j2c
Filename
sub_test_48fps_full_03_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:20:00
PixelArraySize
2048x1080
EditRate
48/1

A.2.150. 2K 48fps Full Subtitle Test Background - Reel 5 🔗

Type
MXF j2c
Filename
sub_test_48fps_full_04_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
2048x1080
EditRate
48/1

A.2.151. 2K 48fps Full Subtitle Test Background - Reel 6 🔗

Type
MXF j2c
Filename
sub_test_48fps_full_05_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:15:00
PixelArraySize
2048x1080
EditRate
48/1

A.2.152. 2K 48fps Full Subtitle Test Background - Reel 7 🔗

Type
MXF j2c
Filename
sub_test_48fps_full_06_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:31:00
PixelArraySize
2048x1080
EditRate
48/1

A.2.153. 2K 48fps Full Subtitle Test Background - Reel 8 🔗

Type
MXF j2c
Filename
sub_test_48fps_full_07_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:10:00
PixelArraySize
2048x1080
EditRate
48/1

A.2.154. 2K 48fps Full Subtitle Test Background - Reel 9 🔗

Type
MXF j2c
Filename
sub_test_48fps_full_08_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:01:45:00
PixelArraySize
2048x1080
EditRate
48/1

A.2.155. 2K 48fps Full Subtitle Test Background - Reel 10 🔗

Type
MXF j2c
Filename
sub_test_48fps_full_09_j2c_ct.mxf
Conforms to
Meta
Encryption
AES-128
Duration
00:00:30:00
PixelArraySize
2048x1080
EditRate
48/1

A.2.156. 2K Scope Subtitle Test - Timed Text track file - Reel 1 🔗

Type
MXF text
Filename
sub_test_2K_scope_00_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.157. 2K Scope Subtitle Test - Timed Text track file - Reel 2 🔗

Type
MXF text
Filename
sub_test_2K_scope_01_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.158. 2K Scope Subtitle Test - Timed Text track file - Reel 3 🔗

Type
MXF text
Filename
sub_test_2K_scope_02_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.159. 2K Scope Subtitle Test - Timed Text track file - Reel 4 🔗

Type
MXF text
Filename
sub_test_2K_scope_03_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.160. 2K Scope Subtitle Test - Timed Text track file - Reel 5 🔗

Type
MXF text
Filename
sub_test_2K_scope_04_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.161. 2K Scope Subtitle Test - Timed Text track file - Reel 6 🔗

Type
MXF text
Filename
sub_test_2K_scope_05_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.162. 2K Scope Subtitle Test - Timed Text track file - Reel 7 🔗

Type
MXF text
Filename
sub_test_2K_scope_06_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.163. 2K Scope Subtitle Test - Timed Text track file - Reel 8 🔗

Type
MXF text
Filename
sub_test_2K_scope_07_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.164. 2K Scope Subtitle Test - Timed Text track file - Reel 9 🔗

Type
MXF text
Filename
sub_test_2K_scope_08_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.165. 2K Scope Subtitle Test - Timed Text track file - Reel 10 🔗

Type
MXF text
Filename
sub_test_2K_scope_09_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.166. 4K Scope Subtitle Test - Timed Text track file - Reel 8 🔗

Type
MXF text
Filename
sub_test_4K_scope_07_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.167. 4K Scope Subtitle Test - Timed Text track file - Reel 9 🔗

Type
MXF text
Filename
sub_test_4K_scope_08_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.168. 2K 48fps Scope Subtitle Test - Timed Text track file - Reel 1 🔗

Type
MXF text
Filename
sub_test_48fps_scope_00_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.169. 2K 48fps Scope Subtitle Test - Timed Text track file - Reel 2 🔗

Type
MXF text
Filename
sub_test_48fps_scope_01_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.170. 2K 48fps Scope Subtitle Test - Timed Text track file - Reel 3 🔗

Type
MXF text
Filename
sub_test_48fps_scope_02_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.171. 2K 48fps Scope Subtitle Test - Timed Text track file - Reel 4 🔗

Type
MXF text
Filename
sub_test_48fps_scope_03_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.172. 2K 48fps Scope Subtitle Test - Timed Text track file - Reel 5 🔗

Type
MXF text
Filename
sub_test_48fps_scope_04_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.173. 2K 48fps Scope Subtitle Test - Timed Text track file - Reel 6 🔗

Type
MXF text
Filename
sub_test_48fps_scope_05_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.174. 2K 48fps Scope Subtitle Test - Timed Text track file - Reel 7 🔗

Type
MXF text
Filename
sub_test_48fps_scope_06_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.175. 2K 48fps Scope Subtitle Test - Timed Text track file - Reel 8 🔗

Type
MXF text
Filename
sub_test_48fps_scope_07_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.176. 2K 48fps Scope Subtitle Test - Timed Text track file - Reel 9 🔗

Type
MXF text
Filename
sub_test_48fps_scope_08_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.177. 2K 48fps Scope Subtitle Test - Timed Text track file - Reel 10 🔗

Type
MXF text
Filename
sub_test_48fps_scope_09_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.178. 2K Flat Subtitle Test - Timed Text track file - Reel 1 🔗

Type
MXF text
Filename
sub_test_2K_flat_00_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.179. 2K Flat Subtitle Test - Timed Text track file - Reel 2 🔗

Type
MXF text
Filename
sub_test_2K_flat_01_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.180. 2K Flat Subtitle Test - Timed Text track file - Reel 3 🔗

Type
MXF text
Filename
sub_test_2K_flat_02_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.181. 2K Flat Subtitle Test - Timed Text track file - Reel 4 🔗

Type
MXF text
Filename
sub_test_2K_flat_03_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.182. 2K Flat Subtitle Test - Timed Text track file - Reel 5 🔗

Type
MXF text
Filename
sub_test_2K_flat_04_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.183. 2K Flat Subtitle Test - Timed Text track file - Reel 6 🔗

Type
MXF text
Filename
sub_test_2K_flat_05_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.184. 2K Flat Subtitle Test - Timed Text track file - Reel 7 🔗

Type
MXF text
Filename
sub_test_2K_flat_06_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.185. 2K Flat Subtitle Test - Timed Text track file - Reel 8 🔗

Type
MXF text
Filename
sub_test_2K_flat_07_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.186. 2K Flat Subtitle Test - Timed Text track file - Reel 9 🔗

Type
MXF text
Filename
sub_test_2K_flat_08_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.187. 2K Flat Subtitle Test - Timed Text track file - Reel 10 🔗

Type
MXF text
Filename
sub_test_2K_flat_09_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.188. 4K Flat Subtitle Test - Timed Text track file - Reel 8 🔗

Type
MXF text
Filename
sub_test_4K_flat_07_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.189. 4K Flat Subtitle Test - Timed Text track file - Reel 9 🔗

Type
MXF text
Filename
sub_test_4K_flat_08_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.190. 2K 48fps Flat Subtitle Test - Timed Text track file - Reel 1 🔗

Type
MXF text
Filename
sub_test_48fps_flat_00_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.191. 2K 48fps Flat Subtitle Test - Timed Text track file - Reel 2 🔗

Type
MXF text
Filename
sub_test_48fps_flat_01_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.192. 2K 48fps Flat Subtitle Test - Timed Text track file - Reel 3 🔗

Type
MXF text
Filename
sub_test_48fps_flat_02_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.193. 2K 48fps Flat Subtitle Test - Timed Text track file - Reel 4 🔗

Type
MXF text
Filename
sub_test_48fps_flat_03_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.194. 2K 48fps Flat Subtitle Test - Timed Text track file - Reel 5 🔗

Type
MXF text
Filename
sub_test_48fps_flat_04_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.195. 2K 48fps Flat Subtitle Test - Timed Text track file - Reel 6 🔗

Type
MXF text
Filename
sub_test_48fps_flat_05_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.196. 2K 48fps Flat Subtitle Test - Timed Text track file - Reel 7 🔗

Type
MXF text
Filename
sub_test_48fps_flat_06_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.197. 2K 48fps Flat Subtitle Test - Timed Text track file - Reel 8 🔗

Type
MXF text
Filename
sub_test_48fps_flat_07_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.198. 2K 48fps Flat Subtitle Test - Timed Text track file - Reel 9 🔗

Type
MXF text
Filename
sub_test_48fps_flat_08_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.199. 2K 48fps Flat Subtitle Test - Timed Text track file - Reel 10 🔗

Type
MXF text
Filename
sub_test_48fps_flat_09_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.200. 2K Full Subtitle Test - Timed Text track file - Reel 1 🔗

Type
MXF text
Filename
sub_test_2K_full_00_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.201. 2K Full Subtitle Test - Timed Text track file - Reel 2 🔗

Type
MXF text
Filename
sub_test_2K_full_01_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.202. 2K Full Subtitle Test - Timed Text track file - Reel 3 🔗

Type
MXF text
Filename
sub_test_2K_full_02_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.203. 2K Full Subtitle Test - Timed Text track file - Reel 4 🔗

Type
MXF text
Filename
sub_test_2K_full_03_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.204. 2K Full Subtitle Test - Timed Text track file - Reel 5 🔗

Type
MXF text
Filename
sub_test_2K_full_04_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.205. 2K Full Subtitle Test - Timed Text track file - Reel 6 🔗

Type
MXF text
Filename
sub_test_2K_full_05_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.206. 2K Full Subtitle Test - Timed Text track file - Reel 7 🔗

Type
MXF text
Filename
sub_test_2K_full_06_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.207. 2K Full Subtitle Test - Timed Text track file - Reel 8 🔗

Type
MXF text
Filename
sub_test_2K_full_07_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.208. 2K Full Subtitle Test - Timed Text track file - Reel 9 🔗

Type
MXF text
Filename
sub_test_2K_full_08_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.209. 2K Full Subtitle Test - Timed Text track file - Reel 10 🔗

Type
MXF text
Filename
sub_test_2K_full_09_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.210. 4K Full Subtitle Test - Timed Text track file - Reel 8 🔗

Type
MXF text
Filename
sub_test_4K_full_07_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.211. 4K Full Subtitle Test - Timed Text track file - Reel 9 🔗

Type
MXF text
Filename
sub_test_4K_full_08_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
24/1

A.2.212. 2K 48fps Full Subtitle Test - Timed Text track file - Reel 1 🔗

Type
MXF text
Filename
sub_test_48fps_full_00_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.213. 2K 48fps Full Subtitle Test - Timed Text track file - Reel 2 🔗

Type
MXF text
Filename
sub_test_48fps_full_01_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.214. 2K 48fps Full Subtitle Test - Timed Text track file - Reel 3 🔗

Type
MXF text
Filename
sub_test_48fps_full_02_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.215. 2K 48fps Full Subtitle Test - Timed Text track file - Reel 4 🔗

Type
MXF text
Filename
sub_test_48fps_full_03_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.216. 2K 48fps Full Subtitle Test - Timed Text track file - Reel 5 🔗

Type
MXF text
Filename
sub_test_48fps_full_04_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.217. 2K 48fps Full Subtitle Test - Timed Text track file - Reel 6 🔗

Type
MXF text
Filename
sub_test_48fps_full_05_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.218. 2K 48fps Full Subtitle Test - Timed Text track file - Reel 7 🔗

Type
MXF text
Filename
sub_test_48fps_full_06_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.219. 2K 48fps Full Subtitle Test - Timed Text track file - Reel 8 🔗

Type
MXF text
Filename
sub_test_48fps_full_07_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.220. 2K 48fps Full Subtitle Test - Timed Text track file - Reel 9 🔗

Type
MXF text
Filename
sub_test_48fps_full_08_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.221. 2K 48fps Full Subtitle Test - Timed Text track file - Reel 10 🔗

Type
MXF text
Filename
sub_test_48fps_full_09_tt_ct.mxf
Description
Encrypted MXF track file containing timed text test content.
Conforms to
Meta
Duration
00:01:00:00
Encryption
AES-128
EditRate
48/1

A.2.222. Sync Count with Subtitle Reticles 🔗

Type
MXF j2c
Filename
sync_count_with_subs_j2c_pt.mxf
Description
MXF track file containing five seconds (120 frames) of plain frames with reticles. followed by a ten second countdown and five seconds of plain frames with subtitle reticles. The countdown consists of ten identical one-second count segments, from 9-0. Each count segment consists of twenty-four frames of the respective digit for the count period. The first frame of each count segment will have a punch set to indicate sync. The example image below shows the first frame of the fourth count period, which contains the number 6 (six).
Conforms to
Meta
Duration
00:00:20:00
PixelArraySize
2048x1080
EditRate
24/1
Test pattern for the first frame of the fourth count period, which displays the number 6
Figure A.2.222 . Sync Count with Subtitle Reticles 🔗

A.2.223. Sync Count with Subtitle Reticles (Encrypted) 🔗

Type
MXF j2c
Filename
sync_count_with_subs_j2c_ct.mxf
Description
Encrypted MXF track file, contents are identical to Section A.2.222: Sync Count with Subtitle Reticles .
Conforms to
Meta
Encryption
AES-128
Duration
00:00:20:00
PixelArraySize
2048x1080
EditRate
24/1

A.2.224. StEM 2K Multi-Reel C (Encrypted) 🔗

Type
MXF j2c multi
Filename
StEM_2K_j2c_multi_C_ct_<segment>.mxf
Description
A set of encrypted MXF track files containing 2k image essence for the DCI StEM Mini Movie. 64 files, each with a duration of 1 second.
Conforms to
Meta
SegmentCount
64
Encryption
AES-128
SegmentDuration
00:01:00
Duration
00:01:04:00
PixelArraySize
2048x858
EditRate
24/1

A.2.225. M25 Picture Track File with Malformed Integrity Pack: Missing MIC item (Encrypted) 🔗

Type
MXF j2c
Filename
m25_integrity_pict_mic_j2c_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count but the 1,441th edit unit is missing the MIC item.
Conforms to
Malformations
The 1,441th edit unit is missing the MIC item

A.2.226. M27 Picture Track File with Malformed Integrity Pack: Missing TrackFileID item (Encrypted) 🔗

Type
MXF j2c
Filename
m27_integrity_pict_tfid_j2c_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count but the 1,441th edit unit is missing the TrackFileID item.
Conforms to
Malformations
The 1,441th edit unit is missing the TrackFileID item

A.2.227. M26 Picture Track File with Malformed Integrity Pack: Missing SequenceNumber item (Encrypted) 🔗

Type
MXF j2c
Filename
m26_integrity_pict_snum_j2c_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count but the 1,441th edit unit is missing the SequenceNumber item.
Conforms to
Malformations
The 1,441th edit unit is missing the SequenceNumber item

A.2.228. Sync Count with KDM-Borne MIC Key Deleted Section 🔗

Type MXF j2c mkey Filename sync_count_j2c_mkey_pt.mxf Description Same as A.2.2. Sync

The section "Sync Count , but with KDM-borne KDM-Borne MIC Keys. Conforms Key" was deleted. The section number is maintained here to SMPTE-377-1 SMPTE-422 SMPTE-429-3 SMPTE-429-4 preserve the numbering of subsequent sections.

A.2.229. Sync Count with KDM-Borne MIC Key (Encrypted) 🔗

Type
MXF j2c mkey
Filename
sync_count_j2c_mkey_ct.mxf
Description
Encrypted MXF track file, contents are identical to A.2.228. A.2.2. Sync Count but with KDM-Borne KDM-borne MIC Key . Keys.
Conforms to

A.2.230. OBAE Rendering Expectations Guide 🔗

Type
MXF j2c mkey
Filename
obae_render_test_j2c_pt.mxf
Description
MXF track file whose image contents illustrates the expected acoustic output resulting from the rendering of A.3.90. OBAE Rendering Test .
Conforms to

A.2.231. HDR Sequential Contrast Sequence 🔗

Type
MXF j2c
Filename
4K_sequential_contrast_hdr_j2c_pt.mxf
Description
MXF track file containing black (X″= 60, Y″ = 62, Z″ = 65), white (X″= 2524, Y″= 2546, Z″= 2583) and aiming target HDR 4K frames.
Conforms to

A.2.232. 4K HDR Color Accuracy Series 🔗

Type
MXF j2c
Filename
4K_sequential_color_hdr_j2c_pt.mxf
Description
MXF track file containing five seconds (120 frames) of a chart illustrating all Color Accuracy Color Patch Code Values specified in [DCI-HDR] . This is followed by 1 minute of each of the Code Values as a full frame.
Conforms to

A.2.233. 2K Full SDR Black 🔗

Type
MXF j2c
Filename
2k_full_sdr_black_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K full frames, each filled with pixels with code value (X′=0, Y′=0, Z′=0).
Conforms to

A.2.234. 2K Scope SDR Black 🔗

Type
MXF j2c
Filename
2k_scope_sdr_black_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K scope frames, each filled with pixels with code value (X′=0, Y′=0, Z′=0).
Conforms to

A.2.235. 2K Flat SDR Black 🔗

Type
MXF j2c
Filename
2k_flat_sdr_black_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K flat frames, each filled with pixels with code value (X′=0, Y′=0, Z′=0).
Conforms to

A.2.236. 4K Full SDR Black 🔗

Type
MXF j2c
Filename
4k_full_sdr_black_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K full frames, each filled with pixels with code value (X′=0, Y′=0, Z′=0).
Conforms to

A.2.237. 4K Scope SDR Black 🔗

Type
MXF j2c
Filename
4k_scope_sdr_black_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K scope frames, each filled with pixels with code value (X′=0, Y′=0, Z′=0).
Conforms to

A.2.238. 4K Flat SDR Black 🔗

Type
MXF j2c
Filename
4k_flat_sdr_black_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K flat frames, each filled with pixels with code value (X′=0, Y′=0, Z′=0).
Conforms to

A.2.239. 2K Full SDR Black with Marks 🔗

Type
MXF j2c
Filename
2k_full_sdr_black_marks_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K full frames, each filled with pixels with code value (X′=0, Y′=0, Z′=0), with the exception of registration marks at each corner of the frame that use pixels with code value (X′=122, Y′=128, Z′=125), as illustrated at Figure A.2.239 .
Conforms to
Black frame with one registration marks at each corner
Figure A.2.239 . Black frame with registration marks (not to scale) 🔗

A.2.240. 2K Scope SDR Black with Marks 🔗

Type
MXF j2c
Filename
2k_scope_sdr_black_marks_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K scope frames, each filled with pixels with code value (X′=0, Y′=0, Z′=0), with the exception of registration marks at each corner of the frame that use pixels with code value (X′=122, Y′=128, Z′=125), as illustrated at Figure A.2.239 .
Conforms to

A.2.241. 2K Flat SDR Black with Marks 🔗

Type
MXF j2c
Filename
2k_flat_sdr_black_marks_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K flat frames, each filled with pixels with code value (X′=0, Y′=0, Z′=0), with the exception of registration marks at each corner of the frame that use pixels with code value (X′=122, Y′=128, Z′=125), as illustrated at Figure A.2.239 .
Conforms to

A.2.242. 4K Full SDR Black with Marks 🔗

Type
MXF j2c
Filename
4k_full_sdr_black_marks_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K full frames, each filled with pixels with code value (X′=0, Y′=0, Z′=0), with the exception of registration marks at each corner of the frame that use pixels with code value (X′=122, Y′=128, Z′=125), as illustrated at Figure A.2.239 .
Conforms to

A.2.243. 4K Scope SDR Black with Marks 🔗

Type
MXF j2c
Filename
4k_scope_sdr_black_marks_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K scope frames, each filled with pixels with code value (X′=0, Y′=0, Z′=0), with the exception of registration marks at each corner of the frame that use pixels with code value (X′=122, Y′=128, Z′=125), as illustrated at Figure A.2.239 .
Conforms to

A.2.244. 4K Flat SDR Black with Marks 🔗

Type
MXF j2c
Filename
4k_flat_sdr_black_marks_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K flat frames, each filled with pixels with code value (X′=0, Y′=0, Z′=0), with the exception of registration marks at each corner of the frame that use pixels with code value (X′=122, Y′=128, Z′=125), as illustrated at Figure A.2.239 .
Conforms to

A.2.245. 2K Full SDR Black with Active Area 🔗

Type
MXF j2c
Filename
2k_full_sdr_black_active_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K flat frames. Each frame, illustrated at Figure A.2.245 , consists of a central rectangular area with dimensions (1440×1080) filled with code value (X′=0, Y′=0, Z′=0). The rest of the frame is filled with code value (X′= 2901, Y′=2171, Z′=100). Registration marks with code value (X′=122, Y′=128, Z′=125) are located at all four corners of the central rectangular area.
Conforms to
Frame with a central black rectangle with registration marks at each corner, with the rest of the frame filled with red.
Figure A.2.245 . Frame with an active area (not to scale) 🔗

A.2.246. 2K Scope SDR Black with Active Area 🔗

Type
MXF j2c
Filename
2k_scope_sdr_black_active_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K scope frames. Each frame, illustrated at Figure A.2.245 , consists of a central rectangular area with dimensions (2048×768) filled with code value (X′=0, Y′=0, Z′=0). The rest of the frame is filled with code value (X′= 2901, Y′=2171, Z′=100). Registration marks with code value (X′=122, Y′=128, Z′=125) are located at all four corners of the central rectangular area.
Conforms to

A.2.247. 2K Flat SDR Black with Active Area 🔗

Type
MXF j2c
Filename
2k_flat_sdr_black_active_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K flat frames. Each frame, illustrated at Figure A.2.245 , consists of a central rectangular area with dimensions (1998×998) filled with code value (X′=0, Y′=0, Z′=0). The rest of the frame is filled with code value (X′= 2901, Y′=2171, Z′=100). Registration marks with code value (X′=122, Y′=128, Z′=125) are located at all four corners of the central rectangular area.
Conforms to

A.2.248. 4K Full SDR Black with Active Area 🔗

Type
MXF j2c
Filename
4k_full_sdr_black_active_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K full frames. Each frame, illustrated at Figure A.2.245 , consists of a central rectangular area with dimensions (2880×2160) filled with code value (X′=0, Y′=0, Z′=0). The rest of the frame is filled with code value (X′= 2901, Y′=2171, Z′=100). Registration marks with code value (X′=122, Y′=128, Z′=125) are located at all four corners of the central rectangular area.
Conforms to

A.2.249. 4K Scope SDR Black with Active Area 🔗

Type
MXF j2c
Filename
4k_scope_sdr_black_active_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K scope frames. Each frame, illustrated at Figure A.2.245 , consists of a central rectangular area with dimensions (4096×1536) filled with code value (X′=0, Y′=0, Z′=0). The rest of the frame is filled with code value (X′= 2901, Y′=2171, Z′=100). Registration marks with code value (X′=122, Y′=128, Z′=125) are located at all four corners of the central rectangular area.
Conforms to

A.2.250. 4K Flat SDR Black with Active Area 🔗

Type
MXF j2c
Filename
4k_flat_sdr_black_active_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K flat frames. Each frame, illustrated at Figure A.2.245 , consists of a central rectangular area with dimensions (3996×1996) filled with code value (X′=0, Y′=0, Z′=0). The rest of the frame is filled with code value (X′= 2901, Y′=2171, Z′=100). Registration marks with code value (X′=122, Y′=128, Z′=125) are located at all four corners of the central rectangular area.
Conforms to

A.2.251. SDR Stereoscopic Contrast Test Patterns 🔗

Type
MXF j2c
Filename
2k_full_sdr_contrast_stereo_j2c_pt.mxf
Description
Image Track File that consists of the sequence of test patterns specified in the stereoscopic extinction ratio & crosstalk and stereoscopic luminance & luminance difference procedures at [ICDM IDMS] :
  • black for left eye and white for right eye
  • white for left eye and black for right eye
  • black for both eyes
  • white for both eyes
Each pattern is displayed for 10s and is preceded by a card that is displayed for 3s and contains a description of the pattern, e.g. test pattern with black for left eye and white for right eye . The white pattern is D65 full screen white at 48 cd/m² (X’ = 3883, Y’ = 3960, Z’ = 4092). The black pattern is zero-signal black (X’=0, Y’=0, Z’=0).
Conforms to

A.2.252. Stereoscopic Color Accuracy Series 🔗

Type
MXF j2c
Filename
color_accuracy_stereo_j2c_pt.mxf
Description
Stereoscopic picture track file containing five seconds (120 frames) of the chart specified at A.2.12. Color Accuracy Series . This is followed by 1 minute of each of the 12 color values as a full frame. There is no disparity between the two eyes.
Conforms to

A.2.253. 4K SDR White Lines on Black Background 🔗

Type
MXF j2c
Filename
4k_white_lines_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K flat frames. Each frame, illustrated at Figure A.2.253 , consists of 3 sets of three patches, with the sets stacked vertically and the patches arranged horizontally. Each set consists one patch with horizontal lines, one patch with vertical lines and one patch with oblique lines. Each patch contains lines that are 1, 2, 3 and 4 pixel-wide, and that are not antialiased. The lines are D65 full screen white and the background is black.
Conforms to
Sets of horizontal, vertical and oblique white lines on a black background.
Figure A.2.253 . Frame with horizontal, vertical and oblique white lines on a black background (not to scale) 🔗

A.2.254. 4K SDR Scaling Test Pattern 🔗

Type
MXF j2c
Filename
4k_full_sdr_scaling_j2c_pt.mxf
Description
Image Track File that contains 10s of the 4K frame illustrated at Figure A.2.254 , which consists of: (a) on left side of the frame, continuous 1-pixel line segments at various angles and of various colors and a small gray square; and (b) on the right side of the frame, a zone plate with a wavelength of 2 pixels.
Conforms to
Frame with line segments, uniform gray square and zone plate.
Figure A.2.254 . Frame with line segments, uniform gray square and zone plate 🔗

A.2.260. HDR Black to Gray Step Series 🔗

Type
MXF j2c
Filename
hdr_gray_step_j2c_pt.mxf
Description
MXF track file containing five seconds (120 frames) of a chart showing all gray step values in [DCI-HDR] , Table 5. This is followed by 1 minute of each of the 10 values as a full frame. The layout of each frame follows that of A.2.10. Black to Gray Step Series .
Conforms to

A.2.261. HDR Black to White Step Series 🔗

Type
MXF j2c
Filename
hdr_white_step_j2c_pt.mxf
Description
MXF track file containing five seconds (120 frames) of a chart showing all gray step values in [DCI-HDR] , Table 4. This is followed by 1 minute of each of the 10 values as a full frame. The layout of each frame follows that of A.2.11. Black to White Step Series .
Conforms to

A.2.262. SDR verification pattern 🔗

Type
MXF j2c
Filename
sdr_check_j2c_pt.mxf
Description
MXF track file consisting of the following sequence: (1) 2-second card displaying the word "SDR dark", (2) 10 seconds of a frame filled with code values (X′=0, Y′=0, Z′=0), (3) 2-second card displaying the word "SDR light", and (4) 10 seconds of a frame filled with code values (X′=2524, Y′=2546, Z′=2583).
Conforms to

A.2.263. HDR verification pattern 🔗

Type
MXF j2c
Filename
hdr_check_j2c_pt.mxf
Description
MXF track file consisting of the following sequence: (1) 2-second card displaying the word "HDR dark", (2) 10 seconds of a frame filled with code values (X″=60, Y″=62, Z″=65), (3) 2-second card displaying the word "HDR light", and (4) 10 seconds of a frame filled with code values (X″=2524, Y″=2546, Z″=2583).
Conforms to

A.2.264. 2K Full HDR Black with Marks 🔗

Type
MXF j2c
Filename
2k_full_hdr_black_marks_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K full frames, each filled with pixels with code value (X″=0, Y″=0, Z″=0), with the exception of registration marks at each corner of the frame that use pixels with code value (X″=157, Y″=161, Z″=167), as illustrated at Figure A.2.239 .
Conforms to

A.2.265. 2K Scope HDR Black with Marks 🔗

Type
MXF j2c
Filename
2k_scope_hdr_black_marks_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K scope frames, each filled with pixels with code value (X″=0, Y″=0, Z″=0), with the exception of registration marks at each corner of the frame that use pixels with code value (X″=157, Y″=161, Z″=167), as illustrated at Figure A.2.239 .
Conforms to

A.2.266. 2K Flat HDR Black with Marks 🔗

Type
MXF j2c
Filename
2k_flat_hdr_black_marks_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K flat frames, each filled with pixels with code value (X″=0, Y″=0, Z″=0), with the exception of registration marks at each corner of the frame that use pixels with code value (X″=157, Y″=161, Z″=167), as illustrated at Figure A.2.239 .
Conforms to

A.2.267. 4K Full HDR Black with Marks 🔗

Type
MXF j2c
Filename
4k_full_hdr_black_marks_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K full frames, each filled with pixels with code value (X″=0, Y″=0, Z″=0), with the exception of registration marks at each corner of the frame that use pixels with code value (X″=157, Y″=161, Z″=167), as illustrated at Figure A.2.239 .
Conforms to

A.2.268. 4K Scope HDR Black with Marks 🔗

Type
MXF j2c
Filename
4k_scope_hdr_black_marks_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K scope frames, each filled with pixels with code value (X″=0, Y″=0, Z″=0), with the exception of registration marks at each corner of the frame that use pixels with code value (X″=157, Y″=161, Z″=167), as illustrated at Figure A.2.239 .
Conforms to

A.2.269. 4K Flat HDR Black with Marks 🔗

Type
MXF j2c
Filename
4k_flat_hdr_black_marks_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K flat frames, each filled with pixels with code value (X″=0, Y″=0, Z″=0), with the exception of registration marks at each corner of the frame that use pixels with code value (X″=157, Y″=161, Z″=167), as illustrated at Figure A.2.239 .
Conforms to

A.2.270. 2K Full HDR Black with Active Area 🔗

Type
MXF j2c
Filename
2k_full_hdr_black_active_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K flat frames. Each frame, illustrated at Figure A.2.245 , consists of a central rectangular area with dimensions (1440×1080) filled with code value (X″=0, Y″=0, Z″=0). The rest of the frame is filled with code value (X″= 2234, Y″=1925, Z″=68). Registration marks with code value (X″=157, Y″=161, Z″=167) are located at all four corners of the central rectangular area.
Conforms to

A.2.271. 2K Scope HDR Black with Active Area 🔗

Type
MXF j2c
Filename
2k_scope_hdr_black_active_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K scope frames. Each frame, illustrated at Figure A.2.245 , consists of a central rectangular area with dimensions (2048×768) filled with code value (X″=0, Y″=0, Z″=0). The rest of the frame is filled with code value (X″= 2234, Y″=1925, Z″=68). Registration marks with code value (X″=157, Y″=161, Z″=167) are located at all four corners of the central rectangular area.
Conforms to

A.2.272. 2K Flat HDR Black with Active Area 🔗

Type
MXF j2c
Filename
2k_flat_hdr_black_active_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 2K flat frames. Each frame, illustrated at Figure A.2.245 , consists of a central rectangular area with dimensions (1998×998) filled with code value (X″=0, Y″=0, Z″=0). The rest of the frame is filled with code value (X″= 2234, Y″=1925, Z″=68). Registration marks with code value (X″=157, Y″=161, Z″=167) are located at all four corners of the central rectangular area.
Conforms to

A.2.273. 4K Full HDR Black with Active Area 🔗

Type
MXF j2c
Filename
4k_full_hdr_black_active_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K full frames. Each frame, illustrated at Figure A.2.245 , consists of a central rectangular area with dimensions (2880×2160) filled with code value (X″=0, Y″=0, Z″=0). The rest of the frame is filled with code value (X″= 2234, Y″=1925, Z″=68). Registration marks with code value (X″=157, Y″=161, Z″=167) are located at all four corners of the central rectangular area.
Conforms to

A.2.274. 4K Scope HDR Black with Active Area 🔗

Type
MXF j2c
Filename
4k_scope_hdr_black_active_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K scope frames. Each frame, illustrated at Figure A.2.245 , consists of a central rectangular area with dimensions (4096×1536) filled with code value (X″=0, Y″=0, Z″=0). The rest of the frame is filled with code value (X″= 2234, Y″=1925, Z″=68). Registration marks with code value (X″=157, Y″=161, Z″=167) are located at all four corners of the central rectangular area.
Conforms to

A.2.275. 4K Flat HDR Black with Active Area 🔗

Type
MXF j2c
Filename
4k_flat_hdr_black_active_j2c_pt.mxf
Description
Image Track File that contains 1 minute of 4K flat frames. Each frame, illustrated at Figure A.2.245 , consists of a central rectangular area with dimensions (3996×1996) filled with code value (X″=0, Y″=0, Z″=0). The rest of the frame is filled with code value (X″= 2234, Y″=1925, Z″=68). Registration marks with code value (X″=157, Y″=161, Z″=167) are located at all four corners of the central rectangular area.
Conforms to

A.2.276. 2K 2D 24 FPS Test 🔗

Type
MXF j2c
Filename
2k_2d_24_fps_j2c_pt.mxf
Description
Image Track File that contains a 2K 2D image sequence at 24 fps intended to verify that an imaging device displays all images. The image sequence displays a continuously swinging pendulum. Every even and odd frame is labeled even and odd , respectively. Every 1 st , 2 nd , 3 rd , 4 th and 5 th frame is labeled 1 , 2 , 3 , 4 and 5 , respectively. A burned-in timecode sequence is displayed in the top-right corner.
Conforms to

A.2.277. 2K 2D 48 FPS Test 🔗

Type
MXF j2c
Filename
2k_2d_48_fps_j2c_pt.mxf
Description
Same as A.2.276. 2K 2D 24 FPS Test but with a 2K 2D image sequence at 48 fps.
Conforms to

A.2.278. 2K 2D 60 FPS Test 🔗

Type
MXF j2c
Filename
2k_2d_60_fps_j2c_pt.mxf
Description
Same as A.2.276. 2K 2D 24 FPS Test but with a 2K 2D image sequence at 60 fps.
Conforms to

A.2.279. 2K 2D 96 FPS Test 🔗

Type
MXF j2c
Filename
2k_2d_96_fps_j2c_pt.mxf
Description
Same as A.2.276. 2K 2D 24 FPS Test but with a 2K 2D image sequence at 96 fps.
Conforms to

A.2.280. 2K 2D 120 FPS Test 🔗

Type
MXF j2c
Filename
2k_2d_120_fps_j2c_pt.mxf
Description
Same as A.2.276. 2K 2D 24 FPS Test but with a 2K 2D image sequence at 120 fps.
Conforms to

A.2.281. 2K Stereoscopic 24 FPS Test 🔗

Type
MXF j2c
Filename
2k_stereo_24_fps_j2c_pt.mxf
Description
Same as A.2.276. 2K 2D 24 FPS Test but with a 2K stereoscopic image sequence at 24 fps, the pendulum popping out of the screen and the words left and right appearing only in the left and right eye, respectively.
Conforms to

A.2.282. 2K Stereoscopic 48 FPS Test 🔗

Type
MXF j2c
Filename
2k_stereo_48_fps_j2c_pt.mxf
Description
Same as A.2.281. 2K Stereoscopic 24 FPS Test but with a 2K stereoscopic image sequence at 48 fps.
Conforms to

A.2.283. 2K Stereoscopic 60 FPS Test 🔗

Type
MXF j2c
Filename
2k_stereo_60_fps_j2c_pt.mxf
Description
Same as A.2.281. 2K Stereoscopic 24 FPS Test but with a 2K stereoscopic image sequence at 60 fps.
Conforms to

A.2.284. 4K 2D 24 FPS Test 🔗

Type
MXF j2c
Filename
4k_2d_24_fps_j2c_pt.mxf
Description
Same as A.2.276. 2K 2D 24 FPS Test but with a 4K image sequence at 24 fps, and the word 4K visible only if the 4K resolution layer is decoded.
Conforms to

A.2.285. 4K 2D 48 FPS Test 🔗

Type
MXF j2c
Filename
4k_2d_48_fps_j2c_pt.mxf
Description
Same as A.2.284. 4K 2D 24 FPS Test but with a 4K 2D image sequence at 48 fps.
Conforms to

A.2.286. 4K 2D 60 FPS Test 🔗

Type
MXF j2c
Filename
4k_2d_60_fps_j2c_pt.mxf
Description
Same as A.2.284. 4K 2D 24 FPS Test but with a 4K 2D image sequence at 60 fps.
Conforms to

A.2.287. 24 FPS test timecode 🔗

Type
MXF text
Filename
24_fps_test_tt_pt.mxf
Description
MXF track file containing timed text that matches the burned-in timecode at 2K 2D 24 FPS Test .
Conforms to

A.2.288. 48 FPS test timecode 🔗

Type
MXF text
Filename
48_fps_test_tt_pt.mxf
Description
MXF track file containing timed text that matches the burned-in timecode at 2K 2D 48 FPS Test .
Conforms to

A.2.289. 60 FPS test timecode 🔗

Type
MXF text
Filename
60_fps_test_tt_pt.mxf
Description
MXF track file containing timed text that matches the burned-in timecode at 2K 2D 60 FPS Test .
Conforms to

A.2.290. 96 FPS test timecode 🔗

Type
MXF text
Filename
96_fps_test_tt_pt.mxf
Description
MXF track file containing timed text that matches the burned-in timecode at 2K 2D 96 FPS Test .
Conforms to

A.2.291. 120 FPS test timecode 🔗

Type
MXF text
Filename
120_fps_test_tt_pt.mxf
Description
MXF track file containing timed text that matches the burned-in timecode at 2K 2D 120 FPS Test .
Conforms to

A.2.292. SDR Dark Gray Scale 🔗

Type
MXF j2c
Filename
4k_full_sdr_dark_gray_j2c_pt.mxf
Description
MXF track file containing five seconds (120 frames) of a chart showing all gray step values in Table A.2 . This is followed by the step values, each as a full frame with a duration of 50 s.
Conforms to
Table A.2 .292 Dark Gray Scale X′Y′Z′ 12-bit Codevalues 🔗
Step Number X′ Y′ Z′
1 269 274 283
2 270 275 284
3 271 276 285
4 272 277 286
5 273 278 287
6 274 279 288
7 275 280 289
8 276 281 290
9 277 282 292
10 278 283 292
11 279 284 293
12 279 285 295
13 280 286 296
14 281 287 297
15 282 288 298
16 283 289 299
17 284 290 300

A.2.293. HDR Dark Gray Scale 🔗

Type
MXF j2c
Filename
4k_full_hdr_dark_gray_j2c_pt.mxf
Description
HDR Picture Track File containing five seconds (120 frames) of a chart showing all gray step values in Table A.2 . This is followed by the step values, each as a full frame with a duration of 50 s.
Conforms to
Table A.2 .293 Dark Gray Scale X″Y″Z″ 12-bit Codevalues 🔗
Step Number X″ Y″ Z″
1 177 181 188
2 178 182 189
3 179 183 190
4 180 184 191
5 181 185 192
6 182 186 193
7 183 187 194
8 184 188 195
9 185 189 196
10 186 190 197
11 187 191 198
12 188 192 199
13 189 193 200
14 190 194 201
15 191 195 203
16 192 196 204
17 193 197 205

A.3. Sound 🔗

A.3.1. Introduction 🔗

This section defines a set of MXF sound track files. For each track file, a description is given which details the sounds encoded in the file. The sound track files will be combined with image files to make complete compositions (see Section A.4 ).

A.3.2. Sync Count 5.1 🔗

Type
MXF pcm
Filename
sync_count_51_pcm_pt.mxf
Description
MXF track file containing six channels of audio. Channels 1,2,4,5 and 6 are silent. Channel 3 (Center) contains five seconds (120 frames) of silence followed by a ten second countdown and five seconds of silence. The countdown consists of ten identical one-second count segments. Each count segment consists of one frame (2000 samples) encoding of a 1 kHz sine wave at -20 dBFS, followed by 23 frames of silence.
Conforms to
Meta
SoundFormat
5.1
Duration
00:20:00
SampleRate
48000
EditRate
24/1

A.3.3. Sync Count 5.1 (Encrypted) 🔗

Type
MXF pcm
Filename
sync_count_51_pcm_ct.mxf
Description
Encrypted MXF track file, contents are identical to Section A.3.2: Sync Count 5
Conforms to
Meta
SoundFormat
5.1
Encryption
AES-128
Duration
00:20:00
SampleRate
48000
EditRate
24/1

A.3.4. Sync Count 5.1 48fps 🔗

Type
MXF pcm
Filename
sync_count_51_48fps_pcm_pt.mxf
Description
MXF track file containing six channels of audio. Channels 1,2,4,5 and 6 are silent. Channel 3 (Center) contains five seconds (240 frames) of silence followed by a ten second countdown and five seconds of silence. The countdown consists of ten identical one-second count segments. Each count segment consists of two frames (2000 samples) encoding of a 1 kHz sine wave at -20 dBFS, followed by 46 frames of silence.
Conforms to
Meta
SoundFormat
5.1
Duration
00:20:00
SampleRate
48000
EditRate
48/1

A.3.5. Channel I.D. 5.1 🔗

Type
MXF pcm
Filename
channel_id_51_pcm_pt.mxf
Description
MXF track file containing a repeated voice announcement of the channel label of the respective channel: Left (Channel 1), Center (Channel 3), Right (Channel 2), Left Surround (Channel 5), Right Surround (Channel 6), LFE (Channel 4). Voice announcements are sequential, in the order given here.
Conforms to
Malformations
Meta
SoundFormat
5.1
Duration
00:40:00
SampleRate
48000
EditRate
24/1

A.3.6. Channel I.D. 1-16 🔗

Type
MXF pcm
Filename
channel_id_01-16_pcm_pt.mxf
Description
MXF track file containing a sequential voice announcement of the channel number of the respective channel.
Conforms to
Meta
SoundFormat
WTF
Duration
01:24:00
SampleRate
48000
EditRate
24/1

A.3.7. Pink Noise, 16 Channels 🔗

Type
MXF pcm
Filename
pink_noise_1-16_pcm_pt.mxf
Description
Pink (1/ f) noise at -20 dBFS on sixteen channels, band limited to 22 KHz. Identical, sample-aligned signal must be used on all channels.
Conforms to
Meta
SoundFormat
WTF
Duration
00:30:00
SampleRate
48000
EditRate
24/1

A.3.8. Pink Noise, 16 Channels, 96 kHz 🔗

Type
MXF pcm
Filename
pink_noise_1-16_96khz_pcm_pt.mxf
Description
Pink (1/ f) noise at -20 dBFS on sixteen channels, band limited to 44 KHz. Identical, sample-aligned signal must be used on all channels.
Conforms to
Meta
SoundFormat
WTF
Duration
00:30:00
SampleRate
96000
EditRate
24/1

A.3.9. Deleted Section 🔗

The section "Pink Noise, 16 Channels, 96 kHz (Encrypted)" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.3.10. Maximum Bitrate, 16 Channels, 96 kHz (Encrypted) 🔗

Type
MXF pcm
Filename
max_bitrate_1-16_96khz_pcm_ct.mxf
Description
Encrypted MXF sound track file containing a count to check synchronization between picture and sound, 10 minutes of pink (1/ f) noise at -20 dBFS on all sixteen channels, band limited to 44 KHz and a second sync count.
Conforms to
Meta
SoundFormat
WTF
Encryption
AES-128
Duration
00:10:40:00
SampleRate
96000
EditRate
24/1

A.3.11. 1 kHz Sine Wave 🔗

Type
MXF pcm
Filename
1_khz_sine_wave_pcm_pt.mxf
Description
MXF track file containing 1 kHz sine wave on sixteen channels at -20 dBFS.
Conforms to
Meta
SoundFormat
WTF
Duration
02:00:00
SampleRate
48000
EditRate
24/1

A.3.12. 1 kHz Sine Wave, 16 Channels 96kHz 🔗

Type
MXF pcm
Filename
1_khz_sine_wave_96khz_pcm_pt.mxf
Description
MXF track file containing 96kHz sample rate 1 kHz sine wave on sixteen channels at -20 dBFS.
Conforms to
Meta
SoundFormat
WTF
Duration
02:00:00
SampleRate
96000
EditRate
24/1

A.3.13. 400 hz sine wave 🔗

Type
MXF pcm
Filename
400_hz_sine_wave_pcm_pt.mxf
Description
MXF track file containing 400 Hz sine wave on six channels at -20 dBfs (dB Full Scale). LFE channel is full-range.
Conforms to
Meta
SoundFormat
5.1
Duration
02:00:00
SampleRate
48000
EditRate
24/1

A.3.14. Deleted Section 🔗

The section "400 hz sine wave (Encrypted)" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.3.15. 400 hz sine wave, WTF (Encrypted) 🔗

Type
MXF pcm
Filename
400_hz_sine_wave_wtf_pcm_ct.mxf
Description
Encrypted MXF track file containing 400 Hz sine wave on sixteen channels at -20 dBfs (dB Full Scale). LFE channel is full-range.
Conforms to
Meta
SoundFormat
WTF
Encryption
AES-128
Duration
02:00:00
SampleRate
48000
EditRate
24/1

A.3.16. Silence, 5.1 🔗

Type
MXF pcm
Filename
black_51_pcm_pt.mxf
Description
MXF track file containing six channels of silence.
Conforms to
Meta
SoundFormat
5.1
Duration
02:00:00
SampleRate
48000
EditRate
24/1

A.3.17. Silence, 5.1, 15 minutes 🔗

Type
MXF pcm
Filename
black_long_51_pcm_pt.mxf
Description
MXF track file containing six channels of silence.
Conforms to
Meta
SoundFormat
5.1
Duration
00:15:00:00
SampleRate
48000
EditRate
24/1

A.3.18. Silence, 5.1, 15 minutes (Encrypted) 🔗

Type
MXF pcm
Filename
black_long_51_pcm_ct.mxf
Description
MXF track file containing six channels of silence.
Conforms to
Prerequisites
Meta
SoundFormat
5.1
Encryption
AES-128
Duration
00:15:00:00
SampleRate
48000
EditRate
24/1

A.3.19. StEM 5.1 Sound 🔗

Type
MXF pcm
Filename
StEM_51_pcm_pt.mxf
Description
MXF track file containing 5.1 sound essence for the DCI StEM Mini Movie.
Conforms to
Meta
SoundFormat
5.1
Duration
11:31:21
SampleRate
48000
EditRate
24/1

A.3.20. StEM 5.1 Sound (Encrypted) 🔗

Type
MXF pcm
Filename
StEM_51_pcm_ct.mxf
Description
Encrypted MXF track file containing 5.1 sound essence for the DCI StEM Mini Movie.
Conforms to
Meta
SoundFormat
5.1
Encryption
AES-128
Duration
11:31:21
SampleRate
48000
EditRate
24/1

A.3.21. StEM 5.1 Sound Multi-Reel A (Encrypted) 🔗

Type
MXF pcm multi
Filename
StEM_51_pcm_multi_A_ct_<segment>.mxf
Description
A set of encrypted MXF track files containing 5.1 sound essence for the DCI StEM Mini Movie.
Conforms to
Meta
SoundFormat
5.1
SegmentCount
128
Encryption
AES-128
SegmentDuration
00:05:00
Duration
00:10:40:00
SampleRate
48000
EditRate
24/1

A.3.22. StEM 5.1 Sound Multi-Reel B (Encrypted) 🔗

Type
MXF pcm multi
Filename
StEM_51_pcm_multi_B_ct_<segment>.mxf
Description
A set of encrypted MXF track files containing 5.1 sound essence for the DCI StEM Mini Movie. Identical to StEM_51_pcm_multi_A_ct
Conforms to
Meta
SoundFormat
5.1
SegmentCount
128
Encryption
AES-128
SegmentDuration
00:05:00
Duration
00:10:40:00
SampleRate
48000
EditRate
24/1

A.3.23. StEM 5.1 Sound Multi-Reel A 🔗

Type
MXF pcm multi
Filename
StEM_51_pcm_multi_A_pt_<segment>.mxf
Description
A set of plaintext MXF track files containing 5.1 sound essence for the DCI StEM Mini Movie. 128 files, each with a duration of 5 seconds.
Conforms to
Meta
SoundFormat
5.1
SegmentCount
128
SegmentDuration
00:05:00
Duration
00:10:40:00
SampleRate
48000
EditRate
24/1

A.3.24. StEM 5.1 Sound Multi-Reel B 🔗

Type
MXF pcm multi
Filename
StEM_51_pcm_multi_B_pt_<segment>.mxf
Description
A set of plaintext MXF track files containing 5.1 sound essence for the DCI StEM Mini Movie. Identical to StEM_51_pcm_multi_A_pt
Conforms to
Meta
SoundFormat
5.1
SegmentCount
128
SegmentDuration
00:05:00
Duration
00:10:40:00
SampleRate
48000
EditRate
24/1

A.3.25. StEM 48fps 5.1 Sound 🔗

Type
MXF pcm
Filename
StEM_48fps_51_pcm_pt.mxf
Description
MXF track file containing 5.1 sound essence for the 48 fps DCI StEM Mini Movie.
Conforms to
Meta
SoundFormat
5.1
Duration
00:51:46
SampleRate
48000
EditRate
48/1

A.3.26. Deleted Section 🔗

The section "FM StEM 5.1 Sound (Encrypted)" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.3.27. FM StEM WTF Sound 🔗

Type
MXF pcm
Filename
fm_StEM_wtf_pcm_pt.mxf
Description
MXF track file for FM testing containing WTF sound essence for the DCI StEM Mini Movie.
Conforms to
Meta
SoundFormat
WTF
Duration
11:31:21
SampleRate
48000
EditRate
24/1

A.3.28. FM StEM WTF Sound (Encrypted) 🔗

Type
MXF pcm
Filename
fm_StEM_wtf_pcm_ct.mxf
Description
Encrypted MXF track file for FM testing containing WTF sound essence for the DCI StEM Mini Movie.
Conforms to
Meta
SoundFormat
WTF
Encryption
AES-128
Duration
11:31:21
SampleRate
48000
EditRate
24/1

A.3.29. Binary Audio FM Bypass WTF Sound (Encrypted) 🔗

Type
MXF pcm
Filename
binary_audio_fm_bypass_wtf_pcm_ct.mxf
Description
Encrypted MXF track file for FM testing containing known binary audio content on 16 channels of WTF format sound essence.
Conforms to
Meta
SoundFormat
WTF
Encryption
AES-128
Duration
10:00:00
SampleRate
48000
EditRate
24/1

A.3.30. m02 Sound Frame Out Of Order (Encrypted) 🔗

Type
MXF pcm
Filename
m02_snd_frame_oo_51_pcm_ct.mxf
Description
Malformed, encrypted MXF track file containing six channels of 400Hz sine waves.
Conforms to
Malformations
The KLV packets containing edit units 01 and 02 are swapped.
Meta
SoundFormat
5.1
Encryption
AES-128
Duration
00:00:05:00
SampleRate
48000
EditRate
24/1

A.3.31. m04 Sound Track File With Wrong TrackFile ID (Encrypted) 🔗

Type
MXF pcm
Filename
m04_sndtk_wrong_file_pcm_ct.mxf
Description
MXF track file in which the integrity pack of the 7th frame has the TrackFile ID replaced with a different value.
Conforms to
Meta
Encryption
AES-128
Duration
00:00:05:00
EditRate
24/1

A.3.32. m10 Sound track file with bad HMAC (Encrypted) 🔗

Type
MXF pcm
Filename
m10_snd_bad_hmac_pcm_ct.mxf
Description
Sound track file in which one of the HMAC values for a single frame has been changed.
Conforms to
Malformations
The file contains a replacement EKLV packet for the seventh frame (index 6). The replacement packet is taken from another track file having a different PackageUID but encrypted with the same symmetric key.
Meta
SoundFormat
5.1
Encryption
AES-128
Duration
00:00:05:00
SampleRate
48000
EditRate
24/1

A.3.33. m12 Sound Track File With Bad Check Value (Encrypted) 🔗

Type
MXF pcm
Filename
m12_snd_bad_chuk_pcm_ct.mxf
Description
MXF track file containing one EKLV packet with an invalid Check Value.
Conforms to
Meta
Encryption
AES-128
Duration
00:00:05:00
EditRate
24/1

A.3.34. 400 hz sine wave, WTF 🔗

Type
MXF pcm
Filename
400_hz_sine_wave_wtf_pcm_pt.mxf
Description
MXF track file containing 400 Hz sine wave on sixteen channels at -20 dBfs (dB Full Scale). LFE channel is full-range.
Conforms to
Meta
SoundFormat
WTF
Duration
02:00:00
SampleRate
48000
EditRate
24/1

A.3.35. Silence, 5.1 (Encrypted) 🔗

Type
MXF pcm
Filename
black_51_pcm_ct.mxf
Description
Encrypted MXF track file containing six channels of silence.
Conforms to
Prerequisites
Meta
SoundFormat
5.1
Encryption
AES-128
Duration
02:00:00
SampleRate
48000
EditRate
24/1

A.3.36. Silence, 5.1, 48 fps (Encrypted) 🔗

Type
MXF pcm
Filename
black_51_48fps_pcm_ct.mxf
Description
48 Frames per second (fps) MXF track file containing six channels of silence.
Conforms to
Meta
SoundFormat
5.1
Encryption
AES-128
Duration
00:02:00:00
SampleRate
48000
EditRate
48/1

A.3.37. StEM 5.1 Sound Multi-Reel C (Encrypted) 🔗

Type
MXF pcm multi
Filename
StEM_51_pcm_multi_C_ct_<segment>.mxf
Description
A set of encrypted MXF track files containing 5.1 sound essence for the DCI StEM Mini Movie. 64 files, each with a duration of 1 second.
Conforms to
Meta
SoundFormat
5.1
SegmentCount
64
Encryption
AES-128
SegmentDuration
00:01:00
Duration
00:01:04:00
SampleRate
48000
EditRate
24/1

A.3.38. Sync Count OBAE (Encrypted) 🔗

Type
MXF obae
Filename
sync_count_obae_ct.mxf
Description
Encrypted version of Section A.3.39: Sync Count OBAE
Conforms to

A.3.39. Sync Count OBAE 🔗

Type
MXF obae
Filename
sync_count_obae_pt.mxf
Description
Immersive Audio track file where the center channel of the 9.1OH bed contains five seconds (120 frames) of silence followed by a ten second countdown and five seconds of silence. The countdown consists of ten identical one-second count segments. Each count segment consists of one frame (2000 samples) encoding of a 1 kHz sine wave at -20 dBFS, followed by 23 frames of silence.
Conforms to

A.3.40. Main Sound for Sync Count OBAE (Encrypted) 🔗

Type
MXF pcm
Filename
sync_count_obae_ms_ct.mxf
Description
Encrypted version of Section A.3.41: Main Sound for Sync Count OBAE .
Conforms to

A.3.41. Main Sound for Sync Count OBAE 🔗

Type
MXF pcm
Filename
sync_count_obae_ms_pt.mxf
Description
Sound Track File as specified in SMPTE ST 429-19, where the FSK synchronization signal is intended to synchronize playback of Section A.3.39: Sync Count OBAE .
Conforms to

A.3.42. Main Sound for StEM OBAE (Encrypted) 🔗

Type
MXF pcm
Filename
StEM_obae_ms_ct.mxf
Description
Encrypted version of Section A.3.43: Main Sound for StEM OBAE .
Conforms to

A.3.43. Main Sound for StEM OBAE 🔗

Type
MXF pcm
Filename
StEM_obae_ms_pt.mxf
Description
Sound Track File as specified in SMPTE ST 429-19, where the FSK synchronization signal is intended to synchronize playback of Section A.3.45: StEM OBAE .
Conforms to

A.3.44. StEM OBAE (Encrypted) 🔗

Type
MXF obae
Filename
StEM_obae_ct.mxf
Description
Encrypted version of Section A.3.45: StEM OBAE
Conforms to

A.3.45. StEM OBAE 🔗

Type
MXF obae
Filename
StEM_obae_pt.mxf
Description
Immersive Audio track file for the StEM mini-movie.
Conforms to

A.3.46. M28 Sound Track File with Malformed Integrity Pack: Missing MIC item (Encrypted) 🔗

Type
MXF pcm
Filename
m28_integrity_snd_mic_pcm_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count 5.1 but the 1,441th edit unit is missing the MIC item.
Conforms to
Malformations
The 1,441th edit unit is missing the MIC item

A.3.47. M30 Sound Track File with Malformed Integrity Pack: Missing TrackFileID item (Encrypted) 🔗

Type
MXF pcm
Filename
m30_integrity_snd_tfid_pcm_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count 5.1 but the 1,441th edit unit is missing the TrackFileID item.
Conforms to
Malformations
The 1,441th edit unit is missing the TrackFileID item

A.3.48. M29 Sound Track File with Malformed Integrity Pack: Missing SequenceNumber item (Encrypted) 🔗

Type
MXF pcm
Filename
m29_integrity_snd_snum_pcm_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count 5.1 but the 1,441th edit unit is missing the SequenceNumber item.
Conforms to
Malformations
The 1,441th edit unit is missing the SequenceNumber item

A.3.49. M20 Sound Track File with Malformed Integrity Pack: Missing MIC item (OBAE) (Encrypted) 🔗

Type
MXF pcm
Filename
m20_integrity_obae_ms_mic_pcm_ct.mxf
Description
Encrypted MXF track file, contents are identical to Main Sound for Sync Count OBAE but the 1,441th edit unit is missing the MIC item.
Conforms to
Malformations
The 1,441th edit unit is missing the MIC item

A.3.50. M22 Sound Track File with Malformed Integrity Pack: Missing TrackFileID item (OBAE) (Encrypted) 🔗

Type
MXF pcm
Filename
m22_integrity_obae_ms_tfid_pcm_ct.mxf
Description
Encrypted MXF track file, contents are identical to Main Sound for Sync Count OBAE but the 1,441th edit unit is missing the TrackFileID item.
Conforms to
Malformations
The 1,441th edit unit is missing the TrackFileID item

A.3.51. M21 Sound Track File with Malformed Integrity Pack: Missing SequenceNumber item (OBAE) (Encrypted) 🔗

Type
MXF pcm
Filename
m21_integrity_obae_ms_snum_pcm_ct.mxf
Description
Encrypted MXF track file, contents are identical to Main Sound for Sync Count OBAE but the 1,441th edit unit is missing the SequenceNumber item.
Conforms to
Malformations
The 1,441th edit unit is missing the SequenceNumber item

A.3.52. M19 OBAE Track File with Malformed Integrity Pack: Missing MIC item (Encrypted) 🔗

Type
MXF obae
Filename
m19_integrity_obae_mic_obae_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count OBAE but the 1,441th edit unit is missing the MIC item.
Conforms to
Malformations
The 1,441th edit unit is missing the MIC item

A.3.53. M24 OBAE Track File with Malformed Integrity Pack: Missing TrackFileID item (OBAE) (Encrypted) 🔗

Type
MXF obae
Filename
m24_integrity_obae_tfid_obae_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count OBAE but the 1,441th edit unit is missing the TrackFileID item.
Conforms to
Malformations
The 1,441th edit unit is missing the TrackFileID item

A.3.54. M23 OBAE Track File with Malformed Integrity Pack: Missing SequenceNumber item (Encrypted) 🔗

Type
MXF obae
Filename
m23_integrity_obae_snum_obae_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count OBAE but the 1,441th edit unit is missing the SequenceNumber item.
Conforms to
Malformations
The 1,441th edit unit is missing the SequenceNumber item

A.3.55. StEM OBAE Multi-Reel C (Encrypted) 🔗

Type
MXF obae multi
Filename
StEM_obae_multi_C_ct_<segment>.mxf
Description
A set of encrypted track files containing OBAE essence for the DCI StEM Mini Movie. 64 files, each with a duration of 1 second.
Conforms to

A.3.56. Main Sound for StEM OBAE Multi-Reel C (Encrypted) 🔗

Type
MXF pcm multi
Filename
StEM_obae_ms_multi_C_ct_<segment>.mxf
Description
A set of encrypted sound track files, where the FSK synchronization signal is intended to synchronize playback of Section A.3.55: StEM OBAE Multi-Reel C (Encrypted) . 64 files, each with a duration of 1 second.
Conforms to

A.3.57. M40 OBAE Track File with Frame-out-of-order error (Encrypted) 🔗

Type
MXF obae
Filename
m40_obae_frame_oo_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count OBAE but the KLV packets for the 1st and 2nd edit units are swapped.
Conforms to
Malformations
The 1st and 2nd edit units contain out-of-order Sequence Number item values.

A.3.58. M41 OBAE Track File With Wrong TrackFile ID (Encrypted) 🔗

Type
MXF obae
Filename
m41_obae_wrong_file_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count OBAE but with the TrackFile ID item value of the 7th edit unit replaced with a different value.
Conforms to
Malformations
The TrackFile ID item value of the 7th edit unit is not equal to the identifier of the Track File.

A.3.59. Sync Count OBAE with MIC Key (Encrypted) 🔗

Type
MXF obae mkey
Filename
sync_count_obae_mkey_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count OBAE , with the MIC item value computed using the MIC Key c5 9a f6 6f bd e0 70 39 ba 36 2c 62 e8 21 e6 02 .
Conforms to

A.3.60. M43 OBAE Track File With Bad Check Value (Encrypted) 🔗

Type
MXF obae
Filename
m43_obae_bad_chuk_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count OBAE but with the Check Value of the 7th edit unit replaced with an invalid value.
Conforms to
Malformations
The Check Value value of the 7th edit unit is invalid.

A.3.61. Sync Count 5.1 with KDM-Borne MIC Key Deleted Section 🔗

Type MXF pcm mkey Filename sync_count_51_pcm_mkey_pt.mxf Description Same as Sync

The section "Sync Count 5.1 but with KDM-borne KDM-Borne MIC Keys. Conforms Key" was deleted. The section number is maintained here to SMPTE-377-1 SMPTE-429-3 SMPTE-382 preserve the numbering of subsequent sections.

A.3.62. Sync Count 5.1 with KDM-Borne MIC Key (Encrypted) 🔗

Type
MXF pcm
Filename
sync_count_51_pcm_mkey_ct.mxf
Description
Encrypted MXF track file, contents are identical to A.3.61. A.3.2. Sync Count 5.1 but with KDM-Borne KDM-borne MIC Key . Keys.
Conforms to

A.3.63. M44 OBAE Track File With Bad HMAC Value (Encrypted) 🔗

Type
MXF obae
Filename
m44_obae_bad_hmac_ct.mxf
Description
Encrypted MXF track file, contents are identical to Sync Count OBAE but with the HMAC value of the 7th edit unit replaced with an invalid value.
Conforms to
Malformations
The HMAC value of the 7th edit unit is invalid.

A.3.64. OBAE Tone Multi-Reel (Encrypted) 🔗

Type
MXF obae multi
Filename
OBAE_tone_multi_ct_<segment>.mxf
Description
Encrypted version of A.3.65. OBAE Tone Multi-Reel Conforms to SMPTE-377-1 SMPTE-429-3 SMPTE-429-18 SMPTE-429-6 A.3.65. OBAE Tone Multi-Reel 🔗 Type MXF obae multi Filename OBAE_tone_multi_pt_<segment>.mxf Description Sequence of 20 Encrypted OBAE Track Files, each 1 second long, whose IA Frame contents, when concatenated, form a single continuous IA Bitstream. The IA Bitstream consists of (a) 9.1OH bed channels, each containing a 400 Hz sine wave tone (-20 dBFS), and (b) one stationary object, using a 400 Hz sine wave tone (-20 dBFS).
Conforms to

A.3.66. A.3.65. Main Sound for OBAE Tone Multi-Reel (Encrypted) Deleted Section 🔗

Type MXF pcm multi Filename OBAE_tone_multi_ms_ct_<segment>.mxf Description Encrypted version of A.3.67. Main Sound for OBAE

The section "OBAE Tone Multi-Reel Conforms Multi-Reel" was deleted. The section number is maintained here to SMPTE-377-1 SMPTE-429-3 SMPTE-429-6 SMPTE-382 SMPTE-430-12 SMPTE-429-19 preserve the numbering of subsequent sections.

A.3.67. A.3.66. Main Sound for OBAE Tone Multi-Reel (Encrypted) 🔗

Type
MXF pcm multi
Filename
OBAE_tone_multi_ms_pt_<segment>.mxf OBAE_tone_multi_ms_ct_<segment>.mxf
Description
Sequence of Encrypted Sound Track Files, each as specified in SMPTE ST 429-19, where the FSK synchronization signal is intended to synchronize playback of A.3.65. OBAE Tone Multi-Reel Deleted Section .
Conforms to

A.3.68. A.3.67. Audio Tone Multi-Reel (Encrypted) Deleted Section 🔗

Type MXF pcm multi Filename audio_tone_multi_ct_<segment>.mxf Description Encrypted version of A.3.69. Audio

The section "Main Sound for OBAE Tone Multi-Reel Conforms Multi-Reel" was deleted. The section number is maintained here to SMPTE-377-1 SMPTE-429-3 SMPTE-429-6 SMPTE-382 preserve the numbering of subsequent sections.

A.3.69. A.3.68. Audio Tone Multi-Reel (Encrypted) 🔗

Type
MXF pcm multi
Filename
audio_tone_multi_pt_<segment>.mxf audio_tone_multi_ct_<segment>.mxf
Description
Sequence of 20 encrypted audio track files, each 1 second long, whose contents, when concatenated, consists of a continuous 400 Hz sine wave on sixteen channels at -20 dBfs (dB Full Scale). The LFE channel is full-range.
Conforms to

A.3.69. Deleted Section 🔗

The section "Audio Tone Multi-Reel" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.3.70. Main Sound for Sync Count (48fps) OBAE 🔗

Type
MXF pcm
Filename
sync_count_48fps_obae_ms_pt.mxf
Description
Sound Track File as specified in SMPTE ST 429-19, where the FSK synchronization signal is intended to synchronize playback of Sync Count (48fps) OBAE .
Conforms to

A.3.71. Sync Count (48fps) OBAE 🔗

Type
MXF obae
Filename
sync_count_48fps_obae_pt.mxf
Description
Identical content to Sync Count OBAE , but framed at 48 fps.
Conforms to

A.3.72. 400 hz sine wave (OBAE) 🔗

Type
MXF obae
Filename
400_hz_sine_wave_obae_pt.mxf
Description
The IA Bitstream consists of (a) 9.1OH bed channels, each containing a 400 Hz sine wave tone (-20 dBFS), and (b) one stationary object located on the ceiling (z=1), using a 400 Hz sine wave tone (-20 dBFS).
Conforms to

A.3.73. 400 hz sine wave (OBAE) (Encrypted) 🔗

Type
MXF obae
Filename
400_hz_sine_wave_obae_ct.mxf
Description
Encrypted version of A.3.72. 400 hz sine wave (OBAE)
Conforms to

A.3.74. Main Sound for 400 hz sine wave (OBAE) 🔗

Type
MXF pcm
Filename
400_hz_sine_wave_obae_ms_pt.mxf
Description
Sound Track File as specified in SMPTE ST 429-19 that contains only an FSK synchronization signal intended to synchronize playback of A.3.72. 400 hz sine wave (OBAE) .
Conforms to

A.3.75. FM StEM OBAE 🔗

Type
MXF obae
Filename
fm_StEM_obae_pt.mxf
Description
Intended to accompany the DCI StEM Mini Movie for FM testing. The IA Bitstream consists of (a) 9.1OH bed channels, each containing a 400 Hz sine wave tone (-20 dBFS), and (b) one object, using a 400 Hz sine wave tone (-20 dBFS), whose trajectory uniformly covers the unit hemisphere.
Conforms to

A.3.76. FM StEM OBAE (Encrypted) 🔗

Type
MXF obae
Filename
fm_StEM_obae_ct.mxf
Description
Encrypted version of A.3.75. FM StEM OBAE
Conforms to

A.3.77. Main Sound for FM StEM OBAE 🔗

Type
MXF pcm
Filename
fm_StEM_obae_ms_pt.mxf
Description
Sound Track File as specified in SMPTE ST 429-19, that contains only an FSK synchronization signal intended to synchronize playback of A.3.75. FM StEM OBAE .
Conforms to

A.3.78. StEM OBAE Multi-Reel A 🔗

Type
MXF obae multi
Filename
StEM_obae_multi_A_pt_<segment>.mxf
Description
A set of plaintext Immersive Audio track files for the StEM mini-movie. 128 files, each with a duration of 5 seconds.
Conforms to

A.3.79. Main Sound for StEM OBAE Multi-Reel A 🔗

Type
MXF pcm multi
Filename
StEM_obae_ms_multi_A_pt_<segment>.mxf
Description
A set of plaintext Sound Track Files, each as specified in [SMPTE-429-19] , where the FSK synchronization signal is intended to synchronize playback of Section A.3.45: StEM OBAE . 128 files, each with a duration of 5 seconds.
Conforms to

A.3.80. StEM OBAE Multi-Reel B 🔗

Type
MXF obae multi
Filename
StEM_obae_multi_B_pt_<segment>.mxf
Description
Set of Track Files whose essence and segmentation are identical to those at A.3.78. StEM OBAE Multi-Reel A .
Conforms to

A.3.81. Main Sound for StEM OBAE Multi-Reel B 🔗

Type
MXF pcm multi
Filename
StEM_obae_ms_multi_B_pt_<segment>.mxf
Description
Set of Track Files whose essence and segmentation are identical to those at A.3.79. Main Sound for StEM OBAE Multi-Reel A .
Conforms to

A.3.82. StEM OBAE Multi-Reel A (Encrypted) 🔗

Type
MXF obae multi
Filename
StEM_obae_multi_A_ct_<segment>.mxf
Description
Encrypted version of A.3.78. StEM OBAE Multi-Reel A , where the same cryptographic key is used for every 2 consecutive Track Files, resulting in 64 distinct cryptographic keys being used.
Conforms to

A.3.83. Main Sound for StEM OBAE Multi-Reel A (Encrypted) 🔗

Type
MXF pcm multi
Filename
StEM_obae_ms_multi_A_ct_<segment>.mxf
Description
Encrypted version of A.3.79. Main Sound for StEM OBAE Multi-Reel A , where the same cryptographic key is used for every 2 consecutive Track Files, resulting in 64 distinct cryptographic keys being used.
Conforms to

A.3.84. StEM OBAE Multi-Reel B (Encrypted) 🔗

Type
MXF obae multi
Filename
StEM_obae_multi_B_ct_<segment>.mxf
Description
Encrypted version of A.3.80. StEM OBAE Multi-Reel B , where the same cryptographic key is used for every 2 consecutive Track Files, resulting in 64 distinct cryptographic keys being used.
Conforms to

A.3.85. Main Sound for StEM OBAE Multi-Reel B (Encrypted) 🔗

Type
MXF pcm multi
Filename
StEM_obae_ms_multi_B_ct_<segment>.mxf
Description
Encrypted version of A.3.81. Main Sound for StEM OBAE Multi-Reel B , where the same cryptographic key is used for every 2 consecutive Track Files, resulting in 64 distinct cryptographic keys being used.
Conforms to

A.3.86. Maximum Bitrate OBAE 48 fps (Encrypted) 🔗

Type
MXF obae
Filename
maximum_bitrate_48Hz_obae_obae_ct.mxf
Description
Intended to accompany StEM 2K 48 fps . The IA Bitstream has a duration of 640s, has a frame rate of 48 Hz and each frame is the maximum size specified in [SMPTE-429-18] .
Conforms to

A.3.87. Main Sound for Maximum Bitrate OBAE 48 fps (Encrypted) 🔗

Type
MXF pcm
Filename
maximum_bitrate_48Hz_obae_pcm_ct.mxf
Description
Sound Track File as specified in SMPTE ST 429-19, that contains only an FSK synchronization signal intended to synchronize playback of A.3.86. Maximum Bitrate OBAE 48 fps (Encrypted) .
Conforms to

A.3.88. Maximum Bitrate OBAE (Encrypted) 🔗

Type
MXF obae
Filename
maximum_bitrate_24Hz_obae_obae_ct.mxf
Description
Intended to accompany StEM 2K . The IA Bitstream has a duration of 640s, has a frame rate of 24 Hz and each frame is the maximum size specified in [SMPTE-429-18] .
Conforms to

A.3.89. Main Sound for Maximum Bitrate OBAE (Encrypted) 🔗

Type
MXF pcm
Filename
maximum_bitrate_24Hz_obae_pcm_ct.mxf
Description
Sound Track File as specified in SMPTE ST 429-19, that contains only an FSK synchronization signal intended to synchronize playback of A.3.88. Maximum Bitrate OBAE (Encrypted) .
Conforms to

A.3.90. OBAE Rendering Test 🔗

Type
MXF obae
Filename
obae_render_test_j2c_pt.mxf
Description
Exercises selected OBAE bitstream capabilities.
Conforms to

A.3.91. Main Sound for OBAE Rendering Test 🔗

Type
MXF pcm
Filename
obae_render_test_ms_pt.mxf
Description
Sound Track File as specified in SMPTE ST 429-19, that contains only an FSK synchronization signal intended to synchronize playback of A.3.90. OBAE Rendering Test .
Conforms to

A.3.92. Silence w/ HI/VI 🔗

Type
MXF pcm
Filename
obae_render_test_ms_silence_pt.mxf
Description
Sound Track File that contains silence on all channels but HI/VI.
Conforms to

A.3.93. Silence, OBAE, 15 minutes (Encrypted) 🔗

Type
MXF obae
Filename
black_long_obae_ct.mxf
Description
Encrypted Immersive Audio Track File that contains an IA Bitstream with a duration of 900s long and a frame rate of 24 Hz. The IA Bitstream contains no objects and has a single 9.1OH bed that contains silence.
Conforms to

A.3.94. Main Sound for Silence, OBAE, 15 minutes (Encrypted) 🔗

Type
MXF pcm
Filename
black_long_obae_ms_ct.mxf
Description
Encrypted Sound Track File as specified in SMPTE ST 429-19, that contains only an FSK synchronization signal intended to synchronize playback of A.3.93. Silence, OBAE, 15 minutes (Encrypted) .
Conforms to

A.3.95. 24 FPS test 🔗

Type
MXF pcm
Filename
24_fps_test_pcm_pt.mxf
Description
24 FPS Sound Track File where the words "left" and "right" are spoken (from the center speaker) as the pendulum of 2K 2D 24 FPS Test reaches the extreme left and right of its trajectory, respectively.
Conforms to

A.3.96. 48 FPS test 🔗

Type
MXF pcm
Filename
48_fps_test_pcm_pt.mxf
Description
48 FPS Sound Track File where the words "left" and "right" are spoken (from the center speaker) as the pendulum of 2K 2D 48 FPS Test reaches the extreme left and right of its trajectory, respectively.
Conforms to

A.3.97. 60 FPS test 🔗

Type
MXF pcm
Filename
60_fps_test_pcm_pt.mxf
Description
60 FPS Sound Track File where the words "left" and "right" are spoken (from the center speaker) as the pendulum of 2K 2D 60 FPS Test reaches the extreme left and right of its trajectory, respectively.
Conforms to

A.3.98. 96 FPS test 🔗

Type
MXF pcm
Filename
96_fps_test_pcm_pt.mxf
Description
96 FPS Sound Track File where the words "left" and "right" are spoken (from the center speaker) as the pendulum of 2K 2D 96 FPS Test reaches the extreme left and right of its trajectory, respectively.
Conforms to

A.3.99. 120 FPS test 🔗

Type
MXF pcm
Filename
120_fps_test_pcm_pt.mxf
Description
120 FPS Sound Track File where the words "left" and "right" are spoken (from the center speaker) as the pendulum of 2K 2D 120 FPS Test reaches the extreme left and right of its trajectory, respectively.
Conforms to

A.4. D-Cinema Packages 🔗

A.4.1. Introduction 🔗

This section defines a set of D-Cinema Compositions and D-Cinema Packages. The Compositions depend upon the track files created in Section A.2 and Section A.3 . The Packages contain the Compositions for ingest.

A.4.2. DCI 2K Sync Test 🔗

Type
CPL
Filename
2K_sync_test.cpl.xml
Conforms to
Prerequisites

A.4.3. DCI 2K Sync Test (Encrypted) 🔗

Type
CPL
Filename
2K_sync_test_ct.cpl.xml
Conforms to
Prerequisites

A.4.4. DCI 2K Sync test with Subtitles 🔗

Type
CPL
Filename
sync_test_with_subs.cpl.xml
Conforms to
Prerequisites

A.4.5. DCI 2K Sync test with Subtitles (Encrypted) 🔗

Type
CPL
Filename
sync_test_with_subs_ct.cpl.xml
Conforms to
Prerequisites

A.4.6. DCI 2K Sync Test (48fps) 🔗

Type
CPL
Filename
sync_test_48fps.cpl.xml
Conforms to
Prerequisites
Meta
EditRate
48/1

A.4.7. 4K Sync Test 🔗

Type
CPL
Filename
4K_sync_test.cpl.xml
Conforms to
Prerequisites

A.4.8. DCI 5.1 Channel Identification 🔗

Type
CPL
Filename
channel_id_51_pt.cpl.xml
Conforms to
Prerequisites

A.4.9. DCI 1-16 Numbered Channel Identification 🔗

Type
CPL
Filename
channel_id_01-16.cpl.xml
Conforms to
Prerequisites

A.4.10. DCI NIST Frame with silence 🔗

Type
CPL
Filename
nist_pattern_black_audio.cpl.xml
Conforms to
Prerequisites

A.4.11. 4K DCI NIST Frame with silence 🔗

Type
CPL
Filename
4K_nist_pattern.cpl.xml
Conforms to
Prerequisites

A.4.12. DCI NIST Frame with Pink Noise 🔗

Type
CPL
Filename
nist_pattern_pink_noise.cpl.xml
Conforms to
Prerequisites

A.4.13. DCI NIST Frame with 1 kHz tone (-20 dB fs) 🔗

Type
CPL
Filename
nist_pattern_1k.cpl.xml
Conforms to
Prerequisites

A.4.14. DCI NIST Frame with Pink Noise (96 kHz) 🔗

Type
CPL
Filename
nist_pattern_pink_noise_96k.cpl.xml
Conforms to
Prerequisites

A.4.15. DCI NIST Frame with 1 kHz tone (-20 dB fs, 96kHz) 🔗

Type
CPL
Filename
nist_pattern_1k_96k.cpl.xml
Conforms to
Prerequisites

A.4.16. DCI NIST Frame no sound files 🔗

Type
CPL
Filename
nist_pattern_no_audio.cpl.xml
Conforms to
Prerequisites

A.4.17. DCI 2K Image with Frame Number Burn In 🔗

Type
CPL
Filename
frame_num_burn_in.cpl.xml
Conforms to
Prerequisites

A.4.18. DCI 2K Image with Frame Number Burn In (Encrypted) 🔗

Type
CPL
Filename
frame_num_burn_in_ct.cpl.xml
Conforms to
Prerequisites

A.4.19. DCI 2K Image with Frame Number Burn In (Flat) 🔗

Type
CPL
Filename
frame_count_flat_2_reels.cpl.xml
Conforms to
Prerequisites

A.4.20. DCI 2K Image with Frame Number Burn In (Scope) 🔗

Type
CPL
Filename
frame_count_scope_2_reels.cpl.xml
Conforms to
Prerequisites

A.4.21. DCI 2K StEM 🔗

Type
CPL
Filename
2K_StEM_pt.cpl.xml
Description
A plaintext composition consisting of the StEM 2K image and 5.1 sound track files.
Conforms to
Prerequisites

A.4.22. DCI 2K StEM (Encrypted) 🔗

Type
CPL
Filename
2K_StEM_ct.cpl.xml
Description
An encrypted composition consisting of the encrypted StEM 2K image and encrypted 5.1 sound track files.
Conforms to
Prerequisites

A.4.23. DCI 2K StEM Test Sequence 🔗

Type
CPL
Filename
2K_StEM_sequence_pt.cpl.xml
Description
A plaintext composition consisting of six (6) reels. Each reel is composed of the StEM 2K image and 5.1 sound track files.
Conforms to
Prerequisites

A.4.24. DCI 2K StEM Test Sequence (Encrypted) 🔗

Type
CPL
Filename
2K_StEM_sequence_ct.cpl.xml
Description
An encrypted composition consisting of six (6) reels. Each reel is composed of the encrypted StEM 2K image and encrypted 5.1 sound track files.
Conforms to
Prerequisites

A.4.25. DCI 2K 48fps StEM 🔗

Type
CPL
Filename
2K_StEM_48fps_pt.cpl.xml
Description
A plaintext composition consisting of the StEM 2K 48 fps image and 5.1 sound track files.
Conforms to
Prerequisites

A.4.26. 128 Reel Composition, "A" Series 🔗

Type
CPL
Filename
2K_StEM_128_a_reels_pt.cpl.xml
Description
A plaintext composition consisting of one hundred and twenty eight (128) reels. Each reel is composed of part of the plaintext StEM 2K image and plaintext 5.1 sound track files.
Conforms to
Prerequisites

A.4.27. 128 Reel Composition, "B" Series 🔗

Type
CPL
Filename
2K_StEM_128_b_reels_pt.cpl.xml
Description
A plaintext composition consisting of one hundred and twenty eight (128) reels. Each reel is composed of part of the plaintext StEM 2K image and plaintext 5.1 sound track files.
Conforms to
Prerequisites

A.4.28. 128 Reel Composition, "A" Series (Encrypted) 🔗

Type
CPL
Filename
2K_StEM_128_a_reels_ct.cpl.xml
Description
An encrypted composition consisting of one hundred and twenty eight (128) reels. Each reel is composed of part of the encrypted StEM 2K image and encrypted 5.1 sound track files.
Conforms to
Prerequisites

A.4.29. 128 Reel Composition, "B" Series (Encrypted) 🔗

Type
CPL
Filename
2K_StEM_128_b_reels_ct.cpl.xml
Description
An encrypted composition consisting of one hundred and twenty eight (128) reels. Each reel is composed of part of the encrypted StEM 2K image and encrypted 5.1 sound track files.
Conforms to
Prerequisites

A.4.30. 64 Reel Composition, 1 Second Reels (Encrypted) 🔗

Type
CPL
Filename
2K_StEM_64_1_second_reels_ct.cpl.xml
Description
An encrypted composition consisting of sixty four (64) reels, each with a duration of 1 second. Each reel is composed of part of the encrypted StEM 2K image and encrypted 5.1 sound track files.
Conforms to
Prerequisites

A.4.31. 2K FM Application Constraints (Encrypted) 🔗

Type
CPL
Filename
2K_fm_constraints_ct.cpl.xml
Description
A composition consisting of FM testing instructions and both encrypted and plaintext StEM 2K image and 16 channel WTF format sound track files.
Conforms to
Prerequisites

A.4.32. 2K FM Control Granularity - No FM (Encrypted) 🔗

Type
CPL
Filename
2K_fm_control_granularity_no_fm.cpl.xml
Description
An encrypted composition containing the encrypted StEM 2K image and encrypted 16 channel WTF format sound track files.
Conforms to
Prerequisites

A.4.33. 2K FM Control Granularity - Image Only FM (Encrypted) 🔗

Type
CPL
Filename
2K_fm_control_granularity_image_only_fm.cpl.xml
Description
An encrypted composition containing the FM encrypted StEM 2K image and encrypted 16 channel WTF format sound track files.
Conforms to
Prerequisites

A.4.34. 2K FM Control Granularity - Sound Only FM (Encrypted) 🔗

Type
CPL
Filename
2K_fm_control_granularity_sound_only_fm.cpl.xml
Description
An encrypted composition containing the encrypted StEM 2K image and encrypted 16 channel WTF format sound track files.
Conforms to
Prerequisites

A.4.35. 2K FM Control Granularity - Image and Sound FM (Encrypted) 🔗

Type
CPL
Filename
2K_fm_control_granularity_image_and_sound_fm.cpl.xml
Description
An encrypted composition containing of the encrypted StEM 2K image and encrypted 16 channel WTF format sound track files.
Conforms to
Prerequisites

A.4.36. 2K FM Payload (Encrypted) 🔗

Type
CPL
Filename
2K_fm_payload_ct.cpl.xml
Description
An encrypted composition for FM detection containing the encrypted StEM 2K image and encrypted 16 channel WTF format sound track files.
Conforms to
Prerequisites

A.4.37. Binary Audio Forensic Marking Bypass Test (Encrypted) 🔗

Type
CPL
Filename
binary_audio_fm_ct.cpl.xml
Description
An encrypted composition containing an encrypted 48 kHz sound track file with 16 channels of audio in WTF format.
Conforms to
Prerequisites

A.4.38. Selective Audio FM - All FM (Encrypted) 🔗

Type
CPL
Filename
selective_audio_fm_all-fm_ct.cpl.xml
Description
An encrypted composition containing an encrypted sound track file with 16 channels of audio.
Conforms to
Prerequisites

A.4.39. Selective Audio FM - No FM (Encrypted) 🔗

Type
CPL
Filename
selective_audio_fm_no-fm_ct.cpl.xml
Description
An encrypted composition containing an encrypted sound track file with 16 channels of audio.
Conforms to
Prerequisites

A.4.40. Selective Audio FM - Not Above Channel 6 (Encrypted) 🔗

Type
CPL
Filename
selective_audio_fm_6ch_ct.cpl.xml
Description
An encrypted composition containing an encrypted sound track file with 16 channels of audio.
Conforms to
Prerequisites

A.4.41. Selective Audio FM - Not Above Channel 8 (Encrypted) 🔗

Type
CPL
Filename
selective_audio_fm_8ch_ct.cpl.xml
Description
An encrypted composition containing an encrypted sound track file with 16 channels of audio.
Conforms to
Prerequisites

A.4.42. Selective Audio FM - Not Above Channel 10 (Encrypted) 🔗

Type
CPL
Filename
selective_audio_fm_10ch_ct.cpl.xml
Description
An encrypted composition containing an encrypted sound track file with 16 channels of audio.
Conforms to
Prerequisites

A.4.43. Selective Audio FM - Not Above Channel 17 (Encrypted) 🔗

Type
CPL
Filename
selective_audio_fm_17ch_ct.cpl.xml
Description
An encrypted composition containing an encrypted sound track file with 16 channels of audio.
Conforms to
Prerequisites

A.4.44. 2K DCI Maximum Bitrate Composition (Encrypted) 🔗

Type
CPL
Filename
2K_max_bitrate_ct.cpl.xml
Description
Encrypted composition containing picture and sound track files of the maximum allowable bitrate.
Conforms to
Prerequisites

A.4.45. 4K DCI Maximum Bitrate Composition (Encrypted) 🔗

Type
CPL
Filename
4K_max_bitrate_ct.cpl.xml
Description
Encrypted composition containing picture and sound track files of the maximum allowable bitrate.
Conforms to
Prerequisites

A.4.46. End of Engagement - Past Time Window Extension (Encrypted) 🔗

Type
CPL
Filename
holdover_long_ct.cpl.xml
Description
An encrypted composition with duration of 6 hours and 11 minutes.
Conforms to
Prerequisites

A.4.47. End of Engagement - Within Time Window Extension (Encrypted) 🔗

Type
CPL
Filename
holdover_short_ct.cpl.xml
Description
An encrypted composition with duration of 5 hours and 59 minutes and 30 seconds.
Conforms to
Prerequisites

A.4.48. Deleted Section 🔗

The section "Multi-line Subtitle Test" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.4.49. Deleted Section 🔗

The section "Multi-line PNG Subtitle Test" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.4.50. Deleted Section 🔗

The section "Subtitle Test Part 1" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.4.51. Deleted Section 🔗

The section "Subtitle Test Part 2" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.4.52. Deleted Section 🔗

The section "Subtitle Test Part 3" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.4.53. DCI Black Spacer - 5 seconds 🔗

Type
CPL
Filename
black_spacer_5s.cpl.xml
Conforms to
Prerequisites

A.4.54. White Frame Sequence 🔗

Type
CPL
Filename
white_pt.cpl.xml
Conforms to
Prerequisites

A.4.55. Intra-Frame Contrast Sequence 🔗

Type
CPL
Filename
checkerboard_pt.cpl.xml
Conforms to
Prerequisites

A.4.56. Sequential Contrast and Uniformity Sequence 🔗

Type
CPL
Filename
sequential_contrast_pt.cpl.xml
Conforms to
Prerequisites

A.4.57. DCI Gray Steps 🔗

Type
CPL
Filename
gray_step.cpl.xml
Conforms to
Prerequisites

A.4.58. DCI White Steps 🔗

Type
CPL
Filename
white_step.cpl.xml
Conforms to
Prerequisites

A.4.59. DCI 2K Moving Gradient 🔗

Type
CPL
Filename
moving-gradient-white.cpl.xml
Conforms to
Prerequisites

A.4.60. Deleted Section 🔗

The section "DCI 2K Moving Gradient" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.4.61. Color Accuracy Series 🔗

Type
CPL
Filename
color_accuracy_pt.cpl.xml
Description
Composition containing five seconds (120 frames) of a chart showing all color values for the test in Section 7.5.12: Color Accuracy . This is followed by 1 minute of each of the 12 color values as a full frame.
Conforms to
Prerequisites

A.4.62. 4K Color Accuracy Series 🔗

Type
CPL
Filename
4K_color_accuracy_pt.cpl.xml
Description
4K composition containing contents identical to Section A.4.61: Color Accuracy Series
Conforms to
Prerequisites

A.4.63. Pixel Structure Pattern N 2k 🔗

Type
CPL
Filename
pixel_structure_N_2k_pt.cpl.xml
Description
North-oriented pixel structure test pattern featuring 16 x 16 and 8 x 8 pixel patterns with binary position indicators. See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Prerequisites

A.4.64. Pixel Structure Pattern S 2k 🔗

Type
CPL
Filename
pixel_structure_S_2k_pt.cpl.xml
Description
South-oriented pixel structure test pattern featuring 16 x 16 and 8 x 8 pixel patterns with binary position indicators. See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Prerequisites

A.4.65. Pixel Structure Pattern E 2k 🔗

Type
CPL
Filename
pixel_structure_E_2k_pt.cpl.xml
Description
East-oriented pixel structure test pattern featuring 16 x 16 and 8 x 8 pixel patterns with binary position indicators. See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Prerequisites

A.4.66. Pixel Structure Pattern W 2k 🔗

Type
CPL
Filename
pixel_structure_W_2k_pt.cpl.xml
Description
West-oriented pixel structure test pattern featuring 16 x 16 and 8 x 8 pixel patterns with binary position indicators. See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Prerequisites

A.4.67. Pixel Structure Pattern N 4k 🔗

Type
CPL
Filename
pixel_structure_N_4k_pt.cpl.xml
Description
North-oriented pixel structure test pattern featuring 16 x 16 pixel patterns with binary position indicators. See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Prerequisites

A.4.68. Pixel Structure Pattern S 4k 🔗

Type
CPL
Filename
pixel_structure_S_4k_pt.cpl.xml
Description
South-oriented pixel structure test pattern featuring 16 x 16 pixel patterns with binary position indicators. See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Prerequisites

A.4.69. Pixel Structure Pattern E 4k 🔗

Type
CPL
Filename
pixel_structure_E_4k_pt.cpl.xml
Description
East-oriented pixel structure test pattern featuring 16 x 16 pixel patterns with binary position indicators. See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Prerequisites

A.4.70. Pixel Structure Pattern W 4k 🔗

Type
CPL
Filename
pixel_structure_W_4k_pt.cpl.xml
Description
West-oriented pixel structure test pattern featuring 16 x 16 pixel patterns with binary position indicators. See 7.5.3. Imaging Device Pixel Count/Structure for description.
Conforms to
Prerequisites

A.4.71. DCI Malformed Test 1: Picture with Frame-out-of-order error (Encrypted) 🔗

Type
CPL
Filename
m01_pict_frame_oo_ct.cpl.xml
Conforms to
Prerequisites

A.4.72. DCI Malformed Test 2: Sound with Frame-out-of-order error (Encrypted) 🔗

Type
CPL
Filename
m02_snd_frame_oo_ct.cpl.xml
Conforms to
Prerequisites

A.4.73. DCI Malformed Test 3: Sound Splice Tests 🔗

Type
CPL
Filename
m03_snd_splc_test.cpl.xml
Conforms to
Prerequisites

A.4.74. DCI Malformed Test 4: DCP With an incorrect audio TrackFile ID (Encrypted) 🔗

Type
CPL
Filename
m04_sndtk_wrong_file_ct.cpl.xml
Conforms to
Prerequisites

A.4.75. DCI Malformed Test 5: DCP With an incorrect image TrackFile ID (Encrypted) 🔗

Type
CPL
Filename
m05_pict_wrong_file_ct.cpl.xml
Conforms to
Prerequisites

A.4.76. DCI Malformed Test 6: CPL with incorrect track file hashes (Encrypted) 🔗

Type
CPL
Filename
m06_cpl_hash_error_ct.cpl.xml
Description
The contents of Asset Hash elements are replaced with random values.
Conforms to
Prerequisites
Meta
Signature
no

A.4.77. DCI Malformed Test 7: CPL with an Invalid Signature (Encrypted) 🔗

Type
CPL
Filename
m07_cpl_invalid_signature_ct.cpl.xml
Conforms to
Prerequisites
Malformations
The contents of dsig:DigestValue are replaced with a random value.

A.4.78. DCI Malformed Test 8: DCP with timed text and a missing font 🔗

Type
CPL
Filename
m08_dcp_timetext_missing_font_pt.cpl.xml
Conforms to
Prerequisites

A.4.79. DCI Malformed Test 9: Picture with HMAC error in MXF Track File (Encrypted) 🔗

Type
CPL
Filename
m09_pict_bad_hmac_ct.cpl.xml
Conforms to
Prerequisites

A.4.80. DCI Malformed Test 10: Sound with HMAC error in MXF Track File (Encrypted) 🔗

Type
CPL
Filename
m10_snd_bad_hmac_ct.cpl.xml
Conforms to
Prerequisites

A.4.81. DCI Malformed Test 11: Picture with Check Value error in MXF Track File (Encrypted) 🔗

Type
CPL
Filename
m11_pict_bad_chuk_ct.cpl.xml
Conforms to
Prerequisites

A.4.82. DCI Malformed Test 12: Sound with Check Value error in MXF Track File (Encrypted) 🔗

Type
CPL
Filename
m12_snd_bad_chuk_ct.cpl.xml
Conforms to
Prerequisites

A.4.83. DCI Malformed Test 13: CPL that references a non-existent track file (Encrypted) 🔗

Type
CPL
Filename
m13_cpl_missing_asset_ct.cpl.xml
Description
The MainSound asset of this composition is an reference to a non-existent track file.
Conforms to
Prerequisites
Malformations
The Id element of the MainSound shall be a random value.
Meta
Signature
no

A.4.84. DCI Malformed Test 14: CPL that does not conform to ST 429-7 (Encrypted) 🔗

Type
CPL
Filename
m14_cpl_format_error_ct.cpl.xml
Conforms to
Prerequisites
Malformations
Create valid CPL using an ad-hoc namespace name.
Meta
Signature
no

A.4.85. DCI Malformed Test 15: CPL signed by a certificate not conforming to ST 430-2 (Encrypted) 🔗

Type
CPL
Filename
m15_cpl_signer_format_error_ct.cpl.xml
Conforms to
Prerequisites
Malformations
Create valid CPL signature using a SHA-1 certificate chain.
Meta
Signature
no

A.4.86. DCI Malformed Test 16: CPL signed with No Role Certificate (Encrypted) 🔗

Type
CPL
Filename
m16_cpl_malf_signer_no_role_ct.cpl.xml
Description
A composition consisting of the encrypted StEM 2K image and encrypted 5.1 sound track files, signed with a certificate that has no role.
Conforms to
Prerequisites
Malformations
The signer certificate of the CPL has no role instead of CS.
Meta
Register
no
Signature
no

A.4.87. DCI Malformed Test 17: CPL signed with Bad Role Certificate (Encrypted) 🔗

Type
CPL
Filename
m17_cpl_malf_signer_bad_role_ct.cpl.xml
Description
An encrypted composition consisting of the encrypted StEM 2K image and encrypted 5.1 sound track files, signed with a certificate with an incorrect role.
Conforms to
Prerequisites
Malformations
The signer certificate of the CPL has the role of SM instead of CS.
Meta
Register
no
Signature
no

A.4.88. DCI Malformed Test 18: CPL signed with Extra Role Certificate (Encrypted) 🔗

Type
CPL
Filename
m18_cpl_malf_signer_extra_role_ct.cpl.xml
Description
An encrypted composition consisting of the encrypted StEM 2K image and encrypted 5.1 sound track files, signed with a certificate with an extra role.
Conforms to
Prerequisites
Malformations
The signer certificate of the CPL has the roles of CS and SM instead of only CS.
Meta
Register
no
Signature
no

A.4.89. Deleted Section 🔗

The section "DCI DCP 2K (Encrypted)" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.4.90. DCI DCP 2K Multi-Reel 128 A (Encrypted) 🔗

Type
DCP
Filename
DCI_2K_128_multi_a_tests
Description
DCP containing 128 reel StEM, 5 seconds per reel, set A
Conforms to
Prerequisites

A.4.91. DCI DCP 2K Multi-Reel 128 B (Encrypted) 🔗

Type
DCP
Filename
DCI_2K_128_multi_b_tests
Description
DCP containing 128 reel StEM, 5 seconds per reel, set B
Conforms to
Prerequisites

A.4.92. DCI DCP 2K Multi-Reel 64 (Encrypted) 🔗

Type
DCP
Filename
DCI_2K_64_multi_tests
Description
DCP containing 64 reel StEM, 1 second per reel
Conforms to
Prerequisites

A.4.93. DCI DCP 2K, Malformed (Encrypted) 🔗

Type
DCP
Filename
DCI_2K_malf
Description
DCP containing malformed test compositions
Conforms to
Prerequisites
Malformations
None
Meta
yes
ExplicitPKLContents

A.4.94. DCI DCP 4K (Encrypted) 🔗

Type
DCP
Filename
DCI_4K_tests
Description
DCP containing well-formed 4K test compositions
Conforms to
Prerequisites

A.4.95. 2K Scope Subtitle Test (Encrypted) 🔗

Type
CPL
Filename
sub_test_2K_scope_ct.cpl.xml
Description
2K Scope Subtitle Test (Encrypted)
Conforms to
Prerequisites

A.4.96. 2K Flat Subtitle Test (Encrypted) 🔗

Type
CPL
Filename
sub_test_2K_flat_ct.cpl.xml
Description
2K Flat Subtitle Test (Encrypted)
Conforms to
Prerequisites

A.4.97. 2K Full Subtitle Test (Encrypted) 🔗

Type
CPL
Filename
sub_test_2K_full_ct.cpl.xml
Description
2K Full Subtitle Test (Encrypted)
Conforms to
Prerequisites

A.4.98. 4K Scope Subtitle Test (Encrypted) 🔗

Type
CPL
Filename
sub_test_4K_scope_ct.cpl.xml
Description
4K Scope Subtitle Test (Encrypted)
Conforms to
Prerequisites

A.4.99. 4K Flat Subtitle Test (Encrypted) 🔗

Type
CPL
Filename
sub_test_4K_flat_ct.cpl.xml
Description
4K Flat Subtitle Test (Encrypted)
Conforms to
Prerequisites

A.4.100. 4K Full Subtitle Test (Encrypted) 🔗

Type
CPL
Filename
sub_test_4K_full_ct.cpl.xml
Description
4K Full Subtitle Test (Encrypted)
Conforms to
Prerequisites

A.4.101. 2K 48fps Scope Subtitle Test (Encrypted) 🔗

Type
CPL
Filename
sub_test_48fps_scope_ct.cpl.xml
Description
2K 48fps Scope Subtitle Test (Encrypted)
Conforms to
Prerequisites

A.4.102. 2K 48fps Flat Subtitle Test (Encrypted) 🔗

Type
CPL
Filename
sub_test_48fps_flat_ct.cpl.xml
Description
2K 48fps Flat Subtitle Test (Encrypted)
Conforms to
Prerequisites

A.4.103. 2K 48fps Full Subtitle Test (Encrypted) 🔗

Type
CPL
Filename
sub_test_48fps_full_ct.cpl.xml
Description
2K 48fps Full Subtitle Test (Encrypted)
Conforms to
Prerequisites

A.4.104. DCI DCP 2K Multi-Reel 128 A (Unencrypted) 🔗

Type
DCP
Filename
DCI_2K_128_multi_a_tests_pt
Description
DCP containing 128 reel StEM, 5 seconds per reel, set A, Unencrypted
Conforms to
Prerequisites
Malformations
None

A.4.105. DCI DCP 2K Multi-Reel 128 B (Unencrypted) 🔗

Type
DCP
Filename
DCI_2K_128_multi_b_tests_pt
Description
DCP containing 128 reel StEM, 5 seconds per reel, set B, Unencrypted
Conforms to
Prerequisites

A.4.106. DCI 2K Sync Test (OBAE) 🔗

Type
CPL
Filename
2K_sync_test_obae.cpl.xml
Description
A Composition that contains an Immersive Audio Track, as specified in SMPTE ST 429-18. It is intended to facilitate test procedures where timing measurements are performed.
Conforms to
Prerequisites

A.4.107. DCI 2K Sync Test (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_sync_test_obae_ct.cpl.xml
Description
Encrypted version of Section A.4.106: DCI 2K Sync Test (OBAE)
Conforms to
Prerequisites

A.4.108. DCI 2K StEM (OBAE) 🔗

Type
CPL
Filename
2K_StEM_obae_pt.cpl.xml
Description
A plaintext composition consisting of the StEM 2K image and an Immersive Audio Track, as specified in SMPTE ST 429-18.
Conforms to
Prerequisites

A.4.109. DCI 2K StEM (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_StEM_obae_ct.cpl.xml
Description
Encrypted version of Section A.4.108: DCI 2K StEM (OBAE)
Conforms to
Prerequisites

A.4.110. DCI 2K Sync Test with subtitles (OBAE) 🔗

Type
CPL
Filename
2K_sync_test_with_subs_obae.cpl.xml
Description
A Composition that contains an Immersive Audio and Subtitle Tracks. It is intended to facilitate test procedures where timing measurements are performed.
Conforms to
Prerequisites

A.4.111. DCI 2K Sync Test with subtitles (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_sync_test_with_subs_obae_ct.cpl.xml
Description
Encrypted version of DCI 2K Sync Test with subtitles (OBAE)
Conforms to
Prerequisites

A.4.112. M25 Composition with Malformed Integrity Pack: Missing MIC item (Picture) (Encrypted) 🔗

Type
CPL
Filename
m25_integrity_pict_mic_ct.cpl.xml
Description
Composition where a MIC item is missing from the Main Picture Track File
Conforms to
Prerequisites
Malformations
A MIC item is missing from the Main Picture Track File

A.4.113. M27 Composition with Malformed Integrity Pack: Missing TrackFileID item (Picture) (Encrypted) 🔗

Type
CPL
Filename
m27_integrity_pict_tfid_ct.cpl.xml
Description
Composition where a TrackFileID item is missing from the Main Picture Track File
Conforms to
Prerequisites
Malformations
A TrackFileID item is missing from the Main Picture Track File

A.4.114. M26 Composition with Malformed Integrity Pack: Missing SequenceNumber item (Picture) (Encrypted) 🔗

Type
CPL
Filename
m26_integrity_pict_snum_ct.cpl.xml
Description
Composition where a SequenceNumber item is missing from the Main Picture Track File
Conforms to
Prerequisites
Malformations
A SequenceNumber item is missing from the Main Picture Track File

A.4.115. M28 Composition with Malformed Integrity Pack: Missing MIC item (PCM) (Encrypted) 🔗

Type
CPL
Filename
m28_integrity_snd_mic_ct.cpl.xml
Description
Composition where a MIC item is missing from the Main Sound Track File
Conforms to
Prerequisites
Malformations
A MIC item is missing from the Main Sound Track File

A.4.116. M30 Composition with Malformed Integrity Pack: Missing TrackFileID item (PCM) (Encrypted) 🔗

Type
CPL
Filename
m30_integrity_snd_tfid_ct.cpl.xml
Description
Composition where a TrackFileID item is missing from the Main Sound Track File
Conforms to
Prerequisites
Malformations
A TrackFileID item is missing from the Main Sound Track File

A.4.117. M29 Composition with Malformed Integrity Pack: Missing SequenceNumber item (PCM) (Encrypted) 🔗

Type
CPL
Filename
m29_integrity_snd_snum_ct.cpl.xml
Description
Composition where a SequenceNumber item is missing from the Main Sound Track File
Conforms to
Prerequisites
Malformations
A SequenceNumber item is missing from the Main Sound Track File

A.4.118. M20 Composition with Malformed Integrity Pack: Missing MIC item (OBAE Main Sound) (Encrypted) 🔗

Type
CPL
Filename
m20_integrity_obae_ms_mic_ct.cpl.xml
Description
OBAE Composition where a MIC item is missing from the Main Sound Track File
Conforms to
Prerequisites
Malformations
A MIC item is missing from the Main Sound Track File

A.4.119. M22 Composition with Malformed Integrity Pack: Missing TrackFileID item (OBAE Main Sound) (Encrypted) 🔗

Type
CPL
Filename
m22_integrity_obae_ms_tfid_ct.cpl.xml
Description
OBAE Composition where a TrackFileID item is missing from the Main Sound Track File
Conforms to
Prerequisites
Malformations
A TrackFileID item is missing from the Main Sound Track File

A.4.120. M21 Composition with Malformed Integrity Pack: Missing SequenceNumber item (OBAE Main Sound) (Encrypted) 🔗

Type
CPL
Filename
m21_integrity_obae_ms_snum_ct.cpl.xml
Description
OBAE Composition where a SequenceNumber item is missing from the Main Sound Track File
Conforms to
Prerequisites
Malformations
A SequenceNumber item is missing from the Main Sound Track File

A.4.121. M19 Composition with Malformed Integrity Pack: Missing MIC item (OBAE) (Encrypted) 🔗

Type
CPL
Filename
m19_integrity_obae_mic_ct.cpl.xml
Description
OBAE Composition where a MIC item is missing from the OBAE Track File
Conforms to
Prerequisites
Malformations
A MIC item is missing from the OBAE Track File

A.4.122. M24 Composition with Malformed Integrity Pack: Missing TrackFileID item (OBAE) (Encrypted) 🔗

Type
CPL
Filename
m24_integrity_obae_tfid_ct.cpl.xml
Description
OBAE Composition where a TrackFileID item is missing from the OBAE Track File
Conforms to
Prerequisites
Malformations
A TrackFileID item is missing from the OBAE Track File

A.4.123. M23 Composition with Malformed Integrity Pack: Missing SequenceNumber item (OBAE) (Encrypted) 🔗

Type
CPL
Filename
m23_integrity_obae_snum_ct.cpl.xml
Description
OBAE Composition where a SequenceNumber item is missing from the OBAE Track File
Conforms to
Prerequisites
Malformations
A SequenceNumber item is missing from the OBAE Track File

A.4.124. 64 Reel Composition, 1 Second Reels (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_StEM_64_1_second_reels_obae_ct.cpl.xml
Description
An encrypted OBAE composition consisting of sixty four (64) reels, each with a duration of 1 second. Each reel is composed of part of the encrypted StEM 2K image and encrypted OBAE track files.
Conforms to
Prerequisites

A.4.125. M40 OBAE DCP with Frame-out-of-order error (Encrypted) 🔗

Type
CPL
Filename
m40_obae_frame_oo_ct.cpl.xml
Conforms to
Prerequisites

A.4.126. M41 OBAE DCP with an incorrect TrackFile ID (Encrypted) 🔗

Type
CPL
Filename
m41_obae_wrong_file_ct.cpl.xml
Conforms to
Prerequisites

A.4.127. DCI 2K Sync Test with MIC Key (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_sync_test_obae_mkey_ct.cpl.xml
Description
Same as A.4.107. DCI 2K Sync Test (OBAE) (Encrypted) but with the OBAE Track File using a KDM-borne MIC Key.
Conforms to
Prerequisites

A.4.128. M43 OBAE DCP with Check Value error in MXF Track File (Encrypted) 🔗

Type
CPL
Filename
m43_obae_bad_chuk_ct.cpl.xml
Conforms to
Prerequisites

A.4.129. End of Engagement - Past Time Window Extension (OBAE) (Encrypted) 🔗

Type
CPL
Filename
holdover_long_obae_ct.cpl.xml
Description
An encrypted OBAE composition with duration of 6 hours and 11 minutes.
Conforms to
Prerequisites

A.4.130. End of Engagement - Within Time Window Extension (OBAE) (Encrypted) 🔗

Type
CPL
Filename
holdover_short_obae_ct.cpl.xml
Description
An encrypted OBAE composition with duration of 5 hours and 59 minutes and 30 seconds.
Conforms to
Prerequisites

A.4.131. DCI 2K Sync Test with KDM-Borne MIC Keys (Encrypted) 🔗

Type
CPL
Filename
2K_sync_test_mkey_ct.cpl.xml
Description
Same as A.4.3. DCI 2K Sync Test (Encrypted) but with KDM-borne MIC Keys.
Conforms to
Prerequisites

A.4.132. M44 OBAE DCP with HMAC value error in MXF Track File (Encrypted) 🔗

Type
CPL
Filename
m44_obae_bad_hmac_ct.cpl.xml
Conforms to
Prerequisites

A.4.133. DCP for OBAE Tone Multi-Reel (Encrypted) 🔗

Type
CPL
Filename
OBAE_tone_multi_ct.cpl.xml
Conforms to
Prerequisites

A.4.134. DCP for Audio Tone Multi-Reel (Encrypted) 🔗

Type
CPL
Filename
audio_tone_multi_ct.cpl.xml
Conforms to
Prerequisites

A.4.135. DCI 2K Sync Test (48fps) (OBAE) 🔗

Type
CPL
Filename
2K_sync_test_48fps_obae.cpl.xml
Description
A 48 fps Composition that contains an Immersive Audio Track, as specified in SMPTE ST 429-18. It is intended to facilitate test procedures where timing measurements are performed.
Conforms to
Prerequisites

A.4.136. 2K FM Application Constraints (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_fm_constraints_obae_ct.cpl.xml
Description
A composition consisting of FM testing instructions and both encrypted and plaintext StEM 2K image and OABE track files.
Conforms to
Prerequisites

A.4.137. 2K FM Control Granularity - No FM (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_fm_control_granularity_no_fm_obae.cpl.xml
Description
An encrypted composition containing image and OBAE essence, for the purpose of detecting the forensic marking application.
Conforms to
Prerequisites

A.4.138. 2K FM Control Granularity - Image Only FM (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_fm_control_granularity_image_only_fm_obae.cpl.xml
Description
An encrypted composition containing image and OBAE essence, for the purpose of detecting the forensic marking application.
Conforms to
Prerequisites

A.4.139. 2K FM Control Granularity - OBAE Only FM (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_fm_control_granularity_obae_only_fm_obae.cpl.xml
Description
An encrypted composition containing image and OBAE essence, for the purpose of detecting the forensic marking application.
Conforms to
Prerequisites

A.4.140. 2K FM Control Granularity - Image and OBAE FM (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_fm_control_granularity_image_and_obae_fm_obae.cpl.xml
Description
An encrypted composition containing image and OBAE essence, for the purpose of detecting the forensic marking application.
Conforms to
Prerequisites

A.4.141. 128 Reel Composition, "A" Series (OBAE) 🔗

Type
CPL
Filename
2K_StEM_128_a_reels_obae_pt.cpl.xml
Description
A plaintext composition consisting of one hundred and twenty eight (128) reels, where no two reels reference identical main picture, main sound or OBAE track files. The main picture, main sound and OBAE tracks are based on those of Section A.4.108: DCI 2K StEM (OBAE) .
Conforms to
Prerequisites

A.4.142. 128 Reel Composition, "B" Series (OBAE) 🔗

Type
CPL
Filename
2K_StEM_128_b_reels_obae_pt.cpl.xml
Description
A plaintext composition consisting of one hundred and twenty eight (128) reels, where no two reels reference identical main picture, main sound or OBAE track files. The main picture, main sound and OBAE tracks are based on those of Section A.4.108: DCI 2K StEM (OBAE) .
Conforms to
Prerequisites

A.4.143. 128 Reel Composition, "A" Series (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_StEM_128_a_reels_obae_ct.cpl.xml
Description
Encypted version of A.4.141. 128 Reel Composition, "A" Series (OBAE) where 256 distinct cryptographic keys are used: 128 for the main picture track and 64 for each of the main sound and OBAE tracks.
Conforms to
Prerequisites

A.4.144. 128 Reel Composition, "B" Series (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_StEM_128_b_reels_obae_ct.cpl.xml
Description
Encypted version of A.4.142. 128 Reel Composition, "B" Series (OBAE) where 256 distinct cryptographic keys are used: 128 for the main picture track and 64 for each of the main sound and OBAE tracks.
Conforms to
Prerequisites

A.4.145. 2K FM Payload (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_fm_payload_obae_ct.cpl.xml
Description
An encrypted composition for FM payload retrieval containing encrypted StEM 2K image and corresponding OBAE essence, preceded and followed by slates.
Conforms to
Prerequisites

A.4.146. 2K FM Payload (plaintext OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_fm_payload_pt_obae_ct.cpl.xml
Description
A version of A.4.145. 2K FM Payload (OBAE) (Encrypted) where the OBAE essence is plaintext.
Conforms to
Prerequisites

A.4.147. Maximum Bitrate OBAE (Encrypted) 🔗

Type
CPL
Filename
maximum_bitrate_24Hz_obae_ct.cpl.xml
Description
A encrypted composition intended to exercise the maximum OBAE bitrate at a frame rate of 24 Hz.
Conforms to
Prerequisites

A.4.148. Maximum Bitrate OBAE 48 fps (Encrypted) 🔗

Type
CPL
Filename
maximum_bitrate_48Hz_obae_ct.cpl.xml
Description
A encrypted composition intended to exercise the maximum OBAE bitrate at a frame rate of 48 Hz.
Conforms to
Prerequisites

A.4.149. OBAE Rendering Expectations 🔗

Type
CPL
Filename
obae_rendering_test_pt.cpl.xml
Description
Composition intended to evaluate whether OBAE rendering expectations are met. Some reels contain neither a sync signal nor OBAE Track Files.
Conforms to
Prerequisites

A.4.150. DCI Malformed Test 6b: CPL with incorrect track file hashes (OBAE) (Encrypted) 🔗

Type
CPL
Filename
m06b_cpl_hash_error_obae_ct.cpl.xml
Description
The contents of Asset Hash elements are replaced with random values.
Conforms to
Prerequisites
Malformations
The contents of Asset Hash elements are replaced with random values.

A.4.151. DCI Malformed Test 7b: CPL with an Invalid Signature (OBAE) (Encrypted) 🔗

Type
CPL
Filename
m07b_cpl_invalid_signature_obae_ct.cpl.xml
Conforms to
Prerequisites
Malformations
The contents of dsig:DigestValue are replaced with a random value.

A.4.152. DCI Malformed Test 13b: CPL that references a non-existent track file (OBAE) (Encrypted) 🔗

Type
CPL
Filename
m13b_cpl_missing_asset_obae_ct.cpl.xml
Description
The MainSound asset of this composition is an reference to a non-existent track file.
Conforms to
Prerequisites
Malformations
The Id element of the MainSound shall be a random value.

A.4.153. DCI Malformed Test 14b: CPL that does not conform to ST 429-7 (OBAE) (Encrypted) 🔗

Type
CPL
Filename
m14b_cpl_format_error_obae_ct.cpl.xml
Conforms to
Prerequisites
Malformations
Create valid CPL using an ad-hoc namespace name.

A.4.154. DCI Malformed Test 15b: CPL signed by a certificate not conforming to ST 430-2 (OBAE) (Encrypted) 🔗

Type
CPL
Filename
m15b_cpl_signer_format_error_obae_ct.cpl.xml
Conforms to
Prerequisites
Malformations
Create valid CPL signature using a SHA-1 certificate chain.

A.4.155. DCI Malformed Test 16b: CPL signed with No Role Certificate (OBAE) (Encrypted) 🔗

Type
CPL
Filename
m16b_cpl_malf_signer_no_role_obae_ct.cpl.xml
Description
A composition signed with a certificate that has no role.
Conforms to
Prerequisites
Malformations
The signer certificate of the CPL has no role instead of CS.

A.4.156. DCI Malformed Test 17b: CPL signed with Bad Role Certificate (OBAE) (Encrypted) 🔗

Type
CPL
Filename
m17b_cpl_malf_signer_bad_role_obae_ct.cpl.xml
Description
An encrypted composition signed with a certificate with an incorrect role.
Conforms to
Prerequisites
Malformations
The signer certificate of the CPL has the role of SM instead of CS.

A.4.157. DCI Malformed Test 18b: CPL signed with Extra Role Certificate (OBAE) (Encrypted) 🔗

Type
CPL
Filename
m18b_cpl_malf_signer_extra_role_obae_ct.cpl.xml
Description
An encrypted composition signed with a certificate with an extra role.
Conforms to
Prerequisites
Malformations
The signer certificate of the CPL has the roles of CS and SM instead of only CS.

A.4.158. OBAE Rendering Expectations (Clip) 🔗

Type
CPL
Filename
obae_rendering_test_clip_pt.cpl.xml
Description
First three reels of OBAE Rendering Expectations
Conforms to
Prerequisites

A.4.159. DCI 2K Image with Frame Number Burn In (OBAE) (Encrypted) 🔗

Type
CPL
Filename
frame_num_burn_in_obae_ct.cpl.xml
Conforms to
Prerequisites

A.4.160. 2K DCI Maximum Bitrate Composition (OBAE) (Encrypted) 🔗

Type
CPL
Filename
2K_max_bitrate_obae_ct.cpl.xml
Description
Encrypted composition containing picture, sound and OBAE track files of the maximum allowable bitrate.
Conforms to
Prerequisites

A.4.161. HDR Sequential Contrast and Uniformity Sequence 🔗

Type
CPL
Filename
sequential_contrast_hdr_pt.cpl.xml
Conforms to
Prerequisites

A.4.162. HDR Color Accuracy Series 🔗

Type
CPL
Filename
sequential_color_hdr_pt.cpl.xml
Description
Composition cycling through the Color Accuracy Color Patch Code Values specified in [DCI-HDR] .
Conforms to
Prerequisites

A.4.163. 2K Full SDR Black 🔗

Type
CPL
Filename
2k_full_sdr_black_pt.cpl.xml
Description
2K full SDR black composition where the MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.164. 2K Scope SDR Black 🔗

Type
CPL
Filename
2k_scope_sdr_black_pt.cpl.xml
Description
2K scope SDR black composition where the MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.165. 2K Flat SDR Black 🔗

Type
CPL
Filename
2k_flat_sdr_black_pt.cpl.xml
Description
2K flat SDR black composition where the MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.166. 4K Full SDR Black 🔗

Type
CPL
Filename
4k_full_sdr_black_pt.cpl.xml
Description
4K full SDR black composition where the MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.167. 4K Scope SDR Black 🔗

Type
CPL
Filename
4k_scope_sdr_black_pt.cpl.xml
Description
4K scope SDR black composition where the MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.168. 4K Flat SDR Black 🔗

Type
CPL
Filename
4k_flat_sdr_black_pt.cpl.xml
Description
4K flat SDR black composition where the MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.169. 2K Full SDR Black with Marks 🔗

Type
CPL
Filename
2k_full_sdr_black_marks_pt.cpl.xml
Description
2K full SDR black composition with registration marks. The MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.170. 2K Scope SDR Black with Marks 🔗

Type
CPL
Filename
2k_scope_sdr_black_marks_pt.cpl.xml
Description
2K scope SDR black composition with registration marks. The MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.171. 2K Flat SDR Black with Marks 🔗

Type
CPL
Filename
2k_flat_sdr_black_marks_pt.cpl.xml
Description
2K flat SDR black composition with registration marks. The MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.172. 4K Full SDR Black with Marks 🔗

Type
CPL
Filename
4k_full_sdr_black_marks_pt.cpl.xml
Description
4K full SDR black composition with registration marks. The MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.173. 4K Scope SDR Black with Marks 🔗

Type
CPL
Filename
4k_scope_sdr_black_marks_pt.cpl.xml
Description
4K scope SDR black composition with registration marks. The MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.174. 4K Flat SDR Black with Marks 🔗

Type
CPL
Filename
4k_flat_sdr_black_marks_pt.cpl.xml
Description
4K flat SDR black composition with registration marks. The MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.175. 2K Full SDR Black with Active Area 🔗

Type
CPL
Filename
2k_full_sdr_black_active_pt.cpl.xml
Description
2K full SDR composition with an active area indicated by registration marks and specified by the MainPictureActiveArea item of the CPL.
Conforms to
Prerequisites

A.4.176. 2K Scope SDR Black with Active Area 🔗

Type
CPL
Filename
2k_scope_sdr_black_active_pt.cpl.xml
Description
2K scope SDR composition with an active area indicated by registration marks and specified by the MainPictureActiveArea item of the CPL.
Conforms to
Prerequisites

A.4.177. 2K Flat SDR Black with Active Area 🔗

Type
CPL
Filename
2k_flat_sdr_black_active_pt.cpl.xml
Description
2K flat SDR with an active area indicated by registration marks and specified by the MainPictureActiveArea item of the CPL.
Conforms to
Prerequisites

A.4.178. 4K Full SDR Black with Active Area 🔗

Type
CPL
Filename
4k_full_sdr_black_active_pt.cpl.xml
Description
4K full SDR with an active area indicated by registration marks and specified by the MainPictureActiveArea item of the CPL.
Conforms to
Prerequisites

A.4.179. 4K Scope SDR Black with Active Area 🔗

Type
CPL
Filename
4k_scope_sdr_black_active_pt.cpl.xml
Description
4K scope SDR with an active area indicated by registration marks and specified by the MainPictureActiveArea item of the CPL.
Conforms to
Prerequisites

A.4.180. 4K Flat SDR Black with Active Area 🔗

Type
CPL
Filename
4k_flat_sdr_black_active_pt.cpl.xml
Description
4K flat SDR with an active area indicated by registration marks and specified by the MainPictureActiveArea item of the CPL.
Conforms to
Prerequisites

A.4.181. Stereoscopic SDR Contrast Test Patterns 🔗

Type
CPL
Filename
sdr_contrast_stereo_pt.cpl.xml
Description
Sequence of full-screen white and black frames designed to evaluate the stereoscopic contrast performance of the Imaging Device.
Conforms to
Prerequisites

A.4.182. 4K Scaling Test Patterns 🔗

Type
CPL
Filename
4k_scaling_patterns_pt.cpl.xml
Description
Static presentation of thin lines for the purpose of detecting scaling artifacts.
Conforms to
Prerequisites

A.4.183. Steroscopic Color Accuracy Series 🔗

Type
CPL
Filename
color_accuracy_stereo_pt.cpl.xml
Description
Stereoscopic Composition that displays the color patches illustrated at A.2.12. Color Accuracy Series .
Conforms to
Prerequisites

A.4.184. 4K White Lines 🔗

Type
CPL
Filename
white_lines_pt.cpl.xml
Description
4K composition that presents white lines on a black background.
Conforms to
Prerequisites

A.4.185. DCI HDR Gray Steps 🔗

Type
CPL
Filename
hdr_gray_step.cpl.xml
Conforms to
Prerequisites

A.4.186. DCI HDR White Steps 🔗

Type
CPL
Filename
hdr_white_step.cpl.xml
Conforms to
Prerequisites

A.4.187. 2K Full HDR Black with Marks 🔗

Type
CPL
Filename
2k_full_hdr_black_marks_pt.cpl.xml
Description
2K full HDR black composition with registration marks. The MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.188. 2K Scope HDR Black with Marks 🔗

Type
CPL
Filename
2k_scope_hdr_black_marks_pt.cpl.xml
Description
2K scope HDR black composition with registration marks. The MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.189. 2K Flat HDR Black with Marks 🔗

Type
CPL
Filename
2k_flat_hdr_black_marks_pt.cpl.xml
Description
2K flat HDR black composition with registration marks. The MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.190. 4K Full HDR Black with Marks 🔗

Type
CPL
Filename
4k_full_hdr_black_marks_pt.cpl.xml
Description
4K full HDR black composition with registration marks. The MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.191. 4K Scope HDR Black with Marks 🔗

Type
CPL
Filename
4k_scope_hdr_black_marks_pt.cpl.xml
Description
4K scope HDR black composition with registration marks. The MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.192. 4K Flat HDR Black with Marks 🔗

Type
CPL
Filename
4k_flat_hdr_black_marks_pt.cpl.xml
Description
4K flat HDR black composition with registration marks. The MainPictureActiveArea item of the CPL is set to the dimensions of the encoded image.
Conforms to
Prerequisites

A.4.193. 2K Full HDR Black with Active Area 🔗

Type
CPL
Filename
2k_full_hdr_black_active_pt.cpl.xml
Description
2K full HDR composition with an active area indicated by registration marks and specified by the MainPictureActiveArea item of the CPL.
Conforms to
Prerequisites

A.4.194. 2K Scope HDR Black with Active Area 🔗

Type
CPL
Filename
2k_scope_hdr_black_active_pt.cpl.xml
Description
2K scope HDR composition with an active area indicated by registration marks and specified by the MainPictureActiveArea item of the CPL.
Conforms to
Prerequisites

A.4.195. 2K Flat HDR Black with Active Area 🔗

Type
CPL
Filename
2k_flat_hdr_black_active_pt.cpl.xml
Description
2K flat HDR with an active area indicated by registration marks and specified by the MainPictureActiveArea item of the CPL.
Conforms to
Prerequisites

A.4.196. 4K Full HDR Black with Active Area 🔗

Type
CPL
Filename
4k_full_hdr_black_active_pt.cpl.xml
Description
4K full HDR with an active area indicated by registration marks and specified by the MainPictureActiveArea item of the CPL.
Conforms to
Prerequisites

A.4.197. 4K Scope HDR Black with Active Area 🔗

Type
CPL
Filename
4k_scope_hdr_black_active_pt.cpl.xml
Description
4K scope HDR with an active area indicated by registration marks and specified by the MainPictureActiveArea item of the CPL.
Conforms to
Prerequisites

A.4.198. 4K Flat HDR Black with Active Area 🔗

Type
CPL
Filename
4k_flat_hdr_black_active_pt.cpl.xml
Description
4K flat HDR with an active area indicated by registration marks and specified by the MainPictureActiveArea item of the CPL.
Conforms to
Prerequisites

A.4.199. SDR Detection 🔗

Type
CPL
Filename
sdr_detection.cpl.xml
Description
SDR composition intended to verify that the system is configured to playback SDR presentations.
Conforms to
Prerequisites

A.4.200. HDR Detection 🔗

Type
CPL
Filename
hdr_detection.cpl.xml
Description
HDR composition intended to verify that the system is configured to playback HDR presentations.
Conforms to
Prerequisites

A.4.201. 2K 2D 24 FPS Test 🔗

Type
CPL
Filename
2k_2d_24_fps_pt.cpl.xml
Description
2K 2D composition at 24 fps intended to verify that an imaging device displays all images.
Conforms to
Prerequisites

A.4.202. 2K 2D 48 FPS Test 🔗

Type
CPL
Filename
2k_2d_48_fps_pt.cpl.xml
Description
2K 2D composition at 48 fps intended to verify that an imaging device displays all images.
Conforms to
Prerequisites

A.4.203. 2K 2D 60 FPS Test 🔗

Type
CPL
Filename
2k_2d_60_fps_pt.cpl.xml
Description
2K 2D composition at 60 fps intended to verify that an imaging device displays all images.
Conforms to
Prerequisites

A.4.204. 2K 2D 96 FPS Test 🔗

Type
CPL
Filename
2k_2d_96_fps_pt.cpl.xml
Description
2K 2D composition at 96 fps intended to verify that an imaging device displays all images.
Conforms to
Prerequisites

A.4.205. 2K 2D 120 FPS Test 🔗

Type
CPL
Filename
2k_2d_120_fps_pt.cpl.xml
Description
2K 2D composition at 120 fps intended to verify that an imaging device displays all images.
Conforms to
Prerequisites

A.4.206. 2K Stereoscopic 24 FPS Test 🔗

Type
CPL
Filename
2k_stereo_24_fps_pt.cpl.xml
Description
2K stereoscopic composition at 24 fps intended to verify that an imaging device displays all images.
Conforms to
Prerequisites

A.4.207. 2K Stereoscopic 48 FPS Test 🔗

Type
CPL
Filename
2k_stereo_48_fps_pt.cpl.xml
Description
2K stereoscopic composition at 48 fps intended to verify that an imaging device displays all images.
Conforms to
Prerequisites

A.4.208. 2K Stereoscopic 60 FPS Test 🔗

Type
CPL
Filename
2k_stereo_60_fps_pt.cpl.xml
Description
2K stereoscopic composition at 60 fps intended to verify that an imaging device displays all images.
Conforms to
Prerequisites

A.4.209. 4K 2D 24 FPS Test 🔗

Type
CPL
Filename
4k_2d_24_fps_pt.cpl.xml
Description
4K 2D composition at 24 fps intended to verify that an imaging device displays all images.
Conforms to
Prerequisites

A.4.210. 4K 2D 48 FPS Test 🔗

Type
CPL
Filename
4k_2d_48_fps_pt.cpl.xml
Description
4K 2D composition at 48 fps intended to verify that an imaging device displays all images.
Conforms to
Prerequisites

A.4.211. 4K 2D 60 FPS Test 🔗

Type
CPL
Filename
4k_2d_60_fps_pt.cpl.xml
Description
4K 2D composition at 60 fps intended to verify that an imaging device displays all images.
Conforms to
Prerequisites

A.4.212. SDR Dark Gray Scale 🔗

Type
CPL
Filename
sdr_dark_gray_pt.cpl.xml
Conforms to
Prerequisites

A.4.213. HDR Dark Gray Scale 🔗

Type
CPL
Filename
hdr_dark_gray_pt.cpl.xml
Conforms to
Prerequisites

A.5. Digital Certificates 🔗

Six certificate chains are defined, which separate certificates by device type and level of conformity. In the descriptions below, the IMB label refers to a certificate which contains roles for a Media Block (MB) or a certificate which signs such certificates. Similarly, PRJ refers to certificates or signers associated with an Imaging Device and KDS refers to certificates associated with a Key Distribution System (a KDM authoring entity).

A.5.1. Chain A1 IMB Certificate Files 🔗

Contents removed, not used by any procedure

A.5.2. Chain A2 IMB Certificate Files 🔗

Contents removed, not used by any procedure

A.5.3. Chain A3 IMB Certificate Files 🔗

A.5.3.1. chain-a3-root 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-root.pem
Description
Root cert, malformed leaves
Conforms to
Prerequisites
A.5.3.2. chain-a3-signer1 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-osig-type.pem
Description
Intermediate Signer, level one
Conforms to
Prerequisites
A.5.3.3. chain-a3-osig-type 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-osig-type.pem
Description
Signature algorithm of outside signature not sha256WithRSAEncryption
Conforms to
Prerequisites
Malformations
Signature algorithm of outside signature is sha1WithRSAEncryption
A.5.3.4. chain-a3-isig-type 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-isig-type.pem
Description
Signature algorithm inside signature not sha256WithRSAEncryption
Conforms to
Prerequisites
Malformations
Signature algorithm inside the signature is sha1WithRSAEncryption
A.5.3.5. chain-a3-iosig-type 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-iosig-type.pem
Description
Signature algorithm inside and outside identical, but not sha256WithRSAEncryption
Conforms to
Prerequisites
Malformations
Signature algorithm is sha1WithRSAEncryption
A.5.3.6. chain-a3-no-rsa 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-short-rsa.pem
Description
Public Key not an RSA Key
Conforms to
Prerequisites
Malformations
Public Key is a DSA key.
A.5.3.7. chain-a3-short-rsa 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-short-rsa.pem
Description
Public Key Length 1024 bit
Conforms to
Prerequisites
Malformations
Public key is 1024 bits.
A.5.3.8. chain-a3-bad-exp 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-bad-exp.pem
Description
Public Key Exponent other than the required 65537
Conforms to
Prerequisites
Malformations
Public Key Exponent is 3.
A.5.3.9. IMB-chain-a3-BER-enc 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-BER-enc.pem
Description
Encoded as BER (not DER)
Conforms to
Prerequisites
Malformations
Certificate uses BER encoding.
A.5.3.10. chain-a3-no-saf 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-no-saf.pem
Description
Missing SignatureAlgorithm field
Conforms to
Prerequisites
Malformations
SignatureAlgorithm field is not present
A.5.3.11. chain-a3-no-svf 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-no-svf.pem
Description
Missing SignatureValue field
Conforms to
Prerequisites
Malformations
Missing SignatureValue field
A.5.3.12. chain-a3-no-ver 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-no-ver.pem
Description
Missing Version field
Conforms to
Prerequisites
Malformations
Missing Version field
A.5.3.13. chain-a3-no-sn 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-no-sn.pem
Description
Missing SerialNumber field
Conforms to
Prerequisites
Malformations
Missing SerialNumber field
A.5.3.14. chain-a3-no-sig 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-no-sig.pem
Description
Missing Signature field
Conforms to
Prerequisites
Malformations
Missing Signature field
A.5.3.15. chain-a3-no-issuer 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-no-issuer.pem
Description
Missing Issuer field
Conforms to
Prerequisites
Malformations
The Issuer field is not present.
A.5.3.16. chain-a3-no-subject 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-no-subject.pem
Description
Missing Subject field
Conforms to
Prerequisites
Malformations
Missing Subject field
A.5.3.17. chain-a3-no-spki 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-no-spki.pem
Description
Missing SubjectPublicKeyInfo field
Conforms to
Prerequisites
Malformations
Missing SubjectPublicKeyInfo field
A.5.3.18. chain-a3-no-val-f 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-no-aki-f.pem
Description
Missing Validity field
Conforms to
Prerequisites
Malformations
Missing Validity field
A.5.3.19. chain-a3-no-aki-f 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-no-aki-f.pem
Description
Missing AuthorityKeyIdentifier field
Conforms to
Prerequisites
Malformations
The AuthorityKeyIdentifier is not present.
A.5.3.20. chain-a3-no-keyuse 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-no-keyuse.pem
Description
Missing KeyUsage field
Conforms to
Prerequisites
Malformations
The Key Usage field is not present.
A.5.3.21. chain-a3-no-basic 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-no-basic.pem
Description
Missing BasicConstraint field
Conforms to
Prerequisites
Malformations
The Basic Constraints field is not present.
A.5.3.22. chain-a3-path-1 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-path-1.pem
Description
Cert.Auth. true, PathLen present and positive
Conforms to
Prerequisites
A.5.3.23. chain-a3-path-2 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-path-2.pem
Description
Cert.Auth. true, PathLen present and positive
Conforms to
Prerequisites
A.5.3.24. chain-a3-path-3 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-path-3.pem
Description
Cert.Auth. true, PathLen present and negative
Conforms to
Prerequisites
Malformations
PathLen is -1.
A.5.3.25. chain-a3-path-4 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-path-4.pem
Description
Cert.Auth. false, PathLen absent
Conforms to
Prerequisites
A.5.3.26. chain-a3-path-5 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-path-6.pem
Description
Cert.Auth. false, PathLen positive
Conforms to
Prerequisites
A.5.3.27. chain-a3-path-6 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-path-6.pem
Description
Cert.Auth. false, PathLen positive
Conforms to
Prerequisites
A.5.3.28. chain-a3-path-7 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-path-7.pem
Description
Cert.Auth. false, PathLen negative
Conforms to
Prerequisites
A.5.3.29. chain-a3-org-name 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-org-name.pem
Description
OrganizationName in subject and issuer fields does not match
Conforms to
Prerequisites
Malformations
OrganizationName in subject field has first two letters transposed.
A.5.3.30. chain-a3-role-1 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-role-2.pem
Description
Cert.Auth. False, no role specified in CommonName
Conforms to
Prerequisites
Malformations
Common Name begins with a period (".")
A.5.3.31. chain-a3-role-2 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-role-2.pem
Description
Non-SMS role in CN
Conforms to
Prerequisites
Malformations
Common Name does not include SMS in the section to the left of the first period (".").
A.5.3.32. chain-a3-date-exp 🔗
Type
IMB Certificate
Filename
IMB-chain-a3-date-exp.pem
Description
Expired
Conforms to
Prerequisites
Malformations
Certificate Not After field contains a date value in the past.

A.5.4. Chain B1 Certificate Files 🔗

A.5.4.1. chain-b1-root 🔗
Type
PRJ Certificate
Filename
PRJ-chain-b1-root.pem
Description
Self-signed root certificate for PRJ devices
Conforms to
Prerequisites

A.5.5. Chain C1 Certificate Files 🔗

A.5.5.1. chain-c1-root 🔗
Type
KDS Certificate
Filename
KDS-chain-c1-root.pem
Description
Self-signed root certificate for KDS devices
Conforms to
Prerequisites

A.5.6. Chain C3 Certificate Files 🔗

A.5.6.1. chain-c3-root 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-root.pem
Description
Self-signed root certificate for KDS devices
Conforms to
Prerequisites
A.5.6.2. chain-c3-signer1 🔗
Type
IMB Certificate
Filename
KDS-chain-c3-signer1.pem
Description
Intermediate Signer, level one
Conforms to
Prerequisites
A.5.6.3. chain-c3-osig-type 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-osig-type.pem
Description
Signature algorithm of outside signature is sha1WithRSAEncryption
Conforms to
Prerequisites
A.5.6.4. chain-c3-isig-type 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-isig-type.pem
Description
Signature algorithm inside signature not sha256WithRSAEncryption
Conforms to
Prerequisites
Malformations
Signature algorithm inside the signature is sha1WithRSAEncryption
A.5.6.5. chain-c3-iosig-type 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-iosig-type.pem
Description
Signature algorithm inside and outside identical, but not sha256WithRSAEncryption
Conforms to
Prerequisites
Malformations
Signature algorithm is sha1WithRSAEncryption
A.5.6.6. chain-c3-no-rsa 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-short-rsa.pem
Description
Public Key not an RSA Key
Conforms to
Prerequisites
Malformations
Public key is DSA key
A.5.6.7. chain-c3-short-rsa 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-short-rsa.pem
Description
Public Key Length 1024 bit
Conforms to
Prerequisites
Malformations
Public key is 1024 bits.
A.5.6.8. chain-c3-bad-exp 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-bad-exp.pem
Description
Public Key Exponent other than default 65537
Conforms to
Prerequisites
Malformations
Public Key Exponent is 3.
A.5.6.9. chain-c3-BER-enc 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-BER-enc.pem
Description
Encoded as BER (not DER)
Conforms to
Prerequisites
Malformations
Certificate uses BER encoding.
A.5.6.10. chain-c3-no-saf 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-no-svf.pem
Description
Missing SignatureAlgorithm field
Conforms to
Prerequisites
Malformations
SignatureAlgorithm field is not present
A.5.6.11. chain-c3-no-svf 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-no-svf.pem
Description
Missing SignatureValue field
Conforms to
Prerequisites
Malformations
Missing SignatureValue field
A.5.6.12. chain-c3-no-ver 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-no-ver.pem
Description
Missing Version field
Conforms to
Prerequisites
Malformations
Missing Version field
A.5.6.13. chain-c3-no-sn 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-no-sn.pem
Description
Missing SerialNumber field
Conforms to
Prerequisites
Malformations
Missing SerialNumber field
A.5.6.14. chain-c3-no-sig 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-no-sig.pem
Description
Missing Signature field
Conforms to
Prerequisites
Malformations
Missing Signature field
A.5.6.15. chain-c3-no-issuer 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-no-issuer.pem
Description
Missing Issuer field
Conforms to
Prerequisites
Malformations
The Issuer field is not present.
A.5.6.16. chain-c3-no-subject 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-no-subject.pem
Description
Missing Subject field
Conforms to
Prerequisites
Malformations
Missing Subject field
A.5.6.17. chain-c3-no-spki 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-no-spki.pem
Description
Missing SubjectPublicKeyInfo field
Conforms to
Prerequisites
Malformations
Missing SubjectPublicKeyInfo field
A.5.6.18. chain-c3-no-val-f 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-no-val-f.pem
Description
Missing Validity field
Conforms to
Prerequisites
Malformations
Missing Validity field
A.5.6.19. chain-c3-no-aki-f 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-no-aki-f.pem
Description
Missing AuthorityKeyIdentifier field
Conforms to
Prerequisites
Malformations
The AuthorityKeyIdentifier is not present.
A.5.6.20. chain-c3-no-keyuse 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-no-keyuse.pem
Description
Missing KeyUsage field
Conforms to
Prerequisites
Malformations
The Key Usage field is not present.
A.5.6.21. chain-c3-no-basic 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-no-basic.pem
Description
Missing BasicConstraint field
Conforms to
Prerequisites
Malformations
The Basic Constraints field is not present.
A.5.6.22. chain-c3-path-1 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-path-1.pem
Description
Cert.Auth. true, PathLenpresent and zero
Conforms to
Prerequisites
A.5.6.23. chain-c3-path-2 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-path-2.pem
Description
Cert.Auth. true, PathLen present and positive
Conforms to
Prerequisites
A.5.6.24. chain-c3-path-3 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-path-3.pem
Description
Cert.Auth. true, PathLen present and negative
Conforms to
Prerequisites
Malformations
PathLen is -1.
A.5.6.25. chain-c3-path-4 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-path-4.pem
Description
Cert.Auth. false, PathLen absent
Conforms to
Prerequisites
A.5.6.26. chain-c3-path-5 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-path-5.pem
Description
Cert.Auth. false, PathLen zero
Conforms to
Prerequisites
A.5.6.27. chain-c3-path-6 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-path-6.pem
Description
Cert.Auth. false, PathLen positive
Conforms to
Prerequisites
A.5.6.28. chain-c3-path-7 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-path-7.pem
Description
Cert.Auth. false, PathLen negative
Conforms to
Prerequisites
A.5.6.29. chain-c3-org-name 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-org-name.pem
Description
OrganizationName in subject and issuer fields does not match
Conforms to
Prerequisites
Malformations
OrganizationName in subject field has first two letters transposed.
A.5.6.30. chain-c3-role-1 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-role-1.pem
Description
Cert.Auth. False, no role specified in CommonName
Conforms to
Prerequisites
Malformations
Common Name begins with a period (".")
A.5.6.31. chain-c3-date-exp 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-date-exp.pem
Description
Expired
Conforms to
Prerequisites
Malformations
Certificate Not After field contains a date value in the past.
A.5.6.32. chain-c3-role-2 🔗
Type
KDS Certificate
Filename
KDS-chain-c3-role-2.pem
Description
Cert.Auth. False, role error (CN contains only FMI).
Conforms to
Prerequisites

A.5.7. Public/Private Key Pairs 🔗

A.5.7.1. chain-a3-bad-exp-key 🔗
Type
RSA keypair
Filename
IMB-chain-a3-bad-exp-key.pem
Description
RSA keypair for Public Key Exponent other than the required 65537
Conforms to
Malformations
Public Key Exponent is 3.
A.5.7.2. chain-a3-leaf-key 🔗
Type
RSA keypair
Filename
IMB-chain-a3-leaf-key.pem
Description
RSA keypair for leaf
Conforms to
A.5.7.3. chain-a3-no-rsa-key 🔗
Type
DSA keypair
Filename
IMB-chain-a3-no-rsa-key.pem
Description
DSA keypair for Public Key not an RSA Key
Conforms to
Malformations
Public Key is a DSA key.
A.5.7.4. chain-a3-root-key 🔗
Type
RSA keypair
Filename
IMB-chain-a3-root-key.pem
Description
RSA keypair for root cert, malformed leaves
Conforms to
A.5.7.5. chain-a3-short-rsa-key 🔗
Type
RSA keypair
Filename
IMB-chain-a3-short-rsa-key.pem
Description
RSA keypair for Public Key Length 1024 bit
Conforms to
Malformations
Public key is 1024 bits.
A.5.7.6. chain-a3-signer1-key 🔗
Type
RSA keypair
Filename
IMB-chain-a3-signer1-key.pem
Description
RSA keypair for Intermediate Signer, level one
Conforms to
A.5.7.7. chain-c1-root-key 🔗
Type
RSA keypair
Filename
KDS-chain-c1-root-key.pem
Description
RSA keypair for self-signed root certificate for KDS devices
Conforms to
A.5.7.8. chain-c3-bad-exp-key 🔗
Type
RSA keypair
Filename
KDS-chain-c3-bad-exp-key.pem
Description
RSA keypair for Public Key Exponent other than default 65537
Conforms to
Malformations
Public Key Exponent is 3.
A.5.7.9. chain-c3-leaf-key 🔗
Type
RSA keypair
Filename
KDS-chain-c3-leaf-key.pem
Description
RSA keypair for leaf
Conforms to
A.5.7.10. chain-c3-no-rsa-key 🔗
Type
DSA keypair
Filename
KDS-chain-c3-no-rsa-key.pem
Description
DSA keypair for Public Key not an RSA Key
Conforms to
Malformations
Public Key is a DSA key.
A.5.7.11. chain-c3-root-key 🔗
Type
RSA keypair
Filename
KDS-chain-c3-root-key.pem
Description
RSA keypair for self-signed root certificate for KDS devices
Conforms to
A.5.7.12. chain-c3-short-rsa-key 🔗
Type
RSA keypair
Filename
KDS-chain-c3-short-rsa-key.pem
Description
RSA keypair for Public Key Length 1024 bit
Conforms to
Malformations
Public key is 1024 bits.
A.5.7.13. chain-c3-signer1-key 🔗
Type
RSA keypair
Filename
KDS-chain-c3-signer1-key.pem
Description
RSA keypair for Intermediate Signer, level one
Conforms to
A.5.7.14. chain-b1-root-key 🔗
Type
RSA keypair
Filename
PRJ-chain-b1-root-key.pem
Description
RSA keypair for self-signed root certificate for PRJ devices
Conforms to

A.6. Key Delivery Messages 🔗

A.6.1. Introduction 🔗

The KDM files defined in this section must be generated for the Test Subject and the time and date of the test procedure.

A.6.2. KDM for DCI 2K Sync Test (Encrypted) 🔗

Type
KDM
Filename
2K_sync_test_ct.kdm.xml
Conforms to
Prerequisites

A.6.3. KDM for DCI 2K Sync Test with Subtitles (Encrypted) 🔗

Type
KDM
Filename
sync_test_with_subs_ct.kdm.xml
Conforms to
Prerequisites

A.6.4. KDM for DCI 2K Image with Frame Number Burn In (Encrypted) 🔗

Type
KDM
Filename
frame_num_burn_in_ct.kdm.xml
Conforms to
Prerequisites

A.6.5. KDM for 2K StEM (Encrypted) 🔗

Type
KDM
Filename
2K_StEM_ct.kdm.xml
Conforms to
Prerequisites

A.6.6. KDM for 2K StEM Sequence (Encrypted) 🔗

Type
KDM
Filename
2K_StEM_sequence_ct.kdm.xml
Conforms to
Prerequisites

A.6.7. KDM for 128 Reel Composition, "A" Series (Encrypted) 🔗

Type
KDM
Filename
2K_StEM_128_a_reels_ct.kdm.xml
Description
KDM that has all content keys for the track files referenced by the CPL, and additionally has one each of key types FMIK and FMAK. The FMIK and FMAK key values shall be appropriate for the specifications of the FM system used by the Test Subject.
Conforms to
Prerequisites

A.6.8. KDM for 128 Reel Composition, "B" Series (Encrypted) 🔗

Type
KDM
Filename
2K_StEM_128_b_reels_ct.kdm.xml
Description
KDM that has all content keys for the track files referenced by the CPL, and additionally has one each of key types FMIK and FMAK. The FMIK and FMAK key values shall be appropriate for the specifications of the FM system used by the Test Subject.
Conforms to
Prerequisites

A.6.9. KDM for 64 1 second reel Composition (Encrypted) 🔗

Type
KDM
Filename
2K_StEM_64_1_second_reels_ct.kdm.xml
Conforms to
Prerequisites

A.6.10. KDM for 2K FM Application Constraints (Encrypted) 🔗

Type
KDM
Filename
2K_fm_constraints_ct.kdm.xml
Conforms to
Prerequisites

A.6.11. KDM for 2K FM Control Granularity - No FM (Encrypted) 🔗

Type
KDM
Filename
2K_fm_control_granularity_no_fm.kdm.xml
Conforms to
Prerequisites

A.6.12. KDM for 2K FM Control Granularity - Image Only FM (Encrypted) 🔗

Type
KDM
Filename
2K_fm_control_granularity_image_only_fm.kdm.xml
Conforms to
Prerequisites

A.6.13. KDM for 2K FM Control Granularity - Sound Only FM (Encrypted) 🔗

Type
KDM
Filename
2K_fm_control_granularity_sound_only_fm.kdm.xml
Conforms to
Prerequisites

A.6.14. KDM for 2K FM Control Granularity - Image and Sound FM (Encrypted) 🔗

Type
KDM
Filename
2K_fm_control_granularity_image_and_sound_fm.kdm.xml
Conforms to
Prerequisites

A.6.15. KDM for 2K FM Payload (Encrypted) 🔗

Type
KDM
Filename
2K_fm_payload_ct.kdm.xml
Conforms to
Prerequisites

A.6.16. KDM for Binary Audio Forensic Marking Test (Encrypted) 🔗

Type
KDM
Filename
binary_audio_fm_ct.kdm.xml
Description
KDM with "no FM mark" flag applied to audio.
Conforms to
Prerequisites

A.6.17. KDM for Binary Selective Audio Forensic Marking Test (Encrypted) 🔗

Type
KDM
Filename
binary_selective_audio_fm_6ch_ct.kdm.xml
Description
KDM with audio forensic marking disabled on audio channels above 6 using the "selective audio FM mark" command.
Conforms to
Prerequisites

A.6.18. KDM for Selective Audio FM - All FM (Encrypted) 🔗

Type
KDM
Filename
selective_audio_fm_all-fm_ct.kdm.xml
Description
KDM with all audio forensic marking enabled on all audio channels.
Conforms to
Prerequisites

A.6.19. KDM for Selective Audio FM - No FM (Encrypted) 🔗

Type
KDM
Filename
selective_audio_fm_no-fm_ct.kdm.xml
Description
KDM with all audio forensic marking disabled by the "no FM mark" URI.
Conforms to
Prerequisites

A.6.20. KDM for Selective Audio FM - Not Above Channel 6 (Encrypted) 🔗

Type
KDM
Filename
selective_audio_fm_6ch_ct.kdm.xml
Description
KDM with audio forensic marking disabled on audio channels above 6 using the "selective audio FM mark" command. The KDM also has the "no FM mark" URI, which should be overridden by the "selective audio FM mark" URI.
Conforms to
Prerequisites

A.6.21. KDM for Selective Audio FM - Not Above Channel 8 (Encrypted) 🔗

Type
KDM
Filename
selective_audio_fm_8ch_ct.kdm.xml
Description
KDM with audio forensic marking disabled on audio channels above 8 using the "selective audio FM mark" command.
Conforms to
Prerequisites

A.6.22. KDM for Selective Audio FM - Not Above Channel 10 (Encrypted) 🔗

Type
KDM
Filename
selective_audio_fm_10ch_ct.kdm.xml
Description
KDM with audio forensic marking disabled on audio channels above 10 using the "selective audio FM mark" command.
Conforms to
Prerequisites

A.6.23. KDM for Selective Audio FM - Not Above Channel 17 (Encrypted) 🔗

Type
KDM
Filename
selective_audio_fm_17ch_ct.kdm.xml
Description
KDM with audio forensic marking disabled on audio channels above 17 using the "selective audio FM mark" command. The KDM also has the "no FM mark" URI, which should be overridden by the "selective audio FM mark" URI.
Conforms to
Prerequisites

A.6.24. KDM with two selective audio FM mark URIs 🔗

Type
KDM
Filename
kdm-malf-2-selective-fm-cmds.kdm.xml
Description
KDM that contains more than one selective audio FM mark URIs
Conforms to
Prerequisites
Malformations
KDM contains one ForensicMarkFlag element with the value http://www.dcimovies.com/430-1/2006/KDM#mrkflg-audio-disable-above-channel-06 , and one ForensicMarkFlag element with the value http://www.dcimovies.com/430-1/2006/KDM#mrkflg-audio-disable-above-channel-08 .

A.6.25. KDM for 2K Maximum Bitrate Composition (Encrypted) 🔗

Type
KDM
Filename
2K_max_bitrate_ct.kdm.xml
Conforms to
Prerequisites

A.6.26. KDM for 4K Maximum Bitrate Composition (Encrypted) 🔗

Type
KDM
Filename
4K_max_bitrate_ct.kdm.xml
Conforms to
Prerequisites

A.6.27. KDM for Past Time Window Extension (Encrypted) 🔗

Type
KDM
Filename
holdover_long_ct-kdm-short-expire.kdm.xml
Description
KDM that has a validity period that is current, but expires in the near future
Conforms to
Prerequisites
Malformations
The value of the ContentKeysNotValidAfter element is a UTC timestamp no greater than 60 minutes in the future.

A.6.28. KDM for Within Time Window Extension (Encrypted) 🔗

Type
KDM
Filename
holdover_short_ct-kdm-short-expire.kdm.xml
Description
KDM that has a validity period that is current, but expires in the near future
Conforms to
Prerequisites
Malformations
The value of the ContentKeysNotValidAfter element is a UTC timestamp no greater than 60 minutes in the future.

A.6.29. KDM for DCI Malformed Test 1: Picture with Frame-out-of-order error (Encrypted) 🔗

Type
KDM
Filename
m01_pict_frame_oo_ct.kdm.xml
Conforms to
Prerequisites

A.6.30. KDM for DCI Malformed Test 2: Sound with Frame-out-of-order error (Encrypted) 🔗

Type
KDM
Filename
m02_snd_frame_oo_ct.kdm.xml
Conforms to
Prerequisites

A.6.31. KDM for DCI Malformed Test 4: DCP With an incorrect audio TrackFile ID (Encrypted) 🔗

Type
KDM
Filename
m04_sndtk_wrong_file_ct.kdm.xml
Conforms to
Prerequisites

A.6.32. KDM for DCI Malformed Test 5: DCP With an incorrect image TrackFile ID (Encrypted) 🔗

Type
KDM
Filename
m05_pict_wrong_file_ct.kdm.xml
Conforms to
Prerequisites

A.6.33. KDM for DCI Malformed Test 6: CPL with incorrect track file hashes (Encrypted) 🔗

Type
KDM
Filename
m06_cpl_hash_error_ct.kdm.xml
Conforms to
Prerequisites

A.6.34. KDM for DCI Malformed Test 7: CPL with an Invalid Signature (Encrypted) 🔗

Type
KDM
Filename
m07_cpl_invalid_signature_ct.kdm.xml
Conforms to
Prerequisites

A.6.35. KDM for DCI Malformed Test 9: Picture with HMAC error in MXF Track File (Encrypted) 🔗

Type
KDM
Filename
m09_pict_bad_hmac_ct.kdm.xml
Description
The KDM does not contain a KDM-borne MIC Key.
Conforms to
Prerequisites

A.6.36. KDM for DCI Malformed Test 10: Sound with HMAC error in MXF Track File (Encrypted) 🔗

Type
KDM
Filename
m10_snd_bad_hmac_ct.kdm.xml
Description
The KDM does not contain a KDM-borne MIC Key.
Conforms to
Prerequisites

A.6.37. KDM for DCI Malformed Test 11: Picture with Check Value error in MXF Track File (Encrypted) 🔗

Type
KDM
Filename
m11_pict_bad_chuk_ct.kdm.xml
Conforms to
Prerequisites

A.6.38. KDM for DCI Malformed Test 12: Sound with Check Value error in MXF Track File (Encrypted) 🔗

Type
KDM
Filename
m12_snd_bad_chuk_ct.kdm.xml
Conforms to
Prerequisites

A.6.39. KDM for DCI Malformed Test 13: CPL that references a non-existent track file (Encrypted) 🔗

Type
KDM
Filename
m13_cpl_missing_asset_ct.kdm.xml
Conforms to
Prerequisites

A.6.40. KDM for DCI Malformed Test 14: CPL that does not conform to ST 429-7 (Encrypted) 🔗

Type
KDM
Filename
m14_cpl_format_error_ct.kdm.xml
Conforms to
Prerequisites

A.6.41. KDM for DCI Malformed Test 15: CPL signed by a certificate not conforming to ST 430-2 (Encrypted) 🔗

Type
KDM
Filename
m15_cpl_signer_format_error_ct.kdm.xml
Conforms to
Prerequisites

A.6.42. KDM for DCI Malformed Test 16: CPL signed with No Role Certificate (Encrypted) 🔗

Type
KDM
Filename
m16_cpl_malf_signer_no_role_ct.kdm.xml
Conforms to
Prerequisites

A.6.43. KDM for DCI Malformed Test 17: CPL signed with Bad Role Certificate (Encrypted) 🔗

Type
KDM
Filename
m17_cpl_malf_signer_bad_role_ct.kdm.xml
Conforms to
Prerequisites

A.6.44. KDM for DCI Malformed Test 18: KDM for CPL signed with Extra Role Certificate (Encrypted) 🔗

Type
KDM
Filename
m18_cpl_malf_signer_extra_role_ct.kdm.xml
Conforms to
Prerequisites

A.6.45. KDM with invalid XML 🔗

Type
KDM
Filename
kdm-malf-any.kdm.xml
Description
KDM that contains an invalid XML file format
Conforms to
Prerequisites
Malformations
Missing </DCinemaSecurityMessage> tag

A.6.46. KDM that has expired 🔗

Type
KDM
Filename
kdm-expired.kdm.xml
Description
KDM that has a validity period that has expired
Conforms to
Prerequisites
Malformations
The value of the ContentKeysNotValidAfter element is a UTC timestamp at least 24 hours in the past.

A.6.47. KDM with future validity period within the UTC offset 🔗

Type
KDM
Filename
kdm-near-future.kdm.xml
Description
KDM that has a validity period in the future according to the full ContentKeysNotValidBefore timestamp but is valid now if the UTC offset is ignored.
Conforms to
Prerequisites
Malformations
The value of the ContentKeysNotValidBefore element is a UTC timestamp between 4 and 6 hours in the future, with a local offset of -06:00.

A.6.48. KDM that has recently expired 🔗

Type
KDM
Filename
kdm-recent-expired.kdm.xml
Description
KDM that has a validity period that has expired according to the full ContentKeysNotValidAfter timestamp but that has not expired if the local offset is ignored.
Conforms to
Prerequisites
Malformations
The value of the ContentKeysNotValidAfter element is a UTC timestamp between 4 and 6 hours in the past, with a local offset of +06:00.

A.6.49. KDM with incorrect message digest 🔗

Type
KDM
Filename
kdm-malf-sig-digest.kdm.xml
Description
KDM in which a Signature Digest has been altered
Conforms to
Prerequisites
Malformations
The plaintext form of the encrypted message digest in the signature is not the same value as a calculated message digest of the KDM.

A.6.50. KDM with future validity period 🔗

Type
KDM
Filename
kdm-future-cy2024.kdm.xml
Description
KDM that has a validity period that is in the future
Conforms to
Prerequisites
Malformations
The value of the ContentKeysNotValidBefore element is a UTC timestamp at least 24 hours in the future.

A.6.51. KDM with empty TDL 🔗

Type
KDM
Filename
kdm-no-tdl.kdm.xml
Description
KDM that has an empty Trusted Device List (TDL)
Conforms to
Prerequisites
Malformations
The DeviceList element of the KDM is empty.

A.6.52. KDM with Assume Trust and random TDL entries 🔗

Type
KDM
Filename
kdm-assume-trust-and-more.kdm.xml
Description
KDM with a TDL consisting of one entry Assume Trust entry ( i.e. "2jmj7l5rSw0yVb/ vlWAYkK/YBwk=") and one random entry.
Conforms to
Prerequisites

A.6.53. KDM with the SM alone on the TDL 🔗

Type
KDM
Filename
kdm-self-tdl.kdm.xml
Description
KDM with a single entry on its TDL corresponding the recipient's SM certificate.
Conforms to
Prerequisites

A.6.54. Deleted Section 🔗

The section "KDM with the projector and LDB on the TDL" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.55. KDM with the Imaging Device alone on the TDL 🔗

Type
KDM
Filename
kdm-projector-tdl.kdm.xml
Description
KDM with a single entry on its TDL corresponding the Imaging Device SPB connected to the MB.
Conforms to
Prerequisites

A.6.56. Deleted Section 🔗

The section "KDM with the LDB alone on the TDL" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.57. Deleted Section 🔗

The section "KDM with imminent expiration date" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.58. KDM with corrupted CipherData block 🔗

Type
KDM
Filename
kdm-malf-CipherData-block.kdm.xml
Description
KDM that contains an Invalid Structure ID field in the CipherData element
Conforms to
Prerequisites
Malformations
The first byte of the Structure ID field contained in the <enc:CipherValue> element inside the <enc:CipherData> element has been changed from "F1" to "1F"

A.6.59. KDM with incorrect signer thumbprint 🔗

Type
KDM
Filename
kdm-malf-signer-tp.kdm.xml
Description
KDM for which the Thumbprint of the Signer's Certificate does not match the Signer of the KDM
Conforms to
Prerequisites
Malformations
The thumbprint of the signer certificate as listed in the KDM is incorrect and does not match the thumbprint for the issuing certificate.

A.6.60. KDM without signer certificate 🔗

Type
KDM
Filename
kdm-malf-chain.kdm.xml
Description
KDM in which the Certificate chain does not contain the Signer's Certificate
Conforms to
Prerequisites
Malformations
The certificate that signed the KDM is not included in the KDM.

A.6.61. KDM without AuthorityKey certificate 🔗

Type
KDM
Filename
kdm-malf-chain-no-cert-authkeyid.kdm.xml
Description
KDM in which the Certificate chain does not contain the certificate specified by the AuthorityKeyIdentifier value in the Signer Certificate
Conforms to
Prerequisites
Malformations
A KDM that specifies the signer's issuer certificate as the AuthorityKeyIdentifier but which does not contain that certificate.

A.6.62. KDM with KeyInfo mismatch 🔗

Type
KDM
Filename
kdm-bad-keyinfo.kdm.xml
Description
KeyInfo field of the audio EncryptedKey element does not match the KeyInfo field of the image EncryptedKey element
Conforms to
Prerequisites
Malformations
The KeyInfo element of the audio encrypted key data contains the correct Issuer Name and an incorrect IssuerSerial of the certificate of the recipient of the KDM.

A.6.63. KDM with invalid MessageType 🔗

Type
KDM
Filename
kdm-malf-bad-MessageType.kdm.xml
Description
KDM with an Invalid MessageType element
Conforms to
Prerequisites
Malformations
MessageType element contains: "http://www.smpte-qa.org/430-1/2006/KDM#kdm-key-type"

A.6.64. KDM with expired Signer certificate 🔗

Type
KDM
Filename
kdm-malf-expired-signer.kdm.xml
Description
KDM with an expired Signer's Certificate and an ETM IssueDate later than Signer's Certificate expiry date
Conforms to
Prerequisites
Malformations
KDM signer's certificate's Validity "Not After" date is earlier than ETM IssueDate

A.6.65. KDM issued before certificate valid 🔗

Type
KDM
Filename
kdm-malf-issue-before-cert-valid.kdm.xml
Description
KDM with a valid Signer's Certificate, but ETM issue date before Signer's Certificate issue date
Conforms to
Prerequisites
Malformations
The <IssueDate> element contains a date prior to the date of the signer certificate's Validity "Not Before" date.

A.6.66. KDM validity exceeds signer validity 🔗

Type
KDM
Filename
kdm-malf-signer-cert-exp-before-kdm-expires.kdm.xml
Description
KDM with a validity period that extends beyond the validity of Signer's Certificate expiry date.
Conforms to
Prerequisites
Malformations
The KDM has a ContentKeysNotValidAfter value later than the signer certificate's "Not After" value.

A.6.67. KDM with mismatched keytype 🔗

Type
KDM
Filename
kdm-malf-mismatched-key-keytype.kdm.xml
Description
KDM with an encryption key that is valid but has an incorrect keytype
Conforms to
Prerequisites
Malformations
Key is a valid image encryption key but has the keytype "MDAK".

A.6.68. KDM with non-empty NonCriticalExtensions 🔗

Type
KDM
Filename
kdm-with-non-crit-exts.kdm.xml
Description
KDM with a non-empty NonCriticalExtensions element
Conforms to
Prerequisites

A.6.69. KDM with invalid ContentAuthenticator 🔗

Type
KDM
Filename
kdm-malf-bad-ContentAuthenticator.kdm.xml
Description
KDM with an Invalid ContentAuthenticator element
Conforms to
Prerequisites
Malformations
the content of the ContentAuthenticator element shall contain a thumbprint of a D-Cinema cert that does not match one in the signer chain of the CPL that the KDM references.

A.6.70. KDM with bad CompositionPlaylistId value 🔗

Type
KDM
Filename
kdm-malf-bad-CompositionPlaylistId.kdm.xml
Description
KDM with an incorrect value in the CompositionPlaylistId element.
Conforms to
Prerequisites
Malformations
The content of the CompositionPlaylistId element shall contain a UUID value that does not match the Id value of the associated CPL.

A.6.71. KDM with bad CipherData CompositionPlaylistId value 🔗

Type
KDM
Filename
kdm-malf-bad-CipherData-CPLId.kdm.xml
Description
KDM with an incorrect value in the CompositionPlaylistId field of the CipherData structure.
Conforms to
Prerequisites
Malformations
The content of the CompositionPlaylistId field of the CipherData structure shall contain a UUID value that does not match the Id value of the associated CPL.

A.6.72. KDM with incorrect namespace name value 🔗

Type
KDM
Filename
kdm-malf-bad-namespace.kdm.xml
Description
KDM has the wrong namespace name.
Conforms to
Prerequisites
Malformations
The namespace name corresponding to the top level XML element does not match the value given in SMPTE-430-3-2006. The bogus value http://www.smpte-qa.org/schemas/430-3/2001/ETM shall be used.

A.6.73. KDM with random TDL entry 🔗

Type
KDM
Filename
kdm-random-tdl.kdm.xml
Description
KDM has a random entry that does not match any known certificated device.
Conforms to
Prerequisites
Malformations
The DeviceInfoList contains a single entry, a randomly generated value.

A.6.74. KDM signed with incorrect signer certificate format 🔗

Type
KDM
Filename
kdm-malf-signer-format.kdm.xml
Description
KDM which has been signed with a certificate not conforming with SMPTE-430-2-2006.
Conforms to
Prerequisites
Malformations
The certificate that signed the KDM is Interop format.

A.6.75. KDM with Assume Trust TDL Entry for 2K StEM (Encrypted) 🔗

Type
KDM
Filename
kdm-assume-trust.kdm.xml
Description
KDM which has only the empty-string thumbprint "assume trust" in the TDL ( i.e. "2jmj7l5rSw0yVb/vlWAYkK/YBwk=").
Conforms to
Prerequisites

A.6.76. Deleted Section 🔗

The section "KDM for 2K StEM with Device Specific Special Auditorium TDL" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.77. Deleted Section 🔗

The section "KDM for DCI 2K StEM with a TDL that contains all of the certificate thumbprints for the devices in the special auditorium situation" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.78. Deleted Section 🔗

The section "KDM with a TDL including Responder A" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.79. Deleted Section 🔗

The section "KDM with a TDL including Responder B" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.80. Deleted Section 🔗

The section "KDM with a TDL that contains all of the certificate thumbprints for the devices in the special auditorium situation and an additional device certificate" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.81. Deleted Section 🔗

The section "KDM with a TDL that contains all but one of the certificate thumbprints for the devices in the special auditorium situation" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.82. Deleted Section 🔗

The section "KDM with a TDL that contains all of the certificate thumbprints for the devices in the special auditorium situation and the 'assume trust' thumbprint" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.83. Deleted Section 🔗

The section "KDM with a TDL that contains one more LD/LE device thumbprints than there are LD/projector thumbprints in the special auditorium situation" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.84. Deleted Section 🔗

The section "KDM with Assume Trust TDL Entry for DCI 2K Sync Test (Encrypted)" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.85. Deleted Section 🔗

The section "KDM with a TDL that contains all of the certificate thumbprints for the devices in the special auditorium situation" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

A.6.86. KDM for 2K Scope Subtitle Test (Encrypted) 🔗

Type
KDM
Filename
sub_test_2K_scope_ct.kdm.xml
Conforms to
Prerequisites

A.6.87. KDM for 2K Flat Subtitle Test (Encrypted) 🔗

Type
KDM
Filename
sub_test_2K_flat_ct.kdm.xml
Conforms to
Prerequisites

A.6.88. KDM for 2K Full Subtitle Test (Encrypted) 🔗

Type
KDM
Filename
sub_test_2K_full_ct.kdm.xml
Conforms to
Prerequisites

A.6.89. KDM for 4K Scope Subtitle Test (Encrypted) 🔗

Type
KDM
Filename
sub_test_4K_scope_ct.kdm.xml
Conforms to
Prerequisites

A.6.90. KDM for 4K Flat Subtitle Test (Encrypted) 🔗

Type
KDM
Filename
sub_test_4K_flat_ct.kdm.xml
Conforms to
Prerequisites

A.6.91. KDM for 4K Full Subtitle Test (Encrypted) 🔗

Type
KDM
Filename
sub_test_4K_full_ct.kdm.xml
Conforms to
Prerequisites

A.6.92. KDM for 2K 48fps Scope Subtitle Test (Encrypted) 🔗

Type
KDM
Filename
sub_test_48fps_scope_ct.kdm.xml
Conforms to
Prerequisites

A.6.93. KDM for 2K 48fps Flat Subtitle Test (Encrypted) 🔗

Type
KDM
Filename
sub_test_48fps_flat_ct.kdm.xml
Conforms to
Prerequisites

A.6.94. KDM for 2K 48fps Full Subtitle Test (Encrypted) 🔗

Type
KDM
Filename
sub_test_48fps_full_ct.kdm.xml
Conforms to
Prerequisites

A.6.95. KDM for DCI 2K Sync Test (OBAE) (Encrypted) 🔗

Type
KDM
Filename
2K_sync_test_obae_ct.kdm.xml
Description
KDM for Section A.4.107: DCI 2K Sync Test (OBAE) (Encrypted)
Conforms to
Prerequisites

A.6.96. KDM with bad CompositionPlaylistId value (OBAE) 🔗

Type
KDM
Filename
kdm-malf-bad-CompositionPlaylistId-obae.kdm.xml
Description
KDM with an incorrect value in the CompositionPlaylistId element.
Conforms to
Prerequisites
Malformations
The content of the CompositionPlaylistId element shall contain a UUID value that does not match the Id value of the associated CPL.

A.6.97. KDM with bad CipherData CompositionPlaylistId value (OBAE) 🔗

Type
KDM
Filename
kdm-malf-bad-CipherData-CPLId-obae.kdm.xml
Description
KDM with an incorrect value in the CompositionPlaylistId field of the CipherData structure.
Conforms to
Prerequisites
Malformations
The content of the CompositionPlaylistId field of the CipherData structure shall contain a UUID value that does not match the Id value of the associated CPL.

A.6.98. KDM for 2K StEM (Encrypted) (OBAE) 🔗

Type
KDM
Filename
2K_StEM_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.99. KDM for DCI 2K Sync test with Subtitles (Encrypted) 🔗

Type
KDM
Filename
2K_sync_test_with_subs_obae_ct.kdm.xml
Description
KDM for DCI 2K Sync Test with subtitles (OBAE) (Encrypted) .
Conforms to
Prerequisites

A.6.100. KDM for DCI 2K Sync test with Subtitles (Encrypted): missing picture essence key 🔗

Type
KDM
Filename
m0100_missing_key_pict.kdm.xml
Description
KDM for DCI 2K Sync test with Subtitles (Encrypted) .
Conforms to
Prerequisites
Malformations
The KDM is missing a single picture essence key used by the associated CPL.

A.6.101. KDM for DCI 2K Sync test with Subtitles (Encrypted): missing sound essence key 🔗

Type
KDM
Filename
m0102_missing_key_snd.kdm.xml
Description
KDM for DCI 2K Sync test with Subtitles (Encrypted) .
Conforms to
Prerequisites
Malformations
The KDM is missing a single sound essence key used by the associated CPL.

A.6.102. KDM for DCI 2K Sync test with Subtitles (Encrypted): missing subtitle essence key 🔗

Type
KDM
Filename
m0104_missing_key_sub.kdm.xml
Description
KDM for DCI 2K Sync test with Subtitles (Encrypted) .
Conforms to
Prerequisites
Malformations
The KDM is missing a single subtitle essence key used by the associated CPL.

A.6.103. KDM for DCI 2K Sync Test with subtitles (OBAE) (Encrypted): missing picture essence key 🔗

Type
KDM
Filename
m0106_missing_key_pict_obae.kdm.xml
Description
KDM for DCI 2K Sync Test with subtitles (OBAE) (Encrypted) .
Conforms to
Prerequisites
Malformations
The KDM is missing a single picture essence key used by the associated CPL.

A.6.104. KDM for DCI 2K Sync Test with subtitles (OBAE) (Encrypted): missing sound essence key 🔗

Type
KDM
Filename
m0108_missing_key_snd_obae.kdm.xml
Description
KDM for DCI 2K Sync Test with subtitles (OBAE) (Encrypted) .
Conforms to
Prerequisites
Malformations
The KDM is missing a single sound essence key used by the associated CPL.

A.6.105. KDM for DCI 2K Sync Test with subtitles (OBAE) (Encrypted): missing picture subtitle key 🔗

Type
KDM
Filename
m0110_missing_key_sub_obae.kdm.xml
Description
KDM for DCI 2K Sync Test with subtitles (OBAE) (Encrypted) .
Conforms to
Prerequisites
Malformations
The KDM is missing a single subtitle essence key used by the associated CPL.

A.6.106. KDM for DCI 2K Sync Test with subtitles (OBAE) (Encrypted): missing OBAE key 🔗

Type
KDM
Filename
m0112_missing_key_obae_obae.kdm.xml
Description
KDM for DCI 2K Sync Test with subtitles (OBAE) (Encrypted) .
Conforms to
Prerequisites
Malformations
The KDM is missing a single OBAE essence key used by the associated CPL.

A.6.107. KDM for M25 Composition with Malformed Integrity Pack: Missing MIC item (Picture) (Encrypted) 🔗

Type
KDM
Filename
m25_integrity_pict_mic_ct.kdm.xml
Description
KDM for M25 Composition with Malformed Integrity Pack: Missing MIC item (Picture) (Encrypted) .
Conforms to
Prerequisites

A.6.108. KDM for M27 Composition with Malformed Integrity Pack: Missing TrackFileID item (Picture) (Encrypted) 🔗

Type
KDM
Filename
m27_integrity_pict_tfid_ct.cpl.xml
Description
KDM for M27 Composition with Malformed Integrity Pack: Missing TrackFileID item (Picture) (Encrypted) .
Conforms to
Prerequisites

A.6.109. KDM for M26 Composition with Malformed Integrity Pack: Missing SequenceNumber item (Picture) (Encrypted) 🔗

Type
KDM
Filename
m26_integrity_pict_snum_ct.kdm.xml
Description
KDM for M26 Composition with Malformed Integrity Pack: Missing SequenceNumber item (Picture) (Encrypted) .
Conforms to
Prerequisites

A.6.110. KDM for M28 Composition with Malformed Integrity Pack: Missing MIC item (PCM) (Encrypted) 🔗

Type
KDM
Filename
m28_integrity_snd_mic_ct.kdm.xml
Description
KDM for M28 Composition with Malformed Integrity Pack: Missing MIC item (PCM) (Encrypted) .
Conforms to
Prerequisites

A.6.111. KDM for M30 Composition with Malformed Integrity Pack: Missing TrackFileID item (PCM) (Encrypted) 🔗

Type
KDM
Filename
m30_integrity_snd_tfid_ct.kdm.xml
Description
KDM for M30 Composition with Malformed Integrity Pack: Missing TrackFileID item (PCM) (Encrypted) .
Conforms to
Prerequisites

A.6.112. KDM for M29 Composition with Malformed Integrity Pack: Missing SequenceNumber item (PCM) (Encrypted) 🔗

Type
KDM
Filename
m29_integrity_snd_snum_ct.kdm.xml
Description
KDM for M29 Composition with Malformed Integrity Pack: Missing SequenceNumber item (PCM) (Encrypted) .
Conforms to
Prerequisites

A.6.113. KDM for M20 Composition with Malformed Integrity Pack: Missing MIC item (OBAE Main Sound) (Encrypted) 🔗

Type
KDM
Filename
m20_integrity_obae_ms_mic_ct.kdm.xml
Description
KDM for M20 Composition with Malformed Integrity Pack: Missing MIC item (OBAE Main Sound) (Encrypted) .
Conforms to
Prerequisites

A.6.114. KDM for M22 Composition with Malformed Integrity Pack: Missing TrackFileID item (OBAE Main Sound) (Encrypted) 🔗

Type
KDM
Filename
m22_integrity_obae_ms_tfid_ct.kdm.xml
Description
KDM for M22 Composition with Malformed Integrity Pack: Missing TrackFileID item (OBAE Main Sound) (Encrypted) .
Conforms to
Prerequisites

A.6.115. KDM for M21 Composition with Malformed Integrity Pack: Missing SequenceNumber item (OBAE Main Sound) (Encrypted) 🔗

Type
KDM
Filename
m21_integrity_obae_ms_snum_ct.kdm.xml
Description
KDM for M21 Composition with Malformed Integrity Pack: Missing SequenceNumber item (OBAE Main Sound) (Encrypted) .
Conforms to
Prerequisites

A.6.116. KDM for M19 Composition with Malformed Integrity Pack: Missing MIC item (OBAE) (Encrypted) 🔗

Type
KDM
Filename
m19_integrity_obae_mic_ct.kdm.xml
Description
KDM for M19 Composition with Malformed Integrity Pack: Missing MIC item (OBAE) (Encrypted) .
Conforms to
Prerequisites

A.6.117. KDM for M24 Composition with Malformed Integrity Pack: Missing TrackFileID item (OBAE) (Encrypted) 🔗

Type
KDM
Filename
m24_integrity_obae_tfid_ct.kdm.xml
Description
KDM for M24 Composition with Malformed Integrity Pack: Missing TrackFileID item (OBAE) (Encrypted) .
Conforms to
Prerequisites

A.6.118. KDM for M23 Composition with Malformed Integrity Pack: Missing SequenceNumber item (OBAE) (Encrypted) 🔗

Type
KDM
Filename
m23_integrity_obae_snum_ct.kdm.xml
Description
KDM for M23 Composition with Malformed Integrity Pack: Missing SequenceNumber item (OBAE) (Encrypted) .
Conforms to
Prerequisites

A.6.119. KDM with mismatched KeyType value (OBAE) 🔗

Type
KDM
Filename
kdm-malf-mismatched-key-keytype-obae.kdm.xml
Description
KDM with an cryptographic key that is valid for an OBAE track file but has an incorrect KeyType value.
Conforms to
Prerequisites
Malformations
Key is a valid OBAE cryptographic key but is associated with the KeyType value "MDAK" .

A.6.120. KDM with incorrect message digest (OBAE) 🔗

Type
KDM
Filename
kdm-malf-sig-digest-obae.kdm.xml
Description
KDM in which a Signature Digest has been altered
Conforms to
Prerequisites
Malformations
The plaintext form of the encrypted message digest in the signature is not the same value as a calculated message digest of the KDM.

A.6.121. KDM that has expired (OBAE) 🔗

Type
KDM
Filename
kdm-expired-obae.kdm.xml
Description
KDM that has a validity period that has expired
Conforms to
Prerequisites
Malformations
The value of the ContentKeysNotValidAfter element is a UTC timestamp at least 24 hours in the past.

A.6.122. KDM with future validity period (OBAE) 🔗

Type
KDM
Filename
kdm-future-obae.kdm.xml
Description
KDM that has a validity period that is in the future
Conforms to
Prerequisites
Malformations
The value of the ContentKeysNotValidBefore element is a UTC timestamp at least 24 hours in the future.

A.6.123. KDM with empty TDL (OBAE) 🔗

Type
KDM
Filename
kdm-no-tdl-obae.kdm.xml
Description
KDM that has an empty Trusted Device List (TDL)
Conforms to
Prerequisites
Malformations
The DeviceList element of the KDM is empty.

A.6.124. KDM with Assume Trust TDL Entry (OBAE) 🔗

Type
KDM
Filename
kdm-assume-trust-obae.kdm.xml
Description
KDM which has only the empty-string thumbprint "assume trust" in the TDL ( i.e. "2jmj7l5rSw0yVb/vlWAYkK/YBwk=").
Conforms to
Prerequisites

A.6.125. KDM with invalid XML (OBAE) 🔗

Type
KDM
Filename
kdm-malf-any-obae.kdm.xml
Description
KDM that contains an invalid XML file format
Conforms to
Prerequisites
Malformations
Missing </DCinemaSecurityMessage> tag

A.6.126. KDM for 64 1 second reel Composition (OBAE) (Encrypted) 🔗

Type
KDM
Filename
2K_StEM_64_1_second_reels_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.127. KDM for M40 OBAE DCP with Frame-out-of-order error (Encrypted) 🔗

Type
KDM
Filename
m40_obae_frame_oo_ct.kdm.xml
Conforms to
Prerequisites

A.6.128. KDM for M41 OBAE DCP with an incorrect TrackFile ID (Encrypted) 🔗

Type
KDM
Filename
m41_obae_wrong_file_ct.kdm.xml
Conforms to
Prerequisites

A.6.129. KDM for DCI 2K Sync Test with MIC Key (OBAE) (Encrypted) 🔗

Type
KDM mkey
Filename
2K_sync_test_obae_mkey_ct.kdm.xml
Conforms to
Prerequisites

A.6.130. KDM for M43 OBAE DCP with Check Value error in MXF Track File (Encrypted) 🔗

Type
KDM
Filename
m43_obae_bad_chuk_ct.kdm.xml
Conforms to
Prerequisites

A.6.131. KDM with invalid MIC Key for DCI 2K Sync Test with MIC Key (OBAE) (Encrypted) 🔗

Type
KDM mkey
Filename
m120_bad_mkey_2K_sync_test_obae_mkey_ct.kdm.xml
Conforms to
Prerequisites
Malformations
The MIC Key specified in the KDM does not match the MIC Key used to generate the MIC item in the OBAE Track File.

A.6.132. KDM with MIC Key for DCI 2K Sync Test (OBAE) (Encrypted) 🔗

Type
KDM mkey
Filename
m121_mkey_2K_sync_test_obae_ct.kdm.xml
Conforms to
Prerequisites
Malformations
The KDM contains a MIC Key for an OBAE Track File that does not use a KDM-borne MIC Key.

A.6.133. KDM for Past Time Window Extension (OBAE) (Encrypted) 🔗

Type
KDM
Filename
holdover_long_obae_ct-kdm-short-expire.kdm.xml holdover_long_obae_ct.kdm.xml
Description
KDM that has a validity period that is current, but expires in the near future
Conforms to
Prerequisites
Malformations
The value of the ContentKeysNotValidAfter element is a UTC timestamp no greater than 60 minutes in the future.

A.6.134. KDM for Within Time Window Extension (OBAE) (Encrypted) 🔗

Type
KDM
Filename
holdover_short_obae_ct-kdm-short-expire.kdm.xml holdover_short_obae_ct.kdm.xml
Description
KDM that has a validity period that is current, but expires in the near future
Conforms to
Prerequisites
Malformations
The value of the ContentKeysNotValidAfter element is a UTC timestamp no greater than 60 minutes in the future.

A.6.133. A.6.135. KDM with MIC Key (Sound) for DCI 2K Sync Test (Encrypted) 🔗

Type
KDM mkey
Filename
m122_mkey_sound_2K_sync_test_ct.kdm.xml
Conforms to
Prerequisites
Malformations
The KDM contains a MIC Key for a Sound Track File that does not use a KDM-borne MIC Key.

A.6.134. A.6.136. KDM with invalid MIC Key (Sound) for DCI 2K Sync Test with KDM-Borne MIC Keys (Encrypted) 🔗

Type
KDM mkey
Filename
m123_bad_mkey_sound_2K_sync_test_mkey_ct.kdm.xml
Conforms to
Prerequisites
Malformations
The MIC Key specified in the KDM does not match the MIC Key used to generate the MIC item in the Sound Track File.

A.6.135. A.6.137. KDM with MIC Key (Picture) for DCI 2K Sync Test (Encrypted) 🔗

Type
KDM mkey
Filename
m124_mkey_pict_2K_sync_test_ct.kdm.xml
Conforms to
Prerequisites
Malformations
The KDM contains a MIC Key for a Picture Track File that does not use a KDM-borne MIC Key.

A.6.136. A.6.138. KDM with invalid MIC Key (Picture) for DCI 2K Sync Test with KDM-Borne MIC Keys (Encrypted) 🔗

Type
KDM mkey
Filename
m125_bad_mkey_pict_2K_sync_test_mkey_ct.kdm.xml
Conforms to
Prerequisites
Malformations
The MIC Key specified in the KDM does not match the MIC Key used to generate the MIC item in the Picture Track File.

A.6.137. A.6.139. KDM for M44 OBAE DCP with HMAC Value error in MXF Track File (Encrypted) 🔗

Type
KDM
Filename
m44_obae_bad_hmac_ct.kdm.xml
Conforms to
Prerequisites

A.6.140. KDM for 2K FM Application Constraints (OBAE) 🔗

Type
KDM
Filename
2K_fm_constraints_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.141. KDM for 2K FM Control Granularity - No FM (OBAE) 🔗

Type
KDM
Filename
2K_fm_control_granularity_no_fm_obae.kdm.xml
Conforms to
Prerequisites

A.6.142. KDM for 2K FM Control Granularity - Image Only FM (OBAE) 🔗

Type
KDM
Filename
2K_fm_control_granularity_image_only_fm_obae.kdm.xml
Conforms to
Prerequisites

A.6.143. KDM for 2K FM Control Granularity - OBAE Only FM (OBAE) 🔗

Type
KDM
Filename
2K_fm_control_granularity_obae_only_fm_obae.kdm.xml
Conforms to
Prerequisites

A.6.144. KDM for 2K FM Control Granularity - Image and OBAE FM (OBAE) 🔗

Type
KDM
Filename
2K_fm_control_granularity_image_and_obae_fm_obae.kdm.xml
Conforms to
Prerequisites

A.6.145. KDM for 128 Reel Composition, "A" Series (OBAE) (Encrypted) 🔗

Type
KDM
Filename
2K_StEM_128_a_reels_obae_ct.kdm.xml
Description
KDM that has all content keys for the track files referenced by the CPL, and additionally has one each of key types FMIK, FMAK. The FMIK and FMAK key values shall be appropriate for the specifications of the FM system used by the Test Subject.
Conforms to
Prerequisites

A.6.146. KDM for 128 Reel Composition, "B" Series (OBAE) (Encrypted) 🔗

Type
KDM
Filename
2K_StEM_128_b_reels_obae_ct.kdm.xml
Description
KDM that has all content keys for the track files referenced by the CPL, and additionally has one each of key types FMIK and FMAK. The FMIK and FMAK key values shall be appropriate for the specifications of the FM system used by the Test Subject.
Conforms to
Prerequisites

A.6.147. KDM for 2K FM Payload (OBAE) (Encrypted) 🔗

Type
KDM
Filename
2K_fm_payload_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.148. KDM for Maximum Bitrate OBAE (Encrypted) 🔗

Type
KDM
Filename
maximum_bitrate_24Hz_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.149. KDM for Maximum Bitrate OBAE 48 fps (Encrypted) 🔗

Type
KDM
Filename
maximum_bitrate_48Hz_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.150. KDM for 2K FM Payload (plaintext OBAE) (Encrypted) 🔗

Type
KDM
Filename
2K_fm_payload_pt_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.151. KDM for 2K FM Payload (OBAE) with FM Bypass (Encrypted) 🔗

Type
KDM
Filename
2K_fm_bypass_obae_ct.kdm.xml
Description
KDM with "no FM mark" flag applied to OBAE essence.
Conforms to
Prerequisites

A.6.152. KDM with non-empty NonCriticalExtensions (OBAE) 🔗

Type
KDM
Filename
kdm-with-non-crit-exts-obae.kdm.xml
Description
KDM with a non-empty NonCriticalExtensions element
Conforms to
Prerequisites

A.6.153. KDM with expired Signer certificate (OBAE) 🔗

Type
KDM
Filename
kdm-malf-expired-signer-obae.kdm.xml
Description
KDM with an expired Signer's Certificate and an ETM IssueDate later than Signer's Certificate expiry date
Conforms to
Prerequisites
Malformations
KDM signer's certificate's Validity "Not After" date is earlier than ETM IssueDate

A.6.154. KDM issued before certificate valid (OBAE) 🔗

Type
KDM
Filename
kdm-malf-issue-before-cert-valid-obae.kdm.xml
Description
KDM with a valid Signer's Certificate, but ETM issue date before Signer's Certificate issue date
Conforms to
Prerequisites
Malformations
The <IssueDate> element contains a date prior to the date of the signer certificate's Validity "Not Before" date.

A.6.155. KDM validity exceeds signer validity (OBAE) 🔗

Type
KDM
Filename
kdm-malf-signer-cert-exp-before-kdm-expires-obae.kdm.xml
Description
KDM with a validity period that extends beyond the validity of Signer's Certificate expiry date.
Conforms to
Prerequisites
Malformations
The KDM has a ContentKeysNotValidAfter value later than the signer certificate's "Not After" value.

A.6.156. KDM with corrupted CipherData block (OBAE) 🔗

Type
KDM
Filename
kdm-malf-CipherData-block-obae.kdm.xml
Description
KDM that contains an Invalid Structure ID field in the CipherData element
Conforms to
Prerequisites
Malformations
The first byte of the Structure ID field contained in the <enc:CipherValue> element inside the <enc:CipherData> element has been changed from "F1" to "1F"

A.6.157. KDM with incorrect signer thumbprint (OBAE) 🔗

Type
KDM
Filename
kdm-malf-signer-tp-obae.kdm.xml
Description
KDM for which the Thumbprint of the Signer's Certificate does not match the Signer of the KDM
Conforms to
Prerequisites
Malformations
The thumbprint of the signer certificate as listed in the KDM is incorrect and does not match the thumbprint for the issuing certificate.

A.6.158. KDM with KeyInfo mismatch (OBAE) 🔗

Type
KDM
Filename
kdm-bad-keyinfo-obae.kdm.xml
Description
KeyInfo field of the audio EncryptedKey element does not match the KeyInfo field of the image EncryptedKey element.
Conforms to
Prerequisites
Malformations
The KeyInfo element of the audio encrypted key data contains the correct Issuer Name and an incorrect IssuerSerial of the certificate of the recipient of the KDM.

A.6.159. KDM with invalid MessageType (OBAE) 🔗

Type
KDM
Filename
kdm-malf-bad-MessageType-obae.kdm.xml
Description
KDM with an Invalid MessageType element
Conforms to
Prerequisites
Malformations
MessageType element contains: "http://www.smpte-qa.org/430-1/2006/KDM#kdm-key-type"

A.6.160. KDM with incorrect namespace name value (OBAE) 🔗

Type
KDM
Filename
kdm-malf-bad-namespace-obae.kdm.xml
Description
KDM has the wrong namespace name.
Conforms to
Prerequisites
Malformations
The namespace name corresponding to the top level XML element does not match the value given in SMPTE-430-3-2006. The bogus value http://www.smpte-qa.org/schemas/430-3/2001/ETMshall be used.

A.6.161. KDM without signer certificate (OBAE) 🔗

Type
KDM
Filename
kdm-malf-chain-obae.kdm.xml
Description
KDM in which the Certificate chain does not contain the Signer's Certificate
Conforms to
Prerequisites
Malformations
The certificate that signed the KDM is not included in the KDM.

A.6.162. KDM signed with incorrect signer certificate format (OBAE) 🔗

Type
KDM
Filename
kdm-malf-signer-format-obae.kdm.xml
Description
KDM which has been signed with a certificate not conforming with SMPTE-430-2-2006.
Conforms to
Prerequisites
Malformations
The certificate that signed the KDM is Interop format.

A.6.163. KDM for DCI Malformed Test 6b: CPL with incorrect track file hashes (OBAE) (Encrypted) 🔗

Type
KDM
Filename
m06b_cpl_hash_error_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.164. KDM for DCI Malformed Test 7b: CPL with an Invalid Signature (OBAE) (Encrypted) 🔗

Type
KDM
Filename
m07b_cpl_invalid_signature_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.165. KDM for DCI Malformed Test 13b: CPL that references a non-existent track file (OBAE) (Encrypted) 🔗

Type
KDM
Filename
m13b_cpl_missing_asset_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.166. KDM for DCI Malformed Test 14b: CPL that does not conform to ST 429-7 (OBAE) (Encrypted) 🔗

Type
KDM
Filename
m14b_cpl_format_error_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.167. KDM for DCI Malformed Test 15b: CPL signed by a certificate not conforming to ST 430-2 (OBAE) (Encrypted) 🔗

Type
KDM
Filename
m15b_cpl_signer_format_error_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.168. KDM with invalid ContentAuthenticator (OBAE) 🔗

Type
KDM
Filename
kdm-malf-bad-ContentAuthenticator-obae.kdm.xml
Description
KDM with an Invalid ContentAuthenticator element
Conforms to
Prerequisites
Malformations
the content of the ContentAuthenticator element shall contain a thumbprint of a D-Cinema cert that does not match one in the signer chain of the CPL that the KDM references.

A.6.169. KDM for DCI Malformed Test 16b: CPL signed with No Role Certificate (OBAE) (Encrypted) 🔗

Type
KDM
Filename
m16b_cpl_malf_signer_no_role_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.170. KDM for DCI Malformed Test 17b: CPL signed with Bad Role Certificate (OBAE) (Encrypted) 🔗

Type
KDM
Filename
m17b_cpl_malf_signer_bad_role_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.171. KDM for DCI Malformed Test 18b: KDM for CPL signed with Extra Role Certificate (OBAE) (Encrypted) 🔗

Type
KDM
Filename
m18b_cpl_malf_signer_extra_role_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.172. KDM that has recently expired (OBAE) 🔗

Type
KDM
Filename
kdm-recent-expired_obae.kdm.xml
Description
KDM that has a validity period that has expired according to the full ContentKeysNotValidAfter timestamp but that has not expired if the local offset is ignored.
Conforms to
Prerequisites
Malformations
The value of the ContentKeysNotValidAfter element is a UTC timestamp between 4 and 6 hours in the past, with a local offset of +06:00.

A.6.173. KDM for DCI 2K Sync Test with subtitles (OBAE) (Encrypted) 🔗

Type
KDM
Filename
2K_sync_test_with_subs_obae_ct.kdm.xml
Description
KDM for DCI 2K Sync Test with subtitles (OBAE) (Encrypted) .
Conforms to
Prerequisites

A.6.174. KDM for DCI 2K Image with Frame Number Burn In (OBAE) (Encrypted) 🔗

Type
KDM
Filename
frame_num_burn_in_obae_ct.kdm.xml
Description
KDM for DCI 2K Image with Frame Number Burn In (OBAE) (Encrypted) .
Conforms to
Prerequisites

A.6.175. KDM for 2K DCI Maximum Bitrate Composition (OBAE) (Encrypted) 🔗

Type
KDM
Filename
2K_max_bitrate_obae_ct.kdm.xml
Conforms to
Prerequisites

A.6.176. KDM for DCI 2K Sync Test with KDM-Borne MIC Keys (Encrypted) 🔗

Type
KDM mkey
Filename
2K_sync_test_mkey_ct.kdm.xml
Conforms to
Prerequisites

A.6.177. KDM for Audio Tone Multi-Reel (Encrypted) 🔗

Type
KDM mkey
Filename
audio_tone_multi_ct.kdm.xml
Conforms to
Prerequisites

Appendix B. Equipment List 🔗

B.1. Hardware 🔗

AES3 Audio Analyzer
Digital audio signal analyzer with AES-3 inputs.
Sound System
5.1 or 7.1 sound system with calibrated level control.
Computer with POSIX OS
Computer with POSIX-like Operating System (OS), such as Linux or Mac OS X. The system must support TCP/IP via 1000 Mb/s ethernet and be backward-compatible to support 100 Mb/ s Ethernet.
Digital Clock
Digital quartz time-of-day clock displaying time accurate to the second
Direct View Display
An imaging device intended for digital cinema applications and Light emission display comprised of a combination of flat panel light-emitting Display Cabinets individual display cabinets conjoined so as to form a single large imaging device. display.
Oscilloscope
Digital storage oscilloscope, 200 MHz or better, with two or more inputs plus external trigger.
Accurate Real-Time Clock
A real-time clock that uses an external reference to maintain precise time (within 1 ms). The external reference should be WWV, GPS or NTP traceable to a trusted hardware clock.
FM Decoder
Forensic mark decoder for image, sound or OBAE essence. The exact type of decoder is dependent upon the type of watermark to be decoded. This equipment is expected to collect the full payload of the forensic marking system.
FM Detector
Forensic mark detector for image or sound essence. The exact type of detector is dependent upon the type of watermark to be detected. This equipment is expected to simply detect the presence of the forensic mark.
Ethernet Switch
A 1000Base-T Ethernet switch capable of sustained full-rate throughput on at least two portpairs. The device must also be able to configure one or more ports as "monitor" ports (selected traffic on the switch can be copied to the monitor port to facilitate diagnostic capture).
Photodiode
Photodiode, of the type most sensitive in the human visible electromagnetic spectrum (about 390 nm to 780 nm), fitted with suitable length of shielded cable, terminated in a BNC connector.
Spectroradiometer
Spectroradiometer as described in [SMPTE-431-1] .
Stopwatch
Digital stopwatch with .01 second resolution.
Still Camera
Digital still image camera.
48 fps Camera
Camera and recorder/reproducer system capable of 48fps (or better) capture rate.
SPB-2 Access Tools
Tools, supplied by the manufacturer of an SPB-2 device, required to gain authorized access to the protected area of the SPB-2.
Dual-link HD monitor.
Bridge Tap Connector
Connector with a bridge tap takeoff point, e.g. a "BNC Tee".
GPIO Test Fixture
A test fixture comprising L.E.D. indicators, switches and a power supply, per the schematic in Appendix E .
DCI Projector
DCI-compliant standalone projector.
DCI Server
DCI-compliant server (includes Image/Sound Media Block)
LDB Monitor
LDB diagnostic utility
Digital Audio Recorder
Audio recorder capable of bit-accurate capture of digital audio channels, e.g, AES/EBU channels.
OBAE Sound System
Calibrated OBAE reproduction environment and system.

B.2. Software 🔗

Audio Editor
A digital audio workstation (DAW), such as Pro Tools or Audacity.
ftlint
The ftlint command line utility from the FreeType library.
It is available from http://www.freetype.org/.
Network Analyzer
Network analysis tool such as Wireshark or tcpdump.
It is available from http://www.wireshark.org/.
Text Editor
Any text editor that can display and write plain text, such as emacs or vi, etc.
Sound Editor
Any sound editing software that provides sample-accurate manipulations of audio waveforms.
OpenJPEG
JPEG 2000 encoder/decoder software such as OpenJPEG.
It is available from http://www.openjpeg.org/.
j2c-scan
JPEG 2000 scanner based on the OpenJPEG library. The source code for this program is available in Section C.8 .
identify
identify is part of the ImageMagick library and utility suite.
It is available from http://www.imagemagick.org/.
klvwalk
The klvwalk utility from the free asdcplib software package.
It is available from http://www.cinecert.com/asdcplib/
asdcp-test
The asdcp-test utility from the free asdcplib software package.
It is available from http://www.cinecert.com/asdcplib/.
openssl
General purpose command line utility from the OpenSSL software package.
It is available from http://www.openssl.org/.
schema-check
Validating XML Parser (note: may use parser from Xerces package). The source code for thisprogram is available in Section C.3 .
It is available from http://xml.apache.org/security/.
checksig
XML Signature validator, distributed with the XML Security library.
It is available from http://xml.apache.org/security/.
dsig_cert.py
XML Signature certificate manipulator. The source code for this program is available in Section C.8 .
dsig_extract.py
XML Signature certificate extractor. The source code for this program is available in Section C.9 .
uuid_check.py
UUID validator. The source code for this program is available in Section C.7 .
dc-thumbprint
Certificate thumbprint calculator. The source code for this program is available in Section C.2 .
kdm-decrypt
KDM decryption tool. The source code for this program is available in Section C.4 .

Appendix C. Source Code 🔗

C.1. Overview 🔗

Wherever possible, the computer programs used in the test procedures in this document are freely available. Where appropriate, the listings in Appendix B provide a URL where the software can be obtained.

In some cases, it was necessary to develop programs because free alternatives were not available. Those programs are presented here in source code form along with instructions for building and executing the programs.

The programs are expressed in the C, C++ and Python programming languages. Build instructions and prerequisites for the C and C++ programs are given in the comments at the beginning of each source module. Machine readable copies of the programs are available in the source-code directory in the Reference Materials distribution (see Appendix A ).

C.2. dc-thumbprint 🔗

This program reads a PEM formatted X509 certificate and calculates a SHA-1 message digest over the signed portion of the certificate as required by [SMPTE-430-2] . The value is encoded as a Base64 string and returned on stdout . The following example illustrates this usage: 

$ dc-thumbprint my-cert.pem
aZMVnZ/TzEvLUCmQFcc8U0je9uo=
Example C.1 . dc-thumbprint execution 🔗

C.2.1. dc-thumbprint Source Code Listing 🔗 

/*
 * dc-thumbprint.c -- calculate certificate thumbprint of PEM-encoded
 *                    X.509 document per SMPTE 430-2
 *
 * $Id$
 *
 * This program requires OpenSSL. To build:
 *  $ cc -o dc-thumbprint dc-thumbprint.c -lcrypto
 */
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <openssl/crypto.h>
#include <openssl/err.h>
#include <openssl/evp.h>
#include <openssl/pem.h>
#include <openssl/x509.h>
int
main(int argc, char* argv[])
{
    /* pointer to SHA-1 hash details */
    const EVP_MD *md = EVP_sha1();
    /* PEM source file pointer */
    FILE *fp = NULL;
    /* pointer to an X509 structure */
    X509 *x = NULL;
    /* pointer to DER-encoded TBSCertificate */
    unsigned char *p_tbs = NULL;
    /* length of DER-encoded TBSCertificate (p_tbs) */
    int tbs_len = 0;
    /* buffer for the message digest */
    unsigned char md_value[EVP_MAX_MD_SIZE];
    /* return value from digest calculation */
    int digest_rc = 0;
    /* buffer for base64 encoding of the message digest */
    char md_base64[EVP_MAX_MD_SIZE * 4 / 3 + 2];
    if (argc != 2)
      {
        fprintf(stderr, "Usage: dc-thumbprint cert-file.pem\n");
        return 1;
      }
    fp = fopen(argv[1], "r");
    if (fp == NULL)
      {
        fprintf(stderr, "ERROR: Cannot open %s: %s\n", argv[1], strerror(errno));
        return 2;
      }
    x = PEM_read_X509(fp, NULL, NULL, NULL);
    (void) fclose(fp);
    if (x == NULL)
      {
        ERR_print_errors_fp(stderr);
        return 3;
      }
    /* get the tbsCertificate as a DER string */
    tbs_len = i2d_re_X509_tbs(x, &p_tbs);
    X509_free(x);
    if (tbs_len <= 0)
      {
        ERR_print_errors_fp(stderr);
        return 4;
      }
    /* perform the message digest */
    digest_rc = EVP_Digest(p_tbs, tbs_len, md_value, NULL, md, NULL);
    OPENSSL_free(p_tbs);
    if (digest_rc == 0)
      {
        ERR_print_errors_fp(stderr);
        return 5;
      }
    /* perform the base64 encoding */
    (void) EVP_EncodeBlock((unsigned char *)md_base64, md_value,
                           EVP_MD_meth_get_result_size(md));
    printf("%s\n", md_base64);
    return 0;
}
/*
 * end dc-thumbprint.c
 */

C.3. schema-check 🔗

This program parses and validates XML instance documents. When an XML document is specified alone, the file is checked for well-formedness but is not validated. When an XML document is specified with one or more schema files, schema-check validates that file against the schemas. Only one file to be tested may be specified at a time. Note that schema files must be listed in order of dependency (most dependent last). The following example illustrates using the program to check well-formedness: 

$
schema-check
perfect-movie.cpl.xml
Example C.2 . Using schema-check to check well-formedness 🔗

The next example shows how to use the program to check for valid content: 

$
schema-check
perfect-movie.cpl.xml
SMPTE-428-7.xsd
Example C.3 . Using schema-check to check validity 🔗

C.3.1. schema-check Source Code Listing 🔗 

//
// schema-check.cpp -- test XML document against schema
//
// $Id$
//
// This program requires the Xerces-c XML library. To build:
//  $ c++ -o schema-check schema-check.cpp -lxerces-c
//
#include <iostream>
#include <list>
#include <string>
#include <cstdio>
#include <xercesc/util/OutOfMemoryException.hpp>
#include <xercesc/dom/DOM.hpp>
#include <xercesc/parsers/XercesDOMParser.hpp>
#include <xercesc/framework/XMLGrammarDescription.hpp>
#include <xercesc/sax/ErrorHandler.hpp>
#include <xercesc/sax/SAXParseException.hpp>
using std::cerr;
using std::endl;
XERCES_CPP_NAMESPACE_USE
// ---------------------------------------------------------------------------
// Utility  code adapted from the DOMPrint program distributed with Xerces-c
// simple transcoding wrapper
class StrX
{
  char*   fLocalForm;
public :
  StrX(const XMLCh* const toTranscode) { fLocalForm = XMLString::transcode(toTranscode); }
  ~StrX() { XMLString::release(&fLocalForm); }
  const char* localForm() const { return fLocalForm; }
};
std::ostream&
operator<<(std::ostream& target, const StrX& toDump)
{
  target << toDump.localForm();
  return target;
}
// error handler interface
class DOMTreeErrorReporter : public ErrorHandler
{
public:
  void warning(const SAXParseException& toCatch) {}
  void resetErrors() {}
  void error(const SAXParseException& toCatch) {
    cerr << "Error at file \"" << StrX(toCatch.getSystemId())
	 << "\", line " << toCatch.getLineNumber()
	 << ", column " << toCatch.getColumnNumber() << endl
	 << "   Message: " << StrX(toCatch.getMessage()) << endl;
  }
  void fatalError(const SAXParseException& toCatch) {
    cerr << "Fatal Error at file \"" << StrX(toCatch.getSystemId())
	 << "\", line " << toCatch.getLineNumber()
	 << ", column " << toCatch.getColumnNumber() << endl
	 << "   Message: " << StrX(toCatch.getMessage()) << endl;
  }
};
// ---------------------------------------------------------------------------
int
main(int argc, const char** argv)
{
  try
    {
      XMLPlatformUtils::Initialize();
    }
  catch(const XMLException& e)
    {
      StrX tmp_e(e.getMessage());
      cerr << "Xerces initialization error: " << tmp_e.localForm() << endl;
      return 2;
    }
  
  // check command line for arguments
  if ( argc < 2 )
    {
      cerr << "usage: schema-check <xml-file> [<schema-file> ...]" << endl;
      return 3;
    }
  for ( int i = 1; i < argc; i++ )
    {
      FILE *f = fopen(argv[i], "r");
      if ( f == 0 )
	{
	  perror(argv[i]);
	  return 4;
	}
    }
  XercesDOMParser *parser = new XercesDOMParser;
  DOMTreeErrorReporter *errReporter = new DOMTreeErrorReporter();
  parser->setErrorHandler(errReporter);
  parser->setDoNamespaces(true);
  parser->setCreateEntityReferenceNodes(true);
  parser->useCachedGrammarInParse(true);
  if ( argc > 2 )
    {
      parser->setDoSchema(true);
      parser->setValidationScheme(AbstractDOMParser::Val_Always);
      parser->setValidationSchemaFullChecking(true);
      for ( int i = 2; i < argc; i++ )
	{    
	  if ( parser->loadGrammar(argv[i], Grammar::SchemaGrammarType, true) == 0 )
	    {
	      cerr << "Error loading grammar " << std::string(argv[i]) << endl;
	      return 4;
	    }
	}
    }
  
  bool errorsOccured = true;
  try
    {
      parser->parse(argv[1]);
      errorsOccured = false;
    }
  catch ( const OutOfMemoryException& )
    {
      cerr << "Out of memory exception." << endl;
    }
  catch ( const XMLException& e )
    {
      cerr << "An error occurred during parsing" << endl
	   << "   Message: " << StrX(e.getMessage()) << endl;
    }
  catch ( const DOMException& e )
    {
      const unsigned int maxChars = 2047;
      XMLCh errText[maxChars + 1];
      
      cerr << endl
	   << "A DOM error occurred during parsing: '" << std::string(argv[1]) << "'" << endl
	   << "DOM Exception code:  " << e.code << endl;
      
      if ( DOMImplementation::loadDOMExceptionMsg(e.code, errText, maxChars) )
	cerr << "Message is: " << StrX(errText) << endl;
    }
  catch (...)
    {
      cerr << "An unclassified error occurred during parsing." << endl;
    }
  
  return errorsOccured ? 1 : 0;
}
//
// end schema-check.cpp
//

C.4. kdm-decrypt 🔗

This program reads a KDM and an RSA private key in PEM format and decrypts the EncryptedKey elements in the KDM. The decrypted key blocks are printed to stdout . Note that key blocks in the KDM must have been encrypted using the public key which corresponds to the RSA key given as the second argument to this program. 

$ kdm-decrypt test_file.kdm.xml my_id_key.pem
        CipherDataID: f1dc124460169a0e85bc300642f866ab
SignerThumbprint: q5Oqr6GkfG6W2HzcBTee5m0Qjzw=
          CPL Id: 119d8990-2e55-4114-80a2-e53f3403118d
          Key Id: b6276c4b-b832-4984-aab6-250c9e4f9138
        Key Type: MDIK
      Not Before: 2007-09-20T03:24:53-00:00
        Not After: 2007-10-20T03:24:53-00:00
Key
Data:
7f2f711f1b4d44b83e1dd1bf90dc7d8c
Example C.4 . kdm-decrypt execution 🔗

C.4.1. kdm-decrypt Source Code Listing 🔗 

//
// kdm-decrypt.cpp -- decrypt and display KDM EncryptedKey elements
//
// $Id$
//
// This program requires the Xerces-c XML, XMLSecurity, OpenSSL
// and asdcplib libraries. To build:
//
// c++ -o kdm-decrypt kdm-decrypt.cpp 
//     -lxerces-c -lxml-security-c -lkumu -lcrypto
//
#include <KM_util.h>
#include <KM_fileio.h>
#include <ctype.h>
#include <iostream>
#include <string>
#include <openssl/pem.h>
#include <xercesc/util/OutOfMemoryException.hpp>
#include <xercesc/parsers/XercesDOMParser.hpp>
#include <xercesc/framework/MemBufInputSource.hpp>
#include <xsec/framework/XSECProvider.hpp>
#include <xsec/framework/XSECException.hpp>
#include <xsec/enc/XSECCryptoException.hpp>
#include <xsec/enc/OpenSSL/OpenSSLCryptoKeyRSA.hpp>
XERCES_CPP_NAMESPACE_USE
using std::cout;
using std::cerr;
using std::endl;
using namespace Kumu;
const size_t KeyType_Length = 4;
const size_t DateTime_Length = 25;
const ui32_t X509Thumbprint_Length = 20;
// A structure to hold key block data retrieved during a decrypt operation.
struct S430_2_KeyBlock
{
  byte_t CipherDataID[UUID_Length];
  byte_t SignerThumbprint[X509Thumbprint_Length];
  byte_t CPLId[UUID_Length];
  byte_t KeyType[KeyType_Length];
  byte_t KeyId[UUID_Length];
  byte_t NotBefore[DateTime_Length];
  byte_t NotAfter[DateTime_Length];
  byte_t KeyData[SymmetricKey_Length];
  S430_2_KeyBlock() {
    memset(this, 0, sizeof(S430_2_KeyBlock));
  }
  std::string Dump() const;
};
std::string safe_char(char c) {
  char b[2] = {'*', 0};
  if ( isprint(c) ) b[0] = c;
  return b;
}
// Pretty-print key block data.
std::string
S430_2_KeyBlock::Dump() const
{
  using std::string;
  Kumu::Identifier<X509Thumbprint_Length> TmpThumbprint;
  UUID   TmpUUID;
  char   tmp_buf[64];
  string out_string;
  bin2hex(CipherDataID, UUID_Length, tmp_buf, 64);
  out_string = "    CipherDataID: " + string(tmp_buf);
  TmpThumbprint.Set(SignerThumbprint);
  out_string += "\nSignerThumbprint: " + string(TmpThumbprint.EncodeBase64(tmp_buf, 64));
  TmpUUID.Set(CPLId);
  out_string += "\n          CPL Id: " + string(TmpUUID.EncodeHex(tmp_buf, 64));
  TmpUUID.Set(KeyId);
  out_string += "\n          Key Id: " + string(TmpUUID.EncodeHex(tmp_buf, 64));
  out_string += "\n        Key Type: "
    + safe_char(KeyType[0]) + safe_char(KeyType[1])
    + safe_char(KeyType[2]) + safe_char(KeyType[3]);
  assert(DateTime_Length<64);
  tmp_buf[DateTime_Length] = 0;
  memcpy(tmp_buf, NotBefore, DateTime_Length);
  out_string += "\n      Not Before: " + string(tmp_buf);
  memcpy(tmp_buf, NotAfter, DateTime_Length);
  out_string += "\n       Not After: " + string(tmp_buf);
  bin2hex(KeyData, UUID_Length, tmp_buf, 64);
  out_string += "\n        Key Data: " + string(tmp_buf);
  out_string += "\n";
  return out_string;
}
// Given a KDM string and a parsed RSA key, decrypt the key blocks
// in the KDM and print them to stdout.
int
decrypt_kdm(const std::string& KDMDocument, EVP_PKEY* Target)
{
  assert(Target);
  XercesDOMParser* parser = new XercesDOMParser;
  parser->setDoNamespaces(true);
  parser->setCreateEntityReferenceNodes(true);
  try
    {
      MemBufInputSource xmlSource(reinterpret_cast<const XMLByte*>(KDMDocument.c_str()),
				  static_cast<XMLSize_t>(KDMDocument.length()),
				  "pidc_rules_file");
      parser->parse(xmlSource);
      int errorCount = parser->getErrorCount();
      if ( errorCount > 0 )
	{
	  cerr << "XML parse errors: " << errorCount << endl;
	  return -1;
	}
    }
  catch ( const OutOfMemoryException& )
    {
      cerr << "Out of memory exception." << endl;
    }
  catch ( const XMLException& e )
    {
      char* emsg = XMLString::transcode(e.getMessage());
      cerr << "An error occurred during parsing" << endl
	   << "   Message: " << emsg << endl;
	  XSEC_RELEASE_XMLCH(emsg);
    }
  catch ( const DOMException& e )
    {
      const unsigned int maxChars = 2047;
      XMLCh errText[maxChars + 1];
      
      cerr << endl
	   << "DOM Exception code is:  " << e.code << endl;
      
      if ( DOMImplementation::loadDOMExceptionMsg(e.code, errText, maxChars) )
	{
	  char* emsg = XMLString::transcode(errText);
	  cerr << "Message is: " << emsg << endl;
	  XSEC_RELEASE_XMLCH(emsg);
	}
    }
  catch (...)
    {
      cerr << "Unexpected XML parser error." << endl;
    }
  try
    {
      XSECProvider prov;
      OpenSSLCryptoKeyRSA* PrivateKey = new OpenSSLCryptoKeyRSA(Target);
      if ( PrivateKey == 0 )
	{
	  cerr << "Error reading private key" << endl;
	  return -1;
	}
      DOMDocument* doc = parser->getDocument();
      assert(doc);
      XENCCipher* cipher = prov.newCipher(doc);
      cipher->setKEK(PrivateKey);
      DOMNodeIterator* Iter =
	((DOMDocumentTraversal*)doc)->createNodeIterator(doc,
							 (DOMNodeFilter::SHOW_ELEMENT),
							 0,  false);
      assert(Iter);
      DOMNode* Node;
      int keys_accepted = 0;
      int key_nodes_found = 0;
      while ( (Node = Iter->nextNode()) != 0 )
	{
	  char* n = XMLString::transcode(Node->getLocalName());
	  if ( n == 0 ) continue;
	  if ( strcmp(n, "EncryptedKey") == 0 )
	    {
	      key_nodes_found++;
	      S430_2_KeyBlock CipherData;
	      ui32_t decrypt_len =
		cipher->decryptKey((DOMElement*)Node,
				   (byte_t*)&CipherData, sizeof(CipherData));
	      if ( decrypt_len == sizeof(CipherData) )
		{
		  keys_accepted++;
		  cout << CipherData.Dump();
		}
	      else if ( decrypt_len > 0 )
		cerr << "Unexpected cipher block length: " << decrypt_len << endl;
	      else
		cerr << "Error decoding key block: " << key_nodes_found << endl;
	    }
	  XSEC_RELEASE_XMLCH(n);
	}
      Iter->release();
    }
  catch (XSECException &e)
    {
      char* emsg = XMLString::transcode(e.getMsg());
      cerr << "Key decryption error: " << emsg << endl;
      XSEC_RELEASE_XMLCH(emsg);
      return -1;
    }
  catch (XSECCryptoException &e)
    {
      cerr << "Crypto error: " << e.getMsg() << endl;
      return -1;
    }
  catch (...)
    {
      cerr << "Unexpected decryption error." << endl;
    }
  delete parser;
  return 0;
}
//
int
main(int argc, const char** argv)
{
  if ( argc < 3 )
    {
      cerr << "USAGE: kdm-decrypt <kdm-file> <RSA-PEM-file>" << endl;
      return 2;
    }
  try
    {
      XMLPlatformUtils::Initialize();
      XSECPlatformUtils::Initialise();
    }
  catch(const XMLException& e)
    {
      char* emsg = XMLString::transcode(e.getMessage());
      cerr << "Xerces or XMLSecurity initialization error: " << emsg << endl;
      XSEC_RELEASE_XMLCH(emsg);
      return 3;
    }
  catch (...)
    {
      cerr << "Unexpected Xerces or XMLSecurity initialization error." << endl;
    }
  FILE* fp = fopen (argv[2], "r");
  if ( fp == 0 )
    {
      perror(argv[2]);
      return 4;
    }
  EVP_PKEY* Target = PEM_read_PrivateKey(fp, 0, 0, 0);
  fclose(fp);
  if ( Target == 0 )
    {
      cerr << "Error reading RSA key in file " << std::string(argv[2]) << endl;
      return 5;
    }
  std::string XML_doc;
  Result_t result = ReadFileIntoString(argv[1], XML_doc);
  if ( KM_FAILURE(result) )
    {
      cerr << "Error reading XML file " << std::string(argv[1]) << endl;
      return 6;
    }
  if ( decrypt_kdm(XML_doc, Target) != 0 )
    return 1;
  return 0;
}
//
// end kdm-decrypt.cpp
//

C.5. j2c-scan 🔗

This program reads a JPEG 2000 codestream from a file and produces parametric data on the standard output. The following example illustrates this usage: 

$ j2c-scan test_frame_000002.j2c
coding parameters
  digital cinema profile: none
  rsiz capabilities: standard
  pixel offset from top-left corner: (0, 0)
  tile width/height in pixels: (2048, 1080)
  image width/height in tiles: (1, 1)
  tile #1
    coding style: 1
    progression order: Component-Position-Resolution-Layer
    POC marker flag: 0
    number of quality layers: 1
      rate for layer #1: 0.0
    multi-component transform flag: 1
    component #1
      coding style: 1
      number of resolutions: 6
      code block width/height: (5, 5)
      code block coding style: 0
      discrete wavelet transform identifier: 0
      quantization style: 2
      number of guard bits: 1
      step size pairs: 16
      region of interest shift: 0
    component #2
      coding style: 1
      number of resolutions: 6
      code block width/height: (5, 5)
      code block coding style: 0
      discrete wavelet transform identifier: 0
      quantization style: 2
      number of guard bits: 1
      step size pairs: 16
      region of interest shift: 0
    component #3
      coding style: 1
      number of resolutions: 6
      code block width/height: (5, 5)
      code block coding style: 0
      discrete wavelet transform identifier: 0
      quantization style: 2
      number of guard bits: 1
      step size pairs: 16
region
of
interest
shift:
0
Example C.5 . j2c-scan execution 🔗

C.5.1. j2c-scan Source Code Listing 🔗 

/*
 * j2c-scan.cpp -- parse j2c file and display data concerning it
 *
 * $Id$
 *
 * This program requires version 1.5.2 of the OpenJPEG
 * library. Furthermore, it requires the header files "openjpeg.h" and
 * "j2k.h" from its source distribution. Copy these headers to your
 * build directory. After doing so, execute the following to build:
 *  $ c++ -o j2c-scan j2c-scan.cpp -lopenjpeg
 */
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "openjpeg.h"
#include "j2k.h"
static void
j2k_dump_cp (opj_image_t * image, opj_cp_t * cp)
{
  const char *s;
  int i, j;
  int step_size_pairs;
  printf ("coding parameters\n");
  if (cp->comment != NULL)
    {
      printf ("  coding comment: %p\n", cp->comment);
    }
  switch (cp->cinema)
    {
    case OFF:      s = "none";      break;
    case CINEMA2K_24:      s = "2k @ 24 fps";      break;
    case CINEMA2K_48:      s = "2k @ 48 fps";      break;
    case CINEMA4K_24:      s = "4k @ 24 fps";      break;
    default:      s = "unknown";      break;
    }
  printf ("  digital cinema profile: %s\n", s);
  switch (cp->rsiz)
    {
    case STD_RSIZ:      s = "standard";      break;
    case CINEMA2K:      s = "2k digital cinema";      break;
    case CINEMA4K:      s = "4k digital cinema";      break;
    default:      s = "unknown";      break;
    }
  printf ("  rsiz capabilities: %s\n", s);
  printf ("  pixel offset from top-left corner: (%d, %d)\n", cp->tx0,
	  cp->ty0);
  printf ("  tile width/height in pixels: (%d, %d)\n", cp->tdx, cp->tdy);
  printf ("  image width/height in tiles: (%d, %d)\n", cp->tw, cp->th);
  for (i = 0; i < cp->tw * cp->th; i++)
    {
      printf ("  tile #%d\n", i + 1);
      printf ("    coding style: %x\n", cp->tcps[i].csty);
      switch (cp->tcps[i].prg)
	{
	case LRCP:	  s = "Layer-Resolution-Component-Position";	  break;
	case RLCP:	  s = "Resolution-Layer-Component-Position";	  break;
	case RPCL:	  s = "Resolution-Position-Component-Layer";	  break;
	case PCRL:	  s = "Position-Component-Resolution-Layer";	  break;
	case CPRL:	  s = "Component-Position-Resolution-Layer";	  break;
	default:	  s = "unknown";	  break;
	}
      printf ("    progression order: %s\n", s);
      printf ("    POC marker flag: %d\n", cp->tcps[i].POC);
      printf ("    number of quality layers: %d\n", cp->tcps[i].numlayers);
      for (j = 0; j < cp->tcps[i].numlayers; j++)
	{
	  printf ("      rate for layer #%d: %.1f\n", j + 1,
		  cp->tcps[i].rates[j]);
	}
      printf ("    multi-component transform flag: %d\n", cp->tcps[i].mct);
      for (j = 0; j < image->numcomps; j++)
	{
	  printf ("    component #%d\n", j + 1);
	  printf ("      coding style: %x\n", cp->tcps[i].tccps[j].csty);
	  printf ("      number of resolutions: %d\n",
		  cp->tcps[i].tccps[j].numresolutions);
	  printf ("      code block width/height: (%d, %d)\n",
		  cp->tcps[i].tccps[j].cblkw, cp->tcps[i].tccps[j].cblkh);
	  printf ("      code block coding style: %x\n",
		  cp->tcps[i].tccps[j].cblksty);
	  printf ("      discrete wavelet transform identifier: %d\n",
		  cp->tcps[i].tccps[j].qmfbid);
	  printf ("      quantization style: %d\n",
		  cp->tcps[i].tccps[j].qntsty);
	  printf ("      number of guard bits: %d\n",
		  cp->tcps[i].tccps[j].numgbits);
	  step_size_pairs =
	    (cp->tcps[i].tccps[j].qntsty ==
	     J2K_CCP_QNTSTY_SIQNT) ? 1 : cp->tcps[i].tccps[j].numresolutions *
	    3 - 2;
	  printf ("      step size pairs: %d\n", step_size_pairs);
	  printf ("      region of interest shift: %d\n",
		  cp->tcps[i].tccps[j].roishift);
	}
    }
}
void
error_callback (const char *msg, void *client_data)
{
  FILE *stream = (FILE *) client_data;
  fprintf (stream, "[ERROR] %s", msg);
}
void
warning_callback (const char *msg, void *client_data)
{
  FILE *stream = (FILE *) client_data;
  fprintf (stream, "[WARNING] %s", msg);
}
int
main (int argc, char *argv[])
{
  char *filename;		/* name of the file to process */
  FILE *fp;			/* input file pointer */
  int file_length;		/* length of the input file */
  unsigned char *buffer = NULL;	/* in-memory buffer containing the input file */
  opj_cio_t *cio = NULL;	/* OpenJPEG wrapper around file buffer */
  opj_dparameters_t parameters;	/* decompression parameters */
  opj_dinfo_t *dinfo = NULL;	/* pointer to a JPEG-2000 decompressor */
  opj_event_mgr_t event_mgr;	/* manager of events' callback functions */
  opj_image_t *image = NULL;	/* pointer to the decoded image */
  memset (&event_mgr, 0, sizeof (opj_event_mgr_t));
  event_mgr.error_handler = error_callback;
  event_mgr.warning_handler = warning_callback;
  event_mgr.info_handler = NULL;
  /* establish default decoding parameters for JPEG-2000 codestreams */
  opj_set_default_decoder_parameters (&parameters);
  parameters.decod_format = 0;
  if (argc != 2)
    {
      fprintf (stderr, "USAGE: j2c-scan file.j2c\n");
      return 1;
    }
  filename = argv[1];
  strncpy (parameters.infile, filename, sizeof (parameters.infile) - 1);
  /* read the input file and put it in memory */
  fp = fopen (parameters.infile, "rb");
  if (fp == NULL)
    {
      perror ("fopen");
      return 2;
    }
  fseek (fp, 0, SEEK_END);
  file_length = (int) ftell (fp);
  fseek (fp, 0, SEEK_SET);
  buffer = (unsigned char *) malloc (file_length);
  fread (buffer, sizeof (unsigned char), file_length, fp);
  fclose (fp);
  /* decode the JPEG-2000 codestream */
  dinfo = opj_create_decompress (CODEC_J2K);
  opj_set_event_mgr ((opj_common_ptr) dinfo, &event_mgr, stderr);
  opj_setup_decoder (dinfo, &parameters);
  cio = opj_cio_open ((opj_common_ptr) dinfo, buffer, file_length);
  image = opj_decode (dinfo, cio);
  if (image == NULL)
    {
      fprintf (stderr, "ERROR -> j2c-scan: failed to decode image!\n");
      opj_destroy_decompress (dinfo);
      opj_cio_close (cio);
      free (buffer);
      return 1;
    }
  opj_cio_close (cio);
  free (buffer);
  /* display information about the image */
  j2k_dump_cp (image, ((opj_j2k_t *) dinfo->j2k_handle)->cp);
  /* free the memory */
  opj_destroy_decompress (dinfo);
  opj_image_destroy (image);
  return 0;
}

C.6. Deleted Section 🔗

The section "eab_calc.py" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

C.7. uuid_check.py 🔗

This program reads one or more XML files containing d-cinema metadata and tests each of the UUID values for compliance with [RFC-4122] . The program will emit a message on stderr for each malformed UUID that is encountered. The following example illustrates this usage for a KDM file: 

$ uuid_check.py Example.kdm.xml
UUID: 7556bff9-58f9-4320-bb1f-fb594219a957
UUID: bdb3a717-5062-4822-8dfc-0dc6570cc116
UUID: 71f7926e-8ce6-4763-b14b-0ef7dcd952f5
UUID: 6083adad-472c-43da-b131-c6dc601cd154
UUID:
aeaae312-a257-11da-a601-8b319b685f8e
Example C.7 . uuid_check.py execution 🔗

C.7.1. uuid_check Source Code Listing 🔗 

#!/usr/bin/env python
#
# uuid_check.py -- Scan an XML file and see that all UUID values
#                  conform to RFC-4122
#
# $Id$
#
from __future__ import print_function
import sys, re
# regular expressions for use below
urn_uuid_re = re.compile('urn:uuid:([^<]*)')
uuid_re = re.compile('^[0-9a-f]{8}-[0-9a-f]{4}-\
([1-5])[0-9a-f]{3}-[8-9a-b][0-9a-f]{3}-[0-9a-f]{12}$', re.IGNORECASE)
#
def uuid_scan(text):
    uuid_list = []
    while text:
        match = urn_uuid_re.search(text)
        if not match: break
        uuid_val = match.group(1)
        text = text[match.end():]
        match = uuid_re.match(uuid_val)
        if not match:
            sys.stderr.write("urn:uuid: value is not an RFC-4122 UUID: %s\n" % (uuid_val))
            continue
        type = int(match.group(1)[0])
        if type not in (1, 4, 5):
            sys.stderr.write("Unexpected UUID type: %d for value %s\n" % (type, uuid_val))
        uuid_list.append(uuid_val)
    return uuid_list
#
#
if len(sys.argv) < 2:
    sys.stderr.write("usage: uuid_check.py <xml-file> [...]\n")
    sys.exit(1)
for filename in sys.argv[1:]:
    try:
        handle = open(filename)
        text = handle.read()
        handle.close()
    except Exception as e:
        print("{0}: {1}".format(filename, e))
    else:
        for uuid in uuid_scan(text):
            print("UUID: {0}".format(uuid))
#
# end uuid_check.py
#

C.8. dsig_cert.py 🔗

This program reads a signed XML file and re-writes the file to the standard output using the certificate order expected by the checksig program from the XML Security package. The following example illustrates this usage for a KDM file: 

$ dsig_cert.py test-kdm.xml >tmp.xml
$ checksig tmp.xml
Signature
verified
OK!
Example C.8 . dsig_cert.py execution 🔗

C.8.1. dsig_cert.py Source Code Listing 🔗 

#!/usr/bin/env python
#
# dsig_cert.py -- Re-order certificates in an XML signature
#
# NOTE: This program requires Python 2.7 or greater
#
# $Id$
#
from __future__ import print_function
import sys, re
from subprocess import Popen, PIPE
# regular expressions for use below
SignatureValue_end_re = re.compile('</(?:[\w\-]+:)?SignatureValue[^>]*>')
X509Data_re = re.compile('<(?:[\w\-]+:)X509Data[^>]*>(.*?)</(?:[\w\-]+:)X509Data\s*>\s+',
                         re.DOTALL)
X509Certificate_re = re.compile('X509Certificate[^>]*>(.*?)</', re.DOTALL)
dnQualifier_re = re.compile('dnQualifier=([\\w+/]+=)')
#
def get_dnq_type(pem_text, type):
    """Extract the dnQualifier value for the given certificate and common name."""
    handle = Popen(('/usr/bin/openssl', 'x509', '-noout', '-'+type),
                   stdin=PIPE, stdout=PIPE, close_fds=True)
    handle.stdin.write(pem_text)
    handle.stdin.close()
    name_text = handle.stdout.read()
    handle.wait()
    if handle.returncode != 0:
        raise Exception("No X509Certificate element in {0}".format(pem_text))
    dnq = dnQualifier_re.search(name_text.replace('\\', ''))
    if not dnq:
        raise Exception("Error retrieving dnQualifier from {0}.".format(type))
    return dnq.group(1)
#
def PEMify(base64_text):
    """ create canonical PEM lines from any base64 input"""
    in_text = re.sub('[\r\n]', '', base64_text)
    idx = 0
    end = len(in_text)
    retval = ''
    while idx < end:
        retval += in_text[idx:idx+64] + '\n'
        idx += 64
    return retval
#
class dsig_certificate_set:
    """An object for manipulating XML Signature certificates."""
    def __init__(self, xml_doc):
        """Initialize with a signed XML document string."""
        body_end = SignatureValue_end_re.search(xml_doc)
        if not body_end:
            raise Exception("Document does not contain a SignatureValue element.")
        self.kdm_head = xml_doc[:body_end.end()]
        xml_doc = xml_doc[body_end.end():]
        self.X509Data_list = []
        x509_data = X509Data_re.search(xml_doc)
        if x509_data:
            self.kdm_head += xml_doc[:x509_data.start()]
        while x509_data:
            x509_text = xml_doc[x509_data.start():x509_data.end()]
            self.X509Data_list.append({ 'text': x509_text })
            xml_doc = xml_doc[x509_data.end():]
            x509_data = X509Data_re.search(xml_doc)
        self.kdm_tail = xml_doc
        for x509_data in self.X509Data_list:
            # extract the certificate
            cert = X509Certificate_re.search(x509_data['text'])
            if not cert:
                raise Exception("No X509Certificate element in {0}".format(x509_data['text']))
            cert = PEMify(cert.group(1))
            cert = "-----BEGIN CERTIFICATE-----\n%s-----END CERTIFICATE-----\n" % (cert)
            x509_data['subject_dnq'] = get_dnq_type(cert, 'subject')
            x509_data['issuer_dnq'] = get_dnq_type(cert, 'issuer')
            x509_data['pem_cert'] = cert
    def order_by_dnq(self):
        """Arrange certificates in leaf-root order."""
        root = None
        issuer_map = {}
        for x509_data in self.X509Data_list:
            if x509_data['subject_dnq'] == x509_data['issuer_dnq']:
                if root:
                    raise Exception("Certificate list contains multiple roots.")
                root = x509_data
            else:
                issuer_map[x509_data['issuer_dnq']] = x509_data
        if not root:
            raise Exception("Self-signed root certificate not found.")
        tmp_list = [root];
        try:
            key = tmp_list[-1]['subject_dnq']
            next = issuer_map[key]
            while next:
                tmp_list.append(next)
                key = tmp_list[-1]['subject_dnq']
                next = issuer_map[key]
        except:
            pass
        if len(self.X509Data_list) != len(tmp_list):
            raise Exception("Certificates do not form a complete chain.")
        tmp_list.reverse()
        self.X509Data_list = tmp_list
        return self
    def write_certs(self, prefix='cert_set_'):
        """Write PEMcertificates to files using the optional filename prefix value."""
        count = 1
        for x509_data in self.X509Data_list:
            filename = "%s%d.pem" % (prefix, count)
            handle = open(filename, 'w')
            handle.write(x509_data['pem_cert'])
            handle.close()
            count += 1
    def __repr__(self):
        cert_text = ''
        for cert in self.X509Data_list:
            cert_text += cert['text']
        return self.kdm_head + cert_text + self.kdm_tail
#
if __name__ == '__main__':
    if len(sys.argv) < 2:
        sys.stderr.write("usage: dsig_cert.py <xml-file>\n")
        sys.exit(1)
    try:
        handle = open(sys.argv[1])
        text = handle.read()
        handle.close()
        cert_set = dsig_certificate_set(text)
        cert_set.order_by_dnq()
        print(cert_set)
    except Exception as e:
        print(e)
#
# end dsig_cert.py
#

C.9. dsig_extract.py 🔗

This program reads a signed XML file and writes the certificates contained within to individual PEM files. As shown below, the
-p option can be used to provide a prefix for the automatically-generated filenames. In this example, the input document contained four certificates. 

$ dsig_extract.py -p my_prefix_ test-kdm.xml
$ ls my_prefix_*
my_prefix_1.pem
my_prefix_2.pem
my_prefix_3.pem
my_prefix_4.pem
Example C.9 . dsig_extract.py execution 🔗

C.9.1. dsig_extract.py Source Code Listing 🔗 

#!/usr/bin/env python
#
# dsig_extract.py -- Extract certificates from an XML signature
#
# $Id$
#
from __future__ import print_function
from dsig_cert import dsig_certificate_set
import sys
prefix = 'xmldsig_cert_'
filename = None
def usage():
    sys.stderr.write("usage: dsig_extract.py [-p <prefix>] <xml-file>\n")
    sys.exit(1)
if len(sys.argv) < 2:
    usage()
if sys.argv[1] == '-p':
    if len(sys.argv) < 4:
        usage()
    prefix = sys.argv[2]
    filename = sys.argv[3]
else:
    filename = sys.argv[1]
try:
    handle = open(filename)
    text = handle.read()
    handle.close()
    set = dsig_certificate_set(text)
    set.write_certs(prefix=prefix)
except Exception as e:
    print(e)
#
# end dsig_extract.py
#

Appendix D. Deleted Section 🔗

The section "ASM Simulator" was deleted. The section number is maintained here to preserve the numbering of subsequent sections.

Appendix E. GPIO Test Fixture 🔗

The GPIO test fixture has eight outputs, which connect to ground via normally-open switch contacts. These outputs are expected to interface to command and/or status inputs of the d-cinema equipment under test.

The fixture has eight inputs, which connect to powered, current limited LEDs and will illuminate when the corresponding input is grounded. These inputs interface to command and/or status outputs of the d-cinema equipment under test.

Example circuits are provided below. Interface of outputs, inputs and ground is made via a single DB-25 female connector on the test fixture.

Testing Entities are not required to follow the above design, and are free to develop their own equipment and connector standards. The manufacturer of the d-cinema equipment being tested is responsible for providing a cable, appropriate for the individual Test Subject, that will interface to the test fixture being used.

Schematic of an electrical circuit
Figure E.1 . GPIO Test Fixture Schematic 🔗

Note that the LED inputs are internally current limited. External devices will be expected to sink 25mA per channel. Also, the test fixture has an integral PSU (the PSU may be external but it must use a different connector).

Schematic of a 25-pin electrical connector
Figure E.2 . GPIO Test Fixture Connector 🔗

Appendix F. Reference Documents 🔗

AES3-2003
AES standard for digital audio - Digital input-output interfacing - Serial transmission format for two-channel linearly represented digital audio data, Audio Engineering Society , September 9, 2003
CIE-15-2004
Colorimetry, 3rd Edition, International Commission on Illumination , 2004
DCI-DCSS
Digital Cinema System Specification Version 1.4.2 , DCI, June 15, 2022. https://dcss.dcimovies.com/0c0cff34d231b516cb89ae3fad352d5cf37a9515/dcss.html
DCI-DCSS-ERR-20110420
Digital Cinema System Specification Version 1.2, erratum dated April 20, 2011 , DCI-DCSS-ERR-20110420. https://www.dcimovies.com/archives/spec_v1_2_No_Errata_Incorporated/errata_1-96_aug30/ERRATA_34-76_2011-04-20_TO_DCI_DCS.html
DCI-DCSS-ERR-20160830
Digital Cinema System Specification Version 1.2, erratum dated August 12, 2012 , DCI. https://www.dcimovies.com/archives/spec_v1_2_No_Errata_Incorporated/errata_1-96_aug30/DCI-Errata_90-96_v1-2_08-30-2012.html
DCI-DCSS-ERR-20160428
Digital Cinema System Specification Version 1.2, erratum dated April 28, 2016 , DCI, April 28, 2016. https://www.dcimovies.com/archives/spec_v1_2_With_Errata_Incorporated/index.html
DCI-NIST-NOTE
DCI Memorandum on NIST Standards Transitions and Non-FIPS Mode , DCI, July 1, 2020. https://www.dcimovies.com/FIPS/
OBAE-ADD
Digital Cinema Object-Based Audio Addendum , DCI, October 1, 2018
DV-ADD
Direct View Display D-Cinema Addendum , DCI
DCI-HDR
High Dynamic Range D-Cinema Addendum , DCI
FIPS-140-2
FIPS 140-2: Security Requirements for Cryptographic Modules , NIST, Decemer 12, 2002
FIPS-140-3
FIPS 140-3: Security Requirements for Cryptographic Modules , NIST, March 22, 2019
FIPS-180-2
FIPS 180-2: Secure Hash Standard , NIST, August 1, 2002
FIPS-197
FIPS 197: Advanced Encryption Standard (AES) , NIST, November 26, 2001
FIPS-198a
FIPS 198a: The Keyed-Hash Message Authentication Code (HMAC) , NIST, March 6, 2002
IEEE-802-3
802-3: Standard for Information technology—Telecommunications and information exchange between systems— Local and metropolitan area networks—Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications , IEEE, 2005
ISO-144496
ISO/IEC 144496: Information technology - Computer graphics and image processing - Font Compression and Streaming , ISO/IEC, 2004
ISO-15948
ISO-15948: Information technology - Computer graphics and image processing - Portable Network Graphics (PNG): Functional specification , ISO/IEC, 2004
ISO-15444-1
ISO/IEC 15444-1 2004, Information Technology: JPEG 2000 Image Coding System , ISO/IEC, 2004
ISO-15444-1-AMD-1
ISO/IEC 15444-1/Amd1:2006 Codestream restrictions - Amendment 1: Profiles for digital cinema applications , ISO/IEC, 2004
ISO-10646
ISO 10646: Information technology – Universal Multiple-Octet Coded Character Set (UCS) , ISO/ IEC, December 15, 2003
ITU-X509
ITU-T Recommendation X.509 (1997 E): Information Technology – Open Systems Interconnection – The Directory: Authentication Framework , ITU, June 1997
NIST-800-38A
NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation - Methods and Techniques , NIST, Morris Dworkin, December 2001
NIST-800-38F
NIST Special Publication 800-38F: Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping , NIST, December 2012
PKCS-1
PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories , June 14, 2002
ICDM IDMS
Information Display Measurements Standard (IDMS) , International Committee for Display Metrology (ICDM), Version 1.1a (March 2022)
RFC-1421
RFC 1421: "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures" , IETF, J. Linn, February 1993
RFC-2045
RFC 2045: "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies" , IETF, N. Freed, N. Borenstein, November 1996
RFC-2246
RFC 2246: “The TLS Protocol Version 1.0” , IETF, T. Dierks, C. Allen, January 1999
RFC-2246
RFC 5246: “The TLS Protocol Version 1.2” , IETF, T. Dierks, E. Rescorla, August 2008
RFC-8446
RFC 8446: “The TLS Protocol Version 1.3” , IETF, E. Rescorla, August 2018
RFC-2253
RFC 2253: "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names" , IETF,
RFC-3174
RFC 3174: "US Secure Hash Algorithm 1 (SHA1)" , IETF, September 2001
RFC-3339
RFC 3339: "Date and Time on the Internet: Timestamps" , IETF, July 2002
RFC-3447
RFC 3447: "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1" , IETF, J. Jonsson, B. Kaliski, February 2003
RFC-4122
RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace" , IETF, P. Leach, M. Mealling, July 2005
RFC-3268
RFC 3268: "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)" , IETF, P. Chown, June 2002
SMPTE-330
SMPTE Standard for Television – Unique Material Identifier (UMID) , SMPTE, 2011
SMPTE-336
SMPTE Standard for Television - Data Encoding Protocol using Key-Length-Value , SMPTE, 2007
SMPTE-372
Television - Dual Link 292M Interface for 1920 x 1080 Picture Raster , SMPTE, 2011
SMPTE-377-1
SMPTE Standard for Television – Material Exchange Format (MXF) – File Format Specification" , SMPTE, 2011
SMPTE-379-1
SMPTE Standard for Television – Material Exchange Format (MXF) – MXF Generic Container , SMPTE, 2009
SMPTE-382
Material Exchange Format (MXF) – Mapping AES3 and Broadcast Wave Audio into the MXF Generic Container , SMPTE, 2007
SMPTE-390
Television - Material Exchange Format (MXF) - Specialized Operational Pattern "Atom" (Simplified Representation of a Single Item) , SMPTE, 2011
SMPTE-410
Material Exchange Format - Generic Stream Partition , SMPTE, 2008
SMPTE-422
Material Exchange Format - Mapping JPEG 2000 Codestreams into the MXF Generic Container , SMPTE, 2006
SMPTE-428-1
D-Cinema Distribution Master - Image Structure , SMPTE, 2006
SMPTE-428-2
D-Cinema Distribution Master- Audio Characteristics , SMPTE, 2006
SMPTE-428-3
D-Cinema Distribution Master - Audio Channel Mapping , SMPTE, 2006
SMPTE-428-7
D-Cinema Distribution Master - Subtitle , SMPTE, 2010
SMPTE-428-10
D-Cinema Distribution Master - Closed Caption and Closed Subtitle , SMPTE, 2008
SMPTE-428-12
D-Cinema Distribution Master - Common Audio Channels and Soundfield Groups , SMPTE, 2013
SMPTE-429-2
D-Cinema Packaging - Operational Constraints , SMPTE, 2011
SMPTE-429-3
D-Cinema Packaging - Sound and Picture Track File Application , SMPTE, 2007
SMPTE-429-4
D-Cinema Packaging - MXF JPEG2000 Application , SMPTE, 2006
SMPTE-429-5
D-Cinema Packaging - Subtitling Distribution Format , SMPTE, 2009
SMPTE-429-6
D-Cinema Packaging - Track File Essence Encryption , SMPTE, 2006
SMPTE-429-7
D-Cinema Packaging - Composition Playlist Application , SMPTE, 2006
SMPTE-429-8
D-Cinema Packaging - Packing List, SMPTE, 2007
SMPTE-429-9
D-Cinema Packaging - Asset Mapping , SMPTE, 2007
SMPTE-429-10
D-Cinema Packaging - Stereoscopic Picture Track File , SMPTE, 2008
SMPTE-429-12
D-Cinema Packaging - Caption and Closed Subtitle , SMPTE, 2008
SMPTE-429-14
D-Cinema Packaging - Aux Data Track File , SMPTE, 2014
SMPTE-429-16
D-Cinema Packaging - Additional Composition Metadata and Guidelines , SMPTE, 2014
SMPTE-429-18
D-Cinema Packaging - Immersive Audio Track File , SMPTE, 2019
SMPTE-429-19
D-Cinema Packaging - DCP Operational Constraints for Immersive Audio , SMPTE, 2019
SMPTE-430-1
D-Cinema Operations - Key Delivery Message , SMPTE, 2017, incorporating Amendment 1, 2019
SMPTE-430-2
D-Cinema Operations - Digital Certificate , SMPTE, 2006
SMPTE-430-3
D-Cinema Operations - Generic Extra-Theatre Message Format , SMPTE, 2008
SMPTE-430-4
D-Cinema Operations - Log Records Format , SMPTE, 2008
SMPTE-430-5
D-Cinema Operations - Security Log Event Class and Constraints , SMPTE, 2011
SMPTE-430-6 D-Cinema Operations - Auditorium Security Messages for Intra-Theater Communications" , SMPTE, 2010
SMPTE-430-12
D-Cinema Operations – FSK Synchronization Signal , SMPTE, 2014, incorporating Amendment 1, 2019
SMPTE-431-1
D-Cinema Quality - Screen Luminance Level, Chromaticity, and Uniformity , SMPTE, 2006
SMPTE-431-2
D-Cinema Quality - Reference Projector and Environment , SMPTE, 2011
SMPTE-432-1
Digital Source Processing - Color Processing for D-Cinema , SMPTE, 2010
SMPTE-432-2
Digital Source Processing - D-Cinema Low Frequency Effects (LFE) Channel Audio Characteristics , SMPTE, 2006
SMPTE-433
D-Cinema - XML Data Types , SMPTE, 2008
SMPTE-rdd-20
D-Cinema - CineLink 2 link encryption protocol , SMPTE, 2010
SMPTE-2098-2
Immersive Audio Bitstream Specification , SMPTE, 2019
SMPTE-2098-3
Immersive Audio Renderer Expectations and Testing Recommendations , SMPTE, 2020
SMPTE-2098-5
D-Cinema Immersive Audio Channels and Soundfield , SMPTE, 2018

Appendix G. Digital Cinema System Specification References to CTP 🔗

DCSS Section CTP Procedure Title CTP Section
2.1.1.4 Decoder Requirements 6.5.2.
3.2.1 Image Frame Rates 7.5.33.
3.2.1.2 Image Structure Container and Image Container Format 4.5.1.
3.2.1.3 Image Structure Container and Image Container Format 4.5.1.
3.2.1.5 Image Compression Standard & Encoding Parameters 4.5.2.
3.2.1.7 Image Structure Container and Image Container Format 4.5.1.
3.3 Constrained OMB Processing Capability 10.4.81.
3.3.2.1 Audio Sample Rate Conversion 6.6.2.
3.3.2.2 Audio Characteristics 4.5.3.
3.3.4 Timed Text Track File Format 4.4.3.
3.3.4.1 Audio Characteristics 4.5.3.
3.3.4.3 Maximum Bitrate OBAE 6.8.3.
3.4.2.2 Timed Text Resource Encoding 4.5.4.
3.4.3 Default Timed Text Font 6.7.4.
3.4.3.4 Timed Text Resource Encoding 4.5.4.
4.2 Image Compression Standard & Encoding Parameters 4.5.2.
4.3.2 Decoder Requirements 6.5.2.
4.4 Image Compression Standard & Encoding Parameters 4.5.2.
4.4.3.2 Timed Text Resource Encoding 4.5.4.
5.2.2.2 Image and Audio Packaging Standard 4.4.2.
5.2.2.3 Image and Audio Packaging Standard 4.4.2.
5.2.2.4 Image and Audio Packaging Standard 4.4.2.
5.2.2.5 Image and Audio Packaging Standard 4.4.2.
5.2.2.6 Image and Audio Packaging Standard 4.4.2.
5.2.2.6 DCP Integrity 4.6.1.
5.2.3 Composition Playlist File 4.3.1.
5.2.3 Composition Playlist Signature Validation 4.3.2.
5.3.1 Image and Audio Packaging Standard 4.4.2.
5.3.1.3 Track File Length 4.4.4.
5.3.1.3 Playback of Image Only Material 6.5.1.
5.3.1.6 Click Free Splicing of Audio Track Files 6.6.4.
5.3.1.6 Click Free Splicing of OBAE Track Files 6.8.1.
5.3.1.7 Composition Playlist Key Usage 4.3.3.
5.3.1.9 DCP Integrity 4.6.1.
5.3.2 Image and Audio Packaging Standard 4.4.2.
5.3.3.2 Image Track File Frame Boundary 4.4.5.
5.3.4.2 Audio Track File Frame Boundary 4.4.6.
5.3.4.5 Maximum Bitrate OBAE 6.8.3.
5.4.2 Composition Playlist File 4.3.1.
5.4.3 Composition Playlist File 4.3.1.
5.4.3.2 Composition Playlist File 4.3.1.
5.4.3.3 Composition Playlist File 4.3.1.
5.4.3.4 Composition Playlist File 4.3.1.
5.4.3.6 Composition Playlist Signature Validation 4.3.2.
5.4.4 Composition Playlist Signature Validation 4.3.2.
5.5.2.1 Asset Map File 4.1.1.
5.5.2.1 Volume Index File 4.1.2.
5.5.2.3 Packing List Signature Validation 4.2.2.
5.5.2.3 DCP Integrity 4.6.1.
5.5.3.1 Packing List File 4.2.1.
5.5.3.2 Packing List File 4.2.1.
5.5.3.2 Packing List Signature Validation 4.2.2.
5.5.3.2 DCP Integrity 4.6.1.
6.2.3 Storage System Ingest Interface 8.1.1.
7.2.3.1 Theater System Reliability 10.4.1.
7.2.3.2 Theater System Reliability 10.4.1.
7.2.3.5 Show Playlist Creation 8.2.2.
7.2.3.5 Show Playlist Creation (OBAE) 8.2.18.
7.2.3.7 Show Playlist Creation 8.2.2.
7.2.3.7 Show Playlist Creation (OBAE) 8.2.18.
7.2.3.11 Storage System Capacity 8.1.2.
7.2.3.13 Restarting Playback 8.2.8.
7.2.3.13 Restarting Playback (OBAE) 8.2.17.
7.3 Show Playlist Format 8.2.3.
7.3.4 Show Playlist Creation 8.2.2.
7.3.4 Automation Control and Interfaces 8.2.5.
7.3.4 Show Playlist Creation (OBAE) 8.2.18.
7.4.1.1 Show Playlist Creation 8.2.2.
7.4.1.1 Show Playlist Creation (OBAE) 8.2.18.
7.4.1.2 Show Playlist Creation 8.2.2.
7.4.1.2 Restarting Playback 8.2.8.
7.4.1.2 Restarting Playback (OBAE) 8.2.17.
7.4.1.2 Show Playlist Creation (OBAE) 8.2.18.
7.4.1.3 Show Playlist Creation 8.2.2.
7.4.1.3 SMS User Accounts 8.2.9.
7.4.1.3 Show Playlist Creation (OBAE) 8.2.18.
7.4.1.4 Show Playlist Creation 8.2.2.
7.4.1.4 Show Playlist Creation (OBAE) 8.2.18.
7.4.1.5 Show Playlist Creation 8.2.2.
7.4.1.5 Show Playlist Creation (OBAE) 8.2.18.
7.4.1.6 Show Playlist Creation 8.2.2.
7.4.1.6 Show Playlist Format 8.2.3.
7.4.1.6 Automation Control and Interfaces 8.2.5.
7.4.1.6 Artifact Free Transition of Image Format 8.2.7.
7.4.1.6 Show Playlist Creation (OBAE) 8.2.18.
7.4.1.7 Automation Control and Interfaces 8.2.5.
7.4.1.8 Audio Delay Setup 6.6.3.
7.4.1.8 OBAE Delay Setup 6.8.2.
7.4.1.8 Interrupt Free Playback 8.2.6.
7.4.1.8 Restarting Playback 8.2.8.
7.4.1.8 Interrupt Free Playback (OBAE) 8.2.16.
7.4.1.8 Restarting Playback (OBAE) 8.2.17.
7.5.3.2 Storage System Redundancy 8.1.3.
7.5.3.3 Storage System Performance 8.1.4.
7.5.3.3 Storage System Performance (OBAE) 8.1.6.
7.5.3.4 Storage System Performance 8.1.4.
7.5.3.4 Storage System Performance (OBAE) 8.1.6.
7.5.3.6 Storage System Performance 8.1.4.
7.5.3.6 Storage System Performance (OBAE) 8.1.6.
7.5.3.8 Theater System Storage Security 10.4.2.
7.5.4.2.5 Media Block Overlay 6.7.1.
7.5.4.2.6 Media Block Overlay 6.7.1.
7.5.4.2.7 Media Block Overlay 6.7.1.
7.5.4.3 Digital Audio Interfaces 6.6.1.
7.5.6.1 Digital Audio Interfaces 6.6.1.
7.5.6.1 OBAE Rendering Expectations 6.8.4.
7.5.6.2 Digital Audio Interfaces 6.6.1.
7.5.7.2 Automation Control and Interfaces 8.2.5.
8.2.2.6 Imaging Device Pixel Count/Structure 7.5.3.
8.2.2.7 Imaging Device Pixel Count/Structure 7.5.3.
8.2.2.9 FM Insertion Requirements 10.4.43.
8.3.3 SDR Contouring 7.5.10.
8.3.3 SDR Color Accuracy 7.5.12.
8.3.3 SDR Stereoscopic Color Accuracy 7.5.26.
8.3.3 HDR Contouring 7.5.35.
8.3.4.3 SDR White Luminance and Chromaticity 7.5.15.
8.3.4.4 SDR White Luminance and Chromaticity 7.5.15.
8.3.4.8 SDR Intra-frame Contrast 7.5.8.
8.3.4.9 Grayscale Tracking 7.5.9.
9.1 Constrained OMB Processing Capability 10.4.81.
9.3.3.2 Security Entity Physical Protection 10.4.4.
9.3.4.11 SDR Transfer Function 7.5.11.
9.4.1 Theater System Storage Security 10.4.2.
9.4.1 Security Devices Self-Test Capabilities 10.4.3. 9.4.1.1 SMS Operator Identification 8.2.10.
9.4.1.1 SMS Operator Identification (OBAE) 8.2.20.
9.4.1.1 Security Entity Physical Protection 10.4.4.
9.4.1.1 Secure SMS-SM Communication 10.4.5.
9.4.2.2 Projector and Direct View Display Physical Protection 7.2.1.
9.4.2.4 SM Operating Environment 9.5.1.
9.4.2.4 Location of Security Manager 10.4.6.
9.4.2.5 SMS Identity and Certificate 8.2.11.
9.4.2.5 Validity of SMS Certificates 8.2.15.
9.4.2.5 Self-initiated cryptographic output capability 9.5.14.
9.4.2.5 Self-initiated cryptographic output capability 9.5.14.
9.4.2.5 Secure SMS-SM Communication 10.4.5.
9.4.2.5 RRP Operational Messages 10.4.40. 9.4.2.5 TLS Authentication of Dual Certificate SM 10.4.80.
9.4.2.7 Constrained OMB Processing Capability 10.4.81.
9.4.2.7 Encrypted Auxiliary Data Processing 10.4.83. 9.4.3.2 Content Keys and TDL check 8.2.12.
9.4.3.2 Content Keys and TDL check (OBAE) 8.2.13.
9.4.3.5 KDM NonCriticalExtensions Element 3.5.1.
9.4.3.5 ETM IssueDate Field Check 3.5.2.
9.4.3.5 Structure ID Check 3.5.4.
9.4.3.5 Certificate Thumbprint Check 3.5.5.
9.4.3.5 KeyInfo Field Check 3.5.7.
9.4.3.5 KDM Malformations 3.5.8.
9.4.3.5 KDM Signature 3.5.9.
9.4.3.5 KDM NonCriticalExtensions Element (OBAE) 3.5.10.
9.4.3.5 ETM IssueDate Field Check (OBAE) 3.5.11.
9.4.3.5 Structure ID Check (OBAE) 3.5.12.
9.4.3.5 Certificate Thumbprint Check (OBAE) 3.5.13.
9.4.3.5 KeyInfo Field Check (OBAE) 3.5.14.
9.4.3.5 KDM Malformations (OBAE) 3.5.15.
9.4.3.5 KDM Signature (OBAE) 3.5.16.
9.4.3.5 Image Integrity Checking 6.1.1.
9.4.3.5 Sound Integrity Checking 6.1.2.
9.4.3.5 Restriction of Keying to MD Type 6.1.4.
9.4.3.5 Restriction of Keying to Valid CPLs 6.1.5.
9.4.3.5 Content Key Extension, End of Engagement 6.1.8.
9.4.3.5 ContentAuthenticator Element Check 6.1.9.
9.4.3.5 KDM TDL Check 6.1.11.
9.4.3.5 CPL Id Check 6.1.13.
9.4.3.5 CPL Id Check (OBAE) 6.1.14.
9.4.3.5 Restriction of Playback in Absence of Integrity Pack Metadata 6.1.15.
9.4.3.5 Restriction of Keying to MDEK Type (OBAE) 6.1.16.
9.4.3.5 OBAE Integrity Checking 6.1.17.
9.4.3.5 Content Key Extension, End of Engagement (OBAE) 6.1.18.
9.4.3.5 Restriction of Keying to Valid CPLs (OBAE) 6.1.22.
9.4.3.5 ContentAuthenticator Element Check (OBAE) 6.1.23.
9.4.3.5 Timed Text Decryption 6.7.6.
9.4.3.5 KDM Content Keys Check 8.2.14.
9.4.3.5 Location of Security Manager 10.4.6.
9.4.3.5 Playback Preparation 10.4.9. 9.4.3.5 Prevention of Keying of Compromised SPBs 10.4.11. 9.4.3.5 KDM Purge upon Expiry 10.4.16.
9.4.3.5 Key Usage Time Window 10.4.17. 9.4.3.5(9d) Export of KDM-Borne Keys 10.4.82.
9.4.3.6.1 KDM TDL Check 6.1.11.
9.4.3.6.1 Projector and Direct View Display Physical Protection 7.2.1.
9.4.3.6.1 Projector and Direct View Display Security Servicing 7.2.2.
9.4.3.6.1 Electronic Marriage Break Key Retaining 7.2.8.
9.4.3.6.1 Companion SPBs with Electronic Marriage 7.3.2.
9.4.3.6.1 Imaging Device Secure Silicon Device 10.4.18.
9.4.3.6.1 Access to Imaging Device Image Signals 10.4.19.
9.4.3.6.1 Systems with Electronic Marriage 10.4.20.
9.4.3.6.1 Imaging Device SPB Log Reporting Requirements 10.4.78.
9.4.3.6.2 Companion SPBs with Electronic Marriage 7.3.2. 9.4.3.6.2 Companion SPB Marriage Break Key Retaining 7.3.3. 9.4.3.6.2 SPB Type 1 Tamper Responsiveness 9.5.3. 9.4.3.6.2 Companion SPB Single Purpose Requirement 10.4.76. 9.4.3.6.2.1 SPB Type 1 Tamper Responsiveness 9.5.3. 9.4.3.6.2.1 SPB Type 1 Log Retention 10.4.69. 9.4.3.6.3 Timed Text Decryption 6.7.6.
9.4.3.6.3 Companion SPBs with Electronic Marriage 7.3.2.
9.4.3.6.3 Companion SPB Marriage Break Key Retaining 7.3.3.
9.4.3.6.3 SPB Type 1 Tamper Responsiveness 9.5.3.
9.4.3.6.3 MB Tasks 10.4.58.
9.4.3.6.3 SPB Type 1 Log Retention 10.4.69.
9.4.3.6.3 Log Collection for Married MB 10.4.75.
9.4.3.6.3 Companion SPB Single Purpose Requirement 10.4.76.
9.4.3.6.3(5) Constrained OMB Processing Capability 10.4.81.
9.4.3.6.4 Restriction of Playback in Absence of Integrity Pack Metadata 6.1.15.
9.4.3.6.4 Restriction of Keying to MDEK Type (OBAE) 6.1.16.
9.4.3.6.4 OBAE Integrity Checking 6.1.17.
9.4.3.6.4 KDM Content Keys Check 8.2.14.
9.4.3.6.4 MB Tasks 10.4.58.
9.4.3.6.4 Constrained OMB Processing Capability 10.4.81.
9.4.3.6.4 Encrypted Auxiliary Data Processing 10.4.83. 9.4.3.6.5 KDM TDL Check 6.1.11.
9.4.3.6.5 Companion SPB Retrieve Imaging Device Cert 10.4.74.
9.4.3.6.6 KDM TDL Check 6.1.11.
9.4.3.6.6 Systems without Electronic Marriage 7.2.7.
9.4.3.6.6 Systems Without Electronic Marriage 10.4.21.
9.4.3.7 Clock Adjustment 6.3.1.
9.4.3.7 SPB Type 1 Clock Battery 6.3.2.
9.4.3.7 Clock Resolution 6.3.3.
9.4.3.7 Clock Resolution (OMB) 6.3.4.
9.4.3.7 Clock Adjustment (OMB) 6.3.5.
9.4.3.7 Clock Date-Time-Range 10.4.22.
9.4.3.7 Clock Setup 10.4.23.
9.4.3.7 Clock Stability 10.4.24.
9.4.3.7 Clock Continuity 10.4.27.
9.4.3.7 SPB Type 1 Battery Life 10.4.73.
9.4.5 Constrained OMB Processing Capability 10.4.81. 9.4.5.1 Secure SMS-SM Communication 10.4.5. 9.4.5.1 TLS Endpoints 10.4.28. 9.4.5.2.3 RRP Synchronism 10.4.32. 9.4.5.2.3 TLS Mode Bypass Prohibition 10.4.33. 9.4.5.2.3 Implementation of Proprietary ITMs 10.4.35. 9.4.5.2.3 RRP "Busy" and Unsupported Types 10.4.39. 9.4.5.2.3.(9) Secure SMS-SM Communication 10.4.5. 9.4.5.2.3.(9) RRP Operational Messages 10.4.40. 9.4.5.2.4 RRP Operational Messages 10.4.40. 9.4.5.2.4 TLS RSA Requirement 10.4.79. 9.4.5.3.2 TLS Authentication of Dual Certificate SM 10.4.80. 9.4.6.1.1 FM Payload 6.4.3.
9.4.6.1.1 FM Payload (OBAE) 6.4.8.
9.4.6.1.1 FM Algorithm General Requirements 10.4.42.
9.4.6.1.1 FM Insertion Requirements 10.4.43.
9.4.6.1.2 IFM Visual Transparency 10.4.44.
9.4.6.1.2 IFM Robustness 10.4.45.
9.4.6.1.3 AFM Inaudibility 10.4.46.
9.4.6.1.3 AFM Robustness 10.4.47.
9.4.6.1.3 OBAE FM Robustness 10.4.85.
9.4.6.1.3 OBAE FM Inaudibility 10.4.86.
9.4.6.2 FM Application Constraints 6.4.1.
9.4.6.2 Granularity of FM Control 6.4.2.
9.4.6.2 FM Audio Bypass 6.4.4.
9.4.6.2 Selective Audio FM Control 6.4.5.
9.4.6.2 FM Application Constraints (OBAE) 6.4.6.
9.4.6.2 Granularity of FM Control (OBAE) 6.4.7.
9.4.6.2 FM Audio Bypass (OBAE) 6.4.9.
9.4.6.2 FM Control Instance 10.4.48.
9.4.6.2(9) FM Insertion Requirements 10.4.43.
9.4.6.3.1 Log Sequence Numbers 5.3.2.3.
9.4.6.3.1 Log Report Signature Validity 5.3.2.6.
9.4.6.3.1 Log Sequence Numbers (OBAE) 5.3.2.7.
9.4.6.3.1 Log Report Signature Validity (OBAE) 5.3.2.8.
9.4.6.3.1 SPB Log Storage Requirements 10.4.51.
9.4.6.3.1 MB Log Storage Capabilities 10.4.53.
9.4.6.3.2 Log Structure 5.3.2.1.
9.4.6.3.3 Log Report Signature Validity 5.3.2.6.
9.4.6.3.3 Log Report Signature Validity (OBAE) 5.3.2.8.
9.4.6.3.4 Log Sequence Numbers 5.3.2.3.
9.4.6.3.4 Log Sequence Numbers (OBAE) 5.3.2.7.
9.4.6.3.7 Log Report Signature Validity 5.3.2.6.
9.4.6.3.7 Log Report Signature Validity (OBAE) 5.3.2.8.
9.4.6.3.7 FrameSequencePlayed Event 5.4.1.1.
9.4.6.3.7 CPLStart Event 5.4.1.2.
9.4.6.3.7 CPLEnd Event 5.4.1.3.
9.4.6.3.7 PlayoutComplete Event 5.4.1.4.
9.4.6.3.7 CPLCheck Event 5.4.1.5.
9.4.6.3.7 KDMKeysReceived Event 5.4.1.6.
9.4.6.3.7 KDMDeleted Event 5.4.1.7.
9.4.6.3.7 FrameSequencePlayed Event (OBAE) 5.4.1.8.
9.4.6.3.7 CPLStart Event (OBAE) 5.4.1.9.
9.4.6.3.7 CPLEnd Event (OBAE) 5.4.1.10.
9.4.6.3.7 PlayoutComplete Event (OBAE) 5.4.1.11.
9.4.6.3.7 CPLCheck Event (OBAE) 5.4.1.12.
9.4.6.3.7 KDMKeysReceived Event (OBAE) 5.4.1.13.
9.4.6.3.7 KDMDeleted Event (OBAE) 5.4.1.14.
9.4.6.3.7 SPBStartup and SPBShutdown Events 5.4.2.6.
9.4.6.3.7 SPBOpen and SPBClose Events 5.4.2.7.
9.4.6.3.7 SPBClockAdjust Event 5.4.2.8.
9.4.6.3.7 SPBMarriage and SPBDivorce Events 5.4.2.9.
9.4.6.3.7 SPBSoftware Event 5.4.2.10.
9.4.6.3.7 SPBSecurityAlert Event 5.4.2.11.
9.4.6.3.7 Logging of Failed Procedures 10.4.55. 9.4.6.3.8 KDM Malformations 3.5.8.
9.4.6.3.8 KDM Malformations (OBAE) 3.5.15.
9.4.6.3.8 FrameSequencePlayed Event 5.4.1.1.
9.4.6.3.8 CPLStart Event 5.4.1.2.
9.4.6.3.8 CPLEnd Event 5.4.1.3.
9.4.6.3.8 PlayoutComplete Event 5.4.1.4.
9.4.6.3.8 CPLCheck Event 5.4.1.5.
9.4.6.3.8 KDMKeysReceived Event 5.4.1.6.
9.4.6.3.8 KDMDeleted Event 5.4.1.7.
9.4.6.3.8 FrameSequencePlayed Event (OBAE) 5.4.1.8.
9.4.6.3.8 CPLStart Event (OBAE) 5.4.1.9.
9.4.6.3.8 CPLEnd Event (OBAE) 5.4.1.10.
9.4.6.3.8 PlayoutComplete Event (OBAE) 5.4.1.11.
9.4.6.3.8 CPLCheck Event (OBAE) 5.4.1.12.
9.4.6.3.8 KDMKeysReceived Event (OBAE) 5.4.1.13.
9.4.6.3.8 KDMDeleted Event (OBAE) 5.4.1.14.
9.4.6.3.8 SPBStartup and SPBShutdown Events 5.4.2.6.
9.4.6.3.8 SPBOpen and SPBClose Events 5.4.2.7.
9.4.6.3.8 SPBClockAdjust Event 5.4.2.8.
9.4.6.3.8 SPBMarriage and SPBDivorce Events 5.4.2.9.
9.4.6.3.8 SPBSoftware Event 5.4.2.10.
9.4.6.3.8 SPBSecurityAlert Event 5.4.2.11.
9.4.6.3.8 SPBSecurityAlert Event 5.4.2.11.
9.4.6.3.8 FM Application Constraints (OBAE) 6.4.6.
9.4.6.3.8 Granularity of FM Control (OBAE) 6.4.7.
9.4.6.3.8 Logging of Failed Procedures 10.4.55. 9.4.6.3.8 Imaging Device SPB Log Reporting Requirements 10.4.78.
9.4.6.3.10 Logging of Failed Procedures 10.4.55. 9.4.6.3.10 SPB Log Failure 10.4.56.
9.4.6.3.10 Log Purging in Failed SPBs 10.4.57.
9.4.6.3.10 SPB Type 1 Log Retention 10.4.69.
9.5.1 Basic Certificate Structure 2.1.1.
9.5.1 SignatureAlgorithm Fields 2.1.2.
9.5.1 SignatureValue Field 2.1.3.
9.5.1 SerialNumber Field 2.1.4.
9.5.1 SubjectPublicKeyInfo Field 2.1.5.
9.5.1 Validity Field 2.1.7.
9.5.1 AuthorityKeyIdentifier Field 2.1.8.
9.5.1 KeyUsage Field 2.1.9.
9.5.1 Basic Constraints Field 2.1.10.
9.5.1 Public Key Thumbprint 2.1.11.
9.5.1 Organization Name Field 2.1.12.
9.5.1 Entity Name and Roles Field 2.1.14.
9.5.1 Unrecognized Extensions 2.1.15.
9.5.1 Signature Validation 2.1.16.
9.5.1 Certificate Chains 2.1.17.
9.5.1 ASN.1 DER Encoding Check 2.2.1.
9.5.1 Missing Required Fields 2.2.2.
9.5.1 PathLen Check 2.2.3.
9.5.1 OrganizationName Match Check 2.2.4.
9.5.1 Certificate Role Check 2.2.5.
9.5.1 Validity Date Check 2.2.6.
9.5.1 Signature Algorithm Check 2.2.7.
9.5.1 Public Key Type Check 2.2.8.
9.5.1 Issuer Certificate Presence Check 2.2.9.
9.5.1 SPB Digital Certificate 5.1.1.
9.5.1 Validity of SPB Certificates 6.1.20.
9.5.1 SMS Identity and Certificate 8.2.11.
9.5.1 Validity of SMS Certificates 8.2.15.
9.5.1 Type 1 SPB RSA Private Keys 10.4.59.
9.5.1 Content Keys Outside Secure Silicon 10.4.60.
9.5.1 TLS Authentication of Dual Certificate SM 10.4.80.
9.5.1.1 KeyUsage Field 2.1.9.
9.5.1.1 SPB Digital Certificate 5.1.1.
9.5.1.1 Log Report Signature Validity 5.3.2.6.
9.5.1.1 Log Report Signature Validity (OBAE) 5.3.2.8.
9.5.1.1 Systems Without Electronic Marriage 10.4.21.
9.5.1.2 KeyUsage Field 2.1.9.
9.5.1.2 SPB Digital Certificate 5.1.1.
9.5.1.2 Log Report Signature Validity 5.3.2.6.
9.5.1.2 Log Report Signature Validity (OBAE) 5.3.2.8.
9.5.1.2 Companion SPB Marriage Break Key Retaining 7.3.3.
9.5.1.2 Systems Without Electronic Marriage 10.4.21.
9.5.1.2 TLS Authentication of Dual Certificate SM 10.4.80.
9.5.1.3 SPB Digital Certificate 5.1.1.
9.5.1.3 Plurality of Media Block Identity Certificates 6.1.19.
9.5.2.2 Projector and Direct View Display Physical Protection 7.2.1.
9.5.2.2 SPB Type 1 Tamper Responsiveness 9.5.3.
9.5.2.2 Type 1 SPB RSA Private Keys 10.4.59.
9.5.2.2 Content Keys Outside Secure Silicon 10.4.60.
9.5.2.2 Use of Software Protection Methods 10.4.62.
9.5.2.2 SPB Secure Silicon Requirements 10.4.72.
9.5.2.3 SPB2 Secure Silicon Field Replacement 7.2.6.
9.5.2.3 Repair and Renewal of SPBs 10.4.25.
9.5.2.3 Prohibition of SPB Type 1 Field Serviceability 10.4.61.
9.5.2.4 Projector and Direct View Display Physical Protection 7.2.1.
9.5.2.4 Projector and Direct View Display Security Servicing 7.2.2.
9.5.2.4 SPB2 Protected Devices 10.4.26.
9.5.2.4.1 Projector and Direct View Display Physical Protection 7.2.1.
9.5.2.4.1 Projector and Direct View Display Security Servicing 7.2.2.
9.5.2.5 SM Operating Environment 9.5.1.
9.5.2.5 SPB Type 1 Tamper Responsiveness 9.5.3.
9.5.2.5 SPB Type 1 FIPS Requirements 9.5.6.
9.5.2.5 Asymmetric Key Generation 9.5.8.
9.5.2.5 Critical Security Parameter Protection 9.5.9.
9.5.2.5 TMS Role 10.4.63.
9.5.2.5.1 Degraded mode(s) of operation prohibited 9.5.11.
9.5.2.5.1 Control output inhibition 9.5.12.
9.5.2.5.1 Maintenance role/interface prohibited 9.5.13.
9.5.2.5.1 Self-initiated cryptographic output capability 9.5.14.
9.5.2.5.1 Self-initiated cryptographic output capability 9.5.15.
9.5.2.5.1 Periodic self-tests 9.5.16.
9.5.2.6 SPB Type 1 Tamper Responsiveness 9.5.3.
9.5.2.6 Critical Security Parameter Protection 9.5.9.
9.5.2.6 D-Cinema Security Parameter Protection 10.4.64.
9.5.2.7 SM Operating Environment 9.5.1.
9.5.2.7 SPB Type 1 Firmware Modifications 10.4.68.
9.6.1 Location of Security Manager 10.4.6.
9.6.1.2 Location of Security Manager 10.4.6.
9.7.2 Timed Text Decryption 6.7.6.
9.7.4 Content Keys Outside Secure Silicon 10.4.60.
9.7.5 Composition Playlist Signature Validation 4.3.2.
9.7.5 DCP Integrity 4.6.1.
9.7.6 Asymmetric Key Generation 9.5.8.
9.7.6 RSA Key Entropy 10.4.65.
9.7.6 Preloaded Symmetric Key Entropy 10.4.66.
9.7.7 Composition Playlist File 4.3.1.
9.7.7 Maximum Number of DCP Keys 6.1.12.
9.7.7 Maximum Number of DCP Keys (OBAE) 6.1.21.
9.7.7 MD Media Block Caching of Keys 10.4.67.
9.8 Basic Certificate Structure 2.1.1.
9.8 SignatureAlgorithm Fields 2.1.2.
9.8 SignatureValue Field 2.1.3.
9.8 SerialNumber Field 2.1.4.
9.8 SubjectPublicKeyInfo Field 2.1.5.
9.8 Validity Field 2.1.7.
9.8 AuthorityKeyIdentifier Field 2.1.8.
9.8 KeyUsage Field 2.1.9.
9.8 Basic Constraints Field 2.1.10.
9.8 Public Key Thumbprint 2.1.11.
9.8 Organization Name Field 2.1.12.
9.8 OrganizationUnitName Field 2.1.13.
9.8 Entity Name and Roles Field 2.1.14.
9.8 Unrecognized Extensions 2.1.15.
9.8 Signature Validation 2.1.16.
9.8 Certificate Chains 2.1.17.
9.8 ASN.1 DER Encoding Check 2.2.1.
9.8 Missing Required Fields 2.2.2.
9.8 PathLen Check 2.2.3.
9.8 OrganizationName Match Check 2.2.4.
9.8 Certificate Role Check 2.2.5.
9.8 Validity Date Check 2.2.6.
9.8 Signature Algorithm Check 2.2.7.
9.8 Public Key Type Check 2.2.8.
9.8 Issuer Certificate Presence Check 2.2.9.
9.8 ETM Structure 3.3.1.
9.8 ETM Validity Date Check 3.3.2.
9.8 ETM Signer Element 3.3.3.
9.8 ETM EncryptionMethod Element 3.3.4.
9.8 KDM MessageType Element 3.4.1.
9.8 KDM SubjectName Element 3.4.2.
9.8 KDM ContentAuthenticator Element 3.4.3.
9.8 KDM KeyIdList/TypedKeyId Field 3.4.5.
9.8 KDM EncryptedData Element 3.4.7.
9.8 KDM KeyInfo Element 3.4.8.
9.8 KDM DeviceListDescription Element 3.4.9.
9.8 KDM CompositionPlaylistId Element 3.4.13.
9.8 KDM Validity Fields 3.4.14.
9.8 KDM KeyIdList Element 3.4.15.
9.8 KDM CipherData Structure ID 3.4.16.
9.8 KDM CipherData Signer Thumbprint 3.4.17.
9.8 KDM CipherData Validity 3.4.18.
9.8 KDM CipherData CPL ID 3.4.19.
9.8 KDM NonCriticalExtensions Element 3.5.1.
9.8 ETM IssueDate Field Check 3.5.2.
9.8 Structure ID Check 3.5.4.
9.8 Certificate Thumbprint Check 3.5.5.
9.8 KeyInfo Field Check 3.5.7.
9.8 KDM Malformations 3.5.8.
9.8 KDM Signature 3.5.9.
9.8 KDM NonCriticalExtensions Element (OBAE) 3.5.10.
9.8 ETM IssueDate Field Check (OBAE) 3.5.11.
9.8 Structure ID Check (OBAE) 3.5.12.
9.8 Certificate Thumbprint Check (OBAE) 3.5.13.
9.8 KeyInfo Field Check (OBAE) 3.5.14.
9.8 KDM Malformations (OBAE) 3.5.15.
9.8 KDM Signature (OBAE) 3.5.16.
9.8 KDM Date Check 6.1.10.
9.8 KDM TDL Check 6.1.11.
9.8 CPL Id Check 6.1.13.
9.8 CPL Id Check (OBAE) 6.1.14.
9.8 KDM Date Check (OBAE) 6.1.24.
10.2.2 Stereoscopic Image Frame Rates 7.5.34.

Appendix H. Abbreviations 🔗

AD
Auxiliary Data
AES
Audio Engineering Society
AES
Advanced Encryption Standard
CMVP
Cryptographic Module Validation Program
CPL
Composition PlayList
DCI
Digital Cinema Initiatives, LLC
DCDM
Digital Cinema Distribution Master
DCP
Digital Cinema Package
DCSS
Digital Cinema System Specification
DSM
Digital Source Master
ETM
Extra Theater Message
FM
Forensic Marking
FMID
Forensic Marking Identification
FPGA
Field-Programmable Gate Array
GUI
Graphical User Interface
IMB
Image Media Block
IMBO
Image Media Block with OMB Functions
ISO
International Organization for Standards
IETF
Internet Engineering Task Force
J2K
JPEG2000
KDM
Key Delivery Message
LCD
Liquid Crystal Display
LD
Link Decryptor
LDB
Link Decryptor Block
LE
Link Encryptor
MB
Media Block
MD
Media Decryptor
NIST
National Institute of Science and Technology
NPRC
Non-Programmable Related Components
OBAE
Object Based Audio Essence
OMB
Outboard Media Block
POSIX
Portable Operating System Interface
RAID
Redundant Array of Independent Disks (formerly: Redundant Array of Inexpensive Disks)
SM
Security Manager
SMS
Screen Managemnt System
SPB
Secure Processing Block
SPL
Show Play List
SMPTE
Society of Motion Picture and Television Engineers
StEM
Standard Evaluation Material
TCP/IP
Transmission Control Protocol/Internet Protocol
TDL
Trusted Device List
TLS
Transport Layer Security, also known as Secure Socket Layer (SSL)
TMS
Theater Management System
UMID
Unique Material Identifier
USB
Universal Serial Bus
UUID
Universally Unique Identifier
WTF
Wild Track Format (numbered audio channels)
XML
eXtensible Markup Language

Appendix I. Subtitle Test Evaluation and Pass/Fail Criteria 🔗

I.1. Overview 🔗

The following describes evaluation requirements, basic and specific pass/fail criteria to be used when testing the subtitle rendering capabilities of the Test Subject, as called for in 6.7.1. Media Block Overlay .

It is expected that the Test Operator shall, by referencing both the CPL and the referenced subtitle track file XML, confirm that all elements expected to appear on (or off) screen for each scene, do so with all intended characteristics. This includes, but is not limited to, positioning, alignment, font size, color, script, effect, effect color, italic, underline, bold, aspect adjust and spacing, whether specified directly, default values, or inherited from ancestor values or defaults.

The colorimetric relationship between the PNG image and the image contained in the DCDM* is, at the time of publication of this document, under study. Unexpected appearance of saturation, hue, luminance and bit-depth of PNG images should be noted in the test results and brought to the attention of the manufacturer pending further work to quantify this relationship. At this time, the Test Subject shall not be subject to failing this test on such characteristics.

The behavior of the Direction attribute of the Text element and/or the Unicode Bidirectional Algorithm is, at the time of publication of this document, under study. Scenes that utilize these features should be noted in the test results and brought to the attention of the manufacturer pending further work to quantify this relationship. At this time, the Test Subject shall not be subject to failing this test on such characteristics

I.2. Basic Pass/Fail Criteria 🔗

This section describes general pass/fail criteria to be applied to all scenes unless Specific Criteria directs otherwise.

Main Picture Image Track Files - Labels : The image track files referenced by the compositions have a burned-in label in a small text font, centered horizontally and close to the bottom of the main picture. The label is comprised of the image structure of the sequence being viewed (2K, 4K, or 2K-48fps), the aspect ratio, and the name of the scene. The name of the scene may be used to locate specific pass/fail requirements for a particular scene, and descriptive notes to the test operator, providing additional context.

Bounding Boxes : White bounding boxes, with a one pixel size, are burned into the image track files to confirm correct positioning of the rendered timed text. Some slides, mainly those that announce upcoming scenes, present timed text that do not have bounding boxes. When bounding boxes are displayed, the associated text is intended to fall completely within the boxes. Differences in implementations can produce significant differences in the vertical positioning of text, depending on whether the renderer uses the baseline of the text characters, or the edges of the rendered characters for positioning. Exceeding the bounding boxes shall not be cause to fail the test.

Composition Main Picture and Alpha Channel Timing : The appearance of a particular label on the main picture, is intended to be accompanied by that scene's rendered text, and/or PNG images, as determined by the provided FadeUpTime and FadeDownTime Text and/or Image element parameters, or their default value of 2 frames if none are specified. For example, for the beginning title slide, "2K-scope-title", the image track file will display the label for 240 frames (10 seconds). The FadeUpTime and FadeDownTime parameters are not specified for the accompanying timed text, so for the 1st frame that displays the image label no timed text should be visible, the 2nd frame should have the timed text at 50% opacity of the rendered intent (the element's final opacity is specified by a parameter of the Font element), and frames 3 until 238 inclusive should have the timed text at 100% opacity of the rendered intent. Frame 239 should be identical to frame 2, and frame 240 should have no visible timed text. Except where specified, if the timing of the rendered text and/or PNG images differs by more than plus or minus 3 frames from that commanded by the Subtitle DCDM and the controlling CPL, this is cause to fail the test.

Some of the slides that test PNG images have FadeUpTime and FadeDownTime values of zero, so it is not expected, or correct behavior, for the corresponding image track labels to be visible with these slides.

I.3. Specific Pass/Fail Criteria 🔗

This section lists pass/fail criteria specific to each scene in the composition. The identifier for each scene is constructed by prepending the image structure and aspect-ratio for the variant under test to the scene title. E.g. "2K-scope-title" or "2K-48fpsflat-title" as applicable. For each of the scenes, refer to the text below the identifier. Descriptions of scene specific elements may be described more fully. Scene specific pass/fail requirements are presented as bullet lists.

Scene 1: <2K|4K[-48fps]-scope|flat|full>-title
The evaluation of the first scene, and all subsequent scenes, must be determined from the display of a normal, single, continuous playback of the composition. To clarify, the composition must be selected, or loaded into a show playlist, and caused to play without using functions such as "pause" or "rewind", which may cause buffering, or other system behaviors that may have an effect of the ability of the system to display subtitles with the correct timing relationship to the other essence tracks.
  • The rendered subtitle text must appear on screen within 3 seconds of the appearance of the label in the main picture. If this requirement is not observed, this is cause to fail this test.
Scene 2: <2K|4K[-48fps]-scope|flat|full>-out-of-bounds-character-codes
  • In the top bounding box, the appearance of any character, space, partial character, or partial space, other than the words "Digital", and "Cinema", with no spaces between them, is cause to fail this test.
  • In the middle bounding box, the appearance of any character, or partial character, is cause to fail this test.
  • In the lower bounding box, the appearance of any character, space, partial character, or partial space, other than the letters "ABCDEF", with no spaces between them, is cause to fail this test.
Scene 3: <2K|4K[-48fps]-scope|flat|full>-control-codes
  • In the top bounding box, the appearance of any character, space, partial character, or partial space, other than the words "Digital", and "Cinema", with no spaces between them, is cause to fail this test.
  • In the middle bounding box, the appearance of any character, or partial character, is cause to fail this test.
  • • In the lower bounding box, the appearance of any character, space, partial character, or partial space, other than the letters "ABCDEF", with no spaces between them, is cause to fail this test.
Scene 4: <2K|4K[-48fps]-scope|flat|full>-4-byte-UTF-8-characters
Record whether the Test Subject displays any rendered subtitles during this slide. Note: Failure to display four domino shapes is not cause to fail this test.
  • If glyphs other than four domino shapes are displayed, this is cause to fail this test.
Scene 5: <2K|4K[-48fps]-scope|flat|full>-default-font-size-attribute
  • If all the "M"s are not the same size, this is cause to fail this test.
Scene 6: <2K|4K[-48fps]-scope|flat|full>-font-effects-1
The text in this slide is intended to be red in color. The presence of the shadow and/or border, can cause the red to be perceived differently.
  • If the size of the rendered characters does not vary in accordance with the labeled point values, this is cause to fail this test.
  • If the body of all text is not substantially red, this is cause to fail this test.
  • If any border or shadow effect is visible on any text labeled "No-shadow", this is cause to fail this test.
  • If a green shadow effect is not visible on all text labeled "Green-Shadow", this is cause to fail this test.
  • If any effect, other than a green shadow, is visible on any text labeled "Green-Shadow", this is cause to fail this test.
  • If a white border effect is not visible on all text labeled "White-Border", this is cause to fail this test
  • If any effect, other than a white border, is visible on any text labeled "White-Border", this is cause to fail this test.
Scene 7: <2K|4K[-48fps]-scope|flat|full>-font-sub-super-script-1
  • If the baseline of any of the words "Normal" is not on the same level vertically, this is cause to fail this test.
  • If the baseline of the word "Super" is not above that of the words "Normal", this is cause to fail this test
  • If the baseline of the word "Sub" is not below that of the words "Normal", this is cause to fail this test.
  • If the size of the words "Super" and "Sub" is not 0.6em compared with the 1.0em size of the words "Normal", inform the manufacturer that the Test Subject may not be fully compliant with newer Standards, but do not fail the device on this criterion.
  • If the baseline of the words "Super" and "Sub" is not offset by a minimum of 0.3em, and a maximum of 0.7em, of the baseline of the 1.0em size of the words "Normal", inform the manufacturer that the Test Subject may not be fully compliant with newer Standards, but do not fail the device on this criterion.
Scene 8: <2K|4K[-48fps]-scope|flat|full>-font-sub-super-script-2
The scene contains two subtitle instances indicated by their respective bounding boxes, one above the other, designated "upper" and "lower" accordingly.
  • If the baseline of both the words "Normal" on each of the two instances is not on the same level vertically, inform the manufacturer that the Test Subject may not be fully compliant with newer Standards, but do not fail the device on this criterion.
  • If the baseline of both the words "Super" is not above that of the words "Normal" on the upper instance, inform the manufacturer that the Test Subject may not be fully compliant with newer Standards, but do not fail the device on this criterion
  • If the baseline of both the words "Sub" is not below that of the words "Normal" on the lower instance, inform the manufacturer that the Test Subject may not be fully compliant with newer Standards, but do not fail the device on this criterion
  • If the baseline of the both the words "Super", or both the words "Sub", are not on the same level vertically, inform the manufacturer that the Test Subject may not be fully compliant with newer Standards, but do not fail the device on this criterion
  • If the size of the both the words "Super", or both the words "Sub", are not the same, inform the manufacturer that the Test Subject may not be fully compliant with newer Standards, but do not fail the device on this criterion
Scene 9: <2K|4K[-48fps]-scope|flat|full>-font-sub-super-script-3
The scene contains two subtitle instances indicated by their respective bounding boxes, one above the other, designated "upper" and "lower" accordingly.
  • For the upper instance, if the baselines of both the words "Super" are not on the same level, and above that of the word "Normal", inform the manufacturer that the Test Subject may not be fully compliant with newer Standards, but do not fail the device on this criterion
  • for the lower instance, if the baselines of both the words "Sub" are not on the same level, and below that of the word "Normal", inform the manufacturer that the Test Subject may not be fully compliant with newer Standards, but do not fail the device on this criterion
Scene 10: <2K|4K[-48fps]-scope|flat|full>-font-italic-weight-bold-1
  • If the text on any of the lines with the bounding boxes is not yellow, this is cause to fail this test.
  • If the text in each of the three lines with the bounding boxes does not have font effects corresponding to the labels, this is cause to fail this test.
Scene 11: <2K|4K[-48fps]-scope|flat|full>-font-color-effectcolor-opacity-1
  • If the opacity of the text in the left column does not vary according to the labels, this is cause to fail this test.
  • If the opacity of the border effect around the text in the right column does not vary according to the labels, record the result.
Scene 12: <2K|4K[-48fps]-scope|flat|full>-position-screen-center-announce
  • If rendered text, describing the following scene, is not displayed, this is cause to fail this test.
Scene 13: <2K|4K[-48fps]-scope|flat|full>-position-screen-center
  • If the text is not near the center of the screen, this is cause to fail this test.
Scene 14: <2K|4K[-48fps]-scope|flat|full>-position-screen-4-edges-announce
  • If rendered text, describing the following scene, is not displayed, this is cause to fail this test.
Scene 15: <2K|4K[-48fps]-scope|flat|full>-position-screen-4-edges
  • If any of the labeled rendered texts are in an incorrect location, this is cause to fail this test.
Scene 16: <2K|4K[-48fps]-scope|flat|full>-position-screen-4-corners-announce
  • If rendered text, describing the following scene, is not displayed, this is cause to fail this test.
Scene 17: <2K|4K[-48fps]-scope|flat|full>-position-screen-4-corners-1
With the publication of ST 428-7:2014, the behavior of the alignment of rendered Text elements has changed. In the 2010 revision, the top, center, or bottom of the subtitle instance bounding box is aligned to the primary picture according to the Valign attribute. The 2014 revision aligns the baseline of the rendered text to the primary picture according to the Valign attribute.
  • If any of the labeled rendered texts are in an incorrect location, this is cause to fail this test.
  • If the Test Subject implements the 2014 Standard, only the descenders of the "Top-Left" and "Top-Right" labels are expected to appear on screen. If this is the case, do not fail the device on this criterion. However, if rendered text is visible outside the limits of the primary picture, this is cause to fail this test.
  • If the Test Subject implements the 2014 Standard, the descenders of the "Bottom-Left" and "Bottom-Right" labels are expected to not appear on screen. If this is the case, do not fail the device on this criterion. However, if rendered text is visible outside the limits of the primary picture, this is cause to fail this test.
Scene 18: <2K|4K[-48fps]-scope|flat|full>-position-screen-4-corners-2
With the publication of ST 428-7:2014, the behavior of the alignment of rendered Text elements has changed. In the 2010 revision, the top, center, or bottom of the subtitle instance bounding box is aligned to the primary picture according to the Valign attribute. The 2014 revision aligns the baseline of the rendered text to the primary picture according to the Valign attribute.
  • If any of the labeled rendered texts are in an incorrect location, this is cause to fail this test.
Scene 19: <2K|4K[-48fps]-scope|flat|full>-position-text-off-screen-1
  • Except for the scene identifier, and the sentence inside the bounding box, the presence of any other text, partial text, or rendered artifacts is cause to fail this test with the exception of the case noted in the following item.
  • The display of some of the edge-most pixels from a single off-screen character at the edge of the screen is acceptable due to implicit variation in absolute font character placement. If any pixels are displayed from an off-screen text character, record the result.
Scene 20: <2K|4K[-48fps]-scope|flat|full>-position-text-off-screen-2
  • Except for the scene identifier, and the sentence inside the bounding box, the presence of any other text, partial text, or rendered artifacts is cause to fail this test.
Scene 21: <2K|4K[-48fps]-scope|flat|full>-font-aspect-adjust-tests
  • If either of the two shapes that have a horizontal bar across them are not circles, this is cause to fail this test.
  • If the shapes to the left of the circle with the bar in the top row do not appear as progressively narrower ellipses (the further away they are) this is cause to fail this test.
  • If the shapes to the right of the circle with the bar in the top row do not appear as progressively wider ellipses (the further away they are) this is cause to fail this test.
  • If the spaces between the shapes appear inconsistent with the increasing width of the shapes, this is cause to fail this test.
Scene 22: <2K|4K[-48fps]-scope|flat|full>-space-element-tests
  • If the pairs of "M"s are not farthest apart at the top, progressively becoming closer going down, and closest together at the bottom, this is cause to fail this test.
Scene 23: <2K|4K[-48fps]-scope|flat|full>-428-7-ruby-example-1
  • If 3 CJK characters are not displayed with 6 CJK characters above them, this is cause to fail this test
Scene 24: <2K|4K[-48fps]-scope|flat|full>-428-7-ruby-example-2
  • If 11 large CJK characters are not displayed, this is cause to fail this test
  • If 2 small CJK characters are not displayed below the first 2 large CJK characters, this is cause to fail this test
  • If 6 small CJK characters are not displayed below the fourth, fifth, and sixth large CJK characters, this is cause to fail this test
Scene 25: <2K|4K[-48fps]-scope|flat|full>-428-7-ruby-example-3
  • If the horizontal text "1963" does not appear at the top, this is cause to fail this test
  • If there are not 9 CJK characters, vertically rendered below the "1963", this is cause to fail this test.
Scene 26: <2K|4K[-48fps]-scope|flat|full>-ruby-test-1
  • If smaller annotation text reading "World Wide Web" is not displayed close to, and centered above, the larger base text "WWW", this is cause to fail this test.
Scene 27: <2K|4K[-48fps]-scope|flat|full>-ruby-test-2
  • If smaller annotation text reading "Month Day Year" is not displayed close to, and centered above, the larger base text "10 31 2002", this is cause to fail this test.
Scene 28: <2K|4K[-48fps]-scope|flat|full>-ruby-test-3
  • If smaller annotation text reading "Expiration Date" is not displayed close to, and centered below, the larger base text "10 31 2002", this is cause to fail this test.
Scene 29: <2K|4K[-48fps]-scope|flat|full>-ruby-test-4
  • If smaller annotation text reading "W3C Associate Chairman" is not displayed close to, and centered below, 4 larger CJK characters, this is cause to fail this test.
Scene 30: <2K|4K[-48fps]-scope|flat|full>-ruby-test-5
  • If smaller, vertical annotation text reading "Shinkansen" from top to bottom, is not displayed close to, and centered on the left, and right sides of 3 larger vertical CJK characters, this is cause to fail this test.
Scene 31: <2K|4K[-48fps]-scope|flat|full>-ruby-aspectadjust-test
  • If any of the shapes are not as described, or missing, this is cause to fail this test.
Scene 32: <2K|4K[-48fps]-scope|flat|full>-ruby-offset-test
The pair of labels with the text 'Offset="-1"' are not expected to be exactly aligned and may vary according to the implementation. The objective of the test is to show that an offset value of -1 causes the pair to be closer than a bigger number.
  • If the size of both labels in all the pairs is not equal, this is cause to fail this test.
  • If the vertical offset between the four pairs of rendered text labels is not greatest on the left and least on the right, this is cause to fail this test.
  • If the vertical offset between the pair of labels 'Default Offset (0)' and 'Offset="0"' is not equal, this is cause to fail this test. Note: The parentheses descend below the baseline of the remainder of the characters, which can cause the text to be further apart in this instance.
Scene 33: <2K|4K[-48fps]-scope|flat|full>-ruby-spacing-test
The pair of circles with the label 'Spacing="-1"' are not expected to be exactly aligned and may vary according to the implementation. The objective of the test is to show that an offset value of -1 causes the pair to be closer than a bigger number.
  • If the horizontal spacing between the four pairs of same colored circles is not greatest on the left and least on the right, this is cause to fail this test.
  • If the horizontal spacing between the pair of green circles and the pair of blue circles is not equal, this is cause to fail this test.
Scene 34: <2K|4K[-48fps]-scope|flat|full>-ruby-cumulative-spacing-test
  • If the spacing between the circles in each colored set is not equal, this is cause to fail this test.
Scene 35: <2K|4K[-48fps]-scope|flat|full>-image-main-picture-equivalency
  • If the size of the two apples is not equal, this is cause to fail this test.
  • Differences in saturation, hue, luminance and bit-depth between the two images should be noted in the test results, and brought to the attention of the manufacturer. At this time, the Test Subject shall not be subject to failing this test because of such differences.
Scene 36: <2K|4K[-48fps]-scope|flat|full>-image-positioning
Three PNG images, with associated descriptive text, will fade in, then fade out, in sequence during this scene. Each image is an exact third, horizontally, of the scope aspect-ratio. Note that the images, as displayed in the flat aspect-ratio variant, will be slightly larger than one third of the screen width, and will not fill the screen vertically in both the flat, and full, aspect-ratio variants (the images will have their top edge aligned with the top edge of the main picture.
  • If the location of any image does not match the descriptive text, this is cause to fail this test.
  • If any image, or associated descriptive text does not appear when expected, this is cause to fail this test.
  • If any image, or associated descriptive text does not fade in, and fade out, when expected, this is cause to fail this test.
  • If the size of any image does not meet the description above, this is cause to fail this test.
Scene 37: <2K|4K[-48fps]-scope|flat|full>-image-to-image-transition-test-1-announce
  • If rendered text, describing the following scene, is not displayed, this is cause to fail this test.
Scene 38: <2K|4K[-48fps]-scope|flat|full>-image-to-image-transition-test-1
A single PNG image will fill the entire screen horizontally for the first half of this scene. For the second half of the scene, the single image will be replaced by two half horizontal screen images, positioned as to be equivalent to their locations on the single image. All FadeDownTime and FadeUpTime elements are set to 00:00:00:00 which will result in a seamless transition between the subtitle instances.
  • If the image displayed on the screen flickers, or any part of the image is not displayed, record the result.
Scene 39: <2K|4K[-48fps]-scope|flat|full>-image-image-text-transparency-test-1-announce
  • If rendered text, describing the following scene, is not displayed, this is cause to fail this test.
  • For 4K test material, some renderers may be unable to display images without flickering, lagging or may display images incompletely. If the renderer displays image anomalies with 4K test material, record the result.
Scene 40: <2K|4K[-48fps]-scope|flat|full>-image-image-text-transparency-test-1
This scene will display a PNG image of a seascape overlaid with a PNG image of a square yellow frame with a transparent background. Inside the yellow frame will be the rendered text "Digital Cinema", in purple.
  • If the seascape, square frame, or rendered text is missing, this is cause to fail this test.
  • If the seascape is not visible through both the square frame and the rendered text, this is cause to fail this test.
  • For 4K test material, some renderers may be unable to display images without flickering, lagging or may display images incompletely. If the renderer displays image anomalies with 4K test material, record the result.
Scene 41: <2K|4K[-48fps]-scope|flat|full>-image-image-image-transparency-test-1-announce
  • If rendered text, describing the following scene, is not displayed, this is cause to fail this test.
  • For 4K test material, some renderers may be unable to display images without flickering, lagging or may display images incompletely. If the renderer displays image anomalies with 4K test material, record the result.
Scene 42: <2K|4K[-48fps]-scope|flat|full>-image-image-image-transparency-test-1
This scene will display a PNG image of a seascape overlaid with a PNG image of a square yellow frame with a transparent background. Inside the yellow frame is overlaid a PNG image of a smaller, rectangular purple frame and the text "Digital Cinema", in purple, and a transparent background.
  • If the seascape, square frame, smaller rectangular frame, or PNG text are missing, this is cause to fail this test.
  • If the seascape is not visible through both the square frame, the rectangular frame, and the text, this is cause to fail this test.
  • For 4K test material, some renderers may be unable to display images without flickering, lagging or may display images incompletely. If the renderer displays image anomalies with 4K test material, record the result.
Scene 43: <2K|4K[-48fps]-scope|flat|full>-image-image-text-transparency-test-2-announce
  • If rendered text, describing the following scene, is not displayed, this is cause to fail this test.
  • For 4K test material, some renderers may be unable to display images without flickering, lagging or may display images incompletely. If the renderer displays image anomalies with 4K test material, record the result.
Scene 44: <2K|4K[-48fps]-scope|flat|full>-image-image-text-transparency-test-2
This scene will display a PNG image of a seascape overlaid with rendered text. Overlaid over the text, is a PNG image of a rose that has a transparent background. The rose will completely cover the rendered text.
  • If the seascape, or the rose, are missing, this is cause to fail this test.
  • If the seascape is not visible up to the edges of the rose, this is cause to fail this test.
  • If any text is visible, other than the scene label in the flat and full variants, this is cause to fail this test.
  • For 4K test material, some renderers may be unable to display images without flickering, lagging or may display images incompletely. If the renderer displays image anomalies with 4K test material, record the result.
Scene 45: <2K|4K[-48fps]-scope|flat|full>-image-transparency-test-1
This scene will display a green background in the main picture. Overlaid in the center, is a PNG image of a house that has transparent windows.
  • If a house is not displayed in the center of the green background, this is cause to fail this test.
  • If the green background is not visible through the windows of the house, this is cause to fail this test.
  • For 4K test material, some renderers may be unable to display images without flickering, lagging or may display images incompletely. If the renderer displays image anomalies with 4K test material, record the result.
Scene 46: <2K|4K[-48fps]-scope|flat|full>-multi-image-multi-text-test-announce
  • If rendered text, describing the following scene, is not displayed, this is cause to fail this test.
  • For 4K test material, some renderers may be unable to display images without flickering, lagging or may display images incompletely. If the renderer displays image anomalies with 4K test material, record the result.
Scene 47: <2K|4K[-48fps]-scope|flat|full>-multi-image-multi-text-test
In the first half of this scene, PNG images of a house and rose, each with descriptive text overlaid, will fade in. Halfway through the scene, PNG images of an apple and a lamp, each with descriptive text, will fade in, for a total of four PNG images and four descriptive text overlays.
  • If the PNG images of the house and rose, with their respective text overlays, do not appear during the first half of the scene, and do not remain on screen after their appearance, for the remainder of the scene, this is cause to fail this test.
  • If the PNG images of the apple and lamp, with their respective text overlays, do not appear on screen during the second half of the scene, this is cause to fail this test.
  • Per the provisions of section 6.1.6 in SMPTE ST 428-7:2014 , in cases where two subtitle instances have overlapping time windows, the values of FadeUpTime and FadeDownTime elements, or their defaults, may be considered to be equal to zero. If any of the fades specified in the XML are rendered as if they were zero, this shall not be cause to fail this test.
  • For 4K test material, some renderers may be unable to display images without flickering, lagging or may display images incompletely. If the renderer displays image anomalies with 4K test material, record the result.
Scene 48: <2K|4K[-48fps]-scope|flat|full>-image-rose-flicker-test-announce
  • If rendered text, describing the following scene, is not displayed, this is cause to fail this test.
  • For 4K test material, some renderers may be unable to display images without flickering, lagging or may display images incompletely. If the renderer displays image anomalies with 4K test material, record the result.
Scene 49: <2K|4K[-48fps]-scope|flat|full>-image-rose-flicker-test
  • If a rose does not appear near the center of the screen, this is cause to fail this test.
  • If the rose flickers, disappears, or exhibits any other dynamic visual artifacts, this is cause to fail this test.
  • For 4K test material, some renderers may be unable to display images without flickering, lagging or may display images incompletely. If the renderer displays image anomalies with 4K test material, record the result.
Scene 50: <2K|4K[-48fps]-scope|flat|full>-text-flicker-test
  • If text inside the bounding box does not appear on the screen, this is cause to fail this test.
  • If the text flickers, disappears, or exhibits any other dynamic visual artifacts, this is cause to fail this test.
Scene 51: <2K|4K[-48fps]-scope|flat|full>-text-direction-test-1
This scene is for informational data only. Describe the appearance of the rendered text elements displayed on the screen.
Scene 52: <2K|4K[-48fps]-scope|flat|full>-text-direction-test-2
This scene is for informational data only. Describe the appearance of the rendered text elements displayed on the screen.
Scene 53: <2K|4K[-48fps]-scope|flat|full>-text-direction-test-3
This scene is for informational data only. Describe the appearance of the rendered text elements displayed on the screen.
Scene 54: <2K|4K[-48fps]-scope|flat|full>-text-valign-direction-test-1
This scene is for informational data only. Describe the appearance of the rendered text elements displayed on the screen.
Scene 55: <2K|4K[-48fps]-scope|flat|full>-end-title
  • If the rendered text does not appear on the screen, this is cause to fail this test.

Appendix J. OBAE Test Evaluation Requirements 🔗

J.1. Overview 🔗

This appendix specifies requirements and expected acoustic outcome from the rendering of OBAE Rendering Expectations by an OBAE Sound System .

J.2. Configuration 🔗

The OBAE Sound System shall be configured as an Ideal Environment , as specified at [SMPTE-2098-3] .

J.3. Requirements 🔗

The test material consists of a sequence of scenes, identified in the top right corner of the image, as illustrated at Figure J.1 .

The expectations for each scene are described using a combination of text and images, as illustrated at Figure J.1 .

Sounds heard during each scene shall conform to the expectations specified for the scene by the corresponding table in J.4. Expectations .

There shall be no sounds heard other than those specified at J.4. Expectations .

Expectations that refer to a specific loudpspeaker, e.g. "Left Speaker", shall be skipped if the OBAE Sound System is not equipped with that loudpspeaker.

Loudspeakers are defined at [SMPTE-428-12] and [SMPTE-2098-5] .

All sounds heard shall be free of artifacts, e.g. "zipper" noise, discontinuities, clicks.

Test pattern with an area labeled with the letter A and another labeled with the letter B
  • A. Text identifying the scene.
  • B. Text and imagery indicating rendering expectations.
Figure J.1 . Visual contents of the OBAE Rendering Expectations test material 🔗

J.4. Expectations 🔗

Table J.4.1 . Sync Test 🔗
Text on screen Expectations
BEEP! A sound is heard
Table J.4.2 . Simple Bed Channel Routing (5.1) 🔗
Text on screen Expectations
You should hear SPEAKING on 'Left' The word "left" is heard from the Left speaker
You should hear PINK on 'Left' Pink noise is heard from the Left speaker
You should hear SPEAKING on 'Right' The word "right" is heard from the Right speaker
You should hear PINK on 'Right' Pink noise is heard from the Right speaker
You should hear SPEAKING on 'Center' The word "center" is heard from the Center speaker
You should hear PINK on 'Center' Pink noise is heard from the Center speaker
You should hear SPEAKING on 'LFE' Sound is heard from the LFE speaker
You should hear PINK on 'LFE' Pink noise is heard from the LFE speaker
You should hear SPEAKING on 'Left Surround' The word "left surround" is heard from the Left Surround speaker
You should hear PINK on 'Left Surround' Pink noise is heard from the Left Surround speaker
You should hear SPEAKING on 'Right Surround' The word "right surround" is heard from the Right Surround speaker
You should hear PINK on 'Right Surround' Pink noise is heard from the Right Surround speaker
Table J.4.3 . Simple Bed Channel Routing (7.1DS) 🔗
Text on screen Expectations
You should hear SPEAKING on 'Left' The word "left" is heard from the Left speaker
You should hear PINK on 'Left' Pink noise is heard from the Left speaker
You should hear SPEAKING on 'Right' The word "right" is heard from the Right speaker
You should hear PINK on 'Right' Pink noise is heard from the Right speaker
You should hear SPEAKING on 'Center' The word "center" is heard from the Center speaker
You should hear PINK on 'Center' Pink noise is heard from the Center speaker
You should hear SPEAKING on 'LFE' Sound is heard from the LFE speaker
You should hear PINK on 'LFE' Pink noise is heard from the LFE speaker
You should hear SPEAKING on 'Left Side Surround' The word "left side surround" is heard from the Left Side Surround speaker
You should hear PINK on 'Left Side Surround' Pink noise is heard from the Left Side Surround speaker
You should hear SPEAKING on 'Right Side Surround' The word "right side surround" is heard from the Right Side Surround speaker
You should hear PINK on 'Right Side Surround' Pink noise is heard from the Right Side Surround speaker
You should hear SPEAKING on 'Left Rear Surround' The word "left rear surround" is heard from the Left Rear Surround speaker
You should hear PINK on 'Left Rear Surround' Pink noise is heard from the Left Rear Surround speaker
You should hear SPEAKING on 'Right Rear Surround' The word "right rear surround" is heard from the Right Rear Surround speaker
You should hear PINK on 'Right Rear Surround' Pink noise is heard from the Right Rear Surround speaker
Table J.4.4 . Simple Bed Channel Routing (9.1OH) 🔗
Text on screen Expectations
You should hear SPEAKING on 'Left' The word "left" is heard from the Left speaker
You should hear PINK on 'Left' Pink noise is heard from the Left speaker
You should hear SPEAKING on 'Right' The word "right" is heard from the Right speaker
You should hear PINK on 'Right' Pink noise is heard from the Right speaker
You should hear SPEAKING on 'Center' The word "center" is heard from the Center speaker
You should hear PINK on 'Center' Pink noise is heard from the Center speaker
You should hear SPEAKING on 'LFE' Sound is heard from the LFE speaker
You should hear PINK on 'LFE' Sound is heard from the LFE speaker
You should hear SPEAKING on 'Left Side Surround' The word "left side surround" is heard from the Left Side Surround speaker
You should hear PINK on 'Left Side Surround' Pink noise is heard from the Left Side Surround speaker
You should hear SPEAKING on 'Right Side Surround' The word "right side surround" is heard from the Right Side Surround speaker
You should hear PINK on 'Right Side Surround' Pink noise is heard from the Right Side Surround speaker
You should hear SPEAKING on 'Left Rear Surround' The word "left rear surround" is heard from the Left Rear Surround speaker
You should hear PINK on 'Left Rear Surround' Pink noise is heard from the Left Rear Surround speaker
You should hear SPEAKING on 'Right Rear Surround' The word "right rear surround" is heard from the Right Rear Surround speaker
You should hear PINK on 'Right Rear Surround' Pink noise is heard from the Right Rear Surround speaker
You should hear SPEAKING on 'Left Top Surround' The word "left top surround" is heard from the Left Top Surround speaker
You should hear PINK on 'Left Top Surround' Pink noise is heard from the Left Top Surround speaker
You should hear SPEAKING on 'Right Top Surround' The word "right top surround" is heard from the Right Top Surround speaker
You should hear PINK on 'Right Top Surround' Pink noise is heard from the Right Top Surround speaker
Table J.4.5 . '91OH' Bed - Gain Test 🔗
Text on screen Expectations
You should hear pink-noise
GainPrefix = ONE 		Pink noise is heard. The noise maintains consistent timbre, loudness, and size.
You should hear Silence
GainPrefix = zero 		No sound is heard.
You should hear the volume changing
GainPrefix = CUSTOM
gain=X.XX 		Pink noise is heard. For three times in a row, the loudness of the pink noise monotically increases from silence, and then monotically decrease back to silence. The loudness scales with the value of gain . The noise maintains consistent timbre and size.
Table J.4.6 . '91OH' Bed - Decorrelation Test 🔗
Text on screen Expectations
You should hear pink noise
ChannelDecorCoefPrefix = NONE 		Pink noise is heard.
You should hear pink noise
ChannelDecorCoefPrefix = MAX 		Pink noise is heard.
You should hear pink noise
ChannelDecorCoefPrefix = CUSTOM XX% 		Pink noise is heard. The noise maintains consistent loudness.
Table J.4.7 . Pink Noise 13.1HT Bed with 3 Spoken Conditional Beds 🔗
Text on screen Expectations
You should not hear pink noise
The 13.1HT pink noise is superseded by one of the 5.1, 7.1DS, 9.1OH beds 		No sound is heard.
Table J.4.8 . Bed Remap Test (Source: 13.1HT Bed, Dest: 5.1, 7.1DS, 11.1HT, 9.1OH) 🔗
Text on screen Expectations
You should only hear pink noise on Center (NOT from Left) Pink noise is heard from the Center speaker only
You should only hear pink noise on Right (NOT from Center) Pink noise is heard from the Right speaker only
You should only hear pink noise on Left (NOT from Right) Pink noise is heard from the Left speaker only
You should only hear pink noise on Center (NOT from Left Side Surround) Pink noise is heard from the Center speaker only
You should only hear pink noise on Left (NOT from Right Side Surround) Pink noise is heard from the Left speaker only
You should only hear pink noise on Center (NOT from Left Rear Surround) Pink noise is heard from the Center speaker only
You should only hear pink noise on Left (NOT from Right Rear Surround) Pink noise is heard from the Left speaker only
You should only hear pink noise on Right (NOT from LFE) Pink noise is heard from the Right speaker only
You should only hear pink noise on Center (NOT from Left Height) Pink noise is heard from the Center speaker only
You should only hear pink noise on Right (NOT from Center Height) Pink noise is heard from the Right speaker only
You should only hear pink noise on Left (NOT from Right Height) Pink noise is heard from the Left speaker only
You should only hear pink noise on Center (NOT from Left Surround Height) Pink noise is heard from the Center speaker only
You should only hear pink noise on Left (NOT from Right Surround Height) Pink noise is heard from the Left speaker only
You should only hear pink noise on Right (NOT from Top Surround) Pink noise is heard from the Right speaker only
The noise maintains consistent timbre and loudness in each test.
Table J.4.9 . Mixing of Two Simultaneous Beds 🔗
Text on screen Expectations
You should hear: SPEAKING on 'Left' The word "left" is heard from the Left speaker
You should hear: PINK on 'Left' Pink noise is heard from the Left speaker
You should hear: SPEAKING on 'Left Center' The word "left center" is heard from the Left Center speaker
You should hear: PINK on 'Left Center' Pink noise is heard from the Left Center speaker
You should hear: SPEAKING on 'Center' The word "center" is heard from the Center speaker
You should hear: PINK on 'Center' Pink noise is heard from the Center speaker
You should hear: SPEAKING on 'Right Center' The word "right center" is heard from the Right Center speaker
You should hear: PINK on 'Right Center' Pink noise is heard from the Right Center speaker
You should hear: SPEAKING on 'Right' The word "right" is heard from the Right speaker
You should hear: PINK on 'Right' Pink noise is heard from the Right speaker
You should hear: SPEAKING on 'Left Side Surround' The word "left side surround" is heard from the Left Side Surround speaker
You should hear: PINK on 'Left Side Surround' Pink noise is heard from the Left Side Surround speaker
You should hear: SPEAKING on 'Left Surround' The word "left surround" is heard from the Left Surround speaker
You should hear: PINK on 'Left Surround' Pink noise is heard from the Left Surround speaker
You should hear: SPEAKING on 'Left Rear Surround' The word "left rear surround" is heard from the Left Rear Surround speaker
You should hear: PINK on 'Left Rear Surround' Pink noise is heard from the Left Rear Surround speaker
You should hear: SPEAKING on 'Right Rear Surround' The word "right rear surround" is heard from the Right Rear Surround speaker
You should hear: PINK on 'Right Rear Surround' Pink noise is heard from the Right Rear Surround speaker
You should hear: SPEAKING on 'Right Side Surround' The word "right side surround" is heard from the Right Side Surround speaker
You should hear: PINK on 'Right Side Surround' Pink noise is heard from the Right Side Surround speaker
You should hear: SPEAKING on 'Right Surround' The word "right surround" is heard from the Right Surround speaker
You should hear: PINK on 'Right Surround' Pink noise is heard from the Right Surround speaker
You should hear: SPEAKING on 'Left Top Surround' The word "left top surround" is heard from the Left Top Surround speaker
You should hear: PINK on 'Left Top Surround' Pink noise is heard from the Left Top Surround speaker
You should hear: SPEAKING on 'Right Top Surround' The word "right top surround" is heard from the Right Top Surround speaker
You should hear: PINK on 'Right Top Surround' Pink noise is heard from the Right Top Surround speaker
You should hear: SPEAKING on 'LFE' Sound is heard from the LFE speaker
You should hear: PINK on 'LFE' Sound is heard from the LFE speaker
You should hear: SPEAKING on 'Left Height' The word "left height" is heard from the Left Height speaker
You should hear: PINK on 'Left Height' Pink noise is heard from the Left Height speaker
You should hear: SPEAKING on 'Right Height' The word "right height" is heard from the Right Height speaker
You should hear: PINK on 'Right Height' Pink noise is heard from the Right Height speaker
You should hear: SPEAKING on 'Center Height' The word "center height" is heard from the Center Height speaker
You should hear: PINK on 'Center Height' Pink noise is heard from the Center Height speaker
You should hear: SPEAKING on 'Left Surround Height' The word "left surround height" is heard from the Left Surround Height speaker
You should hear: PINK on 'Left Surround Height' Pink noise is heard from the Left Surround Height speaker
You should hear: SPEAKING on 'Right Surround Height' The word "right surround height" is heard from the Right Surround Height speaker
You should hear: PINK on 'Right Surround Height' Pink noise is heard from the Right Surround Height speaker
You should hear: SPEAKING on 'Left Side Surround Height' The word "left side surround height" is heard from the Left Side Surround Height speaker
You should hear: PINK on 'Left Side Surround Height' Pink noise is heard from the Left Side Surround Height speaker
You should hear: SPEAKING on 'Right Side Surround Height' The word "right side surround height" is heard from the Right Side Surround Height speaker
You should hear: PINK on 'Right Side Surround Height' Pink noise is heard from the Right Side Surround Height speaker
You should hear: SPEAKING on 'Left Rear Surround Height' The word "left rear surround height" is heard from the Left Rear Surround Height speaker
You should hear: PINK on 'Left Rear Surround Height' Pink noise is heard from the Left Rear Surround Height speaker
You should hear: SPEAKING on 'Right Rear Surround Height' The word "right rear surround height" is heard from the Right Rear Surround Height speaker
You should hear: PINK on 'Right Rear Surround Height' Pink noise is heard from the Right Rear Surround Height speaker
You should hear: SPEAKING on 'Top Surround' The word "top surround" is heard from the Top Surround speaker
You should hear: PINK on 'Top Surround' Pink noise is heard from the Top Surround speaker
Table J.4.10 . Object Gain Test 🔗
Text on screen Expectations
You should hear pink noise
GainPrefix = ONE 		Pink noise is heard. The noise maintains consistent timbre, location, size and loudness.
You should hear silence
GainPrefix = ZERO 		No sound is heard.
You should hear the volume changing
GainPrefix = CUSTOME (X.XX) 		Pink noise is heard. Three times in a row, the loudness of the pink noise monotically increases from silence, and then monotically decrease back to silence. The loudness scales with the value of GainPrefix . The noise maintains consistent timbre and size.
Table J.4.11 . Object Snap Test 🔗
Text on screen Expectations
Snap off
Angle: XXX° 		A point source emitting pink noise is heard, making four revolutions clockwise around the room. The motion of the point source is continuous.
Snap On
Angle: XXX° 		A point source emitting pink noise is heard, making four revolutions clockwise around the room. Sound is heard from only one loudspeaker at any given time.
SnapTolerance
Angle: XXX° 		A point source emitting pink noise is heard, making four revolutions clockwise around the room. Sound may be heard from one or more loudspeakers at any given time.
The noise maintains consistent timbre, loudness, and size in each test.
Table J.4.12 . Object Zone Gain Test (using ZERO/ONE gain flags) 🔗
Text on screen Expectations
Angle: XXX°
You should hear pink noise ONLY in the SCREEN LEFT zone 		Pink noise is heard only from screen loudspeakers left of center.
Angle: XXX°
You should hear pink noise ONLY in the SCREEN CENTER zone 		Pink noise is heard only from screen center loudspeakers.
Angle: XXX°
You should hear pink noise ONLY in the SCREEN RIGHT zone 		Pink noise is heard only from screen loudspeakers right of center.
Angle: XXX°
You should hear pink noise ONLY in the WALL LEFT zone 		Pink noise is heard only from loudspeakers on left wall.
Angle: XXX°
You should hear pink noise ONLY in the WALL RIGHT zone 		Pink noise is heard only from loudspeakers on right wall.
Angle: XXX°
You should hear pink noise ONLY in the REAR LEFT zone 		Pink noise is heard only from loudspeakers on left half of rear wall.
Angle: XXX°
You should hear pink noise ONLY in the REAR RIGHT zone 		Pink noise is heard only from loudspeakers on right half of rear wall.
Angle: XXX°
You should hear pink noise ONLY in the OVERHEAD LEFT zone 		Pink noise is heard only from overhead loudspeakers left of center.
Angle: XXX°
You should hear pink noise ONLY in the OVERHEAD RIGHT zone 		Pink noise is heard only from overhead loudspeakers right of center.
The noise maintains consistent timbre, loudness, and size in each test.
Table J.4.13 . Object Zone Gain Test (using decimal gain) 🔗
Text on screen Expectations
Angle: XXX°
You should hear pink noise ONLY in the SCREEN LEFT zone 		Pink noise is heard only from screen loudspeakers left of center.
Angle: XXX°
You should hear pink noise ONLY in the SCREEN CENTER zone 		Pink noise is heard only from screen center loudspeakers.
Angle: XXX°
You should hear pink noise ONLY in the SCREEN RIGHT zone 		Pink noise is heard only from screen loudspeakers right of center.
Angle: XXX°
You should hear pink noise ONLY in the WALL LEFT zone 		Pink noise is heard only from loudspeakers on left wall.
Angle: XXX°
You should hear pink noise ONLY in the WALL RIGHT zone 		Pink noise is heard only from loudspeakers on right wall.
Angle: XXX°
You should hear pink noise ONLY in the REAR LEFT zone 		Pink noise is heard only from loudspeakers on left half of rear wall.
Angle: XXX°
You should hear pink noise ONLY in the REAR RIGHT zone 		Pink noise is heard only from loudspeakers on right half of rear wall.
Angle: XXX°
You should hear pink noise ONLY in the OVERHEAD LEFT zone 		Pink noise is heard only from overhead loudspeakers left of center.
Angle: XXX°
You should hear pink noise ONLY in the OVERHEAD RIGHT zone 		Pink noise is heard only from overhead loudspeakers right of center.
The noise maintains consistent timbre, loudness, and size in each test.
Table J.4.14 . Object Spread Test 🔗
Text on screen Expectations
Location: Overhead
Spread Mode: Low-Rez
Spread Value: X.XX 		Pink noise is heard centered overhead. The perceived extent of the sound source may flucuates with the Spread Value .
Location: Overhead
Spread Mode: One-D
Spread Value: X.XX 		Pink noise is heard centered overhead. The perceived extent of the sound source may flucuates with the Spread Value .
Location: Overhead
Spread Mode: Three-D
Spread Value: x=X.XX, y=X.XX, z=X.XX 		Pink noise is heard centered on the screen. The perceived extent of the sound source may flucuates with the Spread Value .
Location: Screen
Spread Mode: Low-Rez
Spread Value: X.XX 		Pink noise is heard centered on the screen. The perceived extent of the sound source may flucuates with the Spread Value .
Location: Screen
Spread Mode: One-D
Spread Value: X.XX 		Pink noise is heard centered on the screen. The perceived extent of the sound source may flucuates with the Spread Value .
Location: Screen
Spread Mode: Three-D
Spread Value: x=X.XX, y=X.XX, z=X.XX 		Pink noise is heard centered on the screen. The perceived extent of the sound source may flucuates with the Spread Value .
The noise maintains consistent loudness in each test.
Table J.4.15 . Object - Decorrelation Test 🔗
Text on screen Expectations
You should hear pink noise
ObjectDecorCoefPrefix = NONE
Location: Screen 		Pink noise is heard, centered on the screen.
You should hear pink noise
ObjectDecorCoefPrefix = MAX
Location: Screen 		Pink noise is heard, centered on the screen.
You should hear pink noise
ObjectDecorCoefPrefix = CUSTOM (XX%)
Location: Screen 		Pink noise is heard, centered on the screen.
You should hear pink noise
ObjectDecorCoefPrefix = NONE
Location: Rear 		Pink noise is heard, centered on the rear wall.
You should hear pink noise
ObjectDecorCoefPrefix = MAX
Location: Rear 		Pink noise is heard, centered on the rear wall.
You should hear pink noise
ObjectDecorCoefPrefix = CUSTOM (XX%)
Location: Rear 		Pink noise is heard, centered on the rear wall.
You should hear pink noise
ObjectDecorCoefPrefix = NONE
Location: Left 		Pink noise is heard, centered on the left wall.
You should hear pink noise
ObjectDecorCoefPrefix = MAX
Location: Left 		Pink noise is heard, centered on the left wall.
You should hear pink noise
ObjectDecorCoefPrefix = CUSTOM (XX%)
Location: Left 		Pink noise is heard, centered on the left wall.
You should hear pink noise
ObjectDecorCoefPrefix = NONE
Location: Right 		Pink noise is heard, centered on the right wall.
You should hear pink noise
ObjectDecorCoefPrefix = MAX
Location: Right 		Pink noise is heard, centered on the right wall.
You should hear pink noise
ObjectDecorCoefPrefix = CUSTOM (XX%)
Location: Right 		Pink noise is heard, centered on the right wall.
The noise maintains consistent loudness in each test.
Table J.4.16 . Multiple Objects (3) combined with Snap/Spread Test 🔗
Text on screen Expectations
You should hear a 3 note chord (one note per object)
Spread On 		A sound is heard, centered on the screen.
You should hear a 3 note chord (one note per object)
Snap Off, Spread Off 		A sound is heard, centered on the screen.
You should hear a 3 note chord (one note per object)
Snap On 		A sound is heard, centered on the screen.
You should hear a 3 note chord (one note per object)
SnapTolerance 		A sound is heard, centered on the screen.
Table J.4.17 . Pan Sub-Block Test #2 🔗
Text on screen Expectations
Sub-blocks: XXXXXX
RPM: XX
Angle: XXXXXXXX 		Pink noise is heard, moving clockwise around the room. The noise maintains consistent loudness, timbre and size.
Table J.4.18 . 10 Simultaneous Objects, No Bed 🔗
Text on screen Expectations
You should hear no drop-outs
Active Object: XX 		Pink noise is heard. The noise maintains consistent loudness and timbre. The location of the noise may shift but remains primarily on the screen.
Table J.4.19 . 15 Simultaneous Objects, No Bed 🔗
Text on screen Expectations
You should hear no drop-outs
Active Object: XX 		Pink noise is heard. The noise maintains consistent loudness and timbre. The location of the noise may shift but remains primarily on the screen.
Table J.4.20 . 18 Simultaneous Objects, No Bed 🔗
Text on screen Expectations
You should hear no drop-outs
Active Object: XX 		Pink noise is heard. The noise maintains consistent loudness and timbre. The location of the noise may shift but remains primarily on the screen.
Table J.4.21 . 30 Simultaneous Objects, No Bed 🔗
Text on screen Expectations
You should hear no drop-outs
Active Object: XX 		Pink noise is heard. The noise maintains consistent loudness and timbre. The location of the noise may shift but remains primarily on the screen.
Table J.4.22 . 50 Simultaneous Objects, No Bed 🔗
Text on screen Expectations
You should hear no drop-outs
Active Object: XX 		Pink noise is heard. The noise maintains consistent loudness and timbre. The location of the noise may shift but remains primarily on the screen.
Table J.4.23 . 128 Simultaneous Objects, No Bed 🔗
Text on screen Expectations
You should hear no drop-outs
Active Object: XX 		Pink noise is heard. The noise maintains consistent loudness and timbre. The location of the noise may shift but should remain primarily on the screen.
Table J.4.24 . 10 Simultaneous Objects, Quiet 9.1OH Bed 🔗
Text on screen Expectations
You should hear no drop-outs
Active Object: XX 		Pink noise is heard. The noise maintains consistent loudness and timbre. The location of the noise may shift but should remain primarily on the screen.
Table J.4.25 . 15 Simultaneous Objects, Quiet 9.1OH Bed 🔗
Text on screen Expectations
You should hear no drop-outs
Active Object: XX 		Pink noise is heard. The noise maintains consistent loudness and timbre. The location of the noise may shift but should remain primarily on the screen.
Table J.4.26 . 18 Simultaneous Objects, Quiet 9.1OH Bed 🔗
Text on screen Expectations
You should hear no drop-outs
Active Object: XX 		Pink noise is heard. The noise maintains consistent loudness and timbre. The location of the noise may shift but should remain primarily on the screen.
Table J.4.27 . 30 Simultaneous Objects, Quiet 9.1OH Bed 🔗
Text on screen Expectations
You should hear no drop-outs
Active Object: XX 		Pink noise is heard. The noise maintains consistent loudness and timbre. The location of the noise may shift but should remain primarily on the screen.
Table J.4.28 . 50 Simultaneous Objects, Quiet 9.1OH Bed 🔗
Text on screen Expectations
You should hear no drop-outs
Active Object: XX 		Pink noise is heard. The noise maintains consistent loudness and timbre. The location of the noise may shift but should remain primarily on the screen.
Table J.4.29 . 118 Simultaneous Objects, Quiet 9.1OH Bed 🔗
Text on screen Expectations
You should hear no drop-outs
Active Object: XX 		Pink noise is heard. The noise maintains consistent loudness and timbre. The location of the noise may shift but should remain primarily on the screen.
Table J.4.30 . Authoring Tool Info Test 🔗
Text on screen Expectations
You should hear a 5.1 pink-noise bed
Note: authoring info located at the Beginning of the iaFrame ChildElements 		Pink noise is heard. The noise maintains consistent loudness, timbre and size.
Table J.4.31 . Authoring Tool Info Test 🔗
Text on screen Expectations
You should hear a 5.1 pink-noise bed
Note: authoring info located at the End of the iaFrame ChildElements 		Pink noise is heard. The noise maintains consistent loudness, timbre and size.
Table J.4.32 . Unknown Element Test 🔗
Text on screen Expectations
You should hear a 5.1 pink-noise bed
Unknown element located at the beginning of the IAFrame 		Pink noise is heard. The noise maintains consistent loudness, timbre and size.
Table J.4.33 . Unknown Element Test 🔗
Text on screen Expectations
You should hear a 5.1 pink-noise bed
Unknown element located at the end of the IAFrame 		Pink noise is heard. The noise maintains consistent loudness, timbre and size.
Table J.4.34 . User Data Test 🔗
Text on screen Expectations
You should hear a 5.1 pink-noise bed
User Data located at the Beginning of the iaFrame ChildElements 		Pink noise is heard. The noise maintains consistent loudness, timbre and size.
Table J.4.35 . User Data Test 🔗
Text on screen Expectations
You should hear a 5.1 pink-noise bed
User Data located at the End of the iaFrame ChildElements 		Pink noise is heard. The noise maintains consistent loudness, timbre and size.
Table J.4.36 . Audio Description Test 🔗
Text on screen Expectations
You should hear a pink-noise bed
Audio Description: AMBIENCE, EFFECTS 		Pink noise is heard.
You should hear a pink-noise bed
Audio Description: DIALOG, FOLEY, MUSIC 		Pink noise is heard.
You should hear a pink-noise bed
Audio Description: AMBIENCE, DIALOG 		Pink noise is heard.
You should hear a pink-noise bed
Audio Description: MUSIC 		Pink noise is heard.
You should hear a pink-noise bed
Audio Description: AMBIENCE, DIALOG, EFFECTS 		Pink noise is heard.
You should hear a pink-noise bed
Audio Description: ADDITIONAL, DIALOG
Note: there is a custom Audio Description present 		Pink noise is heard.
The noise maintains consistent loudness, timbre and size in each test.

Appendix K. Summary of substantive changes 🔗

K.1. Overview 🔗

This appendix summarizes changes across releases of the CTP, which are listed in Table K.1 .

This appendix is informative and shall not be used to perform or interpret the contents of the CTP.

Table K.1 . CTP releases 🔗
Version Release date Summary of changes
1.0 Not applicable
1.1 K.2. Changes prior to CTP 1.2.1
1.2
1.2.1
1.3 K.3. Changes between CTP 1.2.1 and CTP 1.3
1.3.1 K.4. Changes between CTP 1.3 and CTP 1.3.1
1.3.2 K.5. Changes between CTP 1.3.1 and CTP 1.3.2
1.3.3 K.6. Changes between CTP 1.3.2 and CTP 1.3.3
1.4b K.7. Changes between CTP 1.3.3 and CTP 1.4b
This version K.8. Changes between CTP 1.4b and this version

K.2. Changes prior to CTP 1.2.1 🔗

Changes to CTP releases prior to CTP 1.2.1 are described in the collection of documents titled Revision To DCI Digital Cinema System Specification Compliance Test Plan at https://www.dcimovies.com/ .

K.3. Changes between CTP 1.2.1 and CTP 1.3 🔗

  1. Add Support for OBAE
    • Several procedures, and corresponding test materials, are added to cover OBAE requirements.
    • Test sequences (Chapters 20 to 23) are added to cover OMB and IMBO Test Subjects.
    • Appendix J is added to describe the expected acoustic outcome from rendering OBAE test materials.
  2. Remove Incorrect Conditions on Remote SPB tests. The condition that the test apply only to a Type 1 SPB device or module which implements features that allow it to supply keys or content to a remote SPB was removed from the following procedures:
    • 9.5.2. LE Key Generation
    • 10.4.31. Idempotency of ITM RRPs
    • 10.4.32. RRP Synchronism
    • 10.4.34. RRP Broadcast Prohibition
    • 10.4.36. RRP Initiator
    • 10.4.39. RRP "Busy" and Unsupported Types
    • 10.4.40. RRP Operational Messages
  3. Clarify that Procedures 10.4.13. TLS Session Key Refreshes applies to sessions with Remote SPBs
  4. Clarify Requirements and Test Subjects for 10.4.13. TLS Session Key Refreshes
  5. Clarify TLS version requirements. See procedures:
    • 10.4.5. Secure SMS-SM Communication
    • 10.4.8. Secure Remote SPB-SM Communications
    • 10.4.39. RRP 'Busy' and Unsupported Types
  6. Update Procedure 10.4.72 to reflect DCSS 1.4 Erratum 6
  7. Clarify objective of Procedure 6.1.15 per DCSS 1.4 Erratum 16
  8. Require that OBAE essence is rendered within the SPB at Procedure 10.4.58
  9. Delete Procedure 3.5.3 as duplicate of Procedure 6.1.12
  10. Add Procedure 5.4.1.7. KDMDeleted Event to Chapter 15 test sequence
  11. Specify process for retrieving Log Reports at Procedure 5.3.2.1
  12. Add subtitle essence to Media Block tasks at Procedure 10.4.58
  13. Add support for RES and MIC certificate roles to Procedure 5.1.1
  14. Add Procedure 6.1.19 to verify that the Media Block supports published and reserved certificate
  15. Add support for KDM-borne MIC keys. See procedures:
    • 6.1.1. Image Integrity Checking
    • 6.1.2. Sound Integrity Checking
    • 6.1.17. OBAE Integrity Checking
  16. Change the test subject of Procedure 8.2.14. to the SMS
  17. Apply revision to CTP 1.2.1 dated 24 March 2021. Chapter 9 requirements are revised to include FIPS 140-3 compliance.
  18. Clarify the semantics of the CPLStart and CPLEnd Log Record tokens. See procedures:
    • 5.3.2.6. Log Report Signature Validity
    • 5.4.1.2. CPLStart Event
    • 5.4.1.3. CPLEnd Event
    • 6.1.8. Content Key Extension, End of Engagement
    • 6.1.12. Maximum Number of DCP Keys
  19. Add missing Procedure 8.2.11 to test sequence Chapter 15

K.4. Changes between CTP 1.3 and CTP 1.3.1 🔗

  1. Fix incorrect pass/fail classification of Procedure 8.2.2
  2. Add missing procedures to Chapter 21 test sequenceSee procedures:
    • 8.1.6. Storage System Performance
    • 8.2.16. Interrupt Free Playback (OBAE)
    • 8.2.17. Restarting Playback (OBAE)
    • 8.2.18. Show Playlist Creation (OBAE)
  3. Add reference to SMPTE ST 430-12:2014 AM1:2019
  4. Replace references to OBAE Addendum with references to DCSS
  5. Add reference to SMPTE ST 430-1:2017 AM1:2019

K.5. Changes between CTP 1.3.1 and CTP 1.3.2 🔗

  1. Clarify Section 11.1 and add CTP version under test to Test Session Data (Table 11.1)
  2. Clarify Chapter 20 requirements

K.6. Changes between CTP 1.3.2 and CTP 1.3.3 🔗

  1. Deprecate selected Test Subjects. Support for the following Test Subjects and corresponding test sequences are removed:
    • Digital Cinema Server (Chapter 13)
    • Standalone D-Cinema Projector (Chapter 14)
    • Link Decryptor/Encryptor (Chapter 16)
  2. Clarify that each test sequence targets a single certificated device
  3. Removed support for Remote SPBs
  4. Allow SSD in addition to HDD for storage
  5. Use encrypted test material for Procedure 7.3.2
  6. Integrate "CTP Addendum on Testing" as Section 11.2
  7. Allow either 19 or 20 bits of location data in the FM payload
  8. Added test sequence (Chapter 24) for a Projector designed to work with an IMB or IMBO

K.7. Changes between CTP 1.3.3 and CTP 1.4b 🔗

  1. Add SDR Direct View, HDR Direct View and HDR Projector test subjects. Corresponding test sequences (Chapters 26 to 28) are added.
  2. Subject all Media Blocks to Procedure 6.7.1
  3. Specify tolerances for SDR Projector procedures and make them pass/fail
  4. Use a spectroradiometer instead of a photometer
  5. Add stereoscopic image procedures
  6. Use the term CMVP testing laboratory consistently
  7. Rename track file and change duration of Test Material A.2.293
  8. Rename track file and change duration of Test Material A.2.292
  9. Fix incorrect "SPEAKING" OBAE expectations
  10. Rename track file of Test Material A.2.251
  11. Rename track file of Test Material A.2.254
  12. Table 11.1: add Test Start Date
  13. Clarify the position of the spectroradiometer at Procedures 7.1.1 and 7.5.15
  14. Update test Procedures 7.5.12 and 7.5.26 to match revised RP 431-2
  15. Clarify ambient light requirements for imaging device environments

K.8. Changes between CTP 1.4b and this version 🔗

  1. Narrow the scope of Procedure 10.4.67 to Media Blocks
  2. Remove Procedure 10.4.3 Security Devices Self-Test Capabilities
  3. Remove Procedure 10.4.83 Encrypted Auxiliary Data Processing
  4. Delete Procedure 10.4.55 Logging of Failed Procedures
  5. Delete Procedure 10.4.17 Key Usage Time Window
  6. Remove ASM and LE tests and references
  7. Clarify the objective of Procedures 8.2.12 and 8.2.13
  8. Specify pass/fail criteria for 10.4.1 Theater System Reliability
  9. Remove ingest storage and network performance tests
  10. Add summary of changes Appendix K
  11. Fix test material filenames of Test Materials A.6.133 and A.6.134
  12. Delete unreferenced Test Materials A.3.65 and A.3.67
  13. Add valid KDM for DCI 2K Sync Test with KDM-Borne MIC Keys
  14. Add missing KDM for Audio Tone Multi-Reel (Encrypted)
  15. Fix Test Material numbering from A.6.135 to A.6.139
  16. Update the definition of Direct View Display to match that in the DCSS
  17. Remove unused test materials A.2.228, A.3.61 and A.3.69