Copyright Β© 2025, Society of Motion Picture and Television Engineers. All rights reserved. No part of this material may be reproduced, by any means whatsoever, without the prior written permission of the Society of Motion Picture and Television Engineers.
The Society of Motion Picture and Television Engineers (SMPTE) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 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 are drafted in accordance with the rules given in its Standards Operations Manual.
For more information, please visit www.smpte.org.
At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Engineering Document. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights.
This document was prepared by Technology Committee 10E.
This clause is entirely informative and does not form an integral part of this Engineering Document.
Computing and compositing systems must often render multiple sources of content, including text, images, and videos, that can be both standard dynamic range and high dynamic range, on the same display, at the same time.
Modern operating systems and compositors accomplish this by combining the sources of content in a common relative linear color space, with the target display's capabilities parameterized by a targeted high dynamic range headroom. Content with a high dynamic range headroom higher than the targeted high dynamic range headroom parameter must be adapted to the target display's dynamic range to prevent clipping and loss of detail. Similarly, content with a high dynamic range headroom lower than the targeted high dynamic range headroom parameter can be enhanced to improve the visual experience. Figure 1 provides a visualization of this process.
Color Volume Transform Application #5 defines dynamic metadata items that provide parameters for the steps in the above-described compositing pipeline of converting to relative linear color space and headroom-adaptive tone mapping to a targeted HDR headroom.
Conversion of the input image essence through its native EOTF produces linear display light which allows each source to be mapped into a relative linear color space using a metadata item parameter to specify the HDR reference white for each content source, as described in Clause A.2. In this conversion, the HDR reference white (with values measured in cd/m2) provides an anchor above which the HDR headroom begins.
Headroom-adaptive tone mapping transforms the input image essence so that the resulting tone mapped image has a HDR headroom equal to a specified targeted HDR headroom parameter,
as described in 6.4.
This operation is parameterized by metadata items specifying
the baseline HDR headroom and
potentially multiple alternate images.
Each alternate image is represented by
an alternate HDR headroom and
a corresponding color gain function.
Each color gain function is specified in the
Adaptation to the specified targeted HDR headroom parameter is performed by applying a weighted average of the color gain functions. The weighting is performed using a function of the targeted HDR headroom, the baseline HDR headroom, and the alternate HDR headroom(s). This is described and illustrated with examples in Annex B.
This standard specifies the metadata for the Color Volume Transform Application #5. It is a specialization of the content-dependent transform metadata entries and processing blocks of the generalized color volume transform model defined in SMPTE ST 2094-1:2016. It includes parameters for conversion of an input image essence to a common relative linear color space, parameters for an headroom-adaptive tone mapping algorithm, and the mathematical definition of that headroom-adaptive tone mapping algorithm.
Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords.
All text in this document is, by default, normative, except: the Introduction, any clause explicitly labeled as "Informative" or individual paragraphs that start with "Note:"
The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.
The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.
The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.
The keyword "reserved" indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword "forbidden" indicates "reserved" and in addition indicates that the provision will never be defined in the future.
A conformant implementation according to this document is one that includes all mandatory provisions ("shall") and, if implemented, all recommended provisions ("should") as described. A conformant implementation need not implement optional provisions ("may") and need not implement them as described.
Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; tables shall be next; then formal languages; then figures; and then any other language forms.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
For the purposes of this document, the following terms and definitions apply:
The symbol
The symbol
The expression
The expression
The expression
A gain curve structure defines a function
A gain curve structure is parameterized by:
The value of
For
For
For
This clause describes the evaluation of the function
For
The function
A component mixing function structure defines a function
A component mixing function structure is parameterized by:
NOTE 1 ββ
The
NOTE 2 ββ This function and its parameterization are the same as the adaptive gain curve input evaluator from Annex 1 of ICC Adaptive Gain Curve.
The values of
It shall be the case that
This clause describes the evaluation of the function
Let
The function
NOTE ββ
If the parameter
A color gain function structure defines a color gain function
A color gain function structure is parameterized by:
a component mixing function structure, which defines the function
a gain curve structure, which defines the function
NOTE ββ The resulting color gain function is equivalent to an adaptive gain curve from ICC Adaptive Gain Curve.
This clause describes the evaluation of the function
Let
The function
NOTE ββ
If it is the case that all components of
The zero color gain function shall equal the color gain function defined in Formula (7).
NOTE ββ The zero color gain function is the color gain function that is applied to the baseline image when performing headroom-adaptive tone mapping with the targeted HDR headroom parameter equal to the baseline HDR headroom.
Figure 2
provides a visualization of
the evaluation of the
An headroom-adaptive tone map structure
defines a function
NOTE ββ
The function
This structure is parameterized by:
a real value
an integer
real values
color gain function structures that define
the function
real valued vectors
The value of
The value of
For
For
For
The length of the vectors
The values of the components of the vectors
This clause is informative.
This clause lists constraints that are useful for achieving coherent headroom-adaptive tone mapping behavior but are not normatively required. Implementations can adjust metadata items so that they satisfy these constraints.
For
When a headroom-adaptive tone mapping is performed with the targeted HDR headroom parameter set equal to an alternate HDR headroom,
pixels in the baseline image with values equal to the baseline HDR headroom
will preferably be mapped to values equal to that alternate HDR headroom.
This is accomplished if for each
Tone mapping to a targeted HDR headroom lower than the baseline HDR headroom
will preferably only decrease the tone mapped result, and
tone mapping to a targeted HDR headroom greater than the baseline HDR headroom
will preferably only increase the tone mapped result.
In symbols, this is accomplished if it is the case that
for
As the targeted HDR headroom of tone mapping increases,
the tone mapped result will preferably only increase.
In symbols, this is accomplished if it is the case that
for
The tone mapping curves will preferably be monotonically increasing.
In symbols, this is accomplished if it is the case that
for
When tone mapping to a targeted HDR headroom that is equal to
an alternate HDR headroom
the result of tone mapping will be
the corresponding alternate image.
In symbols, for any
The equality in Formula (9) is satisfied by the function defined in Formula (13).
This clause describes the evaluation of the function
Create a new list of HDR headrooms by
inserting the baseline HDR headroom
These lists are constructed in order to simplify the presentation by reducing the number of special cases. In this formulation the presentation does not need to distinguish between the case of interpolating between the baseline image and an alternate image and the case of interpolating between two alternate images, because they are unified into a single list.
Implementations can avoid explicitly forming these unified lists as an optimization.
A visualization of an example in which
Let
If there exists a value
Otherwise, there must exist exactly one value
Let
The value of
The headroom-adaptive tone mapping function shall be equivalent to the definition in Formula (13).
Figure 3 provides a visualization of the computation of an alternate image as described in 6.4.4.
Figure 4 provides a visualization of the evaluation of the
A color volume transform structure defines the parameters for the color volume transformation informatively described in Annex A.
A color volume transform structure is parameterized by:
a real value
an optional headroom-adaptive tone map structure defining a function
The value of
A metadata set shall comprise exactly one of each of the following:
The TimeInterval group shall include exactly one of each of the following metadata items defined in Clause 8 of SMPTE ST 2094-1:2016:
The ProcessingWindow group shall include exactly one of each of the following metadata items defined in Clause 9 of SMPTE ST 2094-1:2016:
The ColorVolumeTransform group which shall include at most one the following metadata items:
The HeadroomAdaptiveToneMap group shall include exactly one of each of the following metadata items:
Each ColorGainFunction[a] group shall include exactly one of each of the following metadata items:
Each ComponentMix[a] group shall include exactly one of each of the following metadata items:
Each GainCurve[a] group shall include exactly one of each of the following metadata items:
This clause specifies the constraints on the metadata set from 7.1, and defines the association between the the items of the metadata set and data structures and parameters defined in Clause 6.
The ApplicationIdentifier metadata item shall equal 5.
The ApplicationVersion metadata item shall equal 0.
Thee ProcessingWindow shall be subject to the following constraints.
The ColorVolumeTransform metadata group specifies a color volume transform structure. The metadata items in this metadata group specify the parameters listed in 6.5.1, and are subject to the constraints listed in 6.5.2.
The HeadroomAdaptiveToneMap metadata group, if present, specifies a headroom-adaptive tone map structure. The metadata items in this metadata group specify the parameters listed in 6.4.1, and are subject to the constraints listed in 6.4.2.
The ColorGainFunction[a] metadata group specifies a color gain function structure. The metadata items in this metadata group specify the parameters listed in 6.3.1.
The ComponentMix[a] metadata group specifies a component mixing function structure. The metadata items in this metadata group specify the parameters listed in 6.2.1, and are subject to the constraints listed in 6.2.2.
The GainCurve[a] metadata group specifies a gain curve structure. The metadata items in this metadata group specify the parameters listed in 6.1.1, and are subject to the constraints listed in 6.1.2.
This annex describes the computations to apply the color volume transformation to an input image essence. Figure A.1 illustrates this specification's headroom-adaptive tone mapping algorithm in the framework of the Generalized Color Transform Model described in Annex A and visualized in Figure A.1 of SMPTE ST 2094-1:2016.
The individual stages of Figure A.1 correspond to Figure A.2, followed by Figure 4, followed by Figure A.3.
This clause describes the computation of the function
Throughout this clause, the input signal is assumed to
have three components corresponding to its red, green, and blue primaries,
scaled such that the nominal peak signal is
The computation is visualized in Figure A.2, and represents the "Convert to Gain Application Color Space" block of Figure A.1.
Let
NOTE 1 ββ
Components of
NOTE 2 ββ Scalar functions applied to vector arguments are applied component-wise.
Let
Let
NOTE 3 ββ When refering to the luminance of a single color component, it means the luminance of an equivalent achromatic color with all three color components having that same value.
The function
If the baseline image indicates
Recommendation ITU-R BT.1886,
Recommendation ITU-R BT.709-6, or
Recommendation ITU-R BT.2020-2
transfer characteristics, then
let
NOTE 4 ββ
For this and other standard dynamic range transfer characteristics,
the function
NOTE 5 ββ An input image essence that originates from video that did not indicate its transfer characteristics is often assumed to have Recommendation ITU-R BT.1886 transfer characteristics.
NOTE 6 ββ This formulation is equivalent to the display referred mappings described in Section 5.1.2, Section 5.1.3.1, Figure 5, and Figure 7 of Report ITU-R BT.2408-8, and in MovieLabs Best Practice: SDR to HDR Conversion. When in a context dominated by Recommendation ITU-R BT.2100-3 Hybrid Log-Gamma (HLG) content, some systems may choose to include an extra gamma adjustment step, as described in Section 5.1.3.2, Figure 6, and Figure 8 of Report ITU-R BT.2408-8. Implementations can use the formulation indicated by the content or the application context for this and other standard dynamic range transfer characteristics.
If the baseline image indicates IEC 61966-2-1 sRGB transfer characteristics then
let
If the baseline image indicates Recommendation ITU-R BT.2100-3 Perceptual Quantization (PQ) transfer characteristics then
let
If the baseline image indicates Recommendation ITU-R BT.2100-3 Hybrid Log-Gamma (HLG) transfer characteristics then
let
NOTE 7 ββ The HLG Reference OOTF in this formulation must be applied using the color primaries indicated in Table 2 of Recommendation ITU-R BT.2100-3.
Let
The function
This clause describes the computation of the headroom-adaptive tone mapping algorithm.
Let
Let
Let
This clause describes the computation of the function
Let
The function
Displays can perform more complicated transformations from the gain application color space to the target display, for example, to adjust for non-reference ambient viewing conditions. That topic is out of the scope of this specification.
NOTE ββ
Any colors that do not fit in the targeted display color volume
(any colors with components greater than
Figure B.1 illustrates the color gain functions and associated tone mapping functions
of an headroom-adaptive tone mapping with a baseline high dynamic range headroom
On the left side of Figure B.1 are the underlying color gain functions in the
On the right side of Figure B.1 are the tone mapping curves that are computed from the color gain functions.
The zero color gain function results in an identity tone mapping function.
The alternate image's color gain function results in a tone mapping curve that maps
Adaptation to a different targeted HDR headroom of
Figure B.2 illustrates a slightly more complicated example of headroom-adaptive tone mapping with an additional alternate image with
An example adaptation to a targeted HDR headroom of
Figure B.3 illustrates
an example of inverse tone mapping
with a standard dynamic range baseline image with
This example is the inverse of the transformation performed in the example in Clause B.1. That is to say that a baseline image set to the alternate image from the example in Clause B.1 (the tone mapping to standard dynamic range), with this metadata, would appear identical to the example in Clause B.1, up to any quantization errors.
Note in the legend that in this example
Adaptation to the targeted HDR headroom of
The way to indicate that no tone mapping is to be performed, and that the baseline image is to be projected (clamped) to the target color volume, regardless of the targeted HDR headroom, is to specify that the number of alternate images is 0. This clause illustrates this behavior by working through the details of the computation.
In the context of the headroom-adaptive tone map
computation described in in 6.4.5,
this means that
This means that the image resulting from the headroom-adaptive tone mapping in the color volume transform step in Clause A.3 will be the unchanged baseline image. After this, the image will be converted to the target display as described in Clause A.4, and the resulting image will be projected to the targeted color volume, as described in Clause A.4, Note. The result of this operation will be to clamp the baseline image to the targeted HDR headroom.
Figure B.4 illustrates this case, where the color gain function is always equal to the zero color gain function and the headroom-adaptive tone mapping is the identity.
Figure B.5 illustrates the result of this operation described in Clause A.4, Note, which is to project (or clamp) the baseline image to the targeted HDR headroom.
The metadata for Application #5 shall be stored in binary form according to the syntax structure in Clause C.2. The assignment of values to the items of the metadata set based on the syntax elements is in Clause C.3.
The syntax structures are presented in a tabular form. The type of each syntax element in the bitstream is indicated in the Type column. A syntax element with type u(N) is stored as an N-bit unsigned integer. The bits of each syntax element shall be read in order from most significant to least significant.
NOTE ββ All syntax elements that are one full byte or larger are byte aligned. For syntax elements that are 16-bit unsigned integers, this representation is equivalent to storing those syntax elements in big-endian form.
Syntax elements with the name reserved_zero shall be equal to zero.
Table C.1 presents the syntax structures related to Application #5.
The smpte_st_2094_50_application_info metadata bitstream may have padding after the end of the structure. Parsers shall stop reading after the last recognized syntax element of smpte_st_2094_50_application_info and ignore all remaining data.
| smpte_st_2094_50_application_info() { | Type |
|---|---|
| application_version | u(8) |
| smpte_st_2094_50_color_volume_transform() | |
| } |
Table C.2 presents the syntax for specifying the ColorVolumeTransform metadata group.
| smpte_st_2094_50_color_volume_transform() { | Type |
|---|---|
| has_custom_hdr_reference_white_flag | u(1) |
| has_adaptive_tone_map_flag | u(1) |
| reserved_zero | u(6) |
| if (has_custom_hdr_reference_white_flag == 1) { | |
| hdr_reference_white | u(16) |
| } | |
| if (has_adaptive_tone_map_flag == 1) { | |
| smpte_st_2094_50_adaptive_tone_map() | |
| } | |
| } |
Table C.3 presents the syntax for specifying the HeadroomAdaptiveToneMap metadata group.
| smpte_st_2094_50_adaptive_tone_map() { | Type |
|---|---|
| baseline_hdr_headroom | u(16) |
| use_reference_white_tone_mapping_flag | u(1) |
| if (use_reference_white_tone_mapping_flag == 0) { | |
| num_alternate_images | u(3) |
| gain_application_space_chromaticities_flag | u(2) |
| has_common_component_mix_params_flag | u(1) |
| has_common_curve_params_flag | u(1) |
| if (gain_application_space_chromaticities_flag == 3) { | |
| for (r = 0; r < 8; r++) { | |
| gain_application_space_chromaticities[r] | u(16) |
| } | |
| } | |
| for (a = 0; a < min(num_alternate_images, 4); a++) { | |
| alternate_hdr_headrooms[a] | u(16) |
| smpte_st_2094_50_component_mixing(a) | |
| smpte_st_2094_50_gain_curve(a) | |
| } | |
| } else { | |
| reserved_zero | u(7) |
| } | |
| } |
Table C.4 presents the syntax for specifying a ComponentMix metadata group.
| smpte_st_2094_50_component_mixing(a) { | Type |
|---|---|
| if (a == 0 || has_common_component_mix_params_flag == 0) { | |
| component_mixing_type[a] | u(2) |
| if (component_mixing_type[a] != 3) { | |
| reserved_zero | u(6) |
| } else { | |
| for (k = 0; k < 6; k++) { | |
| has_component_mixing_coefficient_flag[a][k] | u(1) |
| } | |
| for (k = 0; k < 6; k++) { | |
| if (has_component_mixing_coefficient_flag[a][k] == 1) { | |
| component_mixing_coefficient[a][k] | u(16) |
| } else { | |
| component_mixing_coefficient[a][k] = 0 | |
| } | |
| } | |
| } | |
| } else { | |
| component_mixing_type[a] = component_mixing_type[0] | |
| if (component_mixing_type[a] == 3) { | |
| for (k = 0; k < 6; k++) { | |
| component_mixing_coefficient[a][k] = component_mixing_coefficient[0][k] | |
| } | |
| } | |
| } | |
| } |
Table C.5 presents the syntax for specifying a GainCurve metadata group.
| smpte_st_2094_50_gain_curve(a) { | Type |
|---|---|
| if (a == 0 || has_common_curve_params_flag == 0) { | |
| gain_curve_num_control_points_minus_1[a] | u(5) |
| gain_curve_use_pchip_slope_flag[a] | u(1) |
| reserved_zero | u(2) |
| for (c = 0; c < gain_curve_num_control_points_minus_1[a] + 1; c++) { | |
| gain_curve_control_points_x[a][c] | u(16) |
| } | |
| } else { | |
| gain_curve_use_pchip_slope_flag[a] = gain_curve_use_pchip_slope_flag[0] | |
| gain_curve_num_control_points_minus_1[a] = gain_curve_num_control_points_minus_1[0] | |
| for (c = 0; c < gain_curve_num_control_points_minus_1[a] + 1; c++) { | |
| gain_curve_control_points_x[a][c] = gain_curve_control_points_x[0][c] | |
| } | |
| } | |
| for (c = 0; c < gain_curve_num_control_points_minus_1[a] + 1; c++) { | |
| gain_curve_control_points_y[a][c] | u(16) |
| } | |
| if (gain_curve_use_pchip_slope_flag[a] == 0) { | |
| for (c = 0; c < gain_curve_num_control_points_minus_1[a] + 1; c++) { | |
| gain_curve_control_points_theta[a][c] | u(16) |
| } | |
| } | |
| } |
This clause describes how to assign values to the metadata items described in 7.1 given the syntax elements from Clause C.2.
The ApplicationIdentifier metadata item shall be assigned the value 5.
The ApplicationVersion metadata item shall be assigned the value application_version.
The ProcessingWindow metadata group shall be assigned values as follows.
The ColorVolumeTransform metadata group shall be assigned values as specified in C.3.3.
If has_custom_hdr_reference_white_flag==0, then:
If has_custom_hdr_reference_white_flag==1, then:
If has_adaptive_tone_map_flag==0, then:
If has_adaptive_tone_map_flag==1, then:
The BaselineHdrHeadroom metadata item shall be assigned the value
If use_reference_white_tone_mapping_flag==0, then:
For each value
The ColorGainFunction[a] metadata group shall be assigned values as follows.
If use_reference_white_tone_mapping_flag==1, then:
The GainApplicationChromaticities, metadata item shall be assigned a value as follows.
If gain_application_space_chromaticities_flag==0, then:
If gain_application_space_chromaticities_flag==1, then:
If gain_application_space_chromaticities_flag==2, then
If gain_application_space_chromaticities_flag==3, then:
The ComponentMix[a] metadata group shall be assigned values as follows.
If component_mixing_type[a]==0 then:
If component_mixing_type[a]==1 then:
If component_mixing_type[a]==2 then:
If component_mixing_type[a]==3 then:
The GainCurve[a] metadata group shall be assigned values as follows.
The GainCurveNumControlPoints[a] metadata item shall be assigned the value
gain_curve_num_control_points_minus_1[a]
For each value
If gain_curve_use_pchip_slope_flag[a]==0, then:
For each value
If gain_curve_use_pchip_slope_flag[a]==1, then:
This clause specifies the metadata item values to assign in the HeadroomAdaptiveToneMap metadata group when the use_reference_white_tone_mapping_flag syntax element indicates that the parameters for headroom-adaptive tone mapping should be computed (as opposed to being specified).
NOTE ββ The results of this computation are equivalent to the Reference White Tone Mapping Operator described in ISO/TC 22028-5:2023.
Let
The
GainApplicationChromaticities,
metadata item shall be assigned the value
If
If
The AlternateHdrHeadroom[1] metadata item shall be assigned the value
For
The ComponentMix[a] metadata group shall be assigned values as follows.
The GainCurve[a] metadata group shall be assigned values as follows.
Let
The GainCurveNumControlPoints[a] metadata item shall be assigned the value
Let
Let
The control point values will be defined by
the functions
For each value
The functions
The gain curve is
The parametric BΓ©zier curve and its slope are given by
the scalar functions
The quadratic parameters
Finally, the functions
Figure C.1 illustrates the interpretation of the equations in this clause. The BΓ©zier control points in Formula (C.3) and the resulting BΓ©zier curve from Formula (C.4) are displayed on the left. The resulting gain curve from Formula (C.6) is displayed on the right. The extrapolation behavior beyond the control points, specified by Formula (2), is indicated in both plots.
This clause specifies,
for a given value of
NOTE ββ The results of this computation are equivalent to the Piecewise Cubic Hermite Interpolation Package (PCHIP) algorithm described in DOI:10.1137/0905021.
Let
For
Let
Let
For
For each
This clause describes carriage of Application #5 metadata using the Recommendation ITU-T T.35 mechanism.
For Application #5, the Recommendation ITU-T T.35 country code is 0xB5 (United States), the terminal provider code is 0x0090 (SMPTE), and the terminal provider oriented code is 0x0001.
Table D.1 presents the Recommendation ITU-T T.35 metadata syntax structure, truncated to include only the syntax required for Application #5.
| metadata_itu_t_t35() { | Type |
|---|---|
| itu_t_t35_country_code | u(8) |
| if (itu_t_t35_country_code == 0xB5) { | |
| itu_t_t35_us_terminal_provider_code | u(16) |
| if (itu_t_t35_us_terminal_provider_code == 0x0090) { | |
| itu_t_t35_smpte_terminal_provider_oriented_code | u(16) |
| if (itu_t_t35_smpte_terminal_provider_oriented_code == 0x0001) { | |
| smpte_st_2094_50_application_info() | |
| } else { | |
| // Handling of other terminal provider oriented codes | |
| } | |
| } else { | |
| // Handling of other terminal provider codes | |
| } | |
| } else { | |
| // Handling of other country codes | |
| } | |
| } |
The itu_t_t35_country_code syntax element specifies the first byte of the Recommendation ITU-T T.35 country code.
The itu_t_t35_us_terminal_provider_code syntax element specifies the Recommendation ITU-T T.35 terminal provider code for the United States country.
The itu_t_t35_smpte_terminal_provider_oriented_code a syntax element specifies the Recommendation ITU-T T.35 terminal provider oriented code for the SMPTE terminal provider.