The Society of Motion Picture and Television Engineers is an accredited International Standards Development Organisation. It provides a number of services to its members including local branch meetings, technical conferences and webinars. The IABM sends a representative to SMPTE Standards Meetings.

The Standards Monitoring Group has been formed to solicit IABM member feedback on Standards that are in development or revision - reminder: draft documents linked on this page are for review and must not be distributed ouside of the SMG, as required by the participation agreement.

The SMG is monitoring and contributing to the development of the following SMPTE projects; (details in each section lower down this page):

Better Pixels Projects

High Dynamic Range and Wide Color Gamut
Higher Frame Rates

This section deals with work to enhance the viewing experience by improving the pixels; not just giving us more of them. These improvements have an immediate impact on the viewer, i.e. High Dynamic Range, Wide Color Gamut, improved Electro-Optical Transfer Function (EOTF), Higher Frame Rates.

Note that EOTF is intimately related to the specification of HDR systems because optimised transfer function allows the best use of code values to provide the higher dynamic range.


In the television world, it is easy to think that HDR and WCG are new technologies. However, a mature SMPTE project, ACES, was designed from the ground up to handle HDR and WCG without being tied to one representation. ACES standards available.
A new project - overview here - extends the use of ACES as an application format in the Interoperable Mastering Format (IMF).

Also, a project is underway to create a profile of the DPX file format standard (ST 268) to carry HDR / WCG.

Nonetheless, the current main focus is on technologies that will deliver HDR and WCG over television and broadband; projects below.

Existing SMPTE HDR/WCG Standards (and revisions underway)

SMPTE recently (2014-2015) published a set of three standards that implement one approach:

  • High Dynamic Range Electro-Optical Transfer Function of Mastering Reference Displays – ST 2084. This EOTF is often called “PQ” – perceptual quantization. 
  • Y′D′ZD′X Color-Difference Computations for High Dynamic Range X′Y′Z′ Signals – ST 2085
  • Mastering Display Color Volume Metadata Supporting High Luminance and Wide Color Gamut Images - ST 2086 - Note that this is static metadata, not to be confused with dynamic metadata project below.

A project to revise ST 2084 was proposed in the summer of 2016, but it has not progressed to approval, even though there seems to be some work being done:

Problem to be solved: The digital representation in ST 2084 is not normative. As such there is no standard for how to encode the values. This has resulted in inconsistent encodings outside SMPTE; ITU-R has specified an unexpected full-range encoding. The SDI encoding is redundant as this is already covered in RP 2077.

Project scope: Update Annex A to provide normative encodings. Remove redundant encodings.

A project to revise ST 2086 is being considered to resolve an ambiguity over the meaning of value "0"; is it “Unknown” or “0 cd/m” ?

Abstracts for the published versions and information on purchase can be found here (2084)  (2085)  (2086). 

High Dynamic Range Image Ecosystem Study Group

The SG completed its report in the fall 2015, available here (no charge).

The project scope of this group was:
To identify the specific parameters and respective ranges that constitute “High Dynamic Range” (HDR). On that basis, to form a complete ecosystem for the creation, delivery and playback of HDR content across both linear and home entertainment distribution platforms. Deliverable is a report on impacted existing standards, standards gaps that should be addressed, and recommendation on methodology and priority.
The Study Group report investigates the impact that HDR/WCG systems will have on both real-time and non-real-time workflows.

Dynamic Metadata for Color Volume Transformation

The cost of producing content for a small number of HDR/WCG displays may be prohibitive, unless a high-quality transformation into mass-market content suitable for BT.709 displays is available.
It is likely that a high-quality result can only be achieved by adjusting the transform according to the scene content, using dynamic metadata.
This group has completed the standardization of a set of 4* application formats (see document structure below), because the submissions from proponents could not be unified into one system. This is an unfortunate situation because the work of creating the metadata would have to be done for as many of the systems as the content producer wishes to support; even producing it for one system is seen as too much of an overhead by some broadcasters. For instance, the BBC and NHK have developed a system - called Hybrid Log-Gamma (HLG) - that requires no metadata because it is scene-referred. Both Perceptual Quantization (PQ) and HLG are specified in Recommendation ITU-R BT.2100 : Image parameter values for high dynamic range television for use in production and international programme exchange.

