Private Draft Document. Not for Publication

Interoperable Master Format (IMF) Specification

November 6, 2009 August 4, 2009 Version 0.542 DRAFT

AUDIO DRAFT FOR ESSENCE CHAPTER + GENERAL NOTES

Copyright  2009 by Entertainment Technology Center 509 West 29th Street Los Angeles, California 90007 United States of America 213-743-1600 www.etcenter.org

1 Private Draft Document. Not for Publication

2 Private Draft Document. Not for Publication

NOTICE

The Entertainment Technology Center (ETC) is the author and creator of this specification for the purpose of copyright and other laws in all countries throughout the world. The ETC copyright notice must be included in all reproductions, whether in whole or in part, and may not be deleted or attributed to others. ETC hereby grants to its members and their suppliers a limited license to reproduce this specification for their own use, provided it is not sold. Others should obtain permission to reproduce this specification from Entertainment Technology Center; Attn: CEO and Executive Director; 509 West 29th Street, Los Angeles, California 90007; USA; (213) 743-1600 (voice); (213) 743-1803 facsimile.

This document is a specification developed and adopted by ETC. This document may be revised by ETC. It is intended solely as a guide for companies interested in developing products, which can be compatible with other products, developed using this document. Each ETC Member Company shall decide independently the extent to which it will utilize, or require adherence to, these specifications. ETC 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.

This document is an authorized and approved publication of ETC. Only ETC has the right and authority to revise or change the material contained in this document, and any revisions by any party other than ETC are unauthorized and prohibited.

Compliance with this document may require 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 ETC with respect to the validity or infringement of any patent or other proprietary right. ETC hereby expressly disclaims any liability for infringement of intellectual property rights of others by virtue of the use of this document. ETC has not and does not investigate any notices or allegations of infringement prompted by publication of any ETC document, nor does ETC undertake a duty to advise users or potential users of ETC documents of such notices or allegations. ETC 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. ETC expressly disclaims any intent to promote infringement of any intellectual property right by virtue of the evolution, adoption, or publication of this document.

3 Private Draft Document. Not for Publication

Revision History

Date Revision Description Contributors 02/9/09 v0.1 Initial draft Howard Lukk 02/13/09 V0.2 1st Rev, Name Change, revise framework chapter Howard Lukk order and headings. Spell check and general clean up 3/13/09 V0.3 Chapter 10 change to Asset Management, Chapter 5 IMF Tech Committee, H. Lukk change to requirements instead of standard, Document clean up, Chapter 1 review and update, new Annex 6/16/09 V0.41 Update Chapter 1 along with formatting, Complete IMF Tech Committee, H. Lukk re-write of Chapter 2, re label chapters, re structure framework of document 8/4/09 V0.42 Update Figures, Add Table of Tables, Update IMF Tech Committee, H. Lukk Chapter 2., Remove “Clip” from document, Update Chapter 7 to reflect Chapter 2., Updated Glossary 11/6/09 V0.5 Update Chapter 2 and 7. Minor updates throughout IMF Tech Committee, H. Lukk document to remove Dynamic Downmixing and Audio Transitions. Inserted new Chapter 8 for Output Profile List

Reviewed By

Review Type Reviewed By Date Reviewed

Approval / Sign Off

Name Signature Date

4 Private Draft Document. Not for Publication Table of Contents

1. IMF INTRODUCTION...... 21

1.1. INTRODUCTION...... 21 1.1. INTRODUCTION...... 21

1.2. SCOPE...... 21 1.2. SCOPE...... 21

1.3. SYSTEM OBJECTIVES...... 21 1.3. SYSTEM OBJECTIVES...... 21

1.4. DOCUMENT LANGUAGE...... 22 1.4. DOCUMENT LANGUAGE...... 22

2. SYSTEM OVERVIEW...... 24

2.1. FUNCTIONAL FRAMEWORK ...... 24 2.1. FUNCTIONAL FRAMEWORK ...... 24

2.2. OVERVIEW...... 25 2.2. OVERVIEW...... 25 2.2.1. IMF System Architecture...... 25 2.2.1. IMF SYSTEM ARCHITECTURE...... 25 2.2.2. Major System Key Concepts...... 27 2.2.2. MAJOR SYSTEM KEY CONCEPTS...... 27 2.2.2.1. Business to Business Solution...... 27 2.2.2.1. Business to Business Solution...... 27 2.2.2.2. Digital Source Master (DSM)...... 27 2.2.2.2. Digital Source Master (DSM)...... 27 2.2.2.3. Archive not in Scope...... 28 2.2.2.3. Archive not in Scope...... 28 2.2.2.4. File / Frame-Based System...... 28 2.2.2.4. File / Frame-Based System...... 28 2.2.2.5. Essence and Data Essence...... 28 2.2.2.5. Essence and Data Essence...... 28 2.2.2.6. Metadata...... 28 2.2.2.6. Metadata...... 28 2.2.2.7. Security...... 28 2.2.2.7. Security...... 28 2.2.2.8. Wrapping and Track File Creation...... 28 2.2.2.8. Wrapping and Track File Creation...... 28 2.2.2.9. Composition...... 30 2.2.2.9. Composition...... 30 2.2.2.10. Versions...... 30 2.2.2.10. Versions...... 30 2.2.2.11. Sequence...... 30 2.2.2.11. Sequence...... 30 2.2.2.12. Output Profile List...... 32 2.2.2.12. Output Profile List...... 32 2.2.2.13. Packages...... 32 2.2.2.13. Packages...... 32 2.3. IMF ELEMENTS AND PROCESSES...... 34 2.3. IMF ELEMENTS AND PROCESSES...... 34

5 Private Draft Document. Not for Publication

3. ESSENCE...... 35

3.1. OVERVIEW...... 35 3.1. OVERVIEW...... 35 3.1.1. Introduction...... 35 3.1.1. INTRODUCTION...... 35 3.1.2. Essence System Overview...... 35 3.1.2. ESSENCE SYSTEM OVERVIEW...... 35 3.1.3. Major Essence Concepts...... 35 3.1.3. MAJOR ESSENCE CONCEPTS...... 35 3.1.4. Essence and Data Essence Fundamental Requirements...... 35 3.1.4. ESSENCE AND DATA ESSENCE FUNDAMENTAL REQUIREMENTS...... 35 3.1.4.1. Common File Formats...... 35 3.1.4.1. Common File Formats...... 35 3.1.4.2. Frame Rates...... 35 3.1.4.2. Frame Rates...... 35 3.1.4.3. Synchronization...... 35 3.1.4.3. Synchronization...... 35 3.2. IMAGE SPECIFICATION...... 36 3.2. IMAGE SPECIFICATION...... 36 3.2.1. Image Structure...... 36 3.2.1. IMAGE STRUCTURE...... 36 3.2.2. Compression Requirements...... 36 3.2.2. COMPRESSION REQUIREMENTS...... 36 3.2.2.1. Mezzanine Image Compression Requirements...... 36 3.2.2.1. Mezzanine Image Compression Requirements...... 36 3.2.3. Structural Metadata...... 36 3.2.3. STRUCTURAL METADATA...... 36 3.3. AUDIO SPECIFICATION...... 36 3.3. AUDIO SPECIFICATION...... 36 3.3.1. Audio Structure...... 36 3.3.1. AUDIO STRUCTURE...... 36 3.3.2. Structural Metadata...... 46 3.3.2. STRUCTURAL METADATA...... 46 4. DATA ESSENCE...... 47

4.1. OVERVIEW...... 47 4.1. OVERVIEW...... 47 4.1.1. Introduction...... 47 4.1.1. INTRODUCTION...... 47 4.1.2. Data Essence System Overview...... 47 4.1.2. DATA ESSENCE SYSTEM OVERVIEW...... 47 4.1.3. Major Data Essence Concepts...... 47 4.1.3. MAJOR DATA ESSENCE CONCEPTS...... 47 4.1.4. Data Essence Fundamental Requirements...... 47 4.1.4. DATA ESSENCE FUNDAMENTAL REQUIREMENTS...... 47 4.1.4.1. Common File Formats...... 47 4.1.4.1. Common File Formats...... 47 4.1.4.2. Frame Rates...... 47 4.1.4.2. Frame Rates...... 47 4.1.4.3. Synchronization...... 47 4.1.4.3. Synchronization...... 47 4.2. SUBTITLE SPECIFICATION...... 48 4.2. SUBTITLE SPECIFICATION...... 48

6 Private Draft Document. Not for Publication

4.2.1. Sub picture...... 48 4.2.1. SUB PICTURE...... 48 4.2.2. Timed Text...... 48 4.2.2. TIMED TEXT...... 48 4.3. CAPTION SPECIFICATION...... 48 4.3. CAPTION SPECIFICATION...... 48 4.3.1. Sub picture...... 48 4.3.1. SUB PICTURE...... 48 4.3.2. Timed Text...... 48 4.3.2. TIMED TEXT...... 48 5. DYNAMIC METADATA...... 49

5.1. OVERVIEW...... 49 5.1. OVERVIEW...... 49 5.1.1. Introduction...... 49 5.1.1. INTRODUCTION...... 49 5.1.2. Dynamic Metadata System Overview...... 49 5.1.2. DYNAMIC METADATA SYSTEM OVERVIEW...... 49 5.1.3. Major Dynamic Metadata Concepts...... 49 5.1.3. MAJOR DYNAMIC METADATA CONCEPTS...... 49 5.1.4. Dynamic Metadata Fundamental Requirements...... 49 5.1.4. DYNAMIC METADATA FUNDAMENTAL REQUIREMENTS...... 49 5.1.4.1. Common File Formats...... 49 5.1.4.1. Common File Formats...... 49 5.1.4.2. Frame Rates...... 49 5.1.4.2. Frame Rates...... 49 5.2. TIME CODE SPECIFICATION...... 49 5.2. TIME CODE SPECIFICATION...... 49

5.3. PAN AND SCAN SPECIFICATION...... 49 5.3. PAN AND SCAN SPECIFICATION...... 49

5.4. COLOR CORRECTION SPECIFICATION...... 49 5.4. COLOR CORRECTION SPECIFICATION...... 49

5.5. DYNAMIC DOWN-MIXING SPECIFICATION NOT SUPPORTED IN IMF...... 49 5.5. DYNAMIC DOWN-MIXING SPECIFICATION NOT SUPPORTED IN IMF...... 49

6. WRAPPING...... 50

6.1. OVERVIEW...... 50 6.1. OVERVIEW...... 50 6.1.1. Introduction...... 50 6.1.1. INTRODUCTION...... 50 6.1.2. Wrapping System Overview...... 50 6.1.2. WRAPPING SYSTEM OVERVIEW...... 50 6.2. WRAPPING FUNDAMENTAL REQUIREMENTS...... 50 6.2. WRAPPING FUNDAMENTAL REQUIREMENTS...... 50 6.2.1. Common File Formats...... 50 6.2.1. COMMON FILE FORMATS...... 50 6.2.2. Frame Rates...... 50 6.2.2. FRAME RATES...... 50 6.3. WRAPPING OVERVIEW...... 50

7 Private Draft Document. Not for Publication

6.3. WRAPPING OVERVIEW...... 50 6.3.1. Introduction...... 50 6.3.1. INTRODUCTION...... 50 6.3.2. Format Information...... 51 6.3.2. FORMAT INFORMATION...... 51 6.3.3. Sequence...... 51 6.3.3. SEQUENCE...... 51 6.3.4. Track File Replacement...... 52 6.3.4. TRACK FILE REPLACEMENT...... 52 6.3.5. Synchronization...... 52 6.3.5. SYNCHRONIZATION...... 52 6.3.6. Splicing...... 52 6.3.6. SPLICING...... 52 6.3.7. Key Epoch...... 52 6.3.7. KEY EPOCH...... 52 6.3.8. Security...... 52 6.3.8. SECURITY...... 52 6.3.9. Integrity and Authentication...... 52 6.3.9. INTEGRITY AND AUTHENTICATION...... 52 6.3.10. Extensibility...... 52 6.3.10. EXTENSIBILITY...... 52 6.3.11. Random Access and Restarts...... 53 6.3.11. RANDOM ACCESS AND RESTARTS...... 53 6.3.12. Simple Essence...... 53 6.3.12. SIMPLE ESSENCE...... 53 6.4. MXF TRACK FILE ENCRYPTION...... 53 6.4. MXF TRACK FILE ENCRYPTION...... 53 6.4.1. Introduction...... 53 6.4.1. INTRODUCTION...... 53 6.4.2. Encrypted Track File Constraints...... 54 6.4.2. ENCRYPTED TRACK FILE CONSTRAINTS...... 54 6.5. IMAGE TRACK FILE...... 54 6.5. IMAGE TRACK FILE...... 54 6.5.1. Introduction...... 54 6.5.1. INTRODUCTION...... 54 6.5.2. Frame Boundaries...... 54 6.5.2. FRAME BOUNDARIES...... 54 6.5.3. Compression...... 54 6.5.3. COMPRESSION...... 54 6.5.4. Metadata...... 55 6.5.4. METADATA...... 55 6.6. AUDIO TRACK FILE...... 55 6.6. AUDIO TRACK FILE...... 55 6.6.1. Introduction...... 55 6.6.1. INTRODUCTION...... 55 6.6.2. Frame Boundaries...... 55 6.6.2. FRAME BOUNDARIES...... 55 6.6.3. Data Packing Format...... 55 6.6.3. DATA PACKING FORMAT...... 55 6.6.4. Metadata...... 55 6.6.4. METADATA...... 55 6.7. SUBTITLE TRACK FILE...... 55 6.7. SUBTITLE TRACK FILE...... 55

8 Private Draft Document. Not for Publication

6.7.1. Introduction...... 55 6.7.1. INTRODUCTION...... 55 6.7.2. Frame Boundaries...... 56 6.7.2. FRAME BOUNDARIES...... 56 6.7.3. Timed Text...... 56 6.7.3. TIMED TEXT...... 56 6.7.4. Sub picture...... 56 6.7.4. SUB PICTURE...... 56 6.7.5. Metadata...... 56 6.7.5. METADATA...... 56 6.8. CAPTIONS TRACK FILE...... 56 6.8. CAPTIONS TRACK FILE...... 56 6.8.1. Introduction...... 56 6.8.1. INTRODUCTION...... 56 6.8.2. Frame Boundaries...... 56 6.8.2. FRAME BOUNDARIES...... 56 6.8.3. Timed Text...... 56 6.8.3. TIMED TEXT...... 56 6.8.4. Sub picture...... 56 6.8.4. SUB PICTURE...... 56 6.8.5. Metadata...... 56 6.8.5. METADATA...... 56 6.9. TIME CODE TRACK FILES (OPTIONAL)...... 57 6.9. TIME CODE TRACK FILES (OPTIONAL)...... 57 6.9.1. Introduction...... 57 6.9.1. INTRODUCTION...... 57 6.9.2. Frame Boundaries...... 57 6.9.2. FRAME BOUNDARIES...... 57 6.9.3. Metadata...... 57 6.9.3. METADATA...... 57 6.10. PAN AND SCAN TRACK FILES (OPTIONAL)...... 57 6.10. PAN AND SCAN TRACK FILES (OPTIONAL)...... 57 6.10.1. Introduction...... 57 6.10.1. INTRODUCTION...... 57 6.10.2. Frame Boundaries...... 57 6.10.2. FRAME BOUNDARIES...... 57 6.10.3. Metadata...... 57 6.10.3. METADATA...... 57 6.11. COLOR CORRECTION TRACK FILES (OPTIONAL)...... 58 6.11. COLOR CORRECTION TRACK FILES (OPTIONAL)...... 58 6.11.1. Introduction...... 58 6.11.1. INTRODUCTION...... 58 6.11.2. Frame Boundaries...... 58 6.11.2. FRAME BOUNDARIES...... 58 6.11.3. Metadata...... 58 6.11.3. METADATA...... 58 6.12. DYNAMIC DOWN-MIXING TRACK FILES (OPTIONAL)...... 58 6.12. DYNAMIC DOWN-MIXING TRACK FILES (OPTIONAL)...... 58 6.12.1. Introduction...... 58 6.12.1. INTRODUCTION...... 58 6.12.2. Frame Boundaries...... 58 6.12.2. FRAME BOUNDARIES...... 58 6.12.3. Metadata...... 58

9 Private Draft Document. Not for Publication

6.12.3. METADATA...... 58 7. THE COMPOSITION...... 59

7.1. INTRODUCTION...... 59 7.1. INTRODUCTION...... 59

7.2. FUNCTIONAL FRAMEWORK...... 59 7.2. FUNCTIONAL FRAMEWORK...... 59

7.3. THE COMPOSITION FUNDAMENTAL REQUIREMENTS...... 59 7.3. THE COMPOSITION FUNDAMENTAL REQUIREMENTS...... 59 7.3.1. Open Standard...... 59 7.3.1. OPEN STANDARD...... 59 7.3.2. Interoperable...... 59 7.3.2. INTEROPERABLE...... 59 7.3.3. Scalable...... 59 7.3.3. SCALABLE...... 59 7.3.4. Extensible...... 59 7.3.4. EXTENSIBLE...... 59 7.3.5. Synchronization...... 59 7.3.5. SYNCHRONIZATION...... 59 7.3.6. Human Readable Metadata...... 59 7.3.6. HUMAN READABLE METADATA...... 59 7.3.7. File Format...... 60 7.3.7. FILE FORMAT...... 60 7.4. TERMINOLOGY...... 60 7.4. TERMINOLOGY...... 60

7.5. SYNCHRONIZATION...... 61 7.5. SYNCHRONIZATION...... 61

7.6. COMPOSITION PLAYLIST STRUCTURE...... 64 7.6. COMPOSITION PLAYLIST STRUCTURE...... 64 7.6.1. General Information...... 64 7.6.1. GENERAL INFORMATION...... 64 7.6.2. Unique Id...... 65 7.6.2. UNIQUE ID...... 65 7.6.3. AnnotationText [optional]...... 65 7.6.3. ANNOTATIONTEXT [OPTIONAL]...... 65 7.6.4. IssueDate...... 66 7.6.4. ISSUEDATE...... 66 7.6.5. Issuer [optional]...... 66 7.6.5. ISSUER [OPTIONAL]...... 66 7.6.6. Creator [optional]...... 66 7.6.6. CREATOR [OPTIONAL]...... 66 7.6.7. ContentTitleText...... 66 7.6.7. CONTENTTITLETEXT...... 66 7.6.8. ContentKind...... 66 7.6.8. CONTENTKIND...... 66 7.6.9. ContentVersion...... 66 7.6.9. CONTENTVERSION...... 66 7.6.9.1. Id...... 67 7.6.9.1. Id...... 67 7.6.9.2. LabelText...... 67 7.6.9.2. LabelText...... 67 7.6.10. ContentDescription...... 67

10 Private Draft Document. Not for Publication

