The SMG is monitoring and contributing to the development of the following SMPTE projects; (details in each section lower down this page):
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.
SMPTE recently (2014-2015) published a set of three standards that implement one approach:
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/m2 ” ?
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.
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.
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.
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
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
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:
A need for the following additional Part has been identified:
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 email@example.com 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:
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
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:
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.
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.
PLUGFESTS HELD TO-DATE:
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:
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.
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:
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.
Back to top
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:
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
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.
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
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
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.
Back to top
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.
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
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.
This project has remained frozen while the summits took place.
The following suite of 5 Parts closed FCD ballot 21 Sept. 2015:
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
Explanation for change.
zip of revised four-part set (before v2)
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:
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.
Comparison of the two approaches (by ST 2105 proponent)
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