* Since the four documents were completed, Technicolor and Philips have joined forces; so probably three variants.

Document suite:

  • ST 2094-1 Core Components
  • ST 2094-2 KLV Encoding And MXF Mapping
  • ST 2094-10 Application #1 (Dolby submission)
  • ST 2094-20 Application #2 (Philips submission)
  • ST 2094-30 Application #3 (Technicolor submission)
  • ST 2094-40 Application #4 (Samsung submission)

Status of project at 6 Jan. 2017: All documents except ST 2094-2 are now published - abstracts and purchase info here. ST 2094 Part 2 was elevatd to Draft Publication status at the December 2016 meeting round. The document will go to ST Audit before publication.

Version of ST 2094-2 raised to DP

The group is preparing information on how details of SEI messages for each of the four application formats can be found (it currently exists for 3 of the 4).
Patent statements for Parts 1, 10, 30 have been received.

The group is anxious to publicise this work and help the user community to understand how it can be used. There has been considerable interest in other industry bodies.

New Project: HDR and WCG Signaling on Streaming Interfaces

With implementations of high dynamic range (HDR), wide color gamuts (WCG) and new transfer functions (EOTF) developed in SMPTE and elsewhere, there is a need to create a signaling representation to identify the content so that it is properly processed in a production facility as well as correctly displayed in professional reference displays using SMPTE interface standards.​

Status of project at 6 Jan. 2017: Several proposals were reviewed including putting all information in a separate ANC package, defining a completely new Payload ID, and a combination of Payload ID changes with an ANC package.

The Drafting Group has achieved consensus on a plan to put static signaling parameters in the Payload ID (ST 352), and all other HDR-related metadata in a new separate ANC packet. The bit assignments for the Payload ID parameters are in alignment with the ITU-R proposed HDR / WCG PID assignment for BT.2077-1 (requirement identified in ITU-R document "HDR signalling requirements for programme production and international exchange arising from Recommendation ITU-R BT.2100"). It was very difficult finding an acceptable compromise on the use of the remaining few reserved bits of the Payload ID.

Project statements have been prepared for revision of the applicable SDI interface standards in both the 32NF70 UHD-SDI WG and the 32NF40 SDI mapping WG.

A presentation from the December meeting gave a clear description of all the changes planned for the family of 1.5Gb/s and 3Gb/s interface standards.

Back to top

Higher Frame Rates

There has been no new SMPTE work in the last quarter. However, members' attention is drawn to a recent ITU-R document that has added to ITU-R document BT.2100 "Image parameter values for high dynamic range television for use in production and international programme exchange" frame rates of 120, 120/1.001,100 to 1080p images; HFR no longer exclusively a UHD feature.

Work to add higher frame rates to image format documents has been completed for UHDTV formats - provision for 100 and 120 fps (nominal) has already been added to SMPTE’s ST 2036-1 UHDTV standard. However, some content providers are considering using higher frame rates with HDTV standards, so amendment work would have to be done on the two image format documents.

Associated transport documents have also been introduced to cope with the extra bandwidth demands of High frame Rate (see SDI  6, 12, 24 Gb/s family projects in the SDI Interfaces section of this page).

A project to extend SMPTE ST 12 time code to cover higher frame rates has published its standard (see ST 12-3 under the Time Labeling section of this page).

Higher frame rates are essentially future-proofed in Studio Video over IP standards because specification of the frame rate is just a numeric parameter (see IP projects in section below).

Back to top

The move to Internet Protocol For Professional Media Networks

Professional Media Over IP Networks
Media Flow Control
Network-based Media Synchronization
Media Device Control over IP

Professional Media over IP Networks

This project is tasked with producing a suite of standards for handling media streams, based on VSF TR-03 and TR-04, with some additional extensions. The following suite of documents with the title “Professional Media over IP Networks” is in development:

  • ST 2110 Part 10: System Timing and Definitions
  • ST 2110 Part 20: Uncompressed Active Video
  • ST 2110 Part 21: Timing Model for Uncompressed Active Video​
  • ST 2110 Part 30: PCM Digital Audio
  • ST 2110 Part 31: AES3 Transparent Transport​
  • ST 2110 Part 40: Ancillary Data
  • ST 2110 Part 50: SDI as an Essence