7.6.10. CONTENTDESCRIPTION...... 67 7.6.10.1. SourceMediaDescription [optional]...... 67 7.6.10.1. SourceMediaDescription [optional]...... 67 7.6.10.2. Id [optional]...... 67 7.6.10.2. Id [optional]...... 67 7.6.10.3. LabelText [optional]...... 67 7.6.10.3. LabelText [optional]...... 67 7.6.10.4. FrameRate...... 67 7.6.10.4. FrameRate...... 67 7.6.10.5. TimecodeType [optional]...... 67 7.6.10.5. TimecodeType [optional]...... 67 7.6.10.6. ImageEncodingStandard [optional]...... 68 7.6.10.6. ImageEncodingStandard [optional]...... 68 7.6.10.7. StandardsBody [optional]...... 68 7.6.10.7. StandardsBody [optional]...... 68 7.6.10.8. Label [optional]...... 68 7.6.10.8. Label [optional]...... 68 7.6.10.9. AudioSamplingRate...... 68 7.6.10.9. AudioSamplingRate...... 68 7.6.10.10. AudioConfig...... 68 7.6.10.10. AudioConfig...... 68 7.6.10.11. AudioBitDepth...... 68 7.6.10.11. AudioBitDepth...... 68 7.6.11. SubtitleFormat [optional]...... 68 7.6.11. SUBTITLEFORMAT [OPTIONAL]...... 68 7.6.12. CaptionFormat [optional]...... 68 7.6.12. CAPTIONFORMAT [OPTIONAL]...... 68 7.6.13. TotalRunningTime...... 68 7.6.13. TOTALRUNNINGTIME...... 68 7.6.14. Language [optional]...... 68 7.6.14. LANGUAGE [OPTIONAL]...... 68 7.6.15. Country [optional]...... 69 7.6.15. COUNTRY [OPTIONAL]...... 69 7.6.16. RatingList [optional]...... 69 7.6.16. RATINGLIST [OPTIONAL]...... 69 7.6.16.1. Agency...... 69 7.6.16.1. Agency...... 69 7.6.16.2. Label...... 69 7.6.16.2. Label...... 69 7.6.17. ImageOutputFormat...... 69 7.6.17. IMAGEOUTPUTFORMAT...... 69 7.6.17.1. ImageCompressionStandard [optional]...... 69 7.6.17.1. ImageCompressionStandard [optional]...... 69 7.6.17.2. StandardsBody [optional]...... 69 7.6.17.2. StandardsBody [optional]...... 69 7.6.17.3. Label [optional]...... 69 7.6.17.3. Label [optional]...... 69 7.6.17.4. OutputPixelMatrix...... 69 7.6.17.4. OutputPixelMatrix...... 69 7.6.17.5. OutputColorEncoding...... 69 7.6.17.5. OutputColorEncoding...... 69 7.6.17.6. StandardsBody [optional]...... 70 7.6.17.6. StandardsBody [optional]...... 70 7.6.17.7. Label [optional]...... 70 7.6.17.7. Label [optional]...... 70 7.6.17.8. DisplayAspectRatio...... 70 7.6.17.8. DisplayAspectRatio...... 70 7.6.17.9. FrameRate...... 70

11 Private Draft Document. Not for Publication

7.6.17.9. FrameRate...... 70 7.6.17.10. OutputPictureOverlay [optional]...... 70 7.6.17.10. OutputPictureOverlay [optional]...... 70 7.6.17.11. TimeCodeWindow [optional]...... 70 7.6.17.11. TimeCodeWindow [optional]...... 70 7.6.17.12. Spoiler [optional]...... 70 7.6.17.12. Spoiler [optional]...... 70 7.6.18. OutputAudioFormat...... 70 7.6.18. OUTPUTAUDIOFORMAT...... 70 7.6.18.1. AudioCompressionStandard [optional]...... 70 7.6.18.1. AudioCompressionStandard [optional]...... 70 7.6.18.2. StandardsBody [optional]...... 71 7.6.18.2. StandardsBody [optional]...... 71 7.6.18.3. Label [optional]...... 71 7.6.18.3. Label [optional]...... 71 7.6.18.4. OutputAudioConfig...... 71 7.6.18.4. OutputAudioConfig...... 71 7.6.18.5. OutputAudioSamplingRate...... 71 7.6.18.5. OutputAudioSamplingRate...... 71 7.6.18.6. OutputAudioBitDepth...... 71 7.6.18.6. OutputAudioBitDepth...... 71 7.6.19. SubtitleFormat [optional]...... 71 7.6.19. SUBTITLEFORMAT [OPTIONAL]...... 71 7.6.20. CaptionFormat [optional]...... 71 7.6.20. CAPTIONFORMAT [OPTIONAL]...... 71 7.6.21. OutputSpeedOffset [optional]...... 71 7.6.21. OUTPUTSPEEDOFFSET [OPTIONAL]...... 71 7.6.22. Encryption...... 71 7.6.22. ENCRYPTION...... 71 7.6.23. SequenceList...... 71 7.6.23. SEQUENCELIST...... 71 7.6.24. Signer [optional]...... 72 7.6.24. SIGNER [OPTIONAL]...... 72 7.6.25. Signature [optional]...... 72 7.6.25. SIGNATURE [OPTIONAL]...... 72 7.7. SEQUENCE STRUCTURE...... 73 7.7. SEQUENCE STRUCTURE...... 73 7.7.1. Sequence Information...... 74 7.7.1. SEQUENCE INFORMATION...... 74 7.7.2. SequenceType...... 75 7.7.2. SEQUENCETYPE...... 75 7.7.3. Unique Id...... 75 7.7.3. UNIQUE ID...... 75 7.7.4. AnnotationText [optional]...... 75 7.7.4. ANNOTATIONTEXT [OPTIONAL]...... 75 7.7.5. IssueDate...... 75 7.7.5. ISSUEDATE...... 75 7.7.6. Issuer [optional]...... 75 7.7.6. ISSUER [OPTIONAL]...... 75 7.7.7. AssetList...... 75 7.7.7. ASSETLIST...... 75 7.7.7.1. MainMarkers [optional]...... 75 7.7.7.1. MainMarkers [optional]...... 75 7.7.7.2. MainPicture [optional]...... 75 7.7.7.2. MainPicture [optional]...... 75 7.7.7.3. PictureSpatial [optional]...... 75 7.7.7.3. PictureSpatial [optional]...... 75

12 Private Draft Document. Not for Publication

7.7.7.4. PictureTransition [optional]...... 76 7.7.7.4. PictureTransition [optional]...... 76 7.7.7.5. ColorCorrection [optional]...... 76 7.7.7.5. ColorCorrection [optional]...... 76 7.7.7.6. MainSound [optional]...... 76 7.7.7.6. MainSound [optional]...... 76 7.7.7.7. SoundTransition [optional]...... 76 7.7.7.7. SoundTransition [optional]...... 76 7.7.7.8. DownMixing [optional]...... 76 7.7.7.8. DownMixing [optional]...... 76 7.7.7.9. MainSubtitle [optional]...... 76 7.7.7.9. MainSubtitle [optional]...... 76 7.7.7.10. MainCaption [optional]...... 76 7.7.7.10. MainCaption [optional]...... 76 7.7.7.11. Extensions (New Asset Types)...... 77 7.7.7.11. Extensions (New Asset Types)...... 77 7.8. ASSET STRUCTURES...... 78 7.8. ASSET STRUCTURES...... 78 7.8.1. Asset Information...... 78 7.8.1. ASSET INFORMATION...... 78 7.8.2. GenericAssetType...... 79 7.8.2. GENERICASSETTYPE...... 79 7.8.2.1. Id...... 79 7.8.2.1. Id...... 79 7.8.2.2. AnnotationText [optional]...... 79 7.8.2.2. AnnotationText [optional]...... 79 7.8.2.3. EditRate...... 79 7.8.2.3. EditRate...... 79 7.8.2.4. IntrinsicDuration...... 80 7.8.2.4. IntrinsicDuration...... 80 7.8.2.5. EntryPoint [optional]...... 80 7.8.2.5. EntryPoint [optional]...... 80 7.8.2.6. Duration [optional]...... 80 7.8.2.6. Duration [optional]...... 80 7.8.3. TrackFileAssetType...... 80 7.8.3. TRACKFILEASSETTYPE...... 80 7.8.3.1. KeyId [optional]...... 80 7.8.3.1. KeyId [optional]...... 80 7.8.3.2. Hash [optional]...... 80 7.8.3.2. Hash [optional]...... 80 7.8.4. MarkerAssetType...... 81 7.8.4. MARKERASSETTYPE...... 81 7.8.4.1. MarkerList...... 81 7.8.4.1. MarkerList...... 81 7.8.4.2. Label...... 81 7.8.4.2. Label...... 81 7.8.4.3. AnnotationText [optional]...... 81 7.8.4.3. AnnotationText [optional]...... 81 7.8.4.4. Offset...... 82 7.8.4.4. Offset...... 82 7.8.5. PictureTrackFileAssetType...... 82 7.8.5. PICTURETRACKFILEASSETTYPE...... 82 7.8.5.1. PicturePixelMatrix...... 82 7.8.5.1. PicturePixelMatrix...... 82 7.8.5.2. PictureBitDepth...... 82 7.8.5.2. PictureBitDepth...... 82 7.8.5.3. PictureColorEncoding...... 82

13 Private Draft Document. Not for Publication

7.8.5.3. PictureColorEncoding...... 82 7.8.5.4. PictureFrameRate...... 82 7.8.5.4. PictureFrameRate...... 82 7.8.5.5. ImageAspectRatio...... 82 7.8.5.5. ImageAspectRatio...... 82 7.8.6. PictureSpatialMetadataTrackFileAssetType...... 82 7.8.6. PICTURESPATIALMETADATATRACKFILEASSETTYPE...... 82 7.8.6.1. StandardsBody [optional]...... 82 7.8.6.1. StandardsBody [optional]...... 82 7.8.6.2. Label [optional]...... 83 7.8.6.2. Label [optional]...... 83 7.8.7. PictureTransitionMetadataTrackFileAssetType...... 83 7.8.7. PICTURETRANSITIONMETADATATRACKFILEASSETTYPE...... 83 7.8.7.1. StandardsBody [optional]...... 83 7.8.7.1. StandardsBody [optional]...... 83 7.8.7.2. Label [optional]...... 83 7.8.7.2. Label [optional]...... 83 7.8.8. ColorCorrectionMetadataTrackFileAssetType...... 83 7.8.8. COLORCORRECTIONMETADATATRACKFILEASSETTYPE...... 83 7.8.8.1. StandardsBody [optional]...... 83 7.8.8.1. StandardsBody [optional]...... 83 7.8.8.2. Label [optional]...... 83 7.8.8.2. Label [optional]...... 83 7.8.9. SoundTrackFileAssetType...... 84 7.8.9. SOUNDTRACKFILEASSETTYPE...... 84 7.8.9.1. SoundSamplingRate...... 84 7.8.9.1. SoundSamplingRate...... 84 7.8.9.2. SoundBitDepth...... 84 7.8.9.2. SoundBitDepth...... 84 7.8.9.3. SoundChannelNumber...... 84 7.8.9.3. SoundChannelNumber...... 84 7.8.9.4. ChannelConfiguration...... 84 7.8.9.4. ChannelConfiguration...... 84 7.8.9.5. Label...... 84 7.8.9.5. Label...... 84 7.8.9.6. Language [optional]...... 84 7.8.9.6. Language [optional]...... 84 7.8.10. SoundTransitionMetadataTrackFileAssetType...... 85 7.8.10. SOUNDTRANSITIONMETADATATRACKFILEASSETTYPE...... 85 7.8.10.1. StandardsBody [optional]...... 85 7.8.10.1. StandardsBody [optional]...... 85 7.8.10.2. Label [optional]...... 85 7.8.10.2. Label [optional]...... 85 7.8.11. SoundDownMixingMetadataTrackFileAssetType...... 85 7.8.11. SOUNDDOWNMIXINGMETADATATRACKFILEASSETTYPE...... 85 7.8.11.1. StandardsBody [optional]...... 85 7.8.11.1. StandardsBody [optional]...... 85 7.8.11.2. Label [optional]...... 85 7.8.11.2. Label [optional]...... 85 7.8.12. SubtitleTrackFileAssetType...... 86 7.8.12. SUBTITLETRACKFILEASSETTYPE...... 86 7.8.12.1. Language [optional]...... 86 7.8.12.1. Language [optional]...... 86 7.8.13. CaptionTrackFileAssetType...... 86 7.8.13. CAPTIONTRACKFILEASSETTYPE...... 86 7.8.13.1. Language [optional]...... 86 7.8.13.1. Language [optional]...... 86 7.9. CPL CONSTRAINTS...... 87

14 Private Draft Document. Not for Publication

7.9. CPL CONSTRAINTS...... 87 7.9.1. Constant Frame Rate...... 87 7.9.1. CONSTANT FRAME RATE...... 87 7.9.2. Minimum Track File Duration...... 87 7.9.2. MINIMUM TRACK FILE DURATION...... 87 7.9.3. Minimum Sequence Duration...... 87 7.9.3. MINIMUM SEQUENCE DURATION...... 87 7.9.4. Minimum Picture Transition Support...... 87 7.9.4. MINIMUM PICTURE TRANSITION SUPPORT...... 87 7.9.5. Minimum Sound Transition Support...... 87 7.9.5. MINIMUM SOUND TRANSITION SUPPORT...... 87 8. OUTPUT PROFILE LIST...... 88

8.1. INTRODUCTION...... 88 8.1. INTRODUCTION...... 88

8.2. OUTPUT PROFILE LIST OVERVIEW...... 88 8.2. OUTPUT PROFILE LIST OVERVIEW...... 88 8.2.1. Functional Framework...... 88 8.2.1. FUNCTIONAL FRAMEWORK...... 88 8.2.2. Output Profile List Fundamental Requirements...... 88 8.2.2. OUTPUT PROFILE LIST FUNDAMENTAL REQUIREMENTS...... 88 8.2.2.1. Introduction...... 88 8.2.2.1. Introduction...... 88 8.2.2.2. Open Standard...... 88 8.2.2.2. Open Standard...... 88 8.2.2.3. Interoperable...... 88 8.2.2.3. Interoperable...... 88 8.2.2.4. Scalable...... 88 8.2.2.4. Scalable...... 88 8.2.2.5. Extensible...... 88 8.2.2.5. Extensible...... 88 8.2.2.6. Human Readable Metadata...... 88 8.2.2.6. Human Readable Metadata...... 88 8.2.3. Output Profile List Concepts...... 88 8.2.3. OUTPUT PROFILE LIST CONCEPTS...... 88 8.3. OUTPUT PROFILE LIST FORMAT...... 88 8.3. OUTPUT PROFILE LIST FORMAT...... 88 8.3.1. Introduction...... 88 8.3.1. INTRODUCTION...... 88 8.3.2. File Format...... 88 8.3.2. FILE FORMAT...... 88 8.3.3. ImageOutputFormat...... 88 8.3.3. IMAGEOUTPUTFORMAT...... 88 8.3.3.1. OutputPixelMatrix...... 89 8.3.3.1. OutputPixelMatrix...... 89 8.3.3.2. OutputColorEncoding...... 89 8.3.3.2. OutputColorEncoding...... 89 8.3.3.3. StandardsBody [optional]...... 89 8.3.3.3. StandardsBody [optional]...... 89 8.3.3.4. Label [optional]...... 89 8.3.3.4. Label [optional]...... 89 8.3.3.5. DisplayAspectRatio...... 89 8.3.3.5. DisplayAspectRatio...... 89 8.3.3.6. OutputPictureOverlay [optional]...... 89

15 Private Draft Document. Not for Publication

8.3.3.6. OutputPictureOverlay [optional]...... 89 8.3.3.7. TimeCodeWindow [optional]...... 89 8.3.3.7. TimeCodeWindow [optional]...... 89 8.3.3.8. Spoiler [optional]...... 89 8.3.3.8. Spoiler [optional]...... 89 8.3.4. OutputAudioFormat...... 89 8.3.4. OUTPUTAUDIOFORMAT...... 89 8.3.4.1. AudioCompressionStandard [optional]...... 90 8.3.4.1. AudioCompressionStandard [optional]...... 90 8.3.4.2. StandardsBody [optional]...... 90 8.3.4.2. StandardsBody [optional]...... 90 8.3.4.3. Label [optional]...... 90 8.3.4.3. Label [optional]...... 90 8.3.5. OutputSpeedOffset [optional]...... 90 8.3.5. OUTPUTSPEEDOFFSET [OPTIONAL]...... 90 PACKAGING...... 91

8.4. INTRODUCTION...... 91 8.4. INTRODUCTION...... 91

8.5. PACKAGING SYSTEM OVERVIEW...... 91 8.5. PACKAGING SYSTEM OVERVIEW...... 91 8.5.1. Functional Framework...... 91 8.5.1. FUNCTIONAL FRAMEWORK...... 91 8.5.2. Packaging Fundamental Requirements...... 91 8.5.2. PACKAGING FUNDAMENTAL REQUIREMENTS...... 91 8.5.2.1. Introduction...... 91 8.5.2.1. Introduction...... 91 8.5.2.2. Open Standard...... 91 8.5.2.2. Open Standard...... 91 8.5.2.3. Interoperable...... 91 8.5.2.3. Interoperable...... 91 8.5.2.4. Scalable...... 91 8.5.2.4. Scalable...... 91 8.5.2.5. Extensible...... 91 8.5.2.5. Extensible...... 91 8.5.2.6. Synchronization...... 91 8.5.2.6. Synchronization...... 91 8.5.2.7. Human Readable Metadata...... 92 8.5.2.7. Human Readable Metadata...... 92 8.5.3. Packaging Concepts...... 92 8.5.3. PACKAGING CONCEPTS...... 92 8.6. DISTRIBUTION PACKAGE...... 92 8.6. DISTRIBUTION PACKAGE...... 92 8.6.1. Introduction...... 92 8.6.1. INTRODUCTION...... 92 8.6.2. Distribution Package...... 92 8.6.2. DISTRIBUTION PACKAGE...... 92 8.6.2.1. General...... 92 8.6.2.1. General...... 92 8.6.2.2. Packing for Transport...... 92 8.6.2.2. Packing for Transport...... 92 8.6.2.3. Flattened Packages...... 92 8.6.2.3. Flattened Packages...... 92 8.6.2.4. Security...... 92 8.6.2.4. Security...... 92

16 Private Draft Document. Not for Publication

8.6.3. Packing List...... 92 8.6.3. PACKING LIST...... 92 8.6.3.1. File Format...... 92 8.6.3.1. File Format...... 92 8.6.3.2. Fields...... 92 8.6.3.2. Fields...... 92 8.6.4. Asset Map...... 93 8.6.4. ASSET MAP...... 93 8.6.4.1. File Format...... 93 8.6.4.1. File Format...... 93 8.6.4.2. Fields...... 93 8.6.4.2. Fields...... 93 9. ANNEX...... 94

9.1. EXAMPLE WORKFLOWS...... 94 9.1. EXAMPLE WORKFLOWS...... 94

