ENGINEERING REPORT MXF Timecode Study Group

ENGINEERING REPORT MXF Timecode Study SINCE 1916 Group Report

SMPTE ER-1:2017 Corrected 14 November 2017

Copyright © 2017 by the Society of Motion Picture and Television Engineers ®, Inc. (SMPTE ®) - All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, with the express written permission of the publisher.

SMPTE ER-1:2017

Engineering Report

MXF Timecode Study Group Report

Contents Glossary – abridged ...... 3 1 Introduction & Background ...... 4 2 Applications storing MXF Timecode ...... 6 2.1 Storing a single continuous Master Timecode ...... 6 2.1.1 Possible area of future Recommendation for MXF-TC-2.1 ...... 6 2.2 Storing Historical Continuous Timecode as metadata ...... 6 2.2.1 Possible area of future Recommendation for MXF-TC-2.2 ...... 6 2.3 Storing Historical Discontinuous Timecode as metadata ...... 6 2.3.1 Possible area of future Recommendation for MXF-TC-2.3 ...... 7 2.4 Storing per-frame Timecode values ...... 7 2.4.1 What is a per-frame MXF Timecode? ...... 7 2.4.2 What is a continuous per-frame MXF Timecode? ...... 7 2.4.3 Mechanisms ...... 8 2.4.4 Possible area of future Recommendation for MXF-TC-2.4 ...... 9 2.5 Labeling per-frame Timecode Streams...... 9 2.5.1 Possible area of future Recommendation for MXF-TC-2.5 ...... 9 2.6 Storing Timecode Streams in MXF files without Picture Essence ...... 9 2.6.1 Possible area of future Recommendation for MXF-TC-2.6 ...... 10 3 Applications accessing MXF Timecode ...... 10 3.1 Accessing a single continuous “master” Timecode ...... 10 3.1.1 Possible area of future Recommendation for MXF-TC-3.1 ...... 10 3.2 Accessing historical continuous Timecode as metadata ...... 10 3.2.1 Possible area of future Recommendation for MXF-TC-3.2 ...... 10 3.3 Accessing Historical Discontinuous Timecode as metadata ...... 10 3.3.1 Possible area of future Recommendation for MXF-TC-3.3 ...... 10 3.4 Accessing discontinuous Timecode value ...... 11 3.4.1 Possible area of future Recommendation for MXF-TC-3.4 ...... 11 3.5 Accessing Timecode Streams in MXF files without Picture Essence ...... 11 3.5.1 Possible area of future Recommendation for MXF-TC-3.5 ...... 11 3.6 Miscellaneous Use Cases of Timecode in MXF ...... 11 3.6.1 Timecode at non-video rates ...... 11

SMPTE ER-1:2017

3.6.2 Possible area of future Recommendation for MXF-TC-3.6.1 ...... 12 4 Future work on Timecode in MXF...... 12 Annex A An example Timecode Precedence table ...... 13 A.1 Areas where Recommendations could be created ...... 13 Annex B Full Glossary ...... 14 Annex C Excerpt from AMWA AS07 on archiving ...... 15 C.1 AS07 #6.4 Timecode ...... 15 C.1.1 AS07 #6.4.1 Timecode Categories (informative) ...... 15 C.1.2 AS07 #6.4.2 Timecode Sources (informative) ...... 15 C.1.3 AS07 #6.4.4 Master Timecode ...... 16 C.1.4 AS07 #6.4.5 Historical Source Timecode ...... 18 C.1.5 AS07 #6.4.7 Regard to Timecode ...... 19

Foreword SMPTE®, the Society of Motion Picture and Television Engineers® is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in more than 80 countries, on six continents. SMPTE’s Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTE’s Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents and Engineering Reports are drafted in accordance with the rules given in its Standards Operations Manual. This SMPTE Engineering Report was prepared by Technology Committee 31FS.

Page 2 of 20

SMPTE ER-1:2017

Glossary – abridged.

Full glossary later in this SG report. Timecode value A value that is decoded, read, calculated or evaluated to a legal SMPTE ST12-1 Timecode code word. Timecode stream A set of Timecode values that are stored or calculated such that more than one related Timecode Value exists in a file Timecode location The stored location where Timecode values are found for a given stream e.g. SMPTE ST 331 Continuous Timecode A Timecode stream where a Timecode value exists for every frame and all Timecode values must follow SMPTE ST12-1 counting rules Discontinuous Timecode A Timecode stream that is not continuous Master Timecode Master Timecode is continuous and is the primary, canonical representation of references into the essence for all Timecode-dependent activities. There is only one Master Timecode Historical Source Timecode The collective phrase for all non-Master Timecodes in a file Sparse Timecode stream A Timecode stream where values might be missing (e.g. MPEG GOP). A sparse Timecode stream might be continuous or discontinuous. If it is continuous, it must always be labeled as sparse. Consistent Timecode A file with multiple Timecode streams where every stream labeled with “shall” in the “clean” column of Table 1 in this document contains the same Timecode value within each frame. Timecode cleaning The process of modifying a file to create consistent Timecode. MXF-TC-N.M An application in this document specified in section N.M must statement reflecting a “shall” in a current or future specification would statement reflecting a “should” in a current or future specification might statement reflecting a “may” in a current or future specification

Page 3 of 20

SMPTE ER-1:2017

1 Introduction & Background

MXF was developed as a versatile professional wrapping format to describe existing media encapsulation practices as well as providing facilities for new applications. As a result of this evolution, there are many places where MXF is able to store Timecode values. This is summarized in the picture below:

H I Body Body Body

