IEC TS 62871 1 Edition 1 0 201 5 1 2 TECHNICAL SPECIFICATION Professional video storage products – Tape less camera recorder using MXF file format – Encoding guidelines – Part 1 MXF Operational Patter[.]
I E C TS 62 -1 ® Edition 201 5-1 TE C H N I C AL S P E C I F I C ATI ON colour i n sid e P rofe s s i on al vi d e o s torag e prod u cts – Tape-l es s cam era re cord e r u s i n g M XF fi l e form at – E n cod i n g g u i d e l i n es – IEC TS 62871 -1 :201 5-1 2(en) P art : M XF Ope rati on al P attern s T H I S P U B L I C AT I O N I S C O P YRI G H T P RO T E C T E D C o p yri g h t © I E C , G e n e v a , S wi tz e rl a n d All rights reserved Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either IEC or IEC's member National Committee in the country of the requester If you have any questions about I EC copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local I EC member National Committee for further information IEC Central Office 3, rue de Varembé CH-1 21 Geneva 20 Switzerland Tel.: +41 22 91 02 1 Fax: +41 22 91 03 00 info@iec.ch www.iec.ch Ab ou t th e I E C The I nternational Electrotechnical Commission (I EC) is the leading global organization that prepares and publishes I nternational Standards for all electrical, electronic and related technologies Ab o u t I E C p u b l i ca ti o n s The technical content of IEC publications is kept under constant review by the IEC Please make sure that you have the latest edition, a corrigenda or an amendment might have been published I E C Catal og u e - webstore i ec ch /catal og u e The stand-alone application for consulting the entire bibliographical information on IEC International Standards, Technical Specifications, Technical Reports and other documents Available for PC, Mac OS, Android Tablets and iPad I E C pu bl i cati on s s earch - www i ec ch /search pu b The advanced search enables to find IEC publications by a variety of criteria (reference number, text, technical committee,…) It also gives information on projects, replaced and withdrawn publications E l ectroped i a - www el ectroped i a org The world's leading online dictionary of electronic and electrical terms containing more than 30 000 terms and definitions in English and French, with equivalent terms in additional languages Also known as the International Electrotechnical Vocabulary (IEV) online I E C G l os sary - s td i ec ch /g l oss ary More than 60 000 electrotechnical terminology entries in English and French extracted from the Terms and Definitions clause of IEC publications issued since 2002 Some entries have been collected from earlier publications of IEC TC 37, 77, 86 and CISPR I E C J u st Pu bl i s h ed - webstore i ec ch /j u stpu bl i sh ed Stay up to date on all new IEC publications Just Published details all new publications released Available online and also once a month by email I E C C u stom er S ervi ce C en tre - webstore i ec ch /csc If you wish to give us your feedback on this publication or need further assistance, please contact the Customer Service Centre: csc@iec.ch I E C TS 62 -1 ® Edition 201 5-1 TE C H N I C AL S P E C I F I C ATI ON colour i n sid e P rofes s i on al vi d eo s torag e prod u cts – Tape-l es s cam era record e r u s i n g M XF fi l e form at – E n cod i n g g u i d el i n es – P art : M XF O perati on al P atte rn s INTERNATIONAL ELECTROTECHNICAL COMMISSION ICS 33.1 60.40; 35.040 ISBN 978-2-8322-3080-0 Warn i n g ! M ake su re th a t you obtai n ed th i s pu bl i cati on from an au th ori zed d i s tri bu tor ® Registered trademark of the International Electrotechnical Commission –2– I EC TS 62871 -1 :201 © I EC 201 CONTENTS FOREWORD I NTRODUCTI ON Scope Norm ative references Terms, definitions, abbreviations and conventions Terms and definitions Abbreviations 3 Conventions Overview of the MXF file format General File structure Overview 2 File Header File Bod y 4 File Footer Partitions Overview Header Partition 3 Bod y Partition 4 Footer Partition Partition rules summ ary Partition status 1 4 Key-Length-Value (KLV) coding 1 4 KLV encoding structure 1 4 KLV Fill I tem 1 Header Metadata Overview Structural M etadata Descriptive M etadata Structure of Header Metadata Operational Pattern Operation Pattern outline Generalized Operational Pattern 4 Specialized Operational Pattern I ndex Table 5 Encoding guideline for professional tape-less camera recorder 5 General 5 Operational Pattern General 2 Operation of OP-1 a Operation of OP-Atom Bibliograph y 20 Figure – Overview of MXF file structure Figure – Required order of file com ponents in each Partition kind I EC TS 62871 -1 :201 © I EC 201 Figure Figure Figure Figure Figure Figure Figure Figure –3– – Key-length-value encoding 1 – Header Metadata structure – Generalized Operational Pattern – Basic structure of Material Package and File Package in OP-Atom – Typical exam ple of I ndex Table placem ent for OP-1 a – Exam ple-1 to locate the entire I ndex Table in the Bod y Partition – Exam ple-2 to locate the entire I ndex Table in the Header Partition – Basic Structure of OP-Atom –4– I EC TS 62871 -1 :201 © I EC 201 INTERNATI ONAL ELECTROTECHNI CAL COMMISSI ON P RO F E S S I O N AL VI D E O S T O R AG E P R O D U C T S – T AP E -L E S S C AM E RA RE C O R D E R U S I N G M XF F I L E F O RM AT – EN CODI N G GU I DE LI N ES – P a rt : M X F O p e ti o n a l P a tte rn s FOREWORD ) The I nternati on al Electrotechni cal Comm ission (I EC) is a worl d wid e organization for stan dardization com prisin g all n ation al el ectrotechnical comm ittees (I EC National Comm ittees) The object of I EC is to prom ote internati onal co-operation on all questions concerni ng stand ardi zati on in the el ectrical an d electronic fields To this end and in additi on to other acti vities, I EC publish es I nternational Stan dards, Techn ical Specifications, Technical Reports, Publicl y Avail abl e Specificati ons (PAS) an d Gu ides (h ereafter referred to as “I EC Publication(s)”) Thei r preparation is entrusted to technical comm ittees; any I EC National Comm ittee interested in the subj ect dealt with m ay partici pate in this preparatory work I nternational, governm ental an d n on governm ental organ izations l iaising with th e I EC also participate i n this preparation I EC collaborates closel y with the I ntern ational Organi zation for Stand ardization (I SO) in accordance with ditions determ ined by agreem ent between th e two organi zati ons 2) The form al decisions or ag reem ents of I EC on tech nical m atters express, as n early as possible, an i nternati onal consensus of opi nion on the rel evant subjects since each technical com m ittee has representati on from all interested I EC N ational Com m ittees 3) I EC Publications have the form of recomm endations for intern ational use an d are accepted by I EC National Com m ittees in that sense While all reasonable efforts are m ade to ensure that the tech nical content of I EC Publications is accu rate, I EC cann ot be h eld responsi ble for th e way in which th ey are used or for an y m isinterpretation by an y en d u ser 4) I n order to prom ote intern ational u niform ity, I EC National Com m ittees und ertake to apply I EC Publications transparentl y to the m axim um extent possible i n their national an d regi on al publicati ons Any d ivergence between an y I EC Publication and the correspondi ng national or regi on al publicati on sh all be clearl y in dicated in the latter 5) I EC itself d oes n ot provi de an y attestation of conform ity I n depend ent certificati on bodies provi de conform ity assessm ent services and, in som e areas, access to I EC m arks of conform ity I EC is not responsi ble for any services carri ed out by ind ependent certification bodi es 6) All users shou ld ensure that th ey have the l atest editi on of thi s publicati on 7) No liability shall attach to I EC or its directors, em ployees, servants or ag ents inclu din g in divi dual experts an d m em bers of its technical com m ittees and I EC Nati on al Com m ittees for any person al i njury, property d am age or other dam age of any nature whatsoever, wheth er di rect or indirect, or for costs (includ i ng leg al fees) and expenses arisi ng out of the publ ication, use of, or relian ce upon, this I EC Publicati on or any other I EC Publications 8) Attention is drawn to th e N orm ative references cited in th is publ ication Use of the referenced publ ications is indispensable for the correct applicati on of this publication 9) Attention is drawn to the possibility that som e of the elem ents of this I EC Publication m ay be the su bject of patent rig hts I EC shall not be held responsibl e for identifyi ng any or all such patent ri ghts The main task of I EC technical com mittees is to prepare I nternational Standards I n exceptional circum stances, a technical com mittee m ay propose the publication of a Technical Specification when • • the required support cannot be obtained for the publication of an I nternational Standard, despite repeated efforts, or the subj ect is still under technical development or where, for an y other reason, there is the future but no imm ediate possibility of an agreem ent on an I nternational Standard Technical Specifications are subject to review within three years of publication to decide whether they can be transform ed into I nternational Standards I EC TS 62871 -1 , which is a Technical Specification, has been prepared by technical area 6: Storage media, storage data structure, storage system s and equipm ent, of I EC technical comm ittee 00: Audio, video and multim edia systems and equipm ent I EC TS 62871 -1 :201 © I EC 201 –5– The text of this technical specification is based on the following documents: Enqui ry draft Report on votin g 00/2373/DTS 00/2446/RVC Full inform ation on the voting for the approval of this Technical Specification can be found in the report on voting indicated in the above table This publication has been drafted in accordance with the I SO/I EC Directives, Part The comm ittee has decided that the contents of this publication will rem ain unchanged until the stability date indicated on the I EC website under "http: //webstore iec ch" in the data related to the specific publication At this date, the publication will be • • • • • transformed into an I nternational Standard, reconfirmed, withdrawn, replaced by a revised edition, or amended A bilingual version of this publication m ay be issued at a later date I M P O R T AN T th a t it – Th e ' co l ou r i n s i d e' tai n s u n d e rs t a n d i n g c o l o u r p ri n t e r of c o l o u rs i ts wh i c h c o n te n ts l og o a re U s e rs on th e co ve r p ag e o f th i s c o n s i d e re d sh ou ld to t h e re fo re be p u b l i c a ti o n u s e fu l p ri n t th i s fo r i n d i cate s th e d o cu m en t c o rre c t u sin g a –6– I EC TS 62871 -1 :201 © I EC 201 INTRODUCTION The professional camera recorder has evolved from a traditional tape-based system into a file-based system , taking advantage of recent advances in inform ation technolog y I nstead of using conventional m agnetic tape as the recording m edium , video and audio streams can now be stored as files that can be read directl y by a personal computer (PC) Several file format specifications exist, and most broadcasters are using the Material eXchange Form at (MXF) which has been standardized by the Society of Motion Picture and Television Engineers (SM PTE) As reported in I EC TR 6271 2: 201 , the MXF file format has been adopted for various types of professional tape-less cam era recorders MXF is being used by m an y broadcast stations around the world Since the MXF file format provides a multiplicity of functions and options in order to satisfy the needs of various applications in a range of situations, it is im portant to address interoperability issues between equipm ent Therefore, it is essential for interoperability that there is an appropriate Technical Specification that specifies guidelines for MXF im plem entations and operation al usage The I EC 62871 series gives encoding guidelines for professional tape-less camera recorders using the MXF file format to ensure interoperability Future parts will be proposed to specify implementation guid elines appropriate for specific codecs I EC TS 62871 -1 :201 © I EC 201 –7– P RO F E S S I O N AL VI D E O S T O R AG E P R O D U C T S – T AP E -L E S S C AM E RA RE C O R D E R U S I N G M XF F I L E F O RM AT – EN CODI N G G U I DE LI N ES – P a rt : M X F O p e ti o n a l P a tte rn s S cop e This part of I EC 62871 , which is a Technical Specification, gives guidelines for MXF Operational Patterns for professional tape-less cam era recorders and also outlines the general parts of the MXF file format The guidelines are applicable to the creation of an MXF file in professional tape-less cam era recorders They are also applicable for content management software and to equipment that supports MXF files generated by professional tape-less camera recorders N o rm a t i ve re fe re n c e s The following docum ents, in whole or in part, are normativel y referenced in this document and are indispensable for its application For dated references, onl y the edition cited applies For undated references, the latest edition of the referenced docum ent (including an y amendments) applies SM PTE ST 377-1 : 201 , Material Exchange Format (MXF) – File Format Specification For Television – Material Exchange Format (MXF) – Operational Pattern 1a (Single Item, Single Package) SMPTE ST 378:2004, SMPTE ST 379-1 : 2009, Material Exchange Format (MXF) – MXF Generic Container SMPTE ST 379-2:201 0, Container Material Exchange Format (MXF) – MXF Constrained Generic Material Exchange Format (MXF) – Specialized Operational Pattern “OP-Atom” (Simplified Representation of a Single Item) SM PTE ST 390: 201 , 3 T e rm s , d e fi n i t i o n s , a b b re vi a t i o n s a n d c o n v e n t i o n s T e rm s a n d d e fi n i t i o n s For the purposes of this docum ent, the term s and definitions given in SM PTE ST 377-1 , SM PTE ST 379-1 and SMPTE ST 379-2 appl y Ab b re v i a t i o n s Abbreviation Definition MP Material Package FP File Package –8– OP-1 a Operational Pattern a OP-1 b Operational Pattern b OP-1 c Operational Pattern c OP-2a Operational Pattern 2a OP-2b Operational Pattern 2b OP-2c Operational Pattern 2c OP-3a Operational Pattern 3a OP-3b Operational Pattern 3b OP-3c Operational Pattern 3c OP-Atom Operational Pattern Atom CBR Constant Bit Rate VBR Variable Bit Rate 3.3 I EC TS 62871 -1 :201 © I EC 201 Conventions I n this Technical Specification, capital letters are used for terms defining the MXF file standardized in the SM PTE publications which are cited in the norm ative references Overview of the MXF file format 4.1 General The MXF file form at is standardized in specifications are covered in several SM PTE ST 377-1 , which defines the data audio-visual material, all the components enable these com ponents to be added as a SMPTE, and different aspects of the detailed standards The general part is specified in structure of the MXF file for the interchange of of the MXF file form at and the requirem ents to plug-in to an MXF file The MXF Generic Container is specified in SMPTE ST 379-1 and SMPTE ST 379-2 The Generic Container is the native Essence Container of the MXF file bod y and these standards are defined to enable the interchange of streamable audio-visual material Appropriate essence and metadata payloads that can be mapped into the MXF G eneric Container are defined in associated docum ents listed in the Bibliograph y The MXF file form at includes Operational Pattern specifications that m ay define restrictions on the way in which this Essence Container type should be im plemented For exam ple, OP-1 a is specified in SMPTE ST 378 and OP-Atom is specified in SM PTE ST 390 I EC TS 62871 -1 :201 © I EC 201 –9– Fi l e stru ctu re Overvi ew An overview of the MXF file structure is shown in Figure The general structure of the MXF file comprises three com ponents: the File H eader, the File Bod y and the File Footer File H ead er Header Partition Pack Run I n File Bod y Header I ndex Metadata Table (opti on al) (opti on al) Essence Contain er Body Partition Pack File Footer Essence Contain er Footer Partition Pack (opti onal) Header Metadata Ran dom I ndex Pack (opti on al) (opti on al) IEC Fi g u re – Overvi ew of M XF fi l e stru ctu re 2 Fi l e H ead er The File H eader is located at the start of the MXF file and includes a H eader Partition Pack and a H eader Metadata The file header m ay include a Run-I n and an I ndex Table as an option Fi l e Bod y The File Bod y provides the mechanism for em bedding Essence Data such as audio, video and other associated data within the MXF files The File Bod y contains zero or m ore Essence Containers and, if there is more than one Essence Container in the File Bod y, the Essence Containers are m ultiplexed together using Partitions (see 4.3) Furtherm ore, the file bod y may include an index table and a repetition of the Header M etadata as an option 4 Fi l e Footer The File Footer is located at the end of the file As shown in Figure , the File Footer includes a Footer Partition Pack I t m ay include a repetition of the H eader Metadata and a Random I ndex Pack The File Footer m ay also include optional I ndex Table Segm ents 4 Parti ti on s Overvi ew Partitions logicall y divide the MXF file to allow easier parsing, to help stream ing and to manage the creation of I ndex Tables As shown in Figure 2, there are three kinds of Partitions in the MXF file The explanation of each Partition is described in the following sections – 10 – I EC TS 62871 -1 :201 © I EC 201 Header Partiti on Run I n Header Partition Pack Header Metadata (opti on al) I ndex Table Essence Container (opti on al) (opti on al) Next Partition Pack Body Partition Body Partition Pack Header Metadata I ndex Table (opti on al) (opti on al) Essence Container Next Partition Pack (opti on al) Footer Partiti on Body Partition Pack Header Metadata I ndex Table (opti on al) (opti on al) F i g u re – R e q u i re d Ran dom I ndex Pack (opti on al) o rd e r o f fi l e c o m p o n e n t s i n IEC e a ch P a rt i t i o n ki n d H e a d e r P a rt i t i o n The H eader Partition is the first Partition of the M XF file, and is located at the start of the MXF file following the optional Run-I n pack The File H eader of the MXF file always includes one Header Partition B o d y P a rt i t i o n The MXF file has zero or m ore Bod y Partitions As shown in Figure 2, the Bod y Partition Pack is located at the start of the Bod y Partition F o o t e r P a rt i t i o n The Footer Partition is the last Partition in the MXF file and no Essence Container is present in this Partition P a rt i t i o n ru l e s s u m m a ry E ss en ce C on tai n e r The logic describing Partitions, Essence Containers can be summarized as follows – The File bod y contains zero or m ore Essence Containers – The Essence Container can be identified by a non-zero Stream I D value called the Bod ySI D – The Essence Container can be segmented into one or m ore Partitions – The Partition containing data from a particular Essence Container has the sam e value of Bod ySI D – The order of Essence Container data after segmentation into Partitions is the same as the order of the unsegmented Essence Container Data I n d ex Tabl e The logic describing Partitions, I ndex Table can be sum marized as follows I EC TS 62871 -1 :201 © I EC 201 – 11 – – The data of each Essence Container can be indexed by an associated I ndex Table – Each I ndex Table can be identified with a non-zero Stream I D value called I ndexSI D – Each I ndex Table can be segm ented into I ndex Table Segm ents which are distributed into one or m ore Partitions – All Segments of a particular I ndex Table have the sam e value of I ndexSI D Each Partition includes zero or m ore I ndex Table Segments, each of which has the sam e value of I ndexSI D – The I ndex Table Segment segmented into Partitions is located in the sam e order as before the segm entation P a rt i t i o n s ta tu s The status of a Partition is classified into Open/Closed and Com plete/I ncom plete – Open/Closed: an Open Partition is one in which required H eader Metadata values have not been finalized (i.e required values m ay be incorrect) A Closed Partition is one that has a Partition Pack where all values have been finalized and are correct and either contains no Header Metadata or a Header Metadata where all required values have been finalized – I nomplete/Complete: an I ncom plete Partition is one where both Header Metadata exist and one or m ore Best Effort M etadata Properties are identified as unknown by setting their values to the defined Distinguished Value A Complete Partition is one with either no Header Metadata or where a Header M etadata exists and all Best Effort Metadata Properties contain their correct value The Partition status may change depending on whether the MXF file is under creation or finalized The status of a finalized MXF file is Closed When decoding the MXF file, MXF decoders need to recognize the status of each Partition for correct values of Header Metadata Properties 4 4 Ke y - L e n g t h - Va l u e ( KL V ) c o d i n g KL V e n c o d i n g s t ru c t u re Key-Length-Value (KLV) coding is defined in SM PTE ST 336 The MXF file consists of a contiguous sequence of KLV coded data packets All data within an MXF file except for the optional Run-I n are KLV coded with no gaps The KLV encoding structure is shown in Figure The protocol is com posed of a universal label (U L) identification key (U L key), followed by a num eric length (value length), followed by the data value UL Key Len gth Value byte Variable l en gth Actual data IEC F i g u re – K e y- l e n g t h - v a l u e e n c o d i n g 4 KL V F i l l I tem The KLV Fill I tem is defined as an empy m etadata item This is a KLV coded item where the value is comprised of null or meaningless data In certain applications, it is desirable to align KLV elem ents to specific byte boundaries I n such cases, this can be achieved by the insertion of the KLV Fill I tem into the MXF file – 12 – 4.5 4.5.1 I EC TS 62871 -1 :201 © I EC 201 Header M etadata Overview The H eader M etadata contains Metadata Sets which define the contents of the file as a whole, including an y Essence Containers The Header M etadata is broadl y categorized into two kinds: Structural M etadata and Descriptive Metadata 4.5.2 Stru ctural M etadata Structural Metadata describes the structure between each elem ent of the MXF file The MXF file form at defines the Package and the Sets of Structural Metadata as a single extensible schem e, and there are no other Structural M etadata schem es in the MXF file format The Structural Metadata occupies the first part of the H eader Metadata and specifies the relationship on the tim e axis between different types of essence and the relationship on the time axis between each package and Essence Descriptor such as picture size, frame rate, aspect ratio, sam pling rate and others 4.5.3 Descriptive M etadata Descriptive Metadata is defined as optional editorial metadata that enhance the usability of the Essence content of an MXF file Descriptive Metadata can import external metadata by a plug-in m echanism which can be im plem ented into one or more m ultiples in the Header Metadata The MXF file form at provides the function that uniquel y identifies im ported Metadata Schem es and it is possible to decode Descriptive M etadata synchronizing with audio and video using this plug-in mechanism 4.5.4 Structu re of H eader M etadata An example of the structure of H eader Metadata is shown in Figure H eader M etadata starts with the Prim er Pack that gives a Local Tag for each UL Key used in the Partitions Then it is followed by the Structural Metadata and the optional Descriptive M etadata Sets A Fill I tem can be added as padding data into the last part of the Header Metadata in order to align with the total number of bytes Header M etadata is categorized into two kinds of packages: the M aterial Package and the Source Package They are logical groupings which consist of multiple tracks and are identified by the Package U I D (U M I D) given in each Package The Material Package describes an output timeline of the MXF file The Source Package describes link inform ation to the actual Essence The Source Package specified in this Technical Specification is the File Package which is referred from the Material Package and describes the Essence existing in the Essence Container In general, the MXF file recorded on the professional tape-less cam era recorder adopts video, two or four channels of audio and time code as a Track I EC TS 62871 -1 :201 © I EC 201 File Header – 13 – File Body Header Partition Pack Header Metadata Primer Pack Preface Set Essence Container Header Metadata : KLV coded File Footer Footer Partition Pack KLV Fill Item Preface Identification Content Storage Essence container Data Material Package Track (Timecode) Sequence (Timecode) Timecode Component Track (Picture) Sequence (Picture) SourceClip (Picture) Track (Sound ) Sequence (Sound ) SourceClip (Sound ) Track (Sound N) Sequence (Sound N) SourceClip (Sound N) Multiple Descriptor Picture Descriptor Sound Descriptor Sound N Descriptor Track (Timecode) Sequence (Timecode) Timecode Component Track (Picture) Sequence (Picture) SourceClip (Picture) Track (Sound ) Sequence (Sound ) SourceClip (Sound ) Track (Sound N) Sequence (Sound N) SourceClip (Sound N) Source Package IEC Fi gu re – H eader M etadata stru ctu re 6 Operati on al Pattern Operati on Pattern ou tl i n e The MXF file format defines Operational Patterns, as conformance points of MXF files, which specify levels of the MXF file com plexity Each MXF application can select an appropriate Operational Pattern depending on the required operations Figure illustrates nine levels of Generalized Operational Patterns, from OP-1 a to OP-3c, using a m atrix structure I n the m atrix given in Figure 5, the horizontal axes are the I tem Complexity representing the complexity of the I tem (clip) referenced from the output tim eline and the vertical axes are the Package Complexity representing the complexity of the Package (Essence) which are accessed sim ultaneousl y – 14 – I EC TS 62871 -1 :201 © I EC 201 The I tem Com plexity and the Package Com plexity specify three respective levels and each Operational Pattern is defined as a com bination of the levels as illustrated in Figure I n Figure 5, the Material Package (MP) is the m etadata representing the synchronization and playback order of source clips on the output timeline The File Package (FP) is the metadata representing actual essences referenced from the M aterial Package Operational Patterns are specified by the structures of M aterial Packages and File Packages IEC Fi gu re – G en eral ized Operation al Pattern Gen eralized Operation al Pattern The simplest structure in Generalized Operational Patterns is OP-1 a OP-1 a allows playback of a single clip where the length of the clip and the referenced essence are identical The Material Package, which represents clips on the output tim eline, can onl y access a single File Package I f OP-1 a applications access and play back video and multiple channels of audio sim ultaneousl y, all video and audio data need to be multiplexed in a single essence as a single File Package Other Operational Patterns are used for operations that are m ore complex If applications handle video and audio data as separate essences and access them simultaneousl y, OP-1 b, 2b and 3b need to be used to im plem ent multiple File Packages If applications play back m ultiple clips sequentiall y based on a playlist, OP-2a, 2b and 2c need to be used to specify a playlist in a Material Package If applications specify I n-point and Out-point for clips, higher level Operational Patterns, OP-3a, 3b and 3c need to be used OP-1 c, 2c and 3c enable to im plement two or more alternative Material Packages and specify different kinds of playback within a single MXF file I EC TS 62871 -1 :201 © I EC 201 S p e c i a l i z e d O p e t i o n a l – 15 – P a t t e rn The MXF file format allows defining Specialized Operational Patterns as needed depending on applications other than the Generalized Operational Patterns described in 6.2 OP-Atom is defined as a Specialized Operational Pattern to encapsulate each material in a separated file The structure where each video and audio clip is stored in a separated file is suitable for some applications such as editing OP-Atom requires containing a single essence in each MXF file and each essence is specified by a separated File Package I f applications handle m ultiple essences, multiple OP-Atom files, each of which contains a single essence, are needed OP-Atom enables a Material Package to access m ultiple File Packages sim ultaneously and all essences composing a clip can be played back synchronousl y Because of Specialized Operational Pattern, OP-Atom is not included in the m atrix given in Figure An example of the structures of the Material Package and the File Package is illustrated in Figure MP Video MXF file Picture track Sound track MP Audio MXF file Picture track Sound track External reference to FP(V) FP(V) Video essence Video essence Audio essence FP(A) Audio essence External reference to FP(A) F i g u re – B a s i c s t ru c t u re o f M a t e ri a l P acka g e an d F i l e P a cka g e i n IEC O P - At o m I n d ex Tabl e The I ndex Table is a look-up table in order to convert tim e offset on the tim eline of the MXF file into byte offset The I ndex Table gives a byte offset value for each Edit U nit of video and audio data from the start of the Essence Container in the MXF file The I ndex Table enables to speed up access to a target Edit U nit The I ndex Table can be located in an y Partitions of the MXF file Each I ndex Table can be divided into one or more Partitions 5 E n c o d i n g g u i d e l i n e fo r p ro fe s s i o n a l t a p e - l e s s c a m e re c o rd e r G e n e l The outline of the MXF file form at is described in Clause Clause describes recom mended Operational Patterns and restrictions for each Operational Pattern as a guideline for adopting the MXF file format in the professional tape-less cam era recorder I n particular, in order to operate with inform ation technology equipm ent, Clause is intended to maintain interoperability and conservation of the MXF file – 16 – O p e t i o n a l I EC TS 62871 -1 :201 © I EC 201 P a t t e rn G e n e l As reported in I EC TR 6271 2: 201 , two types of Operational Pattern, OP-1 a specified in SM PTE ST 378 and OP-Atom specified in SMPTE ST 390 are adopted for the professional tape-less camera recorder These two types of Operational Patterns are explained in 2.2 and 5.2 O p e t i o n G e n e l of O P-1 a c o n s t i n t s o n OP-1 a General constraints on OP-1 a shall be as specified in SMPTE ST 378 OP-1 a plays back with a single clip and it is required that the duration of the clip and the duration of referred essence are the sam e The Material Package can only access a single File Package OP-1 a allows the use of multiple Bod y Partitions The im plementation of the I ndex Table is optional Re c o m m e n d e d c o n s t i n t s It is recomm ended to enclose the video and audio essence in the MXF file and to interleave the video material, the audio material, and ancillary data as needed on a fram e-by-fram e basis Although an I ndex Table is optional, the I ndex Table that gives the byte offsets for all frames should be im plemented in order to enable random access Although an I ndex Table Segm ent is permitted to extend the 64 kB length lim itation as described in SMPTE ST 377-1 , this Technical Specification recom mends limiting the length to 64 kB in order to be com patible with im plementations that conform to the previous revision of SMPTE ST 377-1 E xa m p l e o f I n d e x T a b l e p l a c e m e n t i n O P -1 a Figure illustrates an exam ple of recom mended structure of I ndex Table placem ent When the professional tape-less camera recorder is creating an MXF file whilst recording, video material, audio m aterial and an y metadata such as tim e code are captured into the clip in real tim e I n order to create and record the associated I ndex Table Segm ent, it is recomm ended that the essence is segm ented into a certain interval of the Partition and the associated I ndex Table Segment(s) is newl y created and placed after the essence they index when closing the Partition The I ndex Table Segm ent is placed at the beginning of the next Partition which is created by the next essence I EC TS 62871 -1 :201 © I EC 201 – 17 – Fi l e H e ad e r Header Partition Pack Fi l e ov e ral l Fi l e B od y Header Metadata Es s ence Container K Edit U nit (1 frame ) L K System L Index Table #m Footer Partition Pack Body Edit Edit ・ ・ ・ Edit Body Unit Unit P.Pack P.Pack UnitSegment#0 Fi l e B od y Fi l e Foote r Index Table #0 Es s ence Container Edit Edit Edit Body Unit Unit ・ ・ ・ Unit P.Pack Segment#1 K Fill L K Picture L Fill Es s ence Container Edit Edit Edit Unit Unit ・ ・ ・ Unit Segment#2 Index Table #1 K Sound ch L K L Random Index Pack Es sence Container Body P.Pack ・・・ Fill ・・・ K Edit Index Edit Edit Table Unit Unit ・ ・ ・ Unit Segment#m #m-1 L Sound Nch K L Fill IEC F i g u re – T y p i c a l e x a m p l e o f I n d e x T a b l e p l a c e m e n t fo r O P - a In the exam ple of I ndex Table placem ent shown in Figure 7, since each I ndex Table Segment is located separatel y in each partition and footer, all the I ndex Table Segm ents need to be read first in order to play back the MXF file However, the larger the MXF file size, the longer the time taken to read them This m ay cause a delay to the start of playback of the MXF file Therefore, as shown in the exam ples of Figure and Figure 9, locating the entire I ndex Table Segm ents in the Bod y Partition or in the Header Partition on creation of the MXF file is recom mended To locate the I ndex Table prior to the Essence Container eases file access Fi l e H e ad e r Header Partition Pack Fi l e ov e ral l Fi l e B od y Fi l e Foote r Header Metadata Footer Partition Pack Random Index Pack Essence Container Body P.Pack Fi l e B od y K Edit U nit (1 frame ) L Index Table #0 System Index Table #1 K Index Table #2 L ・・・ Fill Index Table #m K Edit Edit Edit Edit Edit Edit Edit Edit Edit Unit Unit ・ ・ ・ Unit Unit Unit ・ ・ ・ Unit Unit Unit ・ ・ ・ Unit Segment#0 Segment#1 Segment#2 L Picture K L Fill K Sound ch L K L Fill ・・・ ・・・ Edit Edit Edit Unit Unit ・ ・ ・ Unit Segment#m K L Sound Nch K L Fill IEC F i g u re – E x a m p l e - t o l o c a t e t h e e n t i re I n d e x T a b l e i n t h e B o d y P a rt i t i o n Fi l e B od y Fi l e H e ad e r Fi l e ov e ral l Header Partition Pack Index Table #0 Header Metadata Index Table #1 Index Table #2 ・・・ Fi l e Foote r Index Table #m Footer Partition Pack Random Index Pack Essence Container Fi l e B od y Edit U nit (1 frame ) Body Edit Edit ・ ・ ・ Edit Edit Edit ・ ・ ・ Edit Edit Edit ・ ・ ・ Edit Unit Unit Unit Unit Unit Unit Unit Unit P.Pack UnitSegment#0 Segment#1 Segment#2 K L System K L Fill K L Picture K ・・・ L Edit Edit Edit Unit Unit ・ ・ ・ Unit Segment#m Fill K L Sound ch K L Fill ・・・ K L Sound Nch K L Fill IEC F i g u re – E x a m p l e - t o l o c a t e t h e e n t i re I n d e x T a b l e i n t h e H e a d e r P a rt i t i o n O p e t i o n o f O P - At o m G e n e l C o n s t i n t s o n O P - At o m General constraints on OP-Atom shall be as specified in SMPTE ST 390 As described in 3, each video and audio essence is encapsulated in a separate file in OP-Atom Figure illustrates the basic structure of an OP-Atom file – 18 – I EC TS 62871 -1 :201 © I EC 201 The video m aterial is contained in the video essence file and each channel of the audio material is contained in each audio essence file When ancillary data packets associated with each video fram e are added as data essence, the ancillary data packets are stored in a separate OP-Atom file for data essence Each File Package specifies a single essence in OP-Atom and it is therefore possible to encapsulate each essence using a different wrapping scheme and to specify a different edit rate for each Essence Track The Closed and Complete Header Partition status is required It is prohibited to divide a Bod y Partition into multiple Bod y Partitions I f applications need to divide the Bod y Partition, OP-1 b needs to be used A com plete I ndex Table is required for the Footer Partition File Header File overall Video Header Partition Pack File Body Header Metadata File Footer Footer Partition Pack Index Table Essence Container File Body Video Body Edit Edit Edit Edit Edit Edit Edit Edit Edit Edit Edit Edit Edit Edit Edit Edit Edit Edit Edit Edit Edit P.Pack Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit File Header File overall Audio x ch Header Partition Pack File Body Header Metadata ・・・ Edit Unit File Footer Footer Partition Pack Index Table Essence Container File Body Audio x ch Body Sample Sample Sample Sample Sample Sample Sample Sample Sample Sample P.Pack Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit ・・・ Sample Unit IEC Figure – Basic Structure of OP-Atom 5.2.3.2 Recommended constraints Each video and each channel of audio material is encapsulated using a separate file in OP-Atom When an OP-Atom file is played back, the default behaviour of the decoder is to reproduce the internal essence based on the File Package as Prim ary Package Professional tape-less camera recorders generate video and audio m aterial captured at the same time as a single clip, and m echanism s associating these m aterials are thus required I t is recommended that the Material Package should include all Essence Tracks for the clip and each track of the M aterial Package should reference the respective File Package for synchronization of all the essence I n this im plem entation, the Material Packages in all the OP-Atom files should specify how to play back the whole clip and the structure of the Material Packages should be identical NOTE Althou gh the associati on of essence am ong m ultiple OP-Atom files can be given by external m echan ism using a separate fil e such as an XM L text file, such im plem entations are out of th e scope of this Tech nical Specification OP-Atom requires a Closed and Complete status for the H eader Partition I t means all required and Best Efforts Metadata items are set to the correct values and therefore professional tape-less camera recorders need to update the values of item s such as the Duration to the correct value when it completes the recording