A need for the following additional Part has been identified:

  • ST 2110 Part 2x: Compressed Active Video

The gaps in Part numbering are to allow additional Parts to be grouped logically - e.g. all video documents in the "20" series.

Status of project at 27 Jan 2017:

Time for a small celebration!
At the 26 Jan meeting, it was agreed that the drafts of ST 2110 Part 10, Part 20 and Part 30 could go forward to ballots to raise them to Final Committee Draft status. Latest (28 Jan): the three documents are at ballot, closing 3 Mar 2017.

The Drafting Group Chair will submit the documents to the parent Technology Committee to initiate the ballot.

The documents are available here. If SMG members have any comments, please send them to and we can consider submitting them as ballot comments.

The group has held weekly telecons over the last 3-4 months which have mostly worked on resolving a large number of comments on the three documents when they were submitted for pre-ballot review. The hope is that, with such a thorough review process, there should not be too many ballot comments that are difficult to resolve (though that can never be guaranteed!).

One "sticking point" was debate over a Timing Model that was included in Part 20. The group decided to remove the model and create a new Part 21 for it. This allows the three parts to go to ballot while the timimg model is further discussed. It is hoped that some useful data for the model will be gained at a JT-NM interop that is being held the week of 6 Feb (more info). This zip file contains the latest draft of Part 21 as well as the latest drafts of Parts 31, 40, 50.

There has been some debate about the role of Part 31. It was drafted to provide a means for transporting the AES3 user bit, validity bit, parity bit, control bit in case these have been used. But there is strong opposition to it being seen as anything more than support for a legacy standard.

Comments and queries from SMG members on any aspect of this project are welcome:

Study Group on Flow Control in Professional Media Networks (PMNs)

This study group was formed to compile a report on methods for using IP routers to switch professional media. Three main techniques are available and they have different characteristics - there is no one best technique, as tradeoffs need to be taken into account. 

Status of project at 8 Jan. 2017:
This SG has held five meetings in the last quarter. The report is about 80% complete and needs the insertion of User Survey response summaries. The work has suffered a small interruption whilst a new Chair was found for the SG.
Consequently, the last draft of the report dates back to Oct. 2016, but there have been several contributions since that will be incorporated.

There is some proposed text for a recommendation for SDN control:

The SG determined that a reliable connection management using IGMP is best achieved thru the use of an SDN controller. While it is possible to manage flows without the use of SDN, i.e. by using SNMP or proprietary protocols, in simple networks (one switch) it is not possible to use non-SDN technologies in larger scale networks without a careful network design and rigorous bandwidth measurement.

This statement was challenged by one member who has implemented flow control without SDN. It has also shown up the need to carefully define what is meant by SDN.

Back to top

Projects defining a Network-based Synchronization System

In 2015, SMPTE published an IP network-based synchronization solution using Precision Time Protocol (PTP, IEEE1588v2) constrained by a SMPTE PTP profile. This approach supports ALL image formats rather than having to route a separate "black and burst" for every video standard in the facility and it uses the same IP network that is used for essence streaming and other production functions.

The documents are:

  • ST 2059-1: The SMPTE Epoch and Generation and Alignment of Interface Signals; defines the behavior of the slaves, allowing them to create any synchronized video, audio or time code signal.
  • ST 2059-2: Precision Time Protocol SMPTE Profile for Time and Frequency Synchronization in a Professional Broadcast Environment;  defines the behavior of the master.

Abstracts and information on purchase can be found here.

Current projects supporting the use of this system comprise interop testing and engineering guidelines, detailed below.

ST 2059 -1 and -2 Interoperability Testing Drafting Group

This group was formed shortly after the March 2015 meeting round. The aim is to confirm that the provisions of the standards are unambiguous and that the technology does, indeed, yield the intended results. The Interop DG is open, but the Testing AHG and attendance at the interop meetings ("plugfests") is subject to signing a non-disclosure agreement. 

The IABM does not attend the plugfests because they are aimed at implementers; however, we will include here notes of the group's plans and proposed plugfests, together with their summary reports. In order to check interoperability of a large number of functions, the tests will be split over a number of plugfests.