9.2. EDITORIAL SYSTEMS...... 95 9.2. EDITORIAL SYSTEMS...... 95 9.2.1. Editorial System Fundamental Requirements...... 95 9.2.1. EDITORIAL SYSTEM FUNDAMENTAL REQUIREMENTS...... 95 9.2.1.1. Easy Assembly of Content...... 95 9.2.1.1. Easy Assembly of Content...... 95 9.2.1.2. Movement of Content...... 95 9.2.1.2. Movement of Content...... 95 9.2.1.3. Ease of Operation...... 95 9.2.1.3. Ease of Operation...... 95 9.2.1.4. Multiple Systems...... 96 9.2.1.4. Multiple Systems...... 96 9.3. PLAYOUT SYSTEMS...... 96 9.3. PLAYOUT SYSTEMS...... 96 9.3.1. Playout System Fundamental Requirements...... 96 9.3.1. PLAYOUT SYSTEM FUNDAMENTAL REQUIREMENTS...... 96 9.3.1.1. Easy Assembly of Content...... 96 9.3.1.1. Easy Assembly of Content...... 96 9.3.1.2. Movement of Content...... 96 9.3.1.2. Movement of Content...... 96 9.4. TRANSCODING SYSTEMS...... 96 9.4. TRANSCODING SYSTEMS...... 96 9.4.1. Transcoding System Fundamental Requirements...... 96 9.4.1. TRANSCODING SYSTEM FUNDAMENTAL REQUIREMENTS...... 96 9.4.1.1. Easy Assembly of Content...... 96 9.4.1.1. Easy Assembly of Content...... 96 9.4.1.2. Movement of Content...... 96 9.4.1.2. Movement of Content...... 96 9.5. ASSET MANAGEMENT INTERFACE...... 96 9.5. ASSET MANAGEMENT INTERFACE...... 96 9.5.1. Interface Fundamental Requirements...... 96 9.5.1. INTERFACE FUNDAMENTAL REQUIREMENTS...... 96 9.5.1.1. Introduction...... 96 9.5.1.1. Introduction...... 96 9.5.1.2. API...... 96 9.5.1.2. API...... 96 9.5.1.3. Protocols...... 96

17 Private Draft Document. Not for Publication

9.5.1.3. Protocols...... 96 9.5.2. Asset Management Interface Fundamental Concepts...... 96 9.5.2. ASSET MANAGEMENT INTERFACE FUNDAMENTAL CONCEPTS...... 96 9.5.3. Application Programming Interface...... 97 9.5.3. APPLICATION PROGRAMMING INTERFACE...... 97 9.5.4. Protocols...... 97 9.5.4. PROTOCOLS...... 97 10. GLOSSARY OF TERMS...... 98

18 Private Draft Document. Not for Publication Table of Figures

FIGURE 1 – EXAMPLE THEATRICAL WORKFLOW...... 25

FIGURE 2 – EXAMPLE IMF SYSTEM ARCHITECTURE...... 27

FIGURE 3 – EXAMPLE WRAPPING...... 29

FIGURE 5 – EXAMPLE IMF COMPOSITION...... 30

FIGURE 4 - EXAMPLE IMF HIERARCHICAL STRUCTURE...... 31

FIGURE 6 – EXAMPLE IMF PACKAGE...... 33

FIGURE 7 - EXAMPLE TRACK FILE STRUCTURE...... 51

FIGURE 8 - EXAMPLE OF KLV CODING...... 51

FIGURE 9 - CORRESPONDENCE BETWEEN SOURCE AND ENCRYPTED TRIPLETS...... 54

FIGURE 10 - COMPOSITION PLAYLIST SEQUENCE...... 61

FIGURE 11 - TIMING RELATIONSHIPS WITHIN A SEQUENCE...... 62

FIGURE 12 - SEQUENCE SYNC RELATIONSHIP EXAMPLE...... 63

FIGURE 13 - SEQUENCE STRUCTURE...... 73

FIGURE 14 - ASSET TIMING PARAMETERS...... 80

FIGURE 15 - FUTURE STATE - MASTERING & DISTRIBUTION SERVICING...... 94

FIGURE 16 – EXAMPLE IMF WORKFLOW...... 95

Table of Tables

TABLE 1. IMF BASIC ELEMENTS...... 34

TABLE 2. XML NAMESPACES...... 60

TABLE 3. EXAMPLES OF CONTENT KIND...... 66

TABLE 4. EXAMPLE RATINGS (INFORMATIVE)...... 69

TABLE 5. EXAMPLES STANDARDS BODY LABELS...... 70

TABLE 6. EXAMPLE MARKER LABELS...... 81

TABLE 7. EXAMPLES STANDARDS BODY LABELS...... 83

19 Private Draft Document. Not for Publication

TABLE 8. EXAMPLES CHANNEL LABELS...... 84

TABLE 5. EXAMPLES STANDARDS BODY LABELS...... 89

20 Private Draft Document. Not for Publication

1. IMF Introduction

1.1. Introduction With the advance of technology within the motion picture post-production industry, a paradigm shift is upon us as we move from the videotape workflow to the file based workflow. It is with this shift that a need has risen for a standardized set of specifications for this file-based workflow. In light of this shift, an organization was sought out by content creators to provide the facility for detailed discussions surrounding this topic. The Entertainment Technology Center stood out as a leading candidate for such discussions and in November of 2008 the Interoperable Master Format or IMF specification effort was initiated.

1.2. Scope The IMF file-based workflow is designed to replace the existing tape-based Distribution Servicing workflow. It will store one master set of file based elements to be assembled for any downstream distribution using multiple Composition Play Lists (Recipes), similar to what is used in present day Digital Cinema Packaging (DCP). The broad concept of a high quality, uniform IMF should lower costs, improve time-to-market, and increase interoperability of existing production processes and needs.

This specification is intended to promote improved interoperability and faster implementation of multiple variants on a common video package, while retaining highest quality and appropriate security of the material. It is envisioned that this Final Specification would then be presented to SMPTE (Society of Motion Picture and Television Engineers) to create standards, recommended practices and engineering guidelines to implement this specification throughout the industry as a common interchange method.

1.3. System Objectives At the onset of writing a specification for an Interoperable Master Format, ETC acknowledged certain fundamental requirements, which are:

• The Interoperable Master Format (IMF) shall provide for a single set of master files and recipes to allow for easy creation of versions for distribution channels. This should also provide the potential to repurpose existing content. • The IMF shall have the capability to present Essence and Metadata that is equal to or better than what one could achieve with current practice (i.e. Videotape). • The IMF shall provide mechanisms (i.e. asset management, packing lists) for the exchange of IMF metadata or packages between facilities. • This system should be based upon international standards so that content can be interchanged anywhere in the world as can be done today with videotape. These standards should be open published industry standards that are widely accepted and codified by regional and international standards bodies such as: ANSI, SMPTE, ITU, W3C, and ISO/IEC. • The system specification and formats should be chosen so that the capital equipment and operational costs are reasonable and exploit, as much as possible, the economies of scale associated with equipment and technology in use in other industries. • The hardware and software used in the system should be easily upgraded as advances in technology are made. Upgrades to the format shall be designed in a way so that content may be distributed and compatibly exchanged on the latest IMF-compliant hardware and software, as well as earlier adopted IMF-compliant equipment installations. • The Interoperable Master Format shall be based upon a component architecture (e.g., Mastering, Compression, Encryption, Distribution, Storage, Playback) that allows for the components to be replaced or upgraded in the future without the replacement of the complete system. It is the intention of this Digital Video specification to allow for advances in technology

21 Private Draft Document. Not for Publication

and the economics of technology advancement. • The document specifies a baseline for the implementation of an Interoperable Master Format. The goal of backwards compatibility in this context is to allow, for example, new content at higher resolution and color space to be understood by the baseline implementation. • The Interoperable Master Format shall provide a reliability and availability that is equal to, or better than, current practice. (i.e. videotape) • The Interoperable Master Format shall allow for the use of a security method. The system should provide a means to allow the content to use standardized encryption with private/public keys. The IMF should also allow the use of forensic marking of the content for providing traceable forensic evidence in the case of theft.

1.4. Document Language This document consists of normative text and optional informative text. Normative text is text that describes the elements of the design that are indispensable or contains the conformance language keywords: “shall”, “should” or “may”. Informative text is text that is potentially helpful to the user, but not indispensable and can be removed, changed or added editorially without affecting interoperability. Informative text does not contain any conformance keywords. All text in the document is, by default, normative except: any section titled “Introduction”, any section explicitly labeled as “Informative”, or individual paragraphs that start with the word “Note.” Normative references are those external documents referenced in normative text and are indispensable to the user. Informative, or bibliographic, references are those references made from informative text or are otherwise not indispensable to the user.

The keywords “shall” and “shall not” indicate requirements that must be strictly followed in order to conform to the document and from which no deviation is permitted.

The keywords “should” and “should not” indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required. In the negative form, a certain possibility or course of action is deprecated but not prohibited.

The keywords “may” and “need not” indicate a course of action permissible within the limits of the document.

The keyword “reserved” indicates that a condition is not defined and shall have no meaning. However, it may be defined in the future. The keyword “forbidden” is the same as reserved, except that the condition shall never be defined in the future.

A compliant implementation is one that includes all mandatory provisions (“shall”) and, if implemented, all recommended provisions (“should”) as described. A compliant implementation need not implement optional provisions (“may”).

Requirements are indicated with the key phrases “is required to”, “is encouraged to” and “can” which represent “shall,” “should” and “may” (had the text been in a separate requirements document). This is necessary in order to distinguish requirements from the specification conformance language.

Sentences with the following keywords are italics: shall, shall not, should not, is required, is not required, is not encourage and is encouraged.

The names of standards publications and protocols are placed in [bracketed text]. International and industry standards contain provisions, which, through reference in this text, constitute provisions of this specification. At the time of publication, the editions indicated were valid. These referenced standards are subject to revision, and parties to agreements based upon this specification are encouraged to investigate the possibility of applying the most recent editions of the referenced standards. Section 10 is a glossary of technical terms and acronyms used throughout this specification. The reader is encouraged to refer to the glossary for any unfamiliar terms and acronyms.

22 Private Draft Document. Not for Publication

Trademarked names are the property of their respective owners.

23 Private Draft Document. Not for Publication

2. SYSTEM OVERVIEW

2.1. Functional Framework The document defines technical specifications and requirements for the creation and distribution of Interoperable Master Format. The details are in the following sections: • Essence: This section provides specifications for the image and audio essence and its specific inherent metadata. The image essence specification defines a common set of image structures by specifying parameters such as image container, colorimetry and if required a mezzanine compression structure for the Interoperable Master Format (IMF). The Audio Essence specifies audio characteristics such as; bit depth, sample rate, minimum channel count, channel mapping and reference levels. • Data Essence: This section provides specifications for the subtitle (Timed Text and sub pictures) and captions data essence. The Subtitles Essence specifies the format of a Digital Video subtitle track file. A subtitle file contains a set of instructions for placing rendered text or graphical overlays at precise locations on distinct groups of motion picture frames. A caption file may provide graphical overlays or provide graphical information to a secondary system for display of text. Outside of providing to a secondary system most other parameters are the same as subtitle data essence. • Dynamic Metadata: This section provides the specifications for the Metadata that is outside of the associated metadata of the essence or data essence. This would be metadata such as; time code, pan and scan, color correction, dynamic down-mixing and dynamic range control. • Wrapping: This section defines the requirements for wrapping the content and metadata (image, audio and subtitle) files using (where possible) existing Material eXchange Format (MXF) specifications. The output of this process is the Track Files. This section also defines the requirements for encrypting the essence (sound, picture and subtitles) of the IMF if required • Composition: This section provides the specifications for the creation of XML using Composition PlayLists (CPL) which are scripts that link the IMF Track Files together into synchronized pieces of content. This section will also touch upon the security requirements for a composition and Composition PlayList. • Packaging: Interoperable Master Format Compositions can be Packaged for distribution which is detailed in this section. Provides requirements for all the tools necessary for editorial functions in a typical post-production environment. • Annex: This section contains example workflows using the IMF as well as definitions and suggested devices for editorial systems, transcoding and playout systems.

24 Private Draft Document. Not for Publication

2.2. Overview The goal of the IMF project is to establish an integrated hardware and software solution for the processing, storage, and management of digital content intended for downstream distribution to business that will consume such content.

2.2.1. IMF System Architecture Figure 1 below demonstrates an example of the end-to-end data flow from Production to Distribution. The focus of IMF is within the Distribution Servicing phase.

Distribution Mechanisms

Figure 1 – Example Theatrical Workflow

To further demonstrate the concept of the Interoperable Master Format in a system architecture for distribution servicing refer to Figure 2 below. The IMF aggregates image, audio, and other files to support processing for any downstream delivery requirement. It does this using Composition Play Lists to create the deliverables using transcoding technologies. The IMF package will allow for delivery using the image elements stored in either a compressed or uncompressed file. An example of this would be an HD resolution with 709 color space at 24 FPS converted to SD resolution with 601 color space at 29.97 FPS.

25 Private Draft Document. Not for Publication

26 Private Draft Document. Not for Publication

Figure 2 – Example IMF System Architecture

2.2.2. Major System Key Concepts The following listed concepts below are the Key Concepts of the IMF as a system. These concepts are derived from work done by content creators to create masters for the downstream distribution servicing of theatrical content. This is not to say that these concepts or the IMF cannot be applied to other forms of content. Instead it is noted here so that the reader may better understand its origin.

2.2.2.1. Business to Business Solution The IMF is intended to facilitate internal or a business to business relationship and is not intended to deliver content to the consumer.

2.2.2.2. Digital Source Master (DSM) The IMF is derived from a wide range of sources with a wide range of technical levels. One example is content in its finished state at the end of the theatrical post-production process which is shown above in Figure 1 as a Digital Intermediate or also know as a Digital Source Master (DSM). The DSM can also be used to convert to a film duplication master and/or a master for archival purposes. It is not the intention of this document to, in any way, specify the DSM. This is left to the discretion of the content provider.

27 Private Draft Document. Not for Publication

2.2.2.3. Archive not in Scope It is also not the intention of this specification to design the IMF as an archiveable master. One could conceive this as another use of the IMF, however this is not part of the scope of this specification.

2.2.2.4. File / Frame-Based System The IMF is built upon a data file-based design, i.e., all of the content is made up of data stored in files. These files are organized around the image frames, which means that all of the synchronization references to the image frames and frame rate. The file is the most basic component of the system.

2.2.2.5. Essence and Data Essence The raw image and audio files of the DSM make up what is known as Essence. Also included as part of the IMF there may be subtitle or caption essence. This type of essence is called Data Essence and because of its nature it may require different specifications and hence is described in its own section.

2.2.2.6. Metadata Metadata is essentially data about data. There are many examples of metadata: • Supporting metadata • Descriptive metadata • Dynamic metadata Supporting and Descriptive metadata are defined by SMPTE. A new concept proposed for the IMF is Dynamic metadata. This metadata is metadata that changes on a frame basis such as; time code, pan and scan, color correction and dynamic down-mixing. This metadata may or may not be applied to the underlying essence. It must be synchronized to the essence and therefore with these requirements will need to be wrapped and contained as Track Files.

2.2.2.7. Security The IMF should not preclude the use of encryption or the use of forensic marks. This may occur at the wrapping, composition or packaging stage.

2.2.2.8. Wrapping and Track File Creation Wrapping is the process of encapsulating the essence, data essence and dynamic metadata files into well understood temporal units called Track Files using a standardized wrapping method such as MXF. Figure 3 below shows a basic example of this process of wrapping Essence and Metadata into Track Files. This process includes a way to uniquely identify each Track File along with its associated essence and metadata. It also provides a method to identify synchronization locations within each of the Track Files.

28 Private Draft Document. Not for Publication

Figure 3 – Example Wrapping

29 Private Draft Document. Not for Publication

2.2.2.9. Composition A Composition represents a complete set of files that may be a feature, an episode, a trailer, an advertisement or any other single piece of content. A composition minimally consists of a Composition PlayList (CPL) and one or more Track Files. Composition PlayLists (CPL’s) are XML structured textual lists that define how elements of an IMF are to be assembled and either transcoded to another format or played out as a presentation.

Figure 5 – Example IMF Composition

2.2.2.10. Versions One of the main reasons for having an IMF is the ability to create many versions of a program without duplicating the common essence used for each version. Instead, one Composition PlayList (CPL) is required for each version of the program, which is much smaller in size as compared to the Track Files themselves.

2.2.2.11. Sequence Within the Composition PlayList (CPL) one shall create sequences where the Track Files are nested within these sequences. The CPL is organized in such a way that, finding and possibly replacing sequences becomes more efficient depending on the number of Track Files. This configuration was selected to give the content creator more choices for the structure of the Composition PlayList.

In the IMF, a sequence represents a conceptual period of time having a specific duration chosen by the content provider. For example, a Sequence maybe the same length as a reel or it may be the running time of a television program between commercials. Again this length is determined by the content provider to fit both the particular workflow and content type. Once created, Sequences can then be electronically spliced together within the CPL to create a complete presentation.

An example below (see Figure 4) shows the hierarchical structure of the CPL. A sequence may have one or more Track Files nested within it. The IMF allows for simple transitions to occur between Track Files as well as allowing a minimum duration of a single image frame. Sequences on the other hand only allow a minimum duration of one second and do not allow for transitions to occur between them.

30 Private Draft Document. Not for Publication

Figure 4 - Example IMF Hierarchical Structure

31 Private Draft Document. Not for Publication

2.2.2.12. Output Profile List Once versions of a Composition are created, many different distribution formats may be required to be made from that particular version. In order to assist with the automation of this process, one shall use a method to define the transcoder or play out device’s output. The method of communicating the desired output is called, the Output Profile List or OPL. The OPL is a textual list that contains the specification of the output. It is linked to the CPL by using the UUID of the CPL. This allows one to link many OPL’s to a single CPL and automate the transcoding of the Composition into multiple distribution formats.

2.2.2.13. Packages Once a Composition is created it can be bundled up into a “package” and this “package” maybe interchanged between facilities. At a minimum an An Interoperable MasterF Package (IMP) shall minimally consist of a Composition, an Output Profile List, an Asset Map and Packing List. An Asset Map is a text document that describes how the files are distributed across the physical media that is used for transport. A Packing List is a text document that provides a list of all of the files included in that specific IMPackage. An example of an IMF Package is shown below in Figure 6.

32 Private Draft Document. Not for Publication

Figure 6 – Example IMF Package

33 Private Draft Document. Not for Publication

2.3. IMF Elements and Processes The following table provides a list of the identified IMF elements and processes. The table also provides the category they belong to and where you can find more detail in the following sections.

Table 1. IMF Basic Elements

Element Category Image Essence Audio Essence Primary Display Subtitles / Captions Data Essence Composition PlayList (CPL) Files Dynamic Metadata Output Profile List (OPL) Supporting Metadata Packing List Supporting Metadata Asset Map Supporting Metadata Timecode Dynamic Metadata Secondary Display Captions/Subtitles Data Essence QC / Picture Reports and Fact Sheets Descriptive Metadata Forensic Marking Data Essence Color Correction Dynamic Metadata Pan and Scan (Aspect Ratio Conversion) Dynamic Metadata Dynamic Down-mixing Dynamic Metadata Time Compression/ Expansion Dynamic Metadata HI (Hearing Impaired) Essence VI (Visually Impaired) Essence

34 Private Draft Document. Not for Publication

3. Essence

3.1. Overview

3.1.1. Introduction Essence is the core files that contain the image and audio data. One of the goals of the IMF is to allow for a variety of these files to be included into the IMF. For example the IMF should support multiple image resolutions such as 1920x1080 and 1280x720. This is just one of many different variables that maybe supported by the IMF Essence.The Essence…

3.1.2. Essence System Overview For the purpose of documenting the specific requirements and specifications for Essence, it is helpful to divide the system into a set of components. The specifications and requirements for each of these components will be described in the following sections: • Image – The image specification and file format o Compression Requirements o Structural Metadata • Audio – The audio specification and file format o Structural Metadata