TC modulated in VBI (e.g. ST

TC in video essence (e.g. MP2)

TC in video wrapper (e.g. GOP)

MXF TC in audio essence (e.g. AES) OP1a TC TC TC TC TC TC TC mp2 4.wav.8 TC in MP XDCAM Lead continuous TC

►-SourcePackage---►-TCTrack-►-TCSequence-►-TCComponent TC in SP metadata | Master continuous TC

►-TCTrack-►-TCSequence-►-TCComponent TC in SP | Historical continuous TC

►- DateTimeDescriptor-►-ST405TCindex TC link to essence bytes

MXF can store Timecode values as Metadata in the headers as well as capturing Timecode values from media streams and storing them in a file. The HANC, VANC & VBI specifications from SMPTE as well as de-facto specifications contain rules for the placement of Timecode values. MXF has multiple places in which VANC or VBI information may be carried. The end result is that multiple MXF Timecode values might exist for each frame in a file. The goal of this report is to look at the requirements for the use of Timecode within different MXF applications. The Study group requested a list of Timecode applications from the participants. The sections of this report cover the applications that were identified. MXF applications can broadly be split into storing MXF Timecode or accessing MXF Timecode applications. They are split this way because we describe different behaviors of an application or device e.g. • Storage applications o How do I store a master Timecode values in MXF? o How do I store multiple Timecode streams in MXF? o How do I store discontinuous Timecode values in MXF? o How do I label the Timecode values in MXF? • Access applications o How do I seek and then playback a file from a given Timecode value? o If there are multiple Timecode values, which one should I use? o How do I find the original tape Timecode value for a file Timecode value of hh:mm:ss:ff? o How can I be sure that the embedded Timecode Streams are continuous and agrees with the synthetic lead Timecode Stream? o What is the source audio Timecode value for sample N in a stream?

Page 4 of 20

SMPTE ER-1:2017

There seem to be three key user requirements1 for the values of Timecode in file: 1. A requirement to have multiple, identical Timecode values for each frame, regardless of the source of the Timecode values. 2. A requirement to allow multiple, unique Timecode values for each frame to permit, for example, multiple tape originated Timecode values to be preserved in an MXF File. 3. A requirement for Timecode to be used in MXF files that contain no essence at video frame rates for example audio-only MXF files. This Study Group report examines the usage and requirements of Timecode in MXF files and identifies areas where further Recommendations or Standards could be created to improve interoperability The report also differentiates between content that is being produced or shown and that same content when it is being archived. The archive and preservation application requires all Timecode values to be preserved whereas the production / playback application requires a single canonical representation of Timecode that all devices and software agree on. The EBU recommendation R122 has done good initial work on the requirement (1). Listed in the table below is a high level list of places in which Timecode values in MXF might be found. Table 1: Timecode Value Locations in an MXF File

MXF ref Layer TC type Notes ST 377-1 Header / Footer metadata Material Package continuous TC ST 377-1 Header / Footer metadata File Package TC – contiguous linear segments ST 381 MPEG video GOP header / GOV header Per GOP / GOV TC in video essence ST 381 MPEG video ST 328 #5.6 MPEG2 user data Per frame TC in video essence ST 381 AVC video pic_timing SEI message Per frame TC in video essence ST381 AVC video Proprietary SEI message Per frame TC in video essence ST 381 MPEG video Proprietary MPEG2 user data Per frame TC in video essence ST 381 MPEG video proprietary storage in ISO- Per frame TC in video essence 14496 SEI messages for ANC and/or TC ST 382 AES Audio AES User bits Per audio sub-frame TC in audio essence ST 382 Wav audio bext & iXML chunk Start TC + frame rate ST 383 DV essence Subcode Sync Block TC pack Per frame TC in the DIF block structure ST 385 System Item Essence (ST 331 #8.2) Per-frame TC values (up to 2 streams) ST 405 System Scheme Essence (ST 394 + ST 331 Per-frame TC values (array of N streams) 1 #8.2) ST 436 VBI Essence (ST xxx) In-vision TC in digitized Analogue VBI ST 436 VANC Essence (ST 291) VANC packets containing TC RDD 32 XAVC ST 385 and ST 436 Specific Timecode rules for this mapping ST 386 In-vision Essence in an SD image In-vision TC in digitized Analogue VBI Items in the table above that are blue italic are considered buried Timecodes. See section

This Study Group report examines the usage and requirements of Timecode in MXF files and identifies areas where further Recommendations or Standards could be created to improve interoperability

1 For example see linked in discussion on Timecode values in DPP files https://www.linkedin.com/grp/post/4581207-5936095155584016388

Page 5 of 20

SMPTE ER-1:2017

2 Applications storing MXF Timecode

In this report, Master Timecode is continuous and is the primary, canonical representation of references into the essence for all Timecode-dependent activities. Other Timecode values in a file will be referred to as Historical Source Timecode.

2.1 Storing a single continuous Master Timecode

MXF-TC-2.1 is the term used in this report for an MXF Application that requires a single continuous Master Timecode A single, continuous master Timecode is stored in MXF as the Timecode component of the Material Package as specified in SMPTE ST 377-1. The Primary Package property would be set to that Material Package unless some specification prevents it. The specification states that there may be zero or one Timecode Tracks, but in practice all MXF files have a Material Package Timecode Track. In the AMWA AS-11 specifications and in work from the UK’s Digital Production Partnership, the term authoritative Timecode has been used to define the only Timecode that shall be used to reference content in the file. This prevents decoders having to decide which of the potential Timecode carriage mechanisms should be used as the definitive one. For the AS-11 group of specifications, the Material Package Timecode Component is used as the source of authoritative Timecode.

2.1.1 Possible area of future Recommendation for MXF-TC-2.1 This Study group believes that interoperability would be improved if Technology Committee 31FS (TC31FS) worked on recommendations for compliant encoders to set the Timecode component values to match the frame rate of the video essence stream.

2.2 Storing Historical Continuous Timecode as metadata

MXF-TC-2.2 is the term used in this report for an MXF Application that requires the storing of historical continuous Master Timecode Similar to the “master” Timecode, a single, continuous historical Timecode must be stored in MXF as the Timecode component of the Source Package as specified in SMPTE ST 377-1. Typically the value of the Start Timecode Mxf::Position of the Source Package is equal to the Start Timecode Mxf::Position of the master Timecode, minus the value of origin in the Timeline Track, although this is not required. In particular, the master Timecode may be changed at some time after the clip is created. Master Timecode behavior must be the same as section 2.1

2.2.1 Possible area of future Recommendation for MXF-TC-2.2 This Study group believes that interoperability would be improved if TC31FS worked on recommendations for compliant encoders to store historical consistent Timecode in a single consistent way.

2.3 Storing Historical Discontinuous Timecode as metadata

MXF-TC-2.3 is the term used in this report for an MXF Application that requires the storing of historical discontinuous Timecode values Editorial and Archival applications that require the tracing of the provenance of source material often store Historical Source Timecode tracks in MXF Lower Level Source Packages (LLSPs), referenced via Source Clips in higher level Source Packages, and treat these tracks as metadata. This is useful for describing Timecode discontinuities that may exist in original recordings or that may arise when selected sections of original material are assembled into a composite file.

One methodology creates a LLSP with Timecode Tracks that contain a Sequence of TimecodeComponents (SMPTE ST 377-1 annex B.16), in which segments of Timecode are given as TimecodeComponents (SMPTE ST 377-1 annex B.17) with Start and Length. Segments with no Timecode or undecodable Timecode are given as Filler (SMPTE ST 377-1 annex B.11).

Page 6 of 20

SMPTE ER-1:2017

A second methodology creates a LLSP with a single continuous Timecode as in section 2.2, and uses Timecode Tracks that contain a Sequence of SourceClips (SMPTE ST 377-1 annex B.10) that refer to the LLSP Timecode.

In either case, the Historical Source Timecode may be of a different frame rate or kind that the Master Timecode, and there may be several different Historical Source Timecodes: examples include film key numbers and edge numbers, separate sound Timecodes for post-syncing, and IRIG (Inter Range Instrumentation Group) timestamps.

Both these methodologies are in use in the industry, and both are supported by the provisions of SMPTE ST 377-1 as cited, but neither methodology is formally documented as a SMPTE Standard or Recommended Practice.

2.3.1 Possible area of future Recommendation for MXF-TC-2.3 This Study group believes that interoperability would be improved if TC31FS worked on recommendations for compliant encoders to store historical discontinuous Timecode as metadata.

2.4 Storing per-frame Timecode values

MXF-TC-2.4 is the term used in this report for an MXF Application that requires the storing of historical per-frame Timecode values This section of the report contains paragraphs with guidance notes on storing Timecode in MXF. The assumption in the guidance is that the overall goal of the larger MXF project is to separate different essence component types into different MXF wrappers and to describe them consistently. It assumes that the more “buried” or “encapsulated” that a Timecode value is, then the less importance it should be given in an MXF workflow. For example, Timecode values that are in an MXF System Item should be given precedence over in-vision Timecode values within an MPEG2 elementary stream.

2.4.1 What is a per-frame MXF Timecode? A per-frame Timecode mechanism is one in which one or more streams of legal Timecode values may be stored, identified and uniquely associated with any frame. Within MXF the per-frame Timecode streams are considered as Essence and will be found wrapped in a System Item or Data Essence Item or Video Essence Item. It is possible that some of these per-frame Timecode values are buried inside an MXF file with no metadata to identify their nature or presence. Moreover, there have been devices and software applications created that rely on the presence of these Timecode Streams. These Timecode values may not have been clearly mapped to the MXF layer and the only way in which they could be discovered would be by exhaustive parsing the essence bytes of the corresponding essence track. The Study Group discussed the fact that a buried Timecode Stream is not considered to be a per-frame Timecode stream from an MXF standpoint. It is, however, a stream of Timecode values that may occur once per frame and may be used by some applications even though MXF Timecode values may be available. It is theoretically possible to construct a series of MXF Header metadata Timecode Components for a top level File Package such that there is a Timecode Component per frame (see 2.3 above). Whilst this will give per-frame Timecode values, it is not considered to be a per-frame Timecode stream. The Study Group felt that though this was theoretically possible guidance should be given to prevent it happening in practice.

2.4.2 What is a continuous per-frame MXF Timecode? Continuous per-frame MXF Timecode is any stream that has: 1. A defined Timecode counting mode 2. A Timecode value for every frame 3. The Timecode value for frame [n+1] is always the next legal count value after the Timecode value for frame [n] with no gaps. If any of the rules 1-3 is not met then the stream is not continuous.

Page 7 of 20

SMPTE ER-1:2017

To make a Timecode Stream continuous, each value in that Timecode Stream could be modified. The Study Group also found that updating Timecode Streams in a file may lead to destruction of irretrievable data that may have unknown consequences in certain applications such as archiving. In some application (e.g. playout) updating the Timecode Streams in a file was felt to be acceptable, but in others, such as archiving, it was felt to be bad practice.

2.4.3 Mechanisms Frequently, there is a need to store a unique per-frame Timecode. These per-frame values may be continuous or they may be discontinuous. Typically, there is no way of knowing whether every value of the data will be continuous without inspecting every value. There are a number of places that Timecode values can be stored, some of which are covered by MXF documents, and others which are outside the scope. Table 1 in the introduction gives a list of locations. A subset of those is described in more detail below: • The CP System Item defined by SMPTE ST 331. This structure has two Timecode values. One is defined as a SMPTE ST 12-1 Time Code. The other is defined by ST 309 as a date and time zone but with the same size as the SMPTE ST 12-1 Timecode, some applications store a secondary Timecode here. • The GC System Item. This is defined across a number of documents, beginning with SMPTE ST 394 for the basic structure of this System Item, and SMPTE ST 405 for a variety of elements, including a Timecode array. Currently there exists no linkage mechanism to identify the source of any Timecode in the array. Common use in 2016 places only one Timecode value in the array. Defined outside of MXF (i.e. non-MXF schemes) and currently having no linkage definition to identify the presence of a Timecode stream: • A SMPTE ST 291-1-2011 ANC packet stored in a SMPTE ST 436-1-2014 stream. • DID and SDID values defined at http://smpte-ra.org in the SMPTE Ancillary Data ST 291 section v DID 0x60, SDID 0x60 = Ancillary Time Code v DID 0x64, SDID 0x64 = Time Code in HANC space (Deprecated; for reference only) v DID 0x64, SDID 0x7F = VITC in HANC space (Deprecated; for reference only) • SMPTE RP 291-2-2013 gives guidance on the placement of SMPTE ST 291-1 packets. This should be respected even when encapsulated in a SMPTE ST 436-1 wrapper. • SMPTE ST 328, designed to aid the MPEG editing, includes two slots for SMPTE ST 12-1 Timecode. The structure is stored as MPEG user data and is usually placed in an MPEG video stream. ST 328 mentions long-GOP structure but gives no guidance as to whether Timecode placement is reordered or not. Hence multiple interpretations exist. • ISO/IEC 61883 defines DV and includes Time Code packs within an SSYB Subcode Sync block • H.264 pic_timing SEI messages containing clock_timestamp. H.264 contains a time offset calculation scheme that includes a mechanism for indicating drop frame timing modes. It is bit efficient, but no explicit mapping to the MXF layer exists. • H.264 proprietary SEI messages. Note that the list above and in Table 1 does not imply that only one Timecode Stream will be in a file. For example an SMPTE ST 386 standard definition D10 file may have the following Timecodes within a single file: • In-vision VITC on lines 12-14 (NTSC) (SMPTE ST 386 encodes 32 VBI lines in-vision) • SMPTE ST 436 copy of the VBI TC in (1) • SMPTE ST 436 VANC packet TC • MPEG2 GOP header TC • SMPTE ST 328 MPEG2 user data TC inside SMPTE ST 386 video essence wrapping • SMPTE ST 331 in-audio TC (ch 1 of 4 different TC streams worst case) • SMPTE ST 331 in-audio TC (ch 2 of 4 different TC streams worst case) • SMPTE ST 331 in-audio TC (ch 3 of 4 different TC streams worst case) • SMPTE ST 331 in-audio TC (ch 4 of 4 different TC streams worst case) • SMPTE ST 385 TC – creation TC • SMPTE ST 385 TC – user TC • MXF Material Package TC (metadata) • MXF File Package TC (historical – 1 of N)

Page 8 of 20

SMPTE ER-1:2017

In real life, it is unlikely that a file will have 13 different Timecode streams, but in practice it may have several different Timecode streams within the file. Currently there is no guidance as to their precedence or usage. Based on the feedback gathered during the compilation of this report, a proposed structure for a precedence chart appears in Annex A.

2.4.4 Possible area of future Recommendation for MXF-TC-2.4 This Study group believes that interoperability would be improved if TC31FS worked on recommendations for compliant encoders to store per-frame Timecode in a consistent way with identification of precedence and how that precedence should be used. The Study Group further believes that recommendations for making Timecode Streams continuous would improve the current situation where inadvertent data loss may occur. The Study Group also felt that there were some theoretically possible Timecode constructs that would be bad practice and that recommendations to avoid or prevent these would improve interoperability.

2.5 Labeling per-frame Timecode Streams

MXF-TC-2.5 is the term used in this report for an MXF Applications that label MXF Timecode streams.

2.5.1 Possible area of future Recommendation for MXF-TC-2.5 This Study group believes that interoperability would be improved if TC31FS worked on recommendations for compliant encoders to label Timecode streams in a consistent way with identification of precedence and how that precedence should be used. This work should include 1. Use of the term “Track” so that users have a familiar term to refer to Timecode streams 2. Use of Descriptors, specifically the use of the DateTimeDescriptor defined in SMPTE ST 385- 2012 which provides a good framework for identifying the usage of different Timecode streams with a property “Date/Time Kind” which is a registered SMPTE Label. The DateTimeDescriptor is an extension of File Descriptor and can describe a Track through its LinkedTrackId property as well as describing that the Timecode values are embedded essence 3. Use of any subdescriptor to extends the DateTimeDescriptor in order to identify the historical signal from which the Historical Timecode was derived. Annex C gives an example of existing work in this area done by SMPTE members in the AMWA AS-07 specification. 4. Use of precedence data to define the order in which Timecode streams should be used in a given application

2.6 Storing Timecode Streams in MXF files without Picture Essence

MXF-TC-2.6 is the term used in this report for an MXF Applications that store Timecode in MXF files that do not contain picture essence. MXF componentized workflows, notably those using Digital Cinema Packages or IMF or AS-02 bundles, create MXF Essence files that contain only audio or only subtitles or only SMPTE ST 436 VANC data. For the audio only files, the essence is typically sampled at 48kHz or 96kHz and the MXF data structures can be completely generated without any reference to a video frame rate with one exception. There is no guidance on the correct way of embedding Timecode in these files. MXF mandates that there be zero or one Material Package Timecode tracks, but there is no guidance as to the values that should be set in that MXF Timecode Component. The Study Group found that some applications would create a Timecode stream with a frame rate identical to the original Picture Essence stream with which it was associated. The Study Group also found that this caused issues when, for example, the Picture Essence stream was converted from 24fps to 30fps by insertion of a 3:2 sequence, not all applications would update the Timecode Stream in the associated non-Picture MXF files. It also found that some applications were tolerant of this Timecode difference and that others were not. The study Group also found that for audio codecs such as AAC where alignment of video samples and audio access units rarely occurs, the Track Origin property has been used to offset the audio samples from the video Timecode to achieve alignment. For example when taking an MPEG-TS with H.264 video (60000/1001) with AAC audio (index rate 48000/1024) and creating an AS-02 bundle. There is no guidance on the use of Timecode in this use case and inter-vendor interoperability is unlikely without some common approach.

Page 9 of 20

SMPTE ER-1:2017

The Study Group also found that the use of Timecode in audio-only files is an operational requirement and that the use of thousandths of a second in notation of Timecode isn’t uncommon because it allows truing up of audio samples with video frames even when sampling rate varies.

2.6.1 Possible area of future Recommendation for MXF-TC-2.6 This Study group believes that interoperability would be improved if TC31FS worked on recommendations for compliant encoders to store and update Timecode in non-Picture MXF files, particularly including the interaction of the Timecode values with other MXF properties such as Track Origin and Index Tables.

3 Applications accessing MXF Timecode

3.1 Accessing a single continuous “master” Timecode

MXF-TC-3.1 is the term used in this report for an MXF Applications that needs to access a file using a single continuous Master Timecode stream. To access material in this application, Timecode must be synthesized from MXF metadata. The Timecode corresponding to the first frame of the file is calculated from the Material Package Timecode component. The Timecode for each subsequent frame is calculated by incrementing the count according to the counting rules in SMPTE ST 12-1 according to the metadata in the Timecode component specified in SMPTE ST 377-1. During random access operations, the frame to be accessed is referenced by the value of its MXF::Position. This value is used to retrieve a byte offset from the MXF Index Tables. There should never be a difference between the Timecode value of a frame that is sequentially accessed and the Timecode value of that same frame when it is being randomly accessed.

3.1.1 Possible area of future Recommendation for MXF-TC-3.1 This Study group believes that interoperability would be improved if TC31FS worked on recommendations for compliant decoders to prioritize the Material Package Timecode Component above all others.

3.2 Accessing historical continuous Timecode as metadata

MXF-TC-3.2 is the term used in this report for an MXF Applications that needs to access a file that using a single continuous historical Timecode stream. The behavior of an MXFTC-3.2 application is identical to that of an MXF-TC-3.1 application with the addition of being able to choose and / or communicate the source of the Timecode being used as a reference. The Timecode sources may be any Timecode components in any package within the MXF file. Annex C gives details of an existing application that re-uses SMPTE time label descriptors to identify the sources of Timecode.

3.2.1 Possible area of future Recommendation for MXF-TC-3.2 This Study group believes that interoperability would be improved if TC31FS worked on recommendations for compliant decoders to identify the source of a historical Timecode stream.

3.3 Accessing Historical Discontinuous Timecode as metadata

The behavior of an MXFTC-3.3 application is identical to that of an MXF-TC-3.2 application with the addition of being able to choose and / or communicate discontinuities within the Timecode being used as a reference. The Timecode sources may be any Timecode components in any package within the MXF file.

3.3.1 Possible area of future Recommendation for MXF-TC-3.3 This Study group believes that interoperability would be improved if TC31FS worked on recommendations for compliant decoders to communicate discontinuities within a historical Timecode stream.

Page 10 of 20 pages

SMPTE ER-1:2017

3.4 Accessing discontinuous Timecode value

As described in section 2.4, discontinuous Timecode can be stored as an essence stream in addition to the mechanism in section 2.3 describing discontinuous metadata representation. Annex A gives an example of a precedence table for Timecode Streams in an MXF file. The Study Group found that applications that require the retrieval of discontinuous Timecode would treat the streams like essence. Index tables would be used to find the byte location of the Timecode Essence for any given value of Mxf::Position. Any interface presented to a user would ensure that it is some representation of Mxf::Position that is considered as the master representation of elapsed time, and that any discontinuous Timecode Stream is presented as being indexed against that linear time reference. Currently there is no standardized reference for this behavior. The Study Group found no examples on behavior when index tables were absent and no guidance on the reporting of the relationship between Mxf::Position, the master Material Package Timecode(that is linear) and the retrieved Timecode values from the stream. The Study Group also found inconsistent behavior on an application creator’s assumption that a stored stream of Timecode values will be continuous or linear in count mode. The Study Group also found that some production practices where Timecode is set to time of day could be problematic when synchronizing different files. The Study Group also found that the application behavior of using Timecode in subtitle files was inconsistent and that guidance should be created to explain the relationship between Timecode at the MXF layer and timing information within an embedded subtitle (or caption) file.

3.4.1 Possible area of future Recommendation for MXF-TC-3.4 This Study group believes that interoperability would be improved if TC31FS worked on recommendations for compliant decoders to identify the source of a historical Timecodestream and to address and access discontinuous elements within that stream and gave guidance on application behavior in the presence of discontinuous Timecode behavior.

3.5 Accessing Timecode Streams in MXF files without Picture Essence

MXF-TC-3.5 is the term used in this report for an MXF Applications that access Timecode in MXF files that do not contain picture essence. As described in section 2.5, some applications create Timecode in MXF files that have only non-Picture Essence. The Study Group found that application behavior is inconsistent when MXF files with different Timecode Stream rates were used together.

3.5.1 Possible area of future Recommendation for MXF-TC-3.5 This Study group believes that interoperability would be improved if TC31FS worked on recommendations for compliant decoders to access Timecodein non-Picture MXF files where the base rate of those Timecode Streams may be inconsistent.

3.6 Miscellaneous Use Cases of Timecode in MXF

This section details some specialist applications of Timecode in MXF files. Whilst these use cases might be less common that those describes elsewhere in the document, MXF decoders are expected to be tolerant of these use cases as they are compliant with the rules described in SMPTE ST 377-1

3.6.1 Timecode at non-video rates In some production workflows it is possible that an audio track might be inserted into an MXF file where the Timecode associated with that audio track is different to the video track within the file. This can lead to the situation where some of the Top Level Source Packages might have Timecode Tracks that have a Timecode rate that is different to the video rate.

Page 11 of 20 pages

SMPTE ER-1:2017

For example, the video track may have a Timecoderate of 30 fps. One or more of the audio track may have a Timecodecomponent with a Timecoderate of 24 fps in the Top Level Source Package.

3.6.2 Possible area of future Recommendation for MXF-TC-3.6.1 This Study group believes that interoperability would be improved if TC31FS worked on recommendations for compliant decoders to categorize this Timecode as historical and to access it appropriately.

4 Future work on Timecode in MXF

The Study Group wishes to make the MXF community aware that work on High Frame Rate Timecode has been carried out and will be standardized in SMPTE ST 12-3. Currently this work has not currently been mapped into any update of the MXF Specification. The Study Group also wishes to make the MXF community aware that extensive work on a new Time Label in SMPTE ST 2103, Time Related Label in SMPTE ST 2105, and a new synchronization system in SMPET ST 2059 has been carried out within SMPTE and those works do not currently have any MXF mappings.

Page 12 of 20 pages

SMPTE ER-1:2017

Annex A An example Timecode Precedence table The table in this annex proposes an example of a way that SMPTE could define the order in which Timecode values would be set or used in an MXF Applications. This Study Group felt that recommendations in a format similar to this table would improve interoperability.

Rank Location Name Per-Frame? Clean? Notes 1 Header / Footer metadata No must Lead TC for all MXF operations 2 Header / Footer metadata No must Historical record of TC values 3 System Item: TC (CP) Yes – [One] should A single stream of per-frame TC 4 System Scheme 1: TC [ ] Yes – [N] [0] Multiple streams of per-frame TC. A should smaller array index shall have a high [n] no precedence than a higher array index. 5 ANC in ST 436 Should Should this be higher in rank? (No – TB) 6 TLSP Metadata No Should Series of Timecodecomponents 7 LLSP Metadata No should Series of Timecodecomponents - VITC in ST 436 Yes No Unclassified – do not use for MXF Timecode - MPEG video GOP / GOV Almost Should Unclassified – do not use for MXF Timecode - MPEG video – ST 382 user Yes Should Unclassified – do not use for MXF data Timecode - MPEG video – private user Probably No Unclassified – do not use for MXF data Timecode - AES Audio Yes No Unclassified – do not use for MXF Timecode - Wav audio chunks No No Unclassified – do not use for MXF Timecode - DV essence Yes No Unclassified – do not use for MXF Timecode - VBI In-vision no Unclassified – do not use for MXF Timecode Table 1 Precedance table for Timecode in MXF

Per-Frame: Indicates whether the Timecode Location would store a single value, multiple values per frame. Whether the Timecode Location stores a metadata representation of the Timecode or whether it is neither of those options. Clean? This column indicates that when an Application requires consistent Timecode within a file that the Timecode values at a particular Timecode Location should be modified to agree with the Lead Timecode value for that location. This would have an application axis and would not use normative language. It would use the normative language from ST 436.

A.1 Areas where Recommendations could be created: In the table above, Timecode Locations would be ranked according to their priority in MXF. Recommendations for an application that is able to handle multiple Timecode values would: • Recommend that an application display multiple Timecode values order those values in the same order as in Table 1 • Recommend the use of the Location Name in Table 1 • Recommend the behavior of a Timecode cleaning application that would update Timecode values according to an agreed version of a clean column such as the example in Table 1 The goal would be to help end users have a consistent experience with Timecode in MXF between different manufacturer’s products.

Page 13 of 20 pages

SMPTE ER-1:2017

Annex B Full Glossary The full glossary contains entries copied from other specifications along with examples Timecode value A value that is decoded, read, calculated or evaluated to a legal SMPTE ST 12-1 Timecode codeword. Example 1 A binary number from ST 405 is a Timecode value that can be converted to an ST 12-1 codeword. Example 2 The canonical Timecode value of an MXF Track’s Position property is found by converting the Position to an ST 12-1 codeword by linear interpolation using the Timecode Component’s Start Position, Start Timecode, counting mode etc. Timecode stream A set of Timecode values that are stored or calculated such that more than one related Timecode Value exists in a file Timecode location The stored location where Timecode values are found for a given stream e.g. SMPTE ST 331 Authoritative Timecode A term used in the AS-11 group of specifications to define the definitive Timecode values that shall be used to make references into an MXF file. This is the MXF Material Package Timecode Component Consistent Timecode A file with multiple Timecode streams where every stream labelled with “shall” in the “clean” column of Table 1 in this document contains the same Timecode value for every frame. Continuous Timecode A Timecode stream where a Timecode value exists for every frame and all Timecode values shall follow ST 12-1 counting rules Discontinuous Timecode A Timecode stream that is not continuous IRIG Inter Range Instrumentation Group. A US Military standard for telemetry and Timing from the Range Commanders Council. http://www.irig.org/ Sparse Timecode stream A Timecode stream where values might be missing (e.g. MPEG GOP). A sparse Timecode stream might be continuous or discontinuous. If it is continuous, it shall always be labeled as sparse. Synthetic Timecode A term used to describe a Timecode Stream that must be calculated rather than a byte stream of SMPTE ST 12-1 values that is read. The MXF Timecode Component is an example of the source of Synthetic Timecode Timecode cleaning The process of modifying a file to create consistent Timecode.

Page 14 of 20 pages

SMPTE ER-1:2017

Annex C Excerpt from AMWA AS07 on archiving AMWA’s work on AS07 is oriented towards preservation archiving and has fed into the work on AXF. Portions of that work are duplicated here with permission from AMWA as an example of type of Timecode recommendations that could be created to improve interoperability in archive applications.

C.1 AS07 #6.4 Timecode

C.1.1 AS07 #6.4.1 Timecode Categories (informative) AS-07 Files may contain many types of Timecode, taking advantage of the multipart architecture offered by MXF. In addition to SMPTE’s MXF standard, the specifications that follow owe much to the previous recommendations offered by EBU R122, Material Exchange Format: Timecode Implementation. These EBU recommendations have been extended and revised to support archive and preservation requirements.

The following sections employ two important terms: Master Timecode and Historical Source Timecode. AS- 07 Master Timecode is continuous and is the primary, canonical representation of references into the essence for all timecode-dependent activities; for example, descriptive metadata and playback will refer to this Timecode information. Master Timecode is sometimes referred to as Synthetic Timecode.

The term Historical Source Timecode has been taken from EBU R 122 and names various forms of legacy Timecode, e.g., Timecode(s) retained from a videotape being reformatted. AS-07 Historical Source Timecode may take various forms, including but not limited to, LTC, VITC and ATC, and it may be of various frame rates and frame counting modes. Historical Source Timecode may be discontinuous and is not used as the Master Timecode in AS-07 files.

C.1.2 AS07 #6.4.2 Timecode Sources (informative) AS-07 files will accommodate the range of Timecode types outlined in the following list. Types a through e in the series are defined in EBU R122; types f and g have been added to support AS-07. Using AS-07 terminology, Timecode types a, b, and c are examples of Historical Source Timecode, types d or e mark the start value for expressions of AS-07 Master Timecode.

a. Linear Timecode (LTC) according to SMPTE 12M-1-2008. (Example of AS-07 Historical Source Timecode) b. Vertical interval Timecode (VITC) according to SMPTE 12M-1-2008. (Example of AS-07 Historical Source Timecode) c. Ancillary Time Code (ATC, formerly known as DVITC) according to SMPTE 12M-2-2008. (Example of AS-07 Historical Source Timecode) Editors Note: Although ATC is described in the EBU R122 document as ‘formerly known as DVITC’ this is not technically correct. ATC is standardized in SMPTE ST 12-2, and DVITC is standadized in SMPTE ST 266, and is for use in standard definition video only. Although ATC and DVITC may carry the same SMPTE ST 12-1 codeword, they are orthogonal methods. d. Preset Timecode (Example of AS-07 Master Timecode) e. Timecode from the application controlling the MXF encoder (e.g. real-time recording device or software encoder). Examples of interfaces for such Timecode are the Sony 9 pin protocol, VDCP or other appropriate application programmable interfaces (API). (Example of AS-07 Master Timecode) f. One or more of the Timecode channels may be clock time (aka “TimeOfDay”); this will most likely include discontinuities (for example, if recording was intentionally paused); and it may include SMPTE ST 309 Date and Timezone information. (Example of AS-07 Historical Source Timecode) g. Other potential Timecode types, including Edgecode, Camera Metadata, IRIG, ST 309, even “Next Generation Timecode”. Note that times in some cases may be obtained from the User Bits of the incoming Timecode. (Example of AS-07 Historical Source Timecode) Labeling Timecode 6.4.3 in Header Metadata Next gen, phase etc. not present in all streams Page 15 of 20 pages

SMPTE ER-1:2017

C.1.2.1 AS07 #6.4.3.1 Labeling Timecode in Header Metadata (informative) Although optional in a strict sense, the use of descriptors and sub-descriptors to characterize timecodes is encouraged for AS-07 users. One important application for AS-07 is as a target format for the reformatting of historical videotapes. Such videotapes often carry multiple Timecodes of the types described in the preceding section. These Timecodes often have long-term value: they may pertain to pre-existing log sheets or edit decision lists, represent time-of-day information needed for forensic analysis, or provide data that can be used by a researcher to reconstruct the history of a given stretch of video footage. Proper labeling of Historical Source Timecode serves all of these purposes.

In its handling of Timecode, AS-07 uses elements from two SMPTE specifications: SMPTE ST 405 specifies a method to construct Timecode arrays in essence container System Items, while SMPTE ST 385 provides a scheme for descriptors and sub-descriptors. These descriptors and sub-descriptors are associated with Timecode Tracks. In the case of Master and Historical Source Timecodes in essence container System Items, the tracks and descriptors are to be carried in the File Package (Top Level Source Package). When Timecode Tracks are carried in a Lower Level Source Package, the descriptors will be carried in that location as well.

C.1.2.2 AS07 #6.4.3.2 Labeling Timecode in Header Metadata (requirements) AS-07 encoders should create Timecode Tracks that have Track Numbers specified. The Track Number for Master Timecode shall be set to 1. Each of the Historical Source Timecode Tracks shall be assigned a number in a sequence of ascending integers beginning with 2.

Essence Descriptors of Source Packages should include a DateTimeDescriptor for each Timecode and should comply with the following requirements: 1. When present, a DateTimeDescriptor shall indicate the location in the Essence Container in which the Timecode is embedded, or shall indicate the indicate Track Number in which the Timecode is encoded, or both, as appropriate. 2. When present, a DateTimeDescriptor shall include a SMPTE UL indicating the time code type, as registered in RP 224 (revisions to RP 224 forthcoming). 3. When present, a DateTimeDescriptor should include a subdescriptor that labels the original signal from which the Historical Timecode was derived.

C.1.2.2.1 AS07 #6.4.3.2.1 Timecode Header Label Descriptor The DateTimeDescriptor for AS-07 is derived from the one specified by SMPTE ST 385 table 3. The list of properties of the DateTimeDescriptor, which is derived from SMPTE ST 385 table 3 and updated to match SMPTE ST 377-1:2011 is in appendix C.1.

Note that a single DateTimeDescriptor can simultaneously describe both a Timecode Track and an Essence Timecode. The LinkedTrackID property specifies the Track that is described; the DateTimeEmbedded flag indicates if the Timecode data is also embedded in the essence.

C.1.2.2.2 AS07 #6.4.3.2.2 Timecode Header Label Subdescriptor In addition, the SubDescriptors property shall strongly reference a TimecodeLabelSubDescriptor derived from the SMPTE ST 377-1 annex B.3, and described in detail in appendix C.2.

C.1.3 AS07 #6.4.4 Master Timecode

C.1.3.1 AS07 #6.4.4.1 Master Timecode (informative) AS-07 Master Timecode is required and will be uninterrupted (often called continuous) and ascending. Master Timecode is the primary, canonical representation of references into the essence for all Timecode-dependent activities.

Page 16 of 20 pages

SMPTE ER-1:2017

The best practice for preservation and long-term archival management is to set the frame rate and the frame count mode to match the actual frame repetition rate and count mode of the picture essence and this is required by this specification. For example, if the frame rate of a given source item is an integer (i.e., nonfractional) 30 fps, then the typical choice of non-drop Master Timecode would increment 30 times per second. In an example with a fractional frame rate, an essence with a sample rate of 30000/1001 (customarily stated as 29.97 fps) would typically employ a drop-frame Master Timecode that increments at 30000/1001 times per second. Many archives prefer to produce files for long-term archiving that carry non-drop Master Timecode and integer frame rates.

C.1.3.2 AS07 #6.4.4.2 Master Timecode in Header Metadata File Package Encoders shall place uninterrupted, ascending AS-07 Master Timecode in the Header Metadata as a Timecode Track and shall identify it by setting the track number property to 1. There shall be only one Timecode track with a track number property value of 1 in a package. The Master Timecode frame rate and frame count mode shall be the same as the frame rate and count mode of the essence in the file.

When recording, the AS-07 Master Timecode time addresses for each essence container shall be represented in a TimecodeSegment with Start Time and Length on a Timecode track in the File Package (Top Level Source Package) that describes this essence container.

The start Timecode of the Master Timecode may be set to a fixed number, or to match the Start time (i.e., the initial time address) of a historical source Timecode. The preference may be specified in a shim. Various frame rates and drop-frame and non-drop frame counting modes are permitted for the Master Timecode. This range of options may be constrained in a shim.

C.1.3.3 AS07 #6.4.4.3 Master Timecode in Header Metadata Material Package MXF encoders should generate a Timecode track for each material package. For AS-07 files, the default start Timecode time address of the material package Timecode track should be equal to the Timecode time address of the source package position that is referenced by the start of the first material package source clip.

Timecode frame rate and mode (drop-frame or non-drop frame) are required properties of a TimecodeSegment.

Various frame rates and drop-frame and non-drop frame counting modes are permitted for the Master Timecode. This range of options may be constrained in a shim.

C.1.3.4 AS07 #6.4.4.4 Master Timecode in Essence Containers Encoders shall place AS-07 Master Timecode in the Essence Container as a System Item in the container's Content Packages. It shall be encoded as the first element of the SMPTE ST 405 TimecodeArray of the SMPTE ST 394 System Element. Master Timecode in Essence Containers shall be stored with each frame and not as a start and duration, and shall be frame accurate.

Encoders should encode a DateTimeDescriptor (see above). Note that a single DateTimeDescriptor can simultaneously describe both a Timecode Track and an Essence Timecode.

Page 17 of 20 pages

SMPTE ER-1:2017

C.1.4 AS07 #6.4.5 Historical Source Timecode

C.1.4.1 AS07 #6.4.5.1 Historical Source Timecode (informative) AS-07 Historical Source Timecode is legacy Timecode, e.g., from a videotape being reformatted, and it may take various forms, including but not limited to, LTC, VITC and ATC, and it may be of various frame rates and frame counting modes. Historical Source Timecode may be discontinuous and shall not be used as the Master Timecode.

The legacy Timecodes in videotapes and other sources may themselves be layered in ways that an archive wishes to track, e.g., a videotape may carry LTC and may additionally carry an earlier generation of Timecode recorded, say, as audio track 3. Implementers who wish to document such historical information will employ descriptors and subdescriptors as needed and/or provide documentation in the AS-07 Manifest (section 6.7.1).

C.1.4.2 AS07 #6.4.5.2 Range of Types of Historical Source Timecode When present in source material, AS-07 Baseband Shim encoders shall encode the following types of Historical Source Timecode: a. Linear Timecode (LTC) according to SMPTE 12M-1-2008. b. Vertical interval Timecode (VITC) according to SMPTE 12M-1-2008. c. Ancillary Time Code (ATC, formerly known as DVITC) according to SMPTE 12M-2-2008. d. Other potential Timecode types, including Edgecode, Camera Metadata, IRIG, ST 309, even “Next Generation Timecode”. Note that times in some cases may be obtained from the User Bits of the incoming Timecode.

C.1.4.3 AS07 #6.4.5.3 Historical Source Timecode in Essence Container System Items When supplied to the encoder, Historical Source Timecode shall be encoded in the second and subsequent elements of the SMPTE ST 405 TimecodeArray of the SMPTE ST 394 System Element. (Section 6.4.4.2 reserves the first element for Master Timecode.) Historical Source Timecode in Essence Containers shall be stored with each frame and not as a start and duration. Encoders shall accommodate discontinuities in incoming Historical Source Timecode in Essence Containers and shall record matching discontinuities within the SMPTE ST 405 TimecodeArray. Encoders should encode a DateTimeDescriptor as specified in 6.4.3 above (Labeling Timecode in Header Metadata).

C.1.4.4 AS07 #6.4.5.4 Historical Source Timecode Tracks in Header Metadata AS-07 encoders should generate a Timecode track for each instance of Historical Source Timecode, numbered as indicated in section 6.4.5.3.

C.1.4.5 AS07 #6.4.5.5 Historical Source Timecodes in Essence Container Data Items Additional Historical Source Timecodes may also be represented as SMPTE ST 12-2 data in ANC packages in one or more Data Items in the Essence Container. Encoders should encode a DateTimeDescriptor as specified in 6.4.3 above (Labeling Timecode in Header Metadata).

C.1.4.6 AS07 #6.4.5.6 Historical Source Timecode in Lower Level Source Packages

C.1.4.6.1 AS07 #6.4.5.6.1 Historical Source Timecode in Lower Level Source Packages (informative) EBU R 122 (Material Exchange Format Timecode Implementation) foresaw the need to identify and characterize MXF files that contain multiple expressions of Timecode. In section 3 Recommendations) of this EBU standard, recommendation 2.e specifies an approach that places Historical Source Timecode(s) in Timecode tracks of the Lower Level Source Package (LLSP). This approach will also have value for AS-07 files. As specified below, AS 07 shims may mandate, forbid, encourage, or permit this practice. In

Page 18 of 20 pages

SMPTE ER-1:2017

the initial AS-07 Baseband Shim (appendix J), the use of LLSP for Historical Source Timecode tracks is encouraged.

C.1.4.6.2 AS07 #6.4.5.6.2 Historical Source Timecode in Lower Level Source Packages, Requirement Options for Shims (informative) Each AS-07 shim will specify its requirements for the carriage of AS-07 Historical Source Timecode tracks in Lower Level Source Packages (LLSP) as follows: • LLSP Historical Source Timecode tracks are mandated: The Timecodes encoded as the second and subsequent elements of the SMPTE ST 405 TimecodeArray (section 6.4.5.3) shall have a matching LLSP Timecode track. • LLSP Historical Source Timecode tracks are forbidden: The Timecodes encoded as the second and subsequent elements of the SMPTE ST 405 TimecodeArray (section 6.4.5.3) shall never have a matching LLSP Timecode track. • LLSP Historical Source Timecode tracks are encouraged: The Timecodes encoded as the second and subsequent elements of the SMPTE ST 405 TimecodeArray (section 6.4.5.3) should have a matching LLSP track, and there may be additional LLSP Timecode tracks for which there is no SMPTE ST 405 TimecodeArray element. • LLSP Historical Source Timecode tracks are permitted: The Timecodes encoded as the second and subsequent elements of the SMPTE ST 405 TimecodeArray (section 6.4.5.3), and Timecodes for which there is no SMPTE ST 405 TimecodeArray element, may have matching LLSP tracks. Thus there is no required correspondence between the Timecodes encoded as the second and subsequent elements of the SMPTE ST 405 TimecodeArray (section 6.4.5.3) and LLSP Timecode tracks.

C.1.4.6.3 AS07 #6.4.5.6.3 Historical Source Timecode in Lower Level Source Packages, Encoder Requirements When Historical Source Timecode tracks are to be placed in Lower Level Source Packages, AS-07 encoders shall accommodate discontinuities in incoming Historical Source Timecode. Discontinuous Timecode shall be represented as a Sequence of Timecode Components (SMPTE ST 377-1 annex B.16). Continuous Timecode shall be represented as a Timecode Component with Start Time and Length (SMPTE ST 377-1 annex B.17). Segments with no Timecode or undecodable Timecode shall be represented as Filler (SMPTE ST 377-1 annex B.10).

Encoders should encode a DateTimeDescriptor as specified in 6.4.3 above (Labeling Timecode in Header Metadata).

C.1.5 AS07 #6.4.7 Regard to Timecode

C.1.5.1 AS07 #6.4.7.1 Decoder Behavior with Regard to Master Timecode Decoders shall use the AS-07 Master Timecode as the primary, canonical Timecode instance for playback and other references.

In order to assist users in identifying problems in file encoding or decoding, AS-07 decoders may track Master Timecode in both the essence container (section 6.4.4.4) and in Master Timecode Tracks (sections 6.4.4.2 and 6.4.4.3), and provide an indication of any discrepancies.

C.1.5.2 AS07 #6.4.7.2 Precedence of Timecode Decoders should decode both the Master Timecode in the Header Metadata Material Package and the Master Timecode in the Essence Container, and when decoding a frame of essence, decoders should compare the two Timecodes that are implied for that frame. In the event of a disagreement between the two implied Timecodes, decoders should indicate an error condition and should indicate which Timecode is chosen to take precedence.

C.1.5.3 AS07 #6.4.7.3 Decoder Behavior with Regard to Historical Source Timecode When decoding AS-07 files that carry Historical Source Timecode(s) in the SMPTE 12M-1-2008 format, carried in the SMPTE ST 405 TimecodeArray of the SMPTE ST 394 System Element; Lower Level

Page 19 of 20 pages

SMPTE ER-1:2017

Source Packages; and/or Essence Container Data Items, decoders shall provide the ability to select and display these Timecodes before and during playback, and shall output those instance(s) of Timecode data, in the format as encoded, for applications external to the decoder. Note that SMPTE ST 12 Timecodes (LTC, VITC, and ATC) are listed in section 6.4.5.2.

When decoding AS-07 files that carry other (non-SMPTE 12M-1) Historical Source Timecode(s), decoders may provide the ability to select and display these Timecodes before and during playback, and shall output those instance(s) of Timecode data, in the format as encoded, to applications external to the decoder.

Page 20 of 20 pages