Plugfest 1: Held in November 2015, hosted by FOX NE&O in Houston, TX. The DG Chair provided this summary: Summary Presentation from first 2059 Plugfest. The main conclusion was that ST2059-1/2 fundamentally work as intended; the standards need only minor clarifications.  It was confirmed that goals for Lock Time and Accuracy are achievable. The tests also highlighted the need for the EGs that are in development (see projects below).

Plugfest 2: Held in June 2016, again at FOX NE&O in Houston, Texas. This testing round included some tests with AES67 equipment. A report of this second PTP interop has been completed, see below.

JT-NM Plugfest *: Held in August 2016 with an expanded scope of testing IP media transport and IP discovery and registration (AMWA IS-04), as well as PTP. The success of all these interops led to public demonstrations:

  • All three technologies tested at the JT-NM interop were demonstarted at the "IBC Interop Zone", co-sponsored by IABM.
  • The PTP interop was demonstrated at the SMPTE annual conference, October 2016 in Hollywood.

Both the AES67 group and this SMPTE group have reviewed a document analysing what is needed for the AES and SMPTE PTP profiles to coexist on one network. The AES version of this report has been published: AES67-SMPTE 2059 interop report

JT-NM is the “Joint Task Force on Networked Media” and the members are EBU, SMPTE, VSF and more recently, AMWA. Some very recent news is that AES is expected to also join as a member. JT-NM website.

Status of project at 8 January 2017: Release of the June PTP interop report was discussed at the December 2016 Working Group meeting. It was decided the report needs context for people unfamiliar with the work to understand it properly. It is proposed that the DG Chair will deliver the report in a SMPTE webinar and that a recording of the webinar should be made public.

The group is developing a high-level plan for the next interop sessions that are planned for the week of 20 March 2017, again at Fox NE&O, in Houston, Texas. The group will also be contributing to a JT-NM interop on 3 April 2017 in preparation for a public interop demonstration at NAB.

Engineering Guidelines on the Network-based Synchronization system

The system defined by ST 2059-1 and ST 2059-2 is a substantial departure from traditional media synchronization techniques and it has been identified that some tutorial material is needed.
Therefore, Engineering Guidelines are in development (one published), though after initial enthusiam, progress has generally slowed. The topics are:

Introduction to the New Synchronization System - EG 2059-10
This EG explains the principles of operation of the PTP system for media synchronization applications.

Status at 8 January 2017: This document was published Q3 2016. It is an excellent introduction to PTP technology.
Abstract and information on purchase here

Management of Time Discontinuities - EG 2059-11

It covers the following discontinuity topics:

  • Leap Years
  • Leap Seconds
  • Standard Time <> Daylight Saving Time Shifts
  • Daily Jam

Status at 9 January 2017: A WD was submitted 20 April 2015; no progress in the last few quarters, unfortunately.

Systemization Considerations for using SMPTE ST 2059 - EG 2059-12
This document includes sections on ST 2059 reference distribution systems, Grandmaster considerations, Slave device considerations.

Status at 9 January 2017: This document had previously been called “Facility Migration Guide”. A WD was submitted 23 April 2015; no progress in the last few quarters unfortunately.

Best Practices for Large Scale SMPTE ST 2059-2 PTP implementations - EG 2059-14
The document is planned to cover a large number of implementation topics.

Status at 9 January 2017: The most recent WD was submitted 26 Nov. 2014, no progress since unfortunately.

Local Time Specification for ST 2059 – RP 2059-20
The decision to make this a Recommended Practice was taken because it is anticipated that normative provisions will be incorporated. There has been no recent progress on this document.

Status at 9 January 2017: There has been no progress on this document and it has not been mentioned at meetings for a while. It seems that there is considerable overlap with the EG 2059-11 draft. The last WD was submitted 11 November 2014.

zip of the latest versions of the 4 2059 EG/RP drafts above

Back to top

Media Device Control over IP

This topic is standardized in the ST 2071 document suite.

A lot of work has gone into the development of these documents. MDCoIP, frequently shortened to MDC now, leverages web services technologies and permits manufacturers to specify their own device capabilities by means of a “Capability Interface Repository”.