3.1.3. Major Essence Concepts The following are the major concepts of the Essence files. Fill in the blanks……

3.1.4. Essence and Data Essence Fundamental Requirements

3.1.4.1. Common File Formats The Essence and Data Essence is required to use a common standardized file format for each element (image, audio, subtitles, etc.). The image essence file format is required to be an SMPTE-conformant file based on existing SMPTE standards. The audio essence file format is required to be based on Broadcast Wave. The Subtitle essence should be based on PNG and XML file formats.

3.1.4.2. Frame Rates The image and audio formatsstructure areis required to support a frame rate of 24.000, and 23.976, 60.00 and 59.94 Hz. The image essence structure can also support a frame rate of 59.94 Hz. The frame rate of any individual IMF source master is required to remain constant. Metadata shall beis carried in the image and audio data file format to indicate the frame rate.

3.1.4.3. Synchronization Files within the image and/or audio essence are required to carry information to provide for frame-based synchronization between each file. At a minimum, they are required to include a start of file and a continuous frame count.

35 Private Draft Document. Not for Publication

3.2. Image Specification

3.2.1. Image Structure

3.2.2. Compression Requirements Image Compression for Digital Video may use data reduction techniques to decrease the size of the data for economical delivery and storage. The system uses perceptual coding techniques to achieve an image compression that is visually lossless. It is important to note that image compression is typically used to ensure meeting transmission bandwidth or media storage limitations. This results in image quality being dependent on scene content and delivered bit rate. Digital Video image compression is much less dependent upon bandwidth or storage requirements, thereby making bit rate dependent on desired image quality rather than the reverse.

3.2.2.1. Mezzanine Image Compression Requirements The following section defines the requirements for a Mezzanine Image Compression format and structure.

TBD

3.2.3. Structural Metadata

3.3. Audio Specification

3.3.1. Audio Structure

3.3.1.1 Audio File Format

AUDIO TRACK FILE: Audio Track Files represent audio within the IMF. An audio track file is a single, complete audio element, which can be any soundfield configuration. An audio track file would typically be wrapped or interleaved into a single file, and is limited to a single audio element (such as a composite mix, or dialog track) and a single audio configuration (such as 5.1 or mono) per audio track file. Audio track files are further constrained per sections 3.3.1.6 through 3.3.1.x

AUDIO TRACK FILE FORMAT: Interleaved Broadcast Wave.

Note-interleave is by single sample. Order of samples is determined by audio configuration (TBD)

Note-MXF is not preferred as an audio wrapper due to it’s limitations-e.g. track assignments are not flexible and are strictly pattern based depending on the number of tracks. Note AS02 may play a part here.

Note-Data rate coded audio not allowed (e.g. AC3, DTS-MA, Dolby E).

Matrix encoded audio (e.g. Lt-Rt, Dolby EX) is allowed)

36 Private Draft Document. Not for Publication

DISCRETE INPUTS TO IMF AUTHORING (informative): Broadcast Wave, Wave, PCM

37 Private Draft Document. Not for Publication

3.3.1.2 Sampling Rate

48K, 96K, 47.952K, 95.9K

3.3.1.3 Frame Rate/Audio Speed

• Native 24, 25, 30, 50 and 60 are equivalent audio speeds, as the image being represented is the same.

• Pull down 23.976, 29.97 and 59.94 are equivalent audio speeds, as the image being represented is the

same.

Sped up frame rates (would need metadata to convey this):

• 23.976-25 This is “25 fps”, but is sped up from the native speed of 23.976 to 25 fps. The resultant audio is

4.1% faster and higher in pitch than the original captured audio. Metadata should indicate it is “25 fps sped

up 4.1%”

• 24-25 This is “25 fps”, but is sped up from the native speed of 24 to 25 fps. The resultant audio is 4.0%

faster and higher in pitch than the original captured audio. Metadata should indicate it is “25 fps sped up

4.0%”

38 Private Draft Document. Not for Publication

3.3.1.4 Allowable Samples per Frame

The below table indicates the allowable samples per frame based on frame rate, with the required sample (word) clocking rate to sync to the frame speed of the associated image.

Sample Rate 47.952K 48K 95.9K 96K

Frame Rate

23.976 2000 2002 4000 4004

24 n/a 2000 n/a 4000

25 n/a 1920 n/a 3840

29.97 1600 1601.6 3200 3203.2

30 n/a 1600 n/a 3200

50 n/a 960 n/a 1920

59.94 800 800.8 1600 1601.6

60 n/a 800 n/a 1600

48 n/a 1000 n/a 2000

3.3.1.5 Bit Depth

24 bits.

(16 and 20 bit are not allowed, they are padded in the least significant bits to create 24 bit)

39 Private Draft Document. Not for Publication

Note: Metadata should be included to reflect the original bit depth e.g. “24 bit padded from the original 16 bit source”

3.3.1.6 Audio Track File Content

• Audio Track File content constraint: One audio element per track file. Example audio elements are listed

in section 3.3.1.10

• Audio Track File Language constraint: Only one audio language is allowed per audio track file.

• Track file loudspeaker channel content constraint: A given loudspeaker channel can only be represented

once per track file. i.e., within a track file containing multiple audio channels, there is a one to one

relationship between loudspeakers and audio channels. There cannot be multiple instances of a

loudspeaker channel within a track file.

• Channels per track file constraint: A track file may contain up to 16 audio channels

40 Private Draft Document. Not for Publication

3.3.1.7 Simultaneous Multiple Audio Track File Availability and Playout

The CPL in an IMF must be able to point to multiple audio track files, which are simultaneously available for use by a transcoder or real-time playout device.

IMF must support simultaneous multiple audio track file playout, as multiple audio elements must be available to play out at once.

3.3.1.8 Multiple Audio Track File routing

When accessing multiple track files, the track file individual channels are combined (like channel to like channel) for output routing purposes on a unity gain basis. For example, the left channel of audio track file A and the left channel of audio track file B are combined at unity gain as the overall left channel content of the IMF.

Note: Track file channels are never to be combined at other than unity gain.

Note: Different loudspeaker channels are never to be combined e.g. Left and Right are never combined to make a mono output.

3.3.1.9 Mixing of audio channels

Audio mixing of individual channels within a track file is not permitted

Audio mixing of channels between multiple track files is not permitted other than the routing spec stated above.

Downmixing (combining of different channels to make a narrower audio configuration) is not supported in the IMF.

41 Private Draft Document. Not for Publication

3.3.1.10 Audio Elements

There is only one audio element allowed per track file. Multiple audio elements cannot be combined in a single audio track file.

The following audio elements are typical of what may be carried in the IMF. Other audio elements may be carried in an IMF at the content provider’s discretion.

• Printmaster (reels)

• Composite Mix (full length or parts)

• Music+Effects (one track, two tracks or full multitrack)

• M+E optional material (one track, two tracks or full multitrack)

• Narration

• VI (visually impaired)

• SAP

• Dialog (one track, two tracks, or full multitrack) Often, this is part of a “DME split track”

• Music (one track, two tracks, or full multitrack) Often, this is part of a “DME split track”

• Effects (one track, two tracks, or full multitrack) Often, this is part of a “DME split track”

42 Private Draft Document. Not for Publication

3.3.1.11 Soundfield Configurations

There is only one soundfield configuration allowed per track file. Multiple soundfield configurations cannot be combined in a single audio track file.

The following soundfield configurations must be supported in IMF V.1. Future soundfield configurations must be defined and standardized in order to be supported.

The soundfield configuration must be described in the metadata that is carried with the audio track file. A registry of soundfield configurations is in process in SMPTE 30MR and should be used for this purpose.

• 5.1

• 5.0

• L/R (Lo-Ro) “Standard Stereo”

• Lt-Rt

• Mono

• LCR

• LCRS

• 5.1EX

• 6.1 (discrete)

• 6.0 (discrete)

• 7.1 (L, C, R, Ls, Rs, Rls, Rrs, Sub)

43 Private Draft Document. Not for Publication

3.3.1.12 Channel layout and mapping

Note: SMPTE 428-3 is not applicable to IMF and should not be referenced. 428-3 is specific to digital cinema, is an early document, and will be revised in the future. In addition, SMPTE 31FS-10 is working on defining channel labels using (future) registered UL’s, and this will play a part in all multichannel audio specs once ratified.

IMF V.1 should have a restricted, pattern based layout such that the audio channel layout is always in the same order for a given soundfield configuration e.g. 5.1 (6 channel) would always be L, R, C, Sub, Ls, Rs). These layouts would need to be defined, possibly in an annex of the IMF spec.

IMF V.2 should have the possibility of determining track layout by audio file labeling and/or track file metadata. This would reference and need to be compliant with the 31FS-10 multichannel audio spec.

ADDITIONAL AUDIO ITEMS AND CONCERNS (Please put these in the appropriate area of the spec doc)

1. Partitions:

• Continuous (full length)

• Reels

• Parts

2. Audio Editing Granularity

• Must have frame accuracy within the IMF

• IMF authoring tool must have granularity to the sample

3. Crossfades

• No automatic or automated audio crossfades in the IMF CPL at playout or transcoding.

• Utilize rendered audio to perform difficult crosses between content. These would be created in the audio

editing process and rendered in the IMF authoring process.

44 Private Draft Document. Not for Publication

4. Fade up or fade out (to silence)

• Audio Fade up or fade outs are not supported in IMF.

5. Audio Editing and Transitions

• Hard cuts (“butt splices”) only

• Straightforward cuts and inserts rather than complex editing

6. Audio Insert Considerations

• Audio inserts must be allowed to be of different length than corresponding picture insert to facilitate proper

audio flow across edits

7. Audio Processing

• Audio Dynamic Range Control is not supported in IMF

• “Normalization” of audio is not supported in IMF

• Automatic Gain Control and Volume Changes are not supported in IMF

PARKING LOT ITEMS

1. Homogeneity of audio specs within a Composition

• The initial assumption was homogeneous audio specs would be required in a given composition.

• The audio group has yet to address the possibility of non-homogeneous audio specs within a composition,

which was raised by the TC recently.

2. Metadata

• Metadata has yet to be fully addressed in the audio group

3. Wrapping

• Wrapping has yet to be addressed in the audio group

4. File Naming

45 Private Draft Document. Not for Publication

• File naming has yet to be addressed in the audio group

5. Composition Play List

• The CPL has yet to be addressed by the audio group. Some notes and comments have been made in

chapter 7.

3.3.2. Structural Metadata

The audio group has not addressed metadata specifically as of yet-however, references to places where metadata would be needed are included in the text of 3.3.1 above.

46 Private Draft Document. Not for Publication

4. Data Essence

4.1. Overview

4.1.1. Introduction The Data Essence…

4.1.2. Data Essence System Overview For the purpose of documenting the specific requirements and specifications for Data Essence, it is helpful to divide the system into a set of components. The specifications and requirements for each of these components will be described in the following sections: • Subtitles o Sub picture – The pre-rendered open text specification and file format o Timed Text – The Timed Text data specification and file format • Captions - The Captions specification with similar categories as Subtitles above. o Sub picture – The pre-rendered open text specification and file format o Timed Text – The Timed Text data specification and file format

4.1.3. Major Data Essence Concepts Fill in the blanks……

4.1.4. Data Essence Fundamental Requirements

4.1.4.1. Common File Formats The Essence and Data Essence is required to use a common standardized file format for each element (image, audio, subtitles, etc.). The image essence file format is required to be an SMPTE-conformant file based on existing SMPTE standards. The audio essence file format is required to be based on Broadcast Wave. The Subtitle essence should be based on PNG and XML file formats.

4.1.4.2. Frame Rates The image structure is required to support a frame rate of 24.000 and 23.976 Hz. The image essence structure can also support a frame rate of 59.94 Hz. The frame rate of any individual IMF source master is required to remain constant. Metadata is carried in the image data file format to indicate the frame rate.

4.1.4.3. Synchronization Files within the image and/or audio essence are required to carry information to provide for frame-based synchronization between each file. At a minimum, they are required to include a start of file and a continuous frame count.

47 Private Draft Document. Not for Publication 4.2. Subtitle Specification

4.2.1. Sub picture

4.2.2. Timed Text

4.3. Caption Specification

4.3.1. Sub picture

4.3.2. Timed Text

48 Private Draft Document. Not for Publication

5. Dynamic Metadata

5.1. Overview

5.1.1. Introduction The Metadata…

5.1.2. Dynamic Metadata System Overview For the purpose of documenting the specific requirements and specifications for Metadata, it is helpful to divide the system into a set of components. The specifications and requirements for each of these components will be described in the following sections: • Time code – The specification and file format for Time code Dynamic Metadata • Pan and Scan – The specification and file format for Image Pan and Scan Dynamic Metadata • Color Correction – The specification and file format for Image Color Correction and Scan Dynamic Metadata • Dynamic Down-mixing – The specification and file format for Audio Dynamic Down-mixing Dynamic Metadata NOT SUPPORTED IN IMF PER THE AUDIO GROUP.

5.1.3. Major Dynamic Metadata Concepts Fill in the blanks……

5.1.4. Dynamic Metadata Fundamental Requirements

5.1.4.1. Common File Formats The Dynamic Metadata is required to use a common standardized file format for each element (Time code, aux data, etc.). The time code file format is required to be an MXF-conformant file based on existing SMPTE standards.

5.1.4.2. Frame Rates The time code structure is required to support a frame rate of 24.000 (or 23.976) Hz. The time code structure should also support a frame rate of 60.00 (or 59.94) Hz. The frame rate of any individual IMF source master is required to remain constant.

5.2. Time code Specification

5.3. Pan and Scan Specification

5.4. Color Correction Specification

5.5. Dynamic Down-mixing Specification NOT SUPPORTED IN IMF

49 Private Draft Document. Not for Publication

6. Wrapping

6.1. Overview

6.1.1. Introduction The IMF, as stated in the System Overview, is a collection of files, such as picture essence files and audio essence files. These files, as they stand by themselves, do not represent a complete presentation. Synchronization tools, asset management tools, Metadata, content protection and other information are required for a complete presentation to be understood and played back as it was intended. This is especially important when the files become compressed and/or encrypted and are no longer recognizable as image essence or audio essence in this state. Wrapping is a way to organize and wrap this material in such a way as to make it suitable for storage and movement to its destination. In seeking a common interchange standard for Digital Video between facilities and equipment, it is understood that there may be multiple sources of content. This will require special consideration to achieve IMF interchange. Thus, an interchange wrapping structure is needed that operates across several domains. The section also provides a set of requirements for the Material eXchange Format (MXF) track file encryption and creation.

6.1.2. Wrapping System Overview For the purpose of documenting the specific requirements and specifications for Wrapping, it is helpful to divide the system into a set of components. The specifications and requirements for each of these components will be described in the following sections: • Track Files – The specification and file format for the creation of Track Files o Encryption - The specification for encrypting Essense, Data Essence and Dynamic Metadata if required. o Essence – The specific specifications and file format for wrapping Essence files o Data Essence– The specific specifications and file format for wrapping data essence files o Dynamic Metadata– The specific specifications and file format for wrapping Dynamic Metadata files

6.2. Wrapping Fundamental Requirements

6.2.1. Common File Formats The wrapping process is required to use a common standardized file format for each type of element (Image, audio, Time code, aux data, etc.). This format is required to be an MXF-conformant file based on existing SMPTE standards.

6.2.2. Frame Rates The time code structure is required to support a frame rate of 24.000 (or 23.976) Hz. The time code structure should also support a frame rate of 60.00 (or 59.94) Hz. The frame rate of any individual IMF source master is required to remain constant.

6.3. Wrapping Overview

6.3.1. Introduction The Audio and Image Track Files are the fundamental element in the IMF system. The audio and Image Track File structure and requirements, are defined by the Essence, Data Essence or Dynamic Metadata information

50 Private Draft Document. Not for Publication they contain. Each of these Essence, Data Essence or Dynamic Metadata containers could be image, sound, subtitle (Timed Text, and/or sub picture), caption or auxiliary data. However, each track file follows the same basic file structure. A track file consists of three logical parts: the File Header, the File Body and the File Footer as shown in Figure 7 below.

Figure 7 - Example Track File Structure

The file structure is further broken down into logical data items as defined in [SMPTE 336M Data Encoding Protocol using Key-Length-Value]. The KLV Coding Protocol is composed of Universal Label (UL) identification Key (UL Key), followed by a numeric Length (Value Length), followed by the data Value as shown below in Figure 8 below. One or more of these data items are combined to form the logical parts shown above.

Length

UL Key Length Value

16 bytes BER Variable Length Octets

Figure 8 - Example of KLV Coding

6.3.2. Format Information Each track file is required to be a self-contained element, such that it’s Essence or Metadata can be understood and presented as it was packaged by a compliant decoder. The information is required to be located in the predetermined specified area. The Track File is to contain the following minimum information: • Required Metadata for unique asset identification • Required Metadata for decompression (optional) • Required Metadata for decryption (optional) The following information is required to be configured in a human readable format: • Essence physical format description. (e.g., 4096 x 2160) • Essence title asset information. (e.g., The_Perfect_Movie_English_ R2)

6.3.3. Sequence A Sequence is a conceptual period of time having a specific duration. • Track Files are required to be associated with a particular Sequence. • A Track File is required to not cross over a Sequence boundary that is a playable portion of a Track File, between the mark in and mark out points. • Sequence’s are required to be composed of one or more Track Files.

51 Private Draft Document. Not for Publication

• The minimum duration of a Track File within a sequence is required to be an integer number of frames, such that the length is greater than or equal to one (1) frame.

6.3.4. Track File Replacement A Track File is the smallest unit that can be managed or replaced as a discrete file in the field.

6.3.5. Synchronization Each Track File is required to contain the following synchronization information: • Start of Essence Data (mark in) • End of Essence Data (mark out) • Track File Frame Count • Frame Rate • Internal Synchronization

6.3.6. Splicing Track Files, of the same Essence type, are required to allow for seamless or click-free splicing to create a continuous data stream for a presentation. The playback system is required to be able to perform sample accurate or click free splicing of audio track files.

6.3.7. Key Epoch A Key Epoch is the period of time during which a given Decryption Key is effective. The Key Epoch is one Reel.

6.3.8. Security Each Track File is required to provide for encryption and methods to authenticate the data, if the content provider chooses to use such methods. In addition: • The Essence container is required to allow encrypted data, while the rest of the Track File Metadata is left unencrypted. • At any point in the delivery chain, it is required to be possible to detect whether any accidental or intentional alteration has occurred.

6.3.9. Integrity and Authentication Each Track File is required to provide a method for verification of file integrity that can be easily determined at any step of the delivery process. In addition: • It is encouraged that missing or corrupted data be easily identified. • Track Files are encouraged to be subdivided into smaller segments, which have individual authenticity/error-check codes. This facilitates a decision as to whether the file is so corrupt it cannot be played, or whether it is safe to proceed with play out while requesting a replacement Track File. • Synchronization with other Track Files is encouraged to be verifiable.

6.3.10. Extensibility The Operational Pattern is required to accommodate future extensions within its original scope.

52 Private Draft Document. Not for Publication

6.3.11. Random Access and Restarts The Operational Pattern is required to support random access to the nearest integer minute. Random access to individual frames is neither required nor desired. A restart occurs as a result of a stop or pause in the system while executing a Composition PlayList. The system may be restarted at any frame prior to the frame at which it was stopped or paused. It is required that a restart be logged by the Security Manager, provided the Essence (either image, audio or subtitle) is encrypted.

6.3.12. Simple Essence A track file is required to contain essence of a single Essence type (e.g., audio, image, subtitles). While a Track File can, for instance, contain all audio channels for a given language, additional languages are required to be stored in separate track file. The Composition PlayList will select the correct Track Files to play a requested version of the movie (composition).

6.4. MXF Track File Encryption

6.4.1. Introduction The following are requirements for MXF Track File Encryption. For the purpose of this section, a frame is defined as an image frame time, for example 24 FPS or 48 FPS. • The encryption shall support KLV encoding as specified in SMPTE 336 Data Encoding using Key- Length-Value. • The encrypted sound or picture Track File shall be a valid MXF file. • KLV packets shall be encrypted using the Advanced Encryption Standard (AES) block cipher algorithm using a 128 bit key operating in Cipher Block Chaining (CBC) mode, as defined in NIST SP 800-38A. See National Institute of Standards and Technology FIPS 197 (November 26, 2001). Advanced Encryption Standard. • Each shall use a single cryptographic key for all frames within the sound or picture Track File. • The encryption method shall support random access to any frame of essence within the sound or picture Track File. • The integrity of each frame of sound and picture essence shall be verifiable using the HMAC-SHA1 algorithm. • There shall be a method for verifying that all frames within a sound and picture track are played in correct sequence. • The Track File encryption method shall allow for the common header data within each frame of Essence to be plain text. In other words, the encryption of each frame of essence shall have a programmable offset of “n” bytes such that common header data is left as plaintext. • There shall be a method for verifying that the correct cryptographic key is used and the essence is being decrypted correctly. • A reference decryption model shall be specified. • Track File encryption shall not require encryption of all frames within a file. • Track File encryption shall be independent of the nature of the underlying essence and associated metadata. • No information shall be lost in the Track File encryption process.

53 Private Draft Document. Not for Publication

6.4.2. Encrypted Track File Constraints Encrypted Track Files shall follow the same specification as plain-text Track Files, with the following additional constraints. The following are included in the Encrypted Track File Constraints: • Encrypted Essence Track – A single cryptographic key, and hence, Cryptographic Context, shall be used to encrypt any given Essence track. • Cryptographic Framework Descriptive Metadata Track – Track Files may contain one or more Descriptive Metadata Tracks in the MXF File Package that describes the Essence of the Track File. • Index Tables – In a plain-text Track File, each Index Table entry locates a Triplet containing a single frame of picture Essence. Similarly, in an encrypted Track File, each Index Table entry shall point to an Encrypted Triplet wrapping a single Triplet, itself containing a single frame of picture Essence.

K L V

encryption / decryption

Cryptographic Cryptographic K’ L’ K L E(V) information information (opt)

V’

Figure 9 - Correspondence between Source and Encrypted Triplets1

Figure 9 above illustrates the correspondence between a plaintext KLV triplet and an Encrypted KLV Triplet. The value V of a source plaintext KLV Triplet is first encrypted to yield E(V). This encrypted value, E(V), along with K and L, is wrapped in a K’L’V’ Encrypted Triplet. K' is a unique label common to all Encrypted KLV Triplets, independent of their content. L' refers to the full length of V'. V' consists of K, L and E(V) from the source KLV Triplet as well as cryptographic information specific to the Encrypted KLV Triplet. This cryptographic information includes, for instance, the initialization vector used in generating E(V) and the Message Integrity Code used to verify the integrity of the Triplet.

6.5. Image Track File

6.5.1. Introduction An Image Track File contains the image Essence data and its associated Metadata. Each Image Track File can contain compressed and encrypted image data. The following are requirements for an Image Track File.

6.5.2. Frame Boundaries The Image Track File is required to begin and end with complete frames that allow for splicing. Frames are defined to be image frames such as 24 FPS (1/24 sec) or 48 FPS (1/48 sec).

6.5.3. Compression The Track File is required to support Constant Bit Rate (CBR) compression and Variable Bit Rate (VBR) compression, within the constraints of the specified code stream for the reference decoder

1 Red hatching depicts the encrypted portion of the Encrypted Triplet. Other items are left in the clear. Only the value item of Source Triplet is encrypted, allowing the Essence information to be encrypted prior to wrapping. See “Encrypted Triplet” for a description of the cryptographic information associated with each Encrypted Triplet.

54 Private Draft Document. Not for Publication

6.5.4. Metadata The following Metadata is required to be furnished with the Image Track File: • Unique ID • Unique ID of corresponding plaintext track if encrypted • Track type (i.e., mage) • Total width in pixels • Total height in pixels • Aspect Ratio • Frame Rate • Frame count number (duration)

6.6. Audio Track File

6.6.1. Introduction An Audio Track File contains the audio Essence data and its associated Metadata. The following are requirements for an Audio Track File.

6.6.2. Frame Boundaries 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.

6.6.3. Data Packing Format The Track File is required to support uncompressed audio data.

6.6.4. Metadata The following Metadata is required to be furnished with the Audio Track File: • Unique ID • Unique ID of corresponding plaintext track encrypted • Track type (i.e., audio) • Audio Sampling Frequency • Quantization bits (sample size) • Channel Count • Channel Mapping Labels • Data Packing Format • Frame Rate • Audio Frame count number (duration)

6.7. Subtitle Track File

6.7.1. Introduction A Subtitle Track File contains, for example, the Subtitling Essence data and its associated Metadata. Each Subtitle Track File may contain any combination of text, font references, and image references.

55 Private Draft Document. Not for Publication

6.7.2. Frame Boundaries The Subtitle Track File is required to have the same duration as the playable region of its associated Image Track File.

6.7.3. Timed Text Any Timed Text element is required to use an Open Type font.

6.7.4. Sub picture Sub picture elements are required to use the PNG file format.

6.7.5. Metadata The following Metadata is required to be furnished with the sub picture Track File: • Unique identification • Track Type (i.e., Timed Text, sub picture) • Total Width In Pixels of the Image Track File (PNG files only) • Total Height In Pixels of the Image Track File (PNG files only) • Aspect Ratio (PNG files only) • Frame Rate • Position • Timing (Temporal)

6.8. Captions Track File

6.8.1. Introduction A Caption Track File contains, for example, the Captions Essence data and its associated Metadata. Each Captions Track File may contain any combination of text, font references, and image references.

6.8.2. Frame Boundaries The Captions Track File is required to have the same duration as the playable region of its associated Image Track File.

6.8.3. Timed Text Any Timed Text element is required to use an Open Type font.

6.8.4. Sub picture Sub picture elements are required to use the PNG file format.

6.8.5. Metadata The following Metadata is required to be furnished with the sub picture Track File: • Unique identification • Track Type (i.e., Timed Text, sub picture) • Total Width In Pixels of the Image Track File (PNG files only) • Total Height In Pixels of the Image Track File (PNG files only) • Aspect Ratio (PNG files only)

56 Private Draft Document. Not for Publication

• Frame Rate • Position • Timing (Temporal)

6.9. Time Code Track Files (Optional)

6.9.1. Introduction A Time Code Track File contains, for example, the Unicode text data or any other data or Metadata that belongs in a separate track for functional purposes. The following are requirements for a Time Code Track File.

6.9.2. Frame Boundaries The Time Code Track File is encouraged to begin and end with complete frames that are associated with its Image Track File to allow for a clean transition between reels.

6.9.3. Metadata The following Metadata is required to be furnished with the Time Code Track Files: • Unique identification • Track Type (i.e., auxiliary) • Frame Count Number • Text Format (If Applicable) • Cue Names (If Applicable)

6.10. Pan and Scan Track Files (Optional)

6.10.1. Introduction A Pan and Scan Track File contains, for example, the Unicode text data or any other data or Metadata that belongs in a separate track for functional purposes. The following are requirements for a Pan and Scan Track File.

6.10.2. Frame Boundaries The Pan and Scan Track File is encouraged to begin and end with complete frames that are associated with its Image Track File to allow for a clean transition between reels.

6.10.3. Metadata The following Metadata is required to be furnished with the Pan and Scan Track Files: • Unique identification • Track Type (i.e., auxiliary) • Frame Count Number • Text Format (If Applicable) • Cue Names (If Applicable)

57 Private Draft Document. Not for Publication 6.11. Color Correction Track Files (Optional)

6.11.1. Introduction A Color Correction Track File contains, for example, the Unicode text data or any other data or Metadata that belongs in a separate track for functional purposes. The following are requirements for a Color Correction Track File.

6.11.2. Frame Boundaries The Color Correction Track File is encouraged to begin and end with complete frames that are associated with its Image Track File to allow for a clean transition between reels.

6.11.3. Metadata The following Metadata is required to be furnished with the Color Correction Track Files: • Unique identification • Track Type (i.e., auxiliary) • Frame Count Number • Text Format (If Applicable) • Cue Names (If Applicable)

6.12. Dynamic Down-mixing Track Files (Optional)

6.12.1. Introduction A Dynamic Down-mixing Track File contains, for example, the Unicode text data or any other data or Metadata that belongs in a separate track for functional purposes. The following are requirements for a Dynamic Down-mixing Track File.

6.12.2. Frame Boundaries The Dynamic Down-mixing Track File is encouraged to begin and end with complete frames that are associated with its Image Track File to allow for a clean transition between reels.

6.12.3. Metadata The following Metadata is required to be furnished with the Dynamic Down-mixing Track Files: • Unique identification • Track Type (i.e., auxiliary) • Frame Count Number • Text Format (If Applicable) • Cue Names (If Applicable)

58 Private Draft Document. Not for Publication

7. The Composition

7.1. Introduction The Composition represents a complete self-contained digital media program. This Composition maybe a feature, episode, trailer, advertisement or any other single piece of content. A composition usually consists of at a minimum a Composition PlayList (CPL) and one or more Track Files, which contain the actual program Essence. A very simplified example of the Hierarchical Structure for a Composition is given below.

7.2. Functional Framework For the purpose of documenting the specific requirements for a Interoperable Master Format Packaging system, it is helpful to divide the system into a set of components. The performance requirements for each of these components will be described in the following sections: • Composition – A self-contained representation of a single complete Digital Video work, such as a motion picture, or a trailer, or an advertisement, etc. • Composition PlayList - The instructions to a play out device or a transcoder on how to assemble the Track Files together to create a version of the program. (Similar to an Edit Decision List) • Composition Security – The specifications and requirements of a Security framework the end users may or may not take advantage of.

7.3. The Composition Fundamental Requirements

7.3.1. Open Standard The Composition standard is required to be based upon an open worldwide standard. This format is encouraged to be a license-free technology. It is required to be a complete standard that equipment receiving a compliant Composition can process and interpret unambiguously.

7.3.2. Interoperable The Composition format is required to have an open framework that accommodates compressed, encrypted files as well as all other files used in Digital Video.

7.3.3. Scalable The Composition format is required to accommodate any number of Essence or Metadata components. There is no limit on the number of files included in the package or the size of the files.

7.3.4. Extensible The Composition format is required to allow for new Digital Video features (compositions) to be contained within the package.

7.3.5. Synchronization The Composition format is required to provide support for synchronization of the Essence and Metadata elements.

7.3.6. Human Readable Metadata Human readable Metadata is required to be in English (default) but can be provided in other languages as well.

59 Private Draft Document. Not for Publication

7.3.7. File Format The Composition PlayList is required to use the secure (digitally signed) text-based XML file format. More specifically the structures defined in this document are represented using the Extensible Markup Language (XML) [XML 1.0], and specified using XML Schema [XML Schema Part 1: Structures] and [XML Schema Part 2: Datatypes]. This specification shall be associated with a unique XML namespace name [Namespaces in XML]. The namespace name shall be the string value “http://www.tbd.org“. This namespace name conveys both structural and semantic version information, and serves the purpose of a traditional version number field. Table 2 lists the XML namespace names used in this specification. Namespace names are represented as Uniform Resource Identifier (URI) values [RFC 2396]. These values shall be considered as simple strings, and applications should not attempt to resolve them as URLs.

Table 2. XML Namespaces. Qualifier URI cpl http://www.tbd.org/date xs http://www.w3.org/2001/XMLSchema ds http://www.w3.org/2000/09/xmldsig

The namespace qualifier values (namespace prefixes in XML jargon) used in this document (cpl, xs, ds), are not normative values. Implementations shall perform correctly with any XML compliant namespace prefix value that is associated with a URI from table 1 above. Datatypes from other schemas that are used in this document will be prefixed with the appropriate namespace qualifier (e.g. xs:dateTime). See [XML Schema Part 2: Datatypes] and [XML-Signature Syntax and Processing] for further information about these types. The MIME type [IETF RFC 2046] for a document containing a single Composition PlayList element as its root shall be “text/xml”.

7.4. Terminology The following terms are used to describe the features of this specificationstandard.

Sequence A single or contiguous set of Track Files intended to be reproduced sequentially within a Composition Composition A complete artistic or informational motion picture work, such as a feature, episode, trailer, or an advertisement, etc. Essence The sound, picture and data resources that ultimately are intended for a viewing and/or listening experience. Editable Unit The smallest temporal increment of access to Essence, e.g. a frame or a sample. Edit Rate A number of Editable Units to be reproduced during a temporal interval having a duration of exactly one (1.0) second. Because Edit Rate values are not always integer values and sometimes require many digits of precision, Edit Rate values are expressed as a rational number (the ratio of two integers). Native Duration The total number of Editable Units in a Track File. Native Start Point The first Editable Unit of a Track File. All Track Files are viewed by a Composition PlayList as a sequence of Editable Units numbered from 0 (zero). Consequently, the Editable Unit number of the Native Start Point of a Track File will always be 0 (zero). Native End Point The last Editable Unit of a Track File. Playable Region The set of Editable Units within a Track File that are intended to be reproduced as part of a Composition. A Track File may contain Editable Units before and/or after the Playable Region. Track File A file containing a single Essence, such as sound, picture or subtitle essence. Sample Rate The number of essence samples per second. Sample Rate values are expressed as a rational number (the ratio of two integers) Frame Rate The number of frames per second. Frame Rate values are expressed as a rational number (the ratio of two integers)

60 Private Draft Document. Not for Publication

7.5. Synchronization The Composition PlayList defines an idealized playback timeline using XML to provide information to the transcoder or playback device describing the order and parameters used to manipulate the files. As depicted in first in Figure 1 previously, and now below in Figure 10, the timeline consists of a contiguous set of Sequences that are spliced together, which fit within the region of a complete Composition.

Figure 10 - Composition PlayList sequence

•

Continuing with this hierarchical method, as depicted in Figure 11, the expanded Sequence consists of a set of synchronized Track Files along with their associated Metadata Track Files. •

61 Private Draft Document. Not for Publication

Figure 11 - Timing relationships within a Sequence

For example, the CPL identifies a segment of a Track File to be reproduced in parallel with the other Track Files in the same Clip or Sequence. The Asset’s Entry Point and Duration parameters define the order of Editable Units within the Track File that is to be reproduced (the Playable Region). Track Files are aligned with offsets from their Native Start Points from which they are then synchronized and shall be reproduced simultaneously. Using this same method Figure 12 illustrates the timing relationship between Track Files within a Sequence including transitions.

62 Private Draft Document. Not for Publication

Figure 12 - Sequence Sync Relationship Example

At the start of a given Sequence, playback of all Track Files contained within that Sequence shall start simultaneously at the Entry Point given for each respective Track File. The duration of a Sequence shall be equal to the total duration of the Sequence’s MainPicture Track Files, or the Track Files with the shortest duration if the MainPicture Track File is not present.

63 Private Draft Document. Not for Publication

7.6. Composition PlayList Structure Composition PlayList shall be represented by a unique XML element, the CompositionPlaylist element. The Composition PlayList shall be encoded using the UTF-8 character encoding [XML 1.0]. The Composition PlayList shall include the following fields unless stated as optional in which case they may be included.

7.6.1. General Information The Composition PlayList should provide the following general information to allow quick access to the information about the composition. This should allow either humans or automated systems to source the general information. Below is the list of the both the informative information and required information to complete the structure of the Composition PlayList. Some items are optional and therefore not required for a compliant Composition PlayList. Other sections are described in more detail in later sections. • Unique ID • Annotation Text [optional] • Issue Date • Issuer [optional] • Creator [optional] •

• Content Title Text [optional] • Content Kind (e.g., Feature, Trailer, Logo, Advertisement, Episode) • Content Version o ID [optional] o Label Text [optional] • Content Description o Source Media Description [optional] o Frame Rate o Timecode Type [optional] o Image Encoding Type o Audio Sample Rate o Audio Samples/Frame o Audio Configuration o Audio Bit Depth o Subtitle Type o Caption Type • Media File Size • Total Running Time • Language • Country • Rating [optional]

64 Private Draft Document. Not for Publication

o Agency o Label • Image Output Format o Pixel Matrix (i.e. 1080p, 720p) o Color encoding i. Standards Body ii. Label o Compression Standard [optional] i. Standards Body [optional] ii. Label [optional] o Display Aspect Ratio (4:3, 16:9) o Frame Rate o Picture Overlays [optional] i. Timecode [optional] ii. Spoiler [optional] • Audio Output Format o Audio Configuration (i.e. LtRt, 5.1, 7.1) o Sampling Frequency o Bit Depth o Compression Standard [optional] i. Standards Body [optional] ii. Label [optional] • Subtitle Format (i.e. CEA-708) • Captions Format (i.e. CEA-708) • Speed Offset [optional] • Encryption (yes/no) • Sequence List • Signer [optional] • Signature [optional]

7.6.2. Unique Id The Id element uniquely identifies the Composition PlayList for asset management purposes. It shall not uniquely identify the content represented by the composition. It shall be encoded as a urn:uuid per [RFC 4122].

7.6.3. AnnotationText [optional] The AnnotationText element shall be a free-form, human-readable annotation describing the composition. It is meant strictly as a display hint to the user. The optional language attribute is an xs:language language code and indicates the language used for the text. If the language attribute is not present, the default value en shall be used.

65 Private Draft Document. Not for Publication

7.6.4. IssueDate The IssueDate element shall be used to define the time and date at which the Composition PlayList was issued. It may be displayed to the user. It shall be encoded as an xs:dateTime.

7.6.5. Issuer [optional] The Issuer element shall be a free-form, human-readable annotation that shall identify the entity that created the Composition PlayList. It is meant strictly for display to the user. The Signer element defined in Section 7.6.24 shall be used to identify the entity that digitally signed the Composition PlayList. The optional language attribute is an xs:language language code and indicates the text language of the content of the element. If the language attribute is not present, the default value en shall be used.

7.6.6. Creator [optional] The Creator element shall be a free-form, human-readable annotation that shall identify; the application used to create the Composition PlayList, the Facility that created the CPL and the operator that created the CPL. It is meant strictly for display to the user. The optional language attribute is an xs:language language code and indicates the text language of the content of the element. If the language attribute is not present, the default value en shall be used.

7.6.7. ContentTitleText The ContentTitleText element shall contain a human-readable title for the composition, e.g. The Jazz Singer. It is strictly meant as a display hint to the user. The optional language attribute is an xs:language language code and indicates the language of the content of the element. If the language attribute is not present, the default value en shall be used.

7.6.8. ContentKind The ContentKind element defines the kind of material referred to by the Composition PlayList. It is meant to be both human and machine-readable. Table 3 below show examples of Content Kind.