We all know that there have been many attempts to define open control systems in the past and that they have failed to attract a critical mass of implementations. EBU-SMPTE "ES-bus" and then "ES-net" are good examples. Also, there are competing proposals; the AES Open Control Architecture (covered here) and the IEC 62379 suite of documents "Common Control Interface for Networked Digital Audio and Video Products".

However, this project has attempted to avoid the pitfalls of previous designs and it does fit in with popular networking concepts of today. My only reservation about the work is that it has been developed by a very small core of people and may not have been given enough exposure to drive its adoption and to ensure its provisions are good by getting enough peer review. This view is reinforced by the large number of revisions / additions during the project's development.

The suite comprises:

  • ST 2071 Part 1: Media Device Control Framework (MDCF). 2015 Revision in process to add support for FIMS v1.2
  • ST 2071 Part 2: Wire Level Protocol (MDCP). 2015 Revision under development to add support for FIMS v1.2
  • ST 2071 Part 3: Discovery (MDCD) (describes how existing Service / Device Discovery Protocols work with the MDCF, including a “zero configuration” mode) NOTE: AMWA is developing a different Discovery and Registration technology - IS04.
  • ST 2071 Part 4: Core Capability Interfaces (includes provisions for vendors to publish details of their products’ capabilities publicly accessible)
    This Part provides a common infrastructure and API with which vendors and SDOs can register Capability Interface Definitions, documentation, unit tests, and test cases. Developers, Customers, and Interface Consumers can query the definitions, documentation, and tests for the Capability Interfaces implemented by Devices and Services used within their systems.
  • ST 2071 Part 5: Media Device Control - RESTful Protocol+HATEOAS – New intended project, proposal being deveoloped. HATEOAS = Hypermedia as the Engine of Application State. This is an alternative protocol to Part 2, which was based on SOAP. This work will harmonize MDCoIP closer with FIMS/AMWA application documents.

Status of projects at 9 January 2017: Parts 1-4 have recently been through the SMPTE ballot process and have the status:
Part 1 and Part 2 were published Q4 2016. Abstracts and information on purchase here.
Part 3 revision and Part 4 were elevated to Draft Publication status by vote at the December meeting round. zip of ST 2071 Parts 3 and 4 raised to DP
This presentation from the December 2016 meeting round helps to explain the purpose of Parts 3 and 4.

There has been no report or progress on the proposed Part 5 since the last telecon back in June 2016.
Reminder of the issue: Although there are many RESTful implementations, there is a problem that there is no definition of the RESTful protocol by an SDO that could be used as a normative reference. There are some documents by various organizations (swagger, raml, API blueprints, yaml) but these are not definitive and differ between one another.

At the June telecon, the Chair put forward a way to overcome the problem. Part 5 could simply be a definition of how the Capability Interface (Part 4) is used to contain RESTful implementations. Implementers would state which "flavor" of RESTful protocol they use, allowing the market to eventually choose which one is most popular. 

Back to top

SDI Interfaces

6Gb/s, 12Gb/s, 24Gb/s SDI
Ruggedized Optical Fiber SDI Connector
Coarse Wavelength Division Multiplex for SDI

In addition, it is worth noting that 10Gb/s SDI transports for UHDTV - ST 2036-3 revision and ST 2036-4 - were published late 2015.  Scope and details about purchasing available here.


6Gb/s, 12Gb/s and 24Gb/s SDI interfaces

This Working Group is well-advanced with a large suite of documents specifying the Electrical Interface, Optical Interface, Single Link Mapping, Dual Link Mapping and Quad Link Mapping for each of the 3 bitrates (where applicable). During the lifetime of the projects, it was decided to move the specification of the Optical Interfaces to a revision of an existing document, ST 297 - Optical SDI Networks; now complete and published. Scope and details about purchasing ST 297 available here.

The ST 2081 suite of documents deals with 6Gb/s interfaces, the ST 2082 suite deals with 12Gb/s interfaces (the 24Gb/s work has not yet started - though the equivalent ITU-R document, BT.2077-1, does include 24Gb/s).