Table 3. Examples of Content Kind. Kind Description  feature A theatrical feature.  trailer Short (2 to 3 minutes) content promoting an upcoming theatrical feature.  test Content used to test, calibrate or setup equipment.  teaser Very short (typically less than 1 minute) content promoting an upcoming theatrical feature.  rating Slate/still picture indicating the recommended age group permitted to view the content to follow. This rating is generally unique per country.  advertise Content promoting a product or service other than ment an upcoming feature.  short Non advertising/promotional content (3 to 15 minutes) typically before a theatrical feature.  transitio Extremely short content (1 to 15 seconds) nal separating unrelated compositions.  psa Public service announcement.

7.6.9. ContentVersion Thise defines the version of the content referred to by the composition, as opposed to the Composition PlayList Id element which uniquely identifies an instance of the Composition PlayList. Thus there may be two distinct compositions, with distinct CompositionPlaylist Id values, that refer to the same content and thus have the same ContentVersion Id value. This may occur, for example, if a composition is distributed to supercede a previous version. Similarly, while two compositions may share the same content title, they may

66 Private Draft Document. Not for Publication refer to two different versions, such as French (dubbed) and French (original), and therefore have two distinct ContentVersion Id values. The ContentVersion element is meant to assist both users and software in scheduling and tracking content.

7.6.9.1. Id The Id element shall identify the content contained in the Composition PlayList. It shall be a valid URN, per [RFC 2141].

7.6.9.2. LabelText The LabelText element shall be a human readable label, e.g. “French (1.85 picture, 16.1 sound, dubbed)”, describing the content. The optional language attribute is an xs:language language code and indicates the text language of the content of the element. If the language attribute is not present, the default value en shall be used.

7.6.10. ContentDescription This describes the content referred to by the composition. Most of this information is also contained in the metadata of the Track Files. It is provided here in human readable form for informative purposes only. Machines should not rely on this information for transcoding or Play-Out and in all cases the Track File metadata takes priority over information provided here. The ContentDescription element is meant to assist both users and software in scheduling and tracking content.

7.6.10.1. SourceMediaDescription [optional] The SourceMediaDescription element shall be human readable text, e.g. “HDCamSR (1.85 picture, 16.1 sound, dubbed)”, describing the content source. The optional language attribute is an xs:language language code and indicates the text language of the content of the element. If the language attribute is not present, the default value en shall be used. Further more an element ID and LabelText can be added to the description and is specified below.

7.6.10.2. Id [optional] The Id element shall identify the content contained in the Composition PlayList. It shall be a valid URN, per [RFC 2141].

7.6.10.3. LabelText [optional] The LabelText element shall be a human readable label, e.g. “French (1.85 picture, 16.1 sound, dubbed)”, describing the content. The optional language attribute is an xs:language language code and indicates the text language of the content of the element. If the language attribute is not present, the default value en shall be used.

7.6.10.4. FrameRate The FrameRate element shall contain the number of frames per second of the intended playback rate of the MainPicture element. (ex. 23.98 or 59.94) This is informative information to allow for humans and machine to read and if necessary manipulate the MainPicture asset of the Composition to conform to the FrameRate.

7.6.10.5. TimecodeType [optional] The TimecodeType element shall contain information of the timecode format of the MainPicture element. This is informative information to allow for humans and machine to read and if necessary manipulate the MainPicture asset of the Composition to conform the picture information to the Compression specification.

67 Private Draft Document. Not for Publication

7.6.10.6. ImageEncodingStandard [optional] The ImageEncodingStandard element shall contain information of the encoding paramaters of the MainPicture element. This is informative information to allow for humans and machine to read and if necessary manipulate the MainPicture asset of the Composition to conform the picture information to the encoding specification.

7.6.10.7. StandardsBody [optional] The StandardsBody element shall contain a URI [RFC 2396] that uniquely identifies the Standards Body issuing the Standard.

7.6.10.8. Label [optional] The Label element shall contain a textual representation of the Standards Body, which may be displayed to the user. For each issuing Standards Body, and hence unique URI, there are a number of permissible Label values. An example of such is shown below in Table 4. The specification of this mapping is beyond the scope of this document.

7.6.10.9. AudioSamplingRate The AudioSamplingRate element shall contain the integer of the sampling rate of the MainSound element. (ex. 48 or 96 ) This is informative information to allow for humans and machine to read and if necessary manipulate the MainSound asset of the Composition to conform to the AudioSamplingRate.

7.6.10.10. AudioConfig The AudioConfig element shall contain the Channel configuration of the MainSound element. (ex. LtRt, 5.1 etc.) This is informative information to allow for humans and machine to read and if necessary manipulate the MainSound asset of the Composition to conform to the AudioConfiguration.

7.6.10.11. AudioBitDepth The AudioBitDepth element shall contain the integer of bits per sample of the MainSound element. (ex. 16 or 24) This is informative information to allow for humans and machine to read and if necessary manipulate the MainSound asset of the Composition to conform to the AudioBitDepth.

7.6.11. SubtitleFormat [optional] The SubtitleFormat element defines the format of the MainSubtitle of material referred to by the Composition PlayList. It is meant to be both human and machine-readable.

7.6.12. CaptionFormat [optional] The CaptionFormat element defines the format of the MainCaption of material referred to by the Composition PlayList. It is meant to be both human and machine-readable.

7.6.13. TotalRunningTime The TotalRunningTime element shall be used to define the complete running time of the Composition at the instance when Composition PlayList was issued. It may be displayed to the user. It shall be encoded as an xs:hours:minutes:seconds:frames.

7.6.14. Language [optional] The Language element shall reflect the primary spoken or textual language of the Composition. The element value is encoded as an xs:language language code and indicates the primary language of the content.

68 Private Draft Document. Not for Publication

7.6.15. Country [optional] The Country element shall reflect the primary area of intended distribution of the Composition. This shall use the ISO standard three-letter acronym for it designation.

7.6.16. RatingList [optional] The RatingList element shall contain an ordered list of zero or more Rating elements containing ratings associated with the composition. Each Rating element, shown in Table 4, contains an Agency and a Label element. Each element is meant to be both human and machine-readable. There shall be only one Rating element per given Agency.

7.6.16.1. Agency The Agency element shall contain a URI [RFC 2396] that uniquely identifies the agency issuing the rating.

7.6.16.2. Label The Label element shall contain a textual representation of the rating, which may be displayed to the user. For each issuing agency, and hence unique URI, there are a number of permissible Label values. The specification of this mapping is beyond the scope of this document

Table 4. Example Ratings (Informative). Agency Labels http://www.mpaa.org/2003-ratings R, PG, PG-13, G, NC-17 http://rcq.qc.ca/2003-ratings G, 13+, 16+, 18+

7.6.17. ImageOutputFormat The ImageOutputFormat element defines the output format of the MainPicture of material referred to by the Composition PlayList. It is meant to be both human and machine-readable.

7.6.17.1. ImageCompressionStandard [optional] The ImageCompressionStandard element shall contain information of the compression encoding paramaters of the MainPicture element. This is informative information to allow for humans and machine to read and if necessary manipulate the MainPicture asset of the Composition to conform the picture information to the Compression specification.

7.6.17.2. StandardsBody [optional] The StandardsBody element shall contain a URI [RFC 2396] that uniquely identifies the Standards Body issuing the Standard.

7.6.17.3. Label [optional] The Label element shall contain a textual representation of the Standards Body, which may be displayed to the user. For each issuing Standards Body, and hence unique URI, there are a number of permissible Label values. An example of such is shown below in Table 4. The specification of this mapping is beyond the scope of this document.

7.6.17.4. OutputPixelMatrix The OutputPixelMatrix element shall contain the horizontal and vertical pixel counts of the MainPicture element. This is informative information to allow for humans and machine to read and if necessary manipulate the MainPicture asset of the Composition to conform to the OutputPixelMatrix requirements.

7.6.17.5. OutputColorEncoding The OutputColorEncoding element shall contain information of the color encoding parameters of the MainPicture element. This is informative information to allow for humans and machine to read and if

69 Private Draft Document. Not for Publication

necessary manipulate the MainPicture asset of the Composition to conform the color information to the OutputColorEncoding specification.

7.6.17.6. StandardsBody [optional] The StandardsBody element shall contain a URI [RFC 2396] that uniquely identifies the Standards Body issuing the Standard.

7.6.17.7. Label [optional] The Label element shall contain a textual representation of the Standards Body, which may be displayed to the user. For each issuing Standards Body, and hence unique URI, there are a number of permissible Label values. An example of such is shown below in Table 4. The specification of this mapping is beyond the scope of this document.

Table 5. Examples Standards Body Labels Label URI SMPTE STD xxx- http://www.smpte.org/date y W3 http://www.w3.org/2001 ISO http://www.ISO.org/2009

7.6.17.8. DisplayAspectRatio The DisplayAspectRatio element shall contain the ratio intended display screen of the MainPicture element. (ex. 4:3 or 16:9) This is informative information to allow for humans and machine to read and if necessary manipulate the MainPicture asset of the Composition to conform to the DisplayAspectRatio.

7.6.17.9. FrameRate The FrameRate element shall contain the number of frames per second of the intended playback rate of the MainPicture element. (ex. 23.98 or 59.94) This is informative information to allow for humans and machine to read and if necessary manipulate the MainPicture asset of the Composition to conform to the FrameRate.

7.6.17.10.OutputPictureOverlay [optional] The OutputPictureOverlay element shall contain information about the auxiliary overlay image elements for the MainPicture element. This is informative information to allow for humans and machine to read and if necessary manipulate the MainPicture asset of the Composition to conform the aspects of the required OutputPictureOverlay.

7.6.17.11.TimeCodeWindow [optional] The TimeCodeWindow element shall contain a designation that uniquely identifies the Timecode type and spatial location for the OutputPictureOverlay.

7.6.17.12.Spoiler [optional] The Spoiler element shall contain a textual representation and spatial location for the OutputPictureOverlay.

7.6.18. OutputAudioFormat The OutputAudioFormat element defines the format of the MainSound of material referred to by the Composition PlayList. It is meant to be both human and machine-readable.

7.6.18.1. AudioCompressionStandard [optional] The AudioCompressionStandard element shall contain information of the compression encoding parameters of the MainSound element. This is informative information to allow for humans and machine to

70 Private Draft Document. Not for Publication

read and if necessary manipulate the MainSound asset of the Composition to conform the sound information to the Compression specification.

7.6.18.2. StandardsBody [optional] The StandardsBody element shall contain a URI [RFC 2396] that uniquely identifies the Standards Body issuing the Standard.

7.6.18.3. Label [optional] The Label element shall contain a textual representation of the Standards Body, which may be displayed to the user. For each issuing Standards Body, and hence unique URI, there are a number of permissible Label values. An example of such is shown below in Table 4. The specification of this mapping is beyond the scope of this document.

7.6.18.4. OutputAudioConfig The OutputAudioConfig element shall contain the Channel configuration of the MainSound element. (ex. LtRt, 5.1 etc.) This is informative information to allow for humans and machine to read and if necessary manipulate the MainSound asset of the Composition to conform to the OutputAudioConfiguration.

7.6.18.5. OutputAudioSamplingRate The OutputAudioSamplingRate element shall contain the integer of the sampling rate of the MainSound element. (ex. 48 or 96 ) This is informative information to allow for humans and machine to read and if necessary manipulate the MainSound asset of the Composition to conform to the OutputAudioSamplingRate.

7.6.18.6. OutputAudioBitDepth The OutputAudioBitDepth element shall contain the integer of bits per sample of the MainSound element. (ex. 16 or 24) This is informative information to allow for humans and machine to read and if necessary manipulate the MainSound asset of the Composition to conform to the OutputAudioBitDepth.

7.6.19. SubtitleFormat [optional] The SubtitleFormat element defines the format of the MainSubtitle of material referred to by the Composition PlayList. It is meant to be both human and machine-readable.

7.6.20. CaptionFormat [optional] The CaptionFormat element defines the format of the MainCaption of material referred to by the Composition PlayList. It is meant to be both human and machine-readable.

7.6.21. OutputSpeedOffset [optional] The OutputSpeedOffset element shall contain the rational percentage offset intended to be applied to the Composition. This is informative information to allow for humans and machine to read and if necessary manipulate the Composition to conform to the desired running time of the Composition.

7.6.22. Encryption The Encryption element defines the whether or not Encryption used on any portion of the Composition. It is meant to be both human and machine-readable.

7.6.23. SequenceList The SequenceList element shall contain an ordered list of Sequence elements to be reproduced in continuous order. The structure of the Sequence element shall be as defined in Section 7.7.

71 Private Draft Document. Not for Publication

7.6.24. Signer [optional] The Signer element uniquely identifies the entity, and hence the public-private key pair, that digitally signed the Composition PlayList. It shall be an instance of the KeyInfoType type defined in [XML-Signature Syntax and Processing]. If the Signer element is present, then the Signature element shall also be present. If X.509 certificates are used per [XML-Signature Syntax and Processing], then the Signer element shall contain one X509Data element containing one X509IssuerSerial element, which uniquely identifies the certificate used to sign the Composition PlayList.

7.6.25. Signature [optional] The Signature element shall contain a digital signature authenticating the Composition PlayList. If the Signature element is present, then the Signer element (1.6.19 above) shall also be present. The Signature element shall be an instance of the ds:Signature element defined in [XML-Signature Syntax and Processing]. The digital signature shall be enveloped and apply to the entire Composition PlayList. An enveloped signature is one that is attached to the document being signed. The signature is generated by the signer, as identified by the Signer element, using the signer’s private key.

72 Private Draft Document. Not for Publication

7.7. Sequence Structure Each Sequence shall consist of a number of Assets, each corresponding to a particular aspect of the Digital Video presentation. While this specification defines a number of asset types, additional asset types may be added in the future. The structure is shown below in Figure 13.

Figure 13 - Sequence Structure

•

73 Private Draft Document. Not for Publication

7.7.1. Sequence Information The Composition PlayList should provide the following sequence information to allow quick access to the information about the composition. This should allow either humans or automated systems to source the general information. Below is the list of the both the informative information and required information to complete the structure of the Sequence. Some items are optional and therefore not required for a compliant Composition PlayList. Other sections are described in more detail in later sections. . SequenceType o Unique ID o Annotation Text (Sequence Title) [optional] o Sequence Version [optional] o Issue Date [optional] o Issuer [optional] o AssetList . MainMarkers [optional] . MainPicture [optional] . PictureSpatial [optional] . PictureTransition [optional] . ColorCorrection [optional] . MainSound [optional] . SoundTransition [optional] . DownMixing [optional] . Other Asset [optional]

74 Private Draft Document. Not for Publication

7.7.2. SequenceType The SequenceType describes a Sequence asset intended to be reproduced as part of a Composition PlayList. Individual child elements are defined in the following subsections.

7.7.3. Unique Id The Id element uniquely identifies the Sequence for asset management purposes. It shall be encoded as a urn:uuid per [RFC 4122].

7.7.4. AnnotationText [optional] The AnnotationText element shall be a free-form, human-readable, text annotation associated with the Sequence. It meant strictly as a display hint to the user. The optional language attribute is an xs:languagelanguage code and indicates the text language of the content of the element. If the language attribute is not present, the default value en shall be used.

7.7.5. IssueDate The IssueDate element shall be used to define the time and date at which the Composition PlayList was issued. It may be displayed to the user. It shall be encoded as an xs:dateTime.

7.7.6. Issuer [optional] The Issuer element shall be a free-form, human-readable annotation that shall identify the entity that created the Composition PlayList. It is meant strictly for display to the user.

7.7.7. AssetList The AssetList element shall contain the ordered list of media assets that will be reproduced in parallel during Sequence playback. Each asset shall be uniquely identified by a UUID per [RFC 4122]. The defining specification for each Track File shall specify the location of the identifying UUID. Each child element of the AssetList element shall be derived from the datatype GenericAssetType defined in Section 7.8.2. A number of standard assets are defined in the subsequent sections. As additional assets are defined, e.g. captions, the AssetList element may be extended by introducing new elements.

7.7.7.1. MainMarkers [optional] The MainMarkers element defines markers, e.g. FFOC, LFOC…, associated with the main portion of the presentation, i.e. MainPicture and MainSound assets. Markers shall be referenced from the start of the Sequence they are associated with. The MainMarkers element shall be an instance of MarkersAssetType and its structure is described in more detail in Section 7.8.4.

7.7.7.2. MainPicture [optional] The MainPicture element defines the picture essence to be delivered to the Transcoder or Playback Display device. The actual picture essence is contained in an external Track File. The MainPicture element shall be an instance of PictureTrackFileAssetType and its structure is defined in Section 7.8.5.

7.7.7.3. PictureSpatial [optional] The PictureSpatial element defines the picture spatial metadata to be delivered to the Transcoder or Playback Display device. This provides metadata such as Pan and Scan, Zoom, Matte and Cropping information. The actual picture spatial metadata is contained in an external Track File. The PictureSpatial element shall be an instance of PictureMetadataTrackFileAssetType and its structure is defined in Section 7.8.6.

75 Private Draft Document. Not for Publication

7.7.7.4. PictureTransition [optional] The PictureTransition element defines the picture transition metadata to be delivered to the Transcoder or Playback Display device. This provides metadata such as fade up, fade down and cross fade information. The actual picture transition metadata is contained in an external Track File. The PictureTransition element shall be an instance of PictureMetadataTrackFileAssetType and its structure is defined in Section 7.8.7.

7.7.7.5. ColorCorrection [optional] The ColorCorrection element defines the Color Correction metadata to be delivered to the Transcoder or Playback Display device. This provides metadata such as standardized Primary and Secondary color correction information. The actual color correction metadata is contained in an external Track File. The ColorCorrection element shall be an instance of PictureMetadataTrackFileAssetType and its structure is defined in Section 7.8.8.

7.7.7.6. MainSound [optional] The MainSound element defines the sound essence to be reproduced in the Transcoder or Playback system. The actual sound essence is contained in an external Track File. The MainSound element shall be an instance of SoundTrackFileAssetType and its structure is defined in Section 7.8.6.

7.7.7.7. SoundTransition [optional] The SoundTransition element defines the sound transition metadata to be delivered to the Transcoder or Playback system. This provides the ability to fade up, fade down or cross fade the audio essence. The actual sound transition metadata is contained in an external Track File. The SoundTransition element shall be an instance of SoundMetadataTrackFileAssetType and its structure is defined in Section 7.8.10.

7.7.7.8. DownMixing [optional] The DownMixing element defines the sound Down Mixing metadata to be delivered to the Transcoder or Playback system. This provides the ability to mix down multiple channels of the audio essence to a new required set. The actual sound Down Mixing metadata is contained in an external Track File. The DownMixing element shall be an instance of SoundMetadataTrackFileAssetType and its structure is defined in Section 7.8.11.

7.7.7.9. MainSubtitle [optional] The MainSubtitle element defines the Subtitle essence to be reproduced on the main screen in the Transcoder or Playback system. The actual Subtitle essence is contained in an external Track File. The MainSubtitle element shall be an instance of SubtitleTrackFileAssetType and its structure is defined in Section 7.8.12.

7.7.7.10. MainCaption [optional] The MainCaption element defines the Captions data essence to be reproduced on the main screen in the Transcoder or Playback system. The actual Captions data essence is contained in an external Track File. The MainCaption element shall be an instance of CaptionTrackFileAssetType and its structure is defined in Section 7.8.13.

76 Private Draft Document. Not for Publication

7.7.7.11. Extensions (New Asset Types) Extension elements shall be used to represent asset types not defined in this document. Zero or more extension elements may be present in the AssetList. When present, extension elements shall be located after any elements defined by this document. When present, extension elements shall have names that belong to a namespace different than the namespace declared by this document. Implementations may ignore extension elements belonging to an unknown namespace.

Extension elements shall directly or indirectly extend GenericAssetType. Extension elements may extend any type defined in this document which are derived from GenericAssetType.

Informative note: Extension elements should have unique, descriptive names and should appear only once in a given Sequence. Extension specifications that allow multiple instances of an element in a Sequence should provide both a means of differentiating instances within a Sequence and a means of linking related instances in separate Sequences.

77 Private Draft Document. Not for Publication

7.8. Asset Structures Sequence and Clip Asset elements share common attributes, such as Duration, and are therefore specified as a set of types derived from a common structure, namely the GenericAssetType structure. A number of Asset elements also reference external files, in which case they are derived from the TrackFileAssetType structure.

7.8.1. Asset Information The Composition PlayList should provide the following Asset information to allow quick access to the information about the composition. This should allow either humans or automated systems to source the general information. Below is the list of the both the informative information and required information to complete the structure of the Asset. Some items are optional and therefore not required for a compliant Composition PlayList. Other sections are described in more detail in later sections. • Generic Asset Type o Unique ID o Asset Title (Annotation Text) [optional] o Edit Rate o Intrinsic Duration o Entry Point [optional] o Duration [optional] • Track File Asset Type o Key ID [optional] o Hash File [optional] • Marker Asset Type o Marker List o Label o Annotation Text [optional] o Offset • Picture Track File Asset Type o Pixel Matrix o Bit Depth o Color Encoding o Frame Rate o Image Aspect Ratio • Picture Spatial Metadata Track File Asset Type o Standards Body [optional] o Label [optional] • Picture Transition Metadata Track File Asset Type o Standards Body [optional] o Label [optional]

78 Private Draft Document. Not for Publication

• Color Correction Metadata Track File Asset Type o Standards Body [optional] o Label [optional] • Sound Track File Asset Type o Sampling Rate o Bit Depth o Number of Channels o Channel Configuration . Channel Labels o Language [optional] • Sound Transition Metadata Track File Asset Type o Standards Body [optional] o Label [optional] • Down Mixing Metadata Track File Asset Type o Standards Body [optional] o Label [optional] • Subtitle Track File Asset Type o Language [optional] • Caption Track File Asset Type o Language [optional]

7.8.2. GenericAssetType The GenericAssetType describes a generic asset intended to be reproduced as part of a Sequence or Clip. Individual child elements are defined in the following subsections.

7.8.2.1. Id The Id element uniquely identifies the Asset. It shall be encoded as a urn:uuid per [RFC 4122]. If the Asset refers to an external resource, such as a Track File, the UUID value shall identify the resource. Mapping of UUID values to actual resources is beyond the scope of this document.

7.8.2.2. AnnotationText [optional] The AnnotationText element shall be a free-form, human-readable text annotation associated with the asset. It meant strictly as a display hint to the user. The optional language attribute is an xs:languagelanguage code and indicates the text language of the content of the element. If the language attribute is not present, the default value en shall be used.

7.8.2.3. EditRate The EditRate element defines the Edit Rate of the Asset. It shall be in units of inverse seconds and represented as a Rational Number. The IntrinsicDuration, EntryPointand Duration parameters shall be expressed in units of 1/EditRate (i.e. as integer values). If the Asset refers to an external resource, EditRate may differ from the actual Edit Rate or Sample Rate of the underlying essence.

79 Private Draft Document. Not for Publication

7.8.2.4. IntrinsicDuration The IntrinsicDuration element shall define the Native Duration of the Asset, as illustrated in Figure 14. It shall not take into account the values of the EntryPoint and Duration elements. Unless the optional EntryPoint and Duration parameters are specified, playback of the asset shall start at the Native Start Point and terminate at the Native End Point of the Track File. IntrinsicDuration shall be expressed in units of 1/EditRate, i.e. as a count of Editable Units.

native native start point end point intrinsic duration

asset

• EntryPoint Duration

Figure 14 - Asset Timing Parameters.

7.8.2.5. EntryPoint [optional] This element shall only be present when the Asset refers to an external resource such as a Track File. The EntryPoint element identifies the Edit Unit where playback shall start (the first editable unit of the playable region). It shall be encoded as an integer number and shall be expressed in units of 1/EditRate, i.e. as a count of Editable Units. This element shall be required if the desired Entry Point is greater than 0 (zero). If this element is not present, a value of 0 shall be assumed and Asset playback shall start at the Native Start Point of the resource.

7.8.2.6. Duration [optional] This element shall only be present when the Asset refers to an external resource such as a Track File. The Duration element defines the duration of the Playable Region of the resource. It shall be encoded as an integer number and shall be expressed as an integer number in units of 1/EditRate, i.e. as a count of Editable Units. If present, this value shall be an integer between 0 (zero) and IntrinsicDuration – EntryPoint (the number of edit units between the EntryPoint and the Native End Point the Track File). If this element is not present, Asset playback shall stop after (IntrinsicDuration – EntryPoint)/EditRate seconds, i.e. at the Native End Point of the Asset.

7.8.3. TrackFileAssetType The TrackFileAssetType element shall be derived from GenericAssetType. It describes an asset based on an external file such as a Picture or Sound Track File.

7.8.3.1. KeyId [optional] The KeyId element uniquely identifies the cryptographic key used to encrypt the underlying track file. This element shall contain a key identifier encoded as a urn:uuid value. KeyId shall be present if any portion of the underlying track file is encrypted. The mapping of key identifiers to actual key values is beyond the scope of this document.

7.8.3.2. Hash [optional] The Hash element shall contain the hash (message digest) of the underlying track file computed using the SHA-1 message digest algorithm [RFC 3174]. When authenticated by the digital signature in the Composition PlayList (see 7.6.25), it may be used to verify the integrity and authenticity of the underlying track file. The resulting 160-bit integer shall be encoded using Base64 representation [RFC 2045].

80 Private Draft Document. Not for Publication

7.8.4. MarkerAssetType The MarkerAssetType element shall be derived from the GenericAssetType. It describes the content markers, e.g. FFOC, associated with a Sequence. An instance of the MarkerAssetType is the MainMarkers element. Just as for picture and sound assets, the marker asset has a timeline. The Offset of each Marker (see Figure 6) is the position from the start of the timeline and the Intrinsic Duration of the timeline shall correspond to the Offset of the last Marker.

7.8.4.1. MarkerList The MarkerList element shall contain a list of Marker elements. The members of the Marker element are defined in the following subsections.

7.8.4.2. Label The Label element shall contain a textual representation of the marker. An optional scope attribute with default URI value of “http://www.smpte-ra.org/schemas/TBD/CPL#standard- markers” determines the permissible values of the element.

Table 6. Example Marker Labels. Marker Description  First Frame of Composition. The first frame of a FFOC composition that is intended for display.  Last Frame of Composition. The last frame of a LFOC composition that is intended for display.  First Frame of Title Credits. First displayable frame of content that contains any FFTC intensity of the Title Credits (a non zero alpha value), which appear at the beginning of a feature.  Last Frame of Title Credits. Last displayable frame of content that contains any LFTC intensity of the Title Credits (a non zero alpha value), which appear at the beginning of a feature.  First Frame of Intermission. FFOI  Last Frame of Intermission. LFOI  First Frame of End Credits. First displayable frame of content that contains any FFEC intensity of the End Credits (a non zero alpha value), which appear at the end of a feature.  Last Frame of End Credits. Last displayable frame of content that contains any LFEC intensity of the End Credits (a non zero alpha value), which appear at the end of a feature.  First Frame of Ratings Band. First displayable frame of content of the Rating Band, FFOB which is usually a slate at the beginning of a feature.  Last Frame of Ratings Band. Last displayable frame of content of the Rating Band, LFOB which is usually a slate at the beginning of a feature.  First displayable frame of content that contains any intensity of moving, rolling or FFMC scrolling credits (a non-zero alpha value), which appear at the end of the feature.  Last displayable frame of content that contains any intensity of moving, rolling or LFMC scrolling credits (a non-zero alpha value), which appear at the end of the feature.

7.8.4.3. AnnotationText [optional] The AnnotationText element shall be a free-form, human-readable annotation associated with the marker. It meant strictly as a display hint to the user. The optional language attribute is a standard XML language code and indicates the text language of the content of the element. If the text language attribute is not present, the default value en shall be used.

81 Private Draft Document. Not for Publication

7.8.4.4. Offset The Offset element defines the absolute position of the marker from the start of the marker asset. It shall be represented as integer number of 1/EditRate units, as inherited from the GenericAssetType.

7.8.5. PictureTrackFileAssetType The PictureTrackFileAssetType, shall be derived from the TrackFileAssetType. It describes a Track File containing picture essence. An instance of the PictureTrackFileAssetType is the MainPicture element The elements defined below replicate values contained in the underlying track file and shall remain consistent with the content of the underlying track file at all times. They are included in the Composition PlayList to alleviate the need for software to access and parse individual track files in order to display the values to users. In the event an inconsistency exists, the values contained in the underlying track file shall take precedence.

7.8.5.1. PicturePixelMatrix The PicturePixelMatrix element shall contain the horizontal and vertical pixel count of the underlying picture track file. As described above, it is included in the Composition PlayList for convenience only. It shall be encoded as a rational number of frames per second.

7.8.5.2. PictureBitDepth The PictureBitDepth element shall contain the number of bits assigned to each picture component of the underlying picture track file. As described above, it is included in the Composition PlayList for convenience only. It shall be encoded as a rational number of frames per second.

7.8.5.3. PictureColorEncoding The PictureColorEncoding element shall contain the identification of the color encoding method of the underlying picture track file. As described above, it is included in the Composition PlayList for convenience only. It shall be encoded as a rational number of frames per second.

7.8.5.4. PictureFrameRate The PictureFrameRate element shall contain the frame rate of the underlying picture track file. As described above, it is included in the Composition PlayList for convenience only. It shall be encoded as a rational number of frames per second.

7.8.5.5. ImageAspectRatio The ImageAspectRatio element shall define the aspect ratio of the picture information contained in the underlying picture track file. As described above, it is included in the Composition PlayList for convenience. It is represented as a rational number and applications may convert the ratio to a decimal number to match current practice.

7.8.6. PictureSpatialMetadataTrackFileAssetType The PictureSpatialMetadataTrackFileAssetType, shall be derived from the TrackFileAssetType. It describes a Track File containing picture spatial metadata. An instance of the PictureSpatialMetadataTrackFileAssetType is the MainPictureMetadata element. The elements defined below replicate values contained in the underlying track file and shall remain consistent with the content of the underlying track file at all times. They are included in the Composition PlayList to alleviate the need for software to access and parse individual track files in order to display the values to users. In the event an inconsistency exists, the values contained in the underlying track file shall take precedence.

7.8.6.1. StandardsBody [optional] The StandardsBody element shall contain a URI [RFC 2396] that uniquely identifies the Standards Body issuing the Standard.

82 Private Draft Document. Not for Publication

7.8.6.2. Label [optional] The Label element shall contain a textual representation of the Standards Body, which may be displayed to the user. For each issuing Standards Body, and hence unique URI, there are a number of permissible Label values. An example of such is shown below in Table 7. The specification of this mapping is beyond the scope of this document.

Table 7. Examples Standards Body Labels Label URI SMPTE STD xxx- http://www.smpte.org/date y W3 http://www.w3.org/2001 ISO http://www.ISO.org/2009

7.8.7. PictureTransitionMetadataTrackFileAssetType The PictureTransitionMetadataTrackFileAssetType, shall be derived from the TrackFileAssetType. It describes a Track File containing picture spatial metadata. An instance of the PictureTransitionMetadataTrackFileAssetType is the MainPictureMetadata element. The elements defined below replicate values contained in the underlying track file and shall remain consistent with the content of the underlying track file at all times. They are included in the Composition PlayList to alleviate the need for software to access and parse individual track files in order to display the values to users. In the event an inconsistency exists, the values contained in the underlying track file shall take precedence.

7.8.7.1. StandardsBody [optional] The StandardsBody element shall contain a URI [RFC 2396] that uniquely identifies the Standards Body issuing the Standard.

7.8.7.2. Label [optional] The Label element shall contain a textual representation of the Standards Body, which may be displayed to the user. For each issuing Standards Body, and hence unique URI, there are a number of permissible Label values. An example of such is shown in Table 7. The specification of this mapping is beyond the scope of this document.

7.8.8. ColorCorrectionMetadataTrackFileAssetType The ColorCorrectionMetadataTrackFileAssetType, shall be derived from the TrackFileAssetType. It describes a Track File containing picture spatial metadata. An instance of the ColorCorrectionMetadataTrackFileAssetType is the MainPictureMetadata element. The elements defined below replicate values contained in the underlying track file and shall remain consistent with the content of the underlying track file at all times. They are included in the Composition PlayList to alleviate the need for software to access and parse individual track files in order to display the values to users. In the event an inconsistency exists, the values contained in the underlying track file shall take precedence.

7.8.8.1. StandardsBody [optional] The StandardsBody element shall contain a URI [RFC 2396] that uniquely identifies the Standards Body issuing the Standard.

7.8.8.2. Label [optional] The Label element shall contain a textual representation of the Standards Body, which may be displayed to the user. For each issuing Standards Body, and hence unique URI, there are a number of permissible Label values. An example of such is shown in Table 5. The specification of this mapping is beyond the scope of this document.

83 Private Draft Document. Not for Publication

7.8.9. SoundTrackFileAssetType The SoundTrackFileAssetType is derived from TrackFileAssetType. It describes a Track File containing sound essence. An instance of the SoundTrackFileAssetType is the MainSound element. The elements defined below replicate values contained in the underlying track file and shall remain consistent with the content of the underlying track file at all times. They are included in the Composition PlayList to alleviate the need for software to access and parse individual track files when scheduling content. In the event an inconsistency exists, the values contained in the underlying track file shall take precedence.

7.8.9.1. SoundSamplingRate The SoundSamplingRate element shall contain the frequency of the sampling rate of the underlying sound track file. As described above, it is included in the Composition PlayList for convenience only. It shall be encoded as a rational number of kHz.

7.8.9.2. SoundBitDepth The SoundBitDepth element shall contain the number of the bits assigned to each sample of audio of the underlying sound track file. As described above, it is included in the Composition PlayList for convenience only. It shall be encoded as a integer number of bits.

7.8.9.3. SoundChannelNumber The SoundChannelNumber element shall contain the number of the audio channels of the underlying sound track file. As described above, it is included in the Composition PlayList for convenience only. It shall be encoded as an integer number of channels.

7.8.9.4. ChannelConfiguration The ChannelConfiguration element shall contain the channel number and label assigned to each channel of the underlying sound track file. As described above, it is included in the Composition PlayList for convenience only. It shall be encoded as a integer channel number along with its corresponding label.

7.8.9.5. Label The Label element shall contain a textual representation of the channel, which may be displayed to the user. For each channel number there are a number of permissible Label values. An example of such is shown in Table 8. The specification of this mapping is beyond the scope of this document.

Table 8. Examples Channel Labels Channel No. Label Description 1 L Left 2 R Right 3 C Center 4 LFE Low Frequency Effects 5 Ls Left Surround 6 Rs Right Surround 7 Cs Center Surround 8 Lt Left total (matrix encoded) 9 Rt Right total (matrix encoded) 10 Mono Monaural 11 HI Hearing Impaired (Dynamic compressed dialog centric mix) 12 VI-N Visually Impaired Narration (Descriptive Narration)

7.8.9.6. Language [optional] The Language element shall reflect the primary spoken language of the sound material of the underlying sound track file. The element value is encoded as an xs:language language code and indicates the

84 Private Draft Document. Not for Publication

spoken language of the content. The absence of the element shall indicate that no spoken language is associated with the asset.

7.8.10. SoundTransitionMetadataTrackFileAssetType The SoundTransitionMetadataTrackFileAssetType, shall be derived from the TrackFileAssetType. It describes a Track File containing picture spatial metadata. An instance of the SoundTransitionMetadataTrackFileAssetType is the MainSoundMetadata element. The elements defined below replicate values contained in the underlying track file and shall remain consistent with the content of the underlying track file at all times. They are included in the Composition PlayList to alleviate the need for software to access and parse individual track files in order to display the values to users. In the event an inconsistency exists, the values contained in the underlying track file shall take precedence.

7.8.10.1. StandardsBody [optional] The StandardsBody element shall contain a URI [RFC 2396] that uniquely identifies the Standards Body issuing the Standard.

7.8.10.2. Label [optional] The Label element shall contain a textual representation of the Standards Body, which may be displayed to the user. For each issuing Standards Body, and hence unique URI, there are a number of permissible Label values. An example of such is shown in Table 5. The specification of this mapping is beyond the scope of this document.

7.8.11. SoundDownMixingMetadataTrackFileAssetType The SoundDownMixingMetadataTrackFileAssetType, shall be derived from the TrackFileAssetType. It describes a Track File containing picture spatial metadata. An instance of the SoundTransitionMetadataTrackFileAssetType is the MainSoundMetadata element. The elements defined below replicate values contained in the underlying track file and shall remain consistent with the content of the underlying track file at all times. They are included in the Composition PlayList to alleviate the need for software to access and parse individual track files in order to display the values to users. In the event an inconsistency exists, the values contained in the underlying track file shall take precedence.

7.8.11.1. StandardsBody [optional] The StandardsBody element shall contain a URI [RFC 2396] that uniquely identifies the Standards Body issuing the Standard.

7.8.11.2. Label [optional] The Label element shall contain a textual representation of the Standards Body, which may be displayed to the user. For each issuing Standards Body, and hence unique URI, there are a number of permissible Label values. An example of such is shown in Table 5. The specification of this mapping is beyond the scope of this document.

85 Private Draft Document. Not for Publication

7.8.12. SubtitleTrackFileAssetType The SubtitleTrackFileAssetType element is derived from TrackFileAssetType. It describes the subtitle material associated with the Sequence. An instance of the SubtitleTrackFileAssetType is the MainSubtitle element.

The elements defined below replicate values contained in the underlying track file and shall remain consistent with the content of the underlying track file at all times. They are included in the Composition PlayList to alleviate the need for theater management software to access and parse individual track files when scheduling content. In the event an inconsistency exists, the values contained in the underlying track file shall take precedence.

7.8.12.1. Language [optional] The Language element shall reflect the primary text language used by the Subtitle essence. The absence of the element shall indicate that no primary text language is associated with the asset. It is represented as an xs:language value.

7.8.13. CaptionTrackFileAssetType The CaptionTrackFileAssetType element is derived from TrackFileAssetType. It describes the subtitle material associated with the Sequence. An instance of the CaptionTrackFileAssetType is the MainCaption element.

The elements defined below replicate values contained in the underlying track file and shall remain consistent with the content of the underlying track file at all times. They are included in the Composition PlayList to alleviate the need for theater management software to access and parse individual track files when scheduling content. In the event an inconsistency exists, the values contained in the underlying track file shall take precedence.