ST 2081-1: 6Gb/s Signal/Data Serial Interface – Electrical (published, jitter amendment now also published)
ST 2081-10: 2160-line and 1080-line Source Image and Ancillary Data Mapping for Single-link 6G-SDI (published)
ST 2081-11: 2160-line and 1080-line Source Image and Ancillary Data Mapping for Dual-link 6G-SDI (published)
ST 2081-12: 4320-line and 2160-line Source Image and Ancillary Data Mapping for Quad-link 6G-SDI (published)
ST 2081-30: Transport of Multiple 3Gb/s or 1.5Gb/s signals on a 6G-SDI link

ST 2082-1: 12Gb/s Signal/Data Serial Interface – Electrical (published, jitter amendment now also published)
ST 2082-10: 2160-line and 1080-line Source Image and Ancillary Data Mapping for Single-link 12G-SDI (published)
ST 2082-11: 2160-line and 1080-line Source Image and Ancillary Data Mapping for Dual-link 12G-SDI (published)
ST 2082-12: 4320-line and 2160-line Source Image and Ancillary Data Mapping for Quad-link 12G-SDI (published)
ST 2082-30 : Transport of Multiple 6Gb/s, 3Gb/s or 1.5Gb/s signals on a 12G-SDI link

Abstracts for the published documents and information on purchase: 2081 here, 2082 here

Status of remaining projects at 9 January 2017: Documents ST 2081-30, ST 2082-30 that standardize Multi-stream mapping passed FCD ballot on 5 Dec. 2016 with 7 and 12 comments to resolve respectively. Draft comment resolution documents have been prepared; awaiting commenters' responses.

The one-year-review revisions of ST 2081-10 and ST 2082-10 have been posted for pre-FCD-ballot review.

Remaining work will be stereoscopic image mappings and 24Gb/s interfaces.

Back to top

Broadcast and Video Serial Digital Fiber Transmission Systems – Ruggedized Connector Interfaces

This is a  submission for standardization of a new connector from Neutrik. It is based on standard LC and MPO connectors, so it can support a range of media interface applications.It is offered in single, dual and quad link variants to suit ST 425 multi-link transports. It also features high density 12 and 24 fiber variants. Color coding of parts of the connector is used to indicate the SMPTE standards supported, the fiber polish used, the number of links supported on the connector.

It was decided at the June meeting round that connectivity requirements for the ST 2036-4 interface would be removed from this draft standard and moved to a new RP. So it is expected that the standard will become ST 2091-1 and the recommended practice will be RP 2091-2.

Status of project at 13 October 2016: ST 2091 passed DP elevation ballot on 29 Nov. 2016. It will be posted for ST Audit. Work will start on the RP.

ST 2091 DP ballot draft

Back to top

Multi-Link and Multi-Channel 1.5G, 3G, 6G and 12G-SDI Using CWDM; New Document ST 297-2

This project will standardize a Coarse Wavelength Division Multiplex optical interface for multi-link SDI. This document will be ST 297-2, with ST 297 renamed to ST 297-1.It will define a mapping between the multi-link interfaces and the wavelengths used.

Status of project at 13 October 2016: ST 297-2 was elevated to DP status by a vote at the December 2016 meeting. It will be posted for ST Audit.

ST 297-2 DP elevation draft

A liaison has been prepared to ITU-R, requesting them to harmonize their BT.2077-1 Part 3 document with the wavelengths selected in this document. It was explained that the existing BT.2077-1 wavelengths have not proved popular compared to those in ST 297-2.

Back to top

Time Labeling 

Generic Time Label
Full-featured Time Label
ST 12 HFR "stopgap"

The work of this group follows from a SMPTE / EBU Task Force report in 2009. That work was started because the ubiquitous SMPTE ST 12 timecode no longer had capacity to label every frame of image formats such as 1080p60 (and the higher frame rates that have followed).​
There was a long period of debate in the Time Labeling group with disparate proposals emerging.

Two projects (ST 2103, ST 2105, below) were approved and developed into suites of documents. However, there was growing opinion that we could not publish two incompatible label documents and in an effort to resolve this, it was agreed that “Time Labels Summits” would be held to ensure that user requirements had been collected and maybe see if a single label standard meeting those requirements could be achieved. Summits were held in Hollywood, London and New York City Oct. and Nov. 2016. Meanwhile, no further ballots on either document suite will be held.