7.8.13.1. Language [optional] The Language element shall reflect the primary text language used by the Subtitle essence. The absence of the element shall indicate that no primary text language is associated with the asset. It is represented as an xs:language value.

86 Private Draft Document. Not for Publication

7.9. CPL Constraints The following is a list of items that are intended to be constrained within the Composition and therefore reflected in the CPL.

7.9.1. Constant Frame Rate The Composition shall only consist of similar frame rate content in all of the included track files. Another words all track files shall have the same edit rate and frame rate.

7.9.2. Minimum Track File Duration The duration of any asset contained in a Sequence, as indicated by the Duration and IntrinsicDuration elements, shall be no less than one frame.

7.9.3. Minimum Sequence Duration The duration of any Sequence shall be no less than one second.

7.9.4. Minimum Picture Transition Support The Composition shall only support minimum pictures transitions within a Track FIle. These transitions are limited to Fade Up, Fade Down and Cross Dissolve.

7.9.5. Minimum Sound Transition Support The Composition shall only support minimum sound transitions within a Track FIle. These transitions are limited to Fade Up, Fade Down and Cross Fade.

87 Private Draft Document. Not for Publication

8. Output Profile List

8.1. Introduction

8.2. Output Profile List Overview

8.2.1. Functional Framework For the purpose of documenting the specific requirements for a Interoperable Master Format Output Profile List

o TBD – The specifications for the list of elements included in the Output Profile List

8.2.2. Output Profile List Fundamental Requirements

8.2.2.1. Introduction .

8.2.2.2. Open Standard

8.2.2.3. Interoperable The is required to have an open framework that accommodates compressed, encrypted files as well as all other files used in Digital Video.

8.2.2.4. Scalable The is required to accommodate any number of Essence or Metadata components. There is no limit on the number of files included in the package or the size of the files.

8.2.2.5. Extensible The is required to allow for

8.2.2.6. Human Readable Metadata Human readable Metadata is required to be in English (default) but can be provided in other languages as well.

8.2.3. Output Profile List Concepts

8.3. Output Profile List Format

8.3.1. Introduction

8.3.2. File Format

8.3.3. ImageOutputFormat The ImageOutputFormat element defines the output format of the MainPicture of material referred to by the Composition PlayList. It is meant to be both human and machine-readable.

88 Private Draft Document. Not for Publication

8.3.3.1. OutputPixelMatrix The OutputPixelMatrix element shall contain the horizontal and vertical pixel counts of the MainPicture element. This is informative information to allow for humans and machine to read and if necessary manipulate the MainPicture asset of the Composition to conform to the OutputPixelMatrix requirements.

8.3.3.2. OutputColorEncoding The OutputColorEncoding element shall contain information of the color encoding parameters of the MainPicture element. This is informative information to allow for humans and machine to read and if necessary manipulate the MainPicture asset of the Composition to conform the color information to the OutputColorEncoding specification.

8.3.3.3. StandardsBody [optional] The StandardsBody element shall contain a URI [RFC 2396] that uniquely identifies the Standards Body issuing the Standard.

8.3.3.4. Label [optional] The Label element shall contain a textual representation of the Standards Body, which may be displayed to the user. For each issuing Standards Body, and hence unique URI, there are a number of permissible Label values. An example of such is shown below in Table 4. The specification of this mapping is beyond the scope of this document.

Table 5. Examples Standards Body Labels Label URI SMPTE STD xxx- http://www.smpte.org/date y W3 http://www.w3.org/2001 ISO http://www.ISO.org/2009

8.3.3.5. DisplayAspectRatio The DisplayAspectRatio element shall contain the ratio intended display screen of the MainPicture element. (ex. 4:3 or 16:9) This is informative information to allow for humans and machine to read and if necessary manipulate the MainPicture asset of the Composition to conform to the DisplayAspectRatio.

8.3.3.6. OutputPictureOverlay [optional] The OutputPictureOverlay element shall contain information about the auxiliary overlay image elements for the MainPicture element. This is informative information to allow for humans and machine to read and if necessary manipulate the MainPicture asset of the Composition to conform the aspects of the required OutputPictureOverlay.

8.3.3.7. TimeCodeWindow [optional] The TimeCodeWindow element shall contain a designation that uniquely identifies the Timecode type and spatial location for the OutputPictureOverlay.

8.3.3.8. Spoiler [optional] The Spoiler element shall contain a textual representation and spatial location for the OutputPictureOverlay.

8.3.4. OutputAudioFormat The OutputAudioFormat element defines the format of the MainSound of material referred to by the Composition PlayList. It is meant to be both human and machine-readable.

89 Private Draft Document. Not for Publication

8.3.4.1. AudioCompressionStandard [optional] The AudioCompressionStandard element shall contain information of the compression encoding parameters of the MainSound element. This is informative information to allow for humans and machine to read and if necessary manipulate the MainSound asset of the Composition to conform the sound information to the Compression specification.

8.3.4.2. StandardsBody [optional] The StandardsBody element shall contain a URI [RFC 2396] that uniquely identifies the Standards Body issuing the Standard.

8.3.4.3. Label [optional] The Label element shall contain a textual representation of the Standards Body, which may be displayed to the user. For each issuing Standards Body, and hence unique URI, there are a number of permissible Label values. An example of such is shown below in Table 4. The specification of this mapping is beyond the scope of this document.

8.3.5. OutputSpeedOffset [optional] The OutputSpeedOffset element shall contain the rational percentage offset intended to be applied to the Composition. This is informative information to allow for humans and machine to read and if necessary manipulate the Composition to conform to the desired running time of the Composition.

90 Private Draft Document. Not for Publication

Packaging

8.4. Introduction Packaging is defined as the process of combing elements to prepare them for shipping. This generally will consist of one or more compositions along with two more elements which will be specified in the section of the document. Those elements are the Packing List and the Asset Map.

8.5. Packaging System Overview

8.5.1. Functional Framework For the purpose of documenting the specific requirements for a Interoperable Master Format Packaging system, it is helpful to divide the system into a set of components. The performance requirements for each of these components will be described in the following sections: • Distribution Package – The physical files and the list describing the files and providing a means for authentication as delivered in a Distribution Package (from Distributor to Exhibitor). o Packing List – The specifications for the list of elements included in the Package. o Asset Map – The specification for the directory structure and physical location of those directories and files. o Security –The specifications for the security requirements for the Package.

8.5.2. Packaging Fundamental Requirements

8.5.2.1. Introduction Digital Video presents a challenge to create a versatile packaging system. Throughout this system, some basic requirements are needed and are stated below.

8.5.2.2. Open Standard The Packaging standard is required to be based upon an open worldwide standard. This format is encouraged to be a license-free technology. It is required to be a complete standard that equipment receiving a compliant package can process and interpret unambiguously.

8.5.2.3. Interoperable The Packaging format is required to have an open framework that accommodates compressed, encrypted files as well as all other files used in Digital Video.

8.5.2.4. Scalable The Packaging format is required to accommodate any number of Essence or Metadata components. There is no limit on the number of files included in the package or the size of the files.

8.5.2.5. Extensible The Packaging format is required to allow for new Digital Video features (compositions) to be contained within the package.

8.5.2.6. Synchronization The Packaging format is required to provide support for synchronization of the Essence and Metadata elements.

91 Private Draft Document. Not for Publication

8.5.2.7. Human Readable Metadata Human readable Metadata is required to be in English (default) but can be provided in other languages as well.

8.5.3. Packaging Concepts It is common practice to divide content into reels of between 10 and 20 minutes in length for post-production, and distribution. These reels are then assembled, together with other content, to create the modern play lists that are used in play out devices. This concept of reels is required to be supported with Digital Video content.

8.6. Distribution Package

8.6.1. Introduction The Distribution Package has two major components. One is the Package itself, which includes all of the Track Files and the other is the Packing List. These are all of the elements required for a complete delivery to the theater Digital Cinema system. It is technically possible to include engagement-specific licenses and keying information in a Package in the form of opaque Metadata, but this is not recommended for general usage. A Distribution Package can contain a complete feature film composition or a set of compositions. Alternatively, it can carry as little as a single file to update one reel’s subtitle or sound track.

8.6.2. Distribution Package

8.6.2.1. General The Distribution Package is required to contain a Packing List and one or more Digital Cinema track files. The following requirements apply.

8.6.2.2. Packing for Transport The distribution method is required to allow a DCP to be transported via physical media, satellite or network.

8.6.2.3. Flattened Packages TBD

8.6.2.4. Security The distribution method is required to provide digital signatures to allow the recipient to verify integrity of the Packing List and the enclosed files. Preparation of Packing Lists is a distribution fulfillment or transport function. Therefore, the digital signatures come from these entities, not the content-owner who mastered the files. Packing List security functions do not verify the authenticity of the content, only the intent of the delivery agent. (Content authenticity is verified through PlayList signatures and digital licenses.)

8.6.3. Packing List

8.6.3.1. File Format The Packing List is required to use XML data format with XML Signature (digital signature). It should be in English (default) but can be provided in other languages as well.

8.6.3.2. Fields The following data fields are required to be included in the Packing List for each file in the Package: • Unique identification of each file included in the DCP is encoded as urn:UUID. • Annotation Text parameter (optional), if present, is a free-form, human readable annotation associated with the asset. It is meant strictly as a displayable guidance for the user.

92 Private Draft Document. Not for Publication

• File Integrity check (hash) for each file in the distribution package • Size of the file in bytes • Type (e.g., Packing List, PlayList, Track File, opaque security data) • Original File Name The following fields are required to be included in the digital signature section of the Packing List: • Signer parameter uniquely identifies the entity, and hence public key that digitally signs the packing list. Signature parameter contains a digital signature authenticating the packing list.

8.6.4. Asset Map

8.6.4.1. File Format The Asset Map is required to use XML data format with XML Signature (digital signature). It should be in English (default) but can be provided in other languages as well.

8.6.4.2. Fields The following data fields are required to be included in the Asset Map for each file in the Package:

93 Private Draft Document. Not for Publication

9. Annex

9.1. Example Workflows The following diagrams show an examples of a future state workflows using the concept of the IMF.. This IMF and the file-based workflow will enable Mastering & Distribution Servicing to service both existing and emerging distribution channels. It must be stressed that this is only an example workflow. As one becomes more familiar with the concepts of the IMF one can imagine many different workflows using the IMF. It is not the intention of this document to indentify all of these possibilities.

Figure 15 - Future State - Mastering & Distribution Servicing

94 Private Draft Document. Not for Publication

Figure 16 – Example IMF workflow

9.2. Editorial Systems

9.2.1. Editorial System Fundamental Requirements Digital Video Editorial Systems have some basic requirements that are stated below.

9.2.1.1. Easy Assembly of Content The system is required to provide a graphical user interface (GUI) interface for the assembly of content with relative ease in a timely matter.

9.2.1.2. Movement of Content The system is required to provide for movement of content within a facility. Blah Blah Blah

9.2.1.3. Ease of Operation The Editorial System is encouraged to require only a reasonable level of computer operation knowledge or training for the basic operation of the system. The computer-based user interfaces are required to be simple and intuitive.

95 Private Draft Document. Not for Publication

9.2.1.4. Multiple Systems Editing shall be supported across many different systems that are common in editorial processes today.

9.3. Playout Systems

9.3.1. Playout System Fundamental Requirements IMF Playout Systems have some basic requirements that are stated below.

9.3.1.1. Easy Assembly of Content The system is required to provide a graphical user interface (GUI) interface for the assembly of content with relative ease in a timely matter.

9.3.1.2. Movement of Content The system is required to provide for movement of content within a facility. Blah Blah Blah

9.4. Transcoding Systems

9.4.1. Transcoding System Fundamental Requirements IMF Trascoding Systems have some basic requirements that are stated below.

9.4.1.1. Easy Assembly of Content The system is required to provide a graphical user interface (GUI) interface for the assembly of content with relative ease in a timely matter.

9.4.1.2. Movement of Content The system is required to provide for movement of content within a facility. Blah Blah Blah

9.5. Asset Management Interface Asset Management in the context of the IMF refers to the system interfaces required to allow for automation of repetitive tasks and tracking of assets for such things as location and version control. This section will concentrate on the interfaces and not all of the different applications required or envisioned for a Asset Management system. Below you should find the requirements and specifications for the interfaces required.

9.5.1. Interface Fundamental Requirements

9.5.1.1. Introduction Interoperable Master Format presents unique opportunities for the automation of content and asset tracking.

9.5.1.2. API The Application Programming Interface for the IMF……Blah Blah Blah.

9.5.1.3. Protocols The Protocols to be used for the interfaces shall be….Blah Blah Blah.

9.5.2. Asset Management Interface Fundamental Concepts The interfacing to the Interoperable Master Format can be accomplished in many different ways. Blah, Blah, Blah.

96 Private Draft Document. Not for Publication

9.5.3. Application Programming Interface TBD

9.5.4. Protocols

97 Private Draft Document. Not for Publication

10. GLOSSARY OF TERMS

AES Acronym for Advanced Encryption Standard AES Acronym for Audio Engineering Society ANSI Acronym for American National Standards Institute API Acronym for Application Programming Interface Broadcast Digital Audio file format developed and standardized by the EBU Wave Burned-In Where visual data that is normally supplemental to a motion picture is irrevocably added to the motion-picture image by compositing the data with the underlying image Captions Text that is a representation, often in the same language, of dialog and audio events occurring during scenes of a motion picture. (Generally associated with a dialog and audio event translation for the deaf and hard of hearing.) CBC Acronym for Cipher Block Chaining mode CBR Acronym for Constant Bit Rate for image compression CIE Acronym for International Commission on Illumination (Commission Internationale de l’Eclairage) Closed Referring to visual data that is supplemental to a motion picture being displayed off-screen Composition A motion picture, or a trailer, or an advertisement, etc. Composition consists of a Metadata Composition PlayList along with the Essence and other Metadata track files that define the work. CPL Acronym for Composition PlayList, the definitive PlayList for specifying how a Composition is played and what track files are required DCP Acronym for a Digital Cinema Package, the set of files that are the result of the encoding, encryption and packaging process Distribution The collection of files delivered by the distributor to the exhibitor. A Distribution Package may Package contain pieces of a Composition or several compositions, a complete Composition, replacement/update files, etc. DM Acronym for Descriptive Metadata DRM Acronym for Digital Rights Management DSM Acronym for Digital Source Master, a digital master created in post-production from which different versions and duplication masters may be created. DVD Acronym for Digital Versatile Disc EBU Acronym for European Broadcast Union (a standardization organization) e.g. Abbrevation for the Latin phrase exempli gratia, meaning “for example” Essence Image, audio, subtitles, or any content that is presented to a human being in a presentation ETC Acronym for Entertainment Technology Center FIPS Acronym for Federal Information Processing Standards

98 Private Draft Document. Not for Publication

FM Acronym for Forensic Marking Forensic Data embedded in essence to provide forensic tracking information in the event of content Marking theft. Such marking can be visible or non-visible, audible or non-audible. FPS Acronym for Frames per Second HD Acronym for High Definition HI Acronym for Hearing Imparied HMAC Acronym for Hashing Message Authentication Codes Hz Abbreviation for Hertz, a unit of frequency expressed in cycles per second i.e. Abbreviation for the Latin phrase id est, meaning “that is” IEC Acronym for Internation Electrotechnical Commission IP Acronym for Intellectual Property IMF Acronym for Interoperable Master Format ISO Acronym for International Organization for Standardization ITU Acronym for International Telecommunications Union JPEG Acronym for Joint Photographic Experts Group, the international body that developed the JPEG 2000 standard Key Electronic data used to allow data encryption and decryption Key Epoch The period of time during which a given decryption key is valid. The key epoch defines a minimum practical time period for use of encrypted track files. kHz Acronym for kilo Hertz, one thousand cycles per second, a measure of frequency KLV Acronym for Key Length Value – used by the MXF to parse binary data Localizations Text on screen representing either non-source language dialog or information pertinent to the story such as time and place. This is specifically the text that is absent in text-less masters. This text is localized or translated for various markets either through subtitles or entire image replacement. LTC Acronym for Linear Time Code LUT Acronym for Look Up Table Main Titles A credit sequence generally shown near the beginning of a motion picture Metadata Data about data or data describing other data. Information that is considered ancillary to or otherwise directly complementary to essence. Information that is useful or of value when associated with the essence being provided. MTBF Acronym for Mean Time Between Failure MXF Acronym for Material eXchange Format NDF Acronym for Non Drop Frame (Timecode) NTSC Acronym for National Television System Committee, which developed the NTSC television broadcasting standard Open Referring to visual data that is supplemental to a motion picture being displayed on-screen

99 Private Draft Document. Not for Publication

Operational An MXF construct to define file structures Pattern Packing List A list describing the files and providing a means for authentication of the files as delivered in a package PAL Acronym for Phase Alternation by Line, a television broadcasting standard. PlayList Conceptually, the format and structure of the various lists used to define the playback of content. PNG Acronym for Portable Network Graphics, an extensible file format for the lossless, portable, well-compressed storage of raster images defined by the PNG Development Group. QC Acronym for Quality Control RAND Acronym reasonable and nondiscriminatory Reel A conceptual period of time having a specific duration of generally 10 to 20 minutes. Used primarly in feature film production. Renewable A software component is renewable if it can be remotely, smoothly and possibly automatically upgraded or replaced without significantly disturbing system operations. A system shutdown and normal restart is acceptable, provided that after the restart, the system can be operated as before. Replaceable A component is said to be replaceable if it can be upgraded or replaced without significantly disturbing system operations. A system shutdown and restart is acceptable, provided that after the replacement, the system can be operated as before. SD Acronym for Standard Definition SHA1 Acronym for Secure Hashing Algorithm 1 SMPTE Acronym for Society of Motion Picture and Television Engineers Subpicture A multiple-image file format for the transport of visual data supplemental to a motion picture that is intended only for graphic overlay with the main image output of a digital projector Subtitle Text that is a representation, in a different language, of dialog occurring during scenes of a motion picture. Generally associated with dialog translation for localization of a motion picture in a particular territory. TCP/IP Acronym for Transmission Control Protocol / Internet Protocol TDES or 3DES Acronym for Triple Data Encryption Standard. TDES or 3DES was adopted as a federal standard in 1998 [FIPS (46-3) and ANSI standard X9.32] Track File The smallest element of a package that can be managed or replaced as a distinct asset. A track file may contain Essence and/or Metadata, and its duration matches an associated Reel. UDP Acronym for User Datagram Protocol UL Acronym for Universal Lable used in MXF

Unicode The Universal Multiple-Octet Coded Character set, the [ISO/IEC 10646:2003] standard that defines a single code for representation, interchange, processing, storage, entry and presentation of the written form of the world’s major languages urn Acronym for uniform resource name USB Acronym for Universal Serial Bus, standardized serial communications connection found on computers

100 Private Draft Document. Not for Publication

UTC Acronym for Universal Coordinated Time UUID Acronym for Universal Unique IDentifier VFX Acronym for Visual Effects VI Acronym for Visually Imparied VOD Acronym for Video on Demand Visually An image compression method is considered visually lossless when the processed image is Lossless indistinguishable from the unprocessed image under normal theatrical viewing conditions. VPN Acronym for Virtual Private Network. VBR Acronym for Variable Bit Rate W3C Acronym for The World Wide Web Consortium, the organization responsible for the development of Internet protocols XML Acronym for eXtensible Markup Language

101