Status of Time Label Summits at 9 January 2017: A report from the summits was presented at the December 2016 meeting round. It has uncovered some new applications for the time label, but (in my opinion) it has not provided any information that will help with the design of the label or the choice between the two existing projects, as they can both satisfy the applications. Indeed, it is now expected that a third label project will be proposed! There was a strong caution at the December 2016 meetings that a time label should NOT attempt to implement applications; it should be a simple design that will SUPPORT applications.

Generic Time Label - draft ST 2103

This project has remained frozen while the summits took place.
The following suite of 5 Parts closed FCD ballot 21 Sept. 2015:

  • ST 2103-1: Generic Time Label - Data Definition
  • ST 2103-2: Generic Time Label - Transmission in Ancillary Data Space
  • ST 2103-3: Generic Time Label - Character Representation
  • RP 2103-4: Generic Time Label - Interoperation with Time and Control Code
  • RP 2103-5: Generic Time Label - Time and Date Calculations

Status of project at 9 January 2017: In the process of comment resolution, it was decided to restructure the documents into four parts by dropping Part 5 and incorporating its provisions in the other parts. The resulting four part set incorporates some comment resolution from the five-part set ballots. At the September meeting round, the proponent gave details on reconsideration of the best form for this label and has submitted a replacement draft for Part 1 of a “v2” label. Data now consists of ISO 8601-like fields
(Year-Month-Day) Hour:Minute:Second.fractionalsecond.
Explanation for change.

zip of revised four-part set (before v2)

Full-featured Time Labels - draft ST 2105

This project has remained essentially frozen while the summits took place, though small updates to some parts of the document suite took place.The suite currently consists of:

  • EG 2105-1: Time Related Label (TRL) – Ecosystem
  • RP 2105-2: Time Related Label (TRL) – Terms, Definitions and Timescales
  • ST 2105-3: Time Related Label (TRL) – Media Index Counts
  • ST 2105-4: Time Related Label (TRL) – Data Objects and Container Structure
  • ST 2105-5: Time Related Label (TRL) – Conversions
  • ST 2105-6: Time Related Label (TRL) – Character Format Encoding (TCF)
  • ST 2105-11: Time Related Label (TRL) – Ancillary Data Mapping
  • ST 2105-12: Time Related Label (TRL) – Mapping to ST 12-1 and ST 12-2 Timecodes
  • ST 2105-21: Time Related Label (TRL) – Legacy Timecodes
  • RP 2105-31: Time Related Label (TRL) – Profiles

Status of project at 9 January 2017: The TC has reviewed the drafts, but the suite has not been balloted. Part 12 was introduced after the review, and it may replace Part 21. Also, Part 31 may have been withdrawn; neither of these have been stated by the proponent; we will check. Answer: The proponent is experimenting with reorganizing the Parts; best to leave all of them in for now.

updated zip of Full Featured Time Labels drafts

Comparison of the two approaches (by ST 2105 proponent)

Completed Project to Extend ST 12 Timecode for High Frame Rates

This project has standardized an extension to the ubiquitous SMPTE timecode standards (currently ST 12-1: Time and Control Code  and ST 12-2: Transmission of Time Code in the Ancillary Data Space) with an additional document ST 12-3: Time Address for High Frame Rate Signal and its Format in the Ancillary Data Space. This work was started because other, more ambitious, work on time labeling has not proceeded quickly enough to fill the present need.

The technique maintains the existing format for time address, whose frame count capacity cannot support standards above 30 fps - called Superframes in this document - but it makes use of some binary group flags that are incremented in order to define a sequence of labels for each Superframe and thus permit unique identification of every frame. There is capacity to label rates up to 960 fps, but the current version will only be defined up to 120 fps. ST 12-3 will not apply to LTC or VITC, only timecodes carried in the Ancillary Data Space (ATC). ATC has capacity to provide more information about the high frame rate labels.

Status at 9 January 2017:
The document was published at the end of March 2016. We are keeping it on this page to ensure that members don't miss this standard that supports today's high frame rates.
Scope details and information on purchase can be found here.    

Back to top

Facebook Twitter LinkedIn YouTube

IABM is a company limited by guarantee.
Registered in England No: 5262009. Registered Offic: 5 Deansway, Worcester, WR1 2JG, UK. VAT No: GB727297701