Overview of LCEVC carriages
Introduction
As an MPEG standard (ISO/IEC 23094-2), LCEVC uses a NAL (Network Abstraction Layer) format for its encoded frame data, in the same way AVC, HEVC, EVC and VVC do. However each MPEG standard defines its own NAL format. Since LCEVC is an enhancement codec, its encoded data need to be carried as an addition to the base video it enhances. The LCEVC AU (Access Unit) consists of a single LCEVC NAL unit of type either LCEVC IDR or LCEVC non-IDR. This LCEVC NAL unit, which enhances a corresponding base AU, can be multiplexed with the base in two ways:
As a separate ES (Elementary Stream) track in the same container (e.g. Transport Stream ES PID, or track in ISOBMFF/MP4), or delivery system (HLS, DASH);
As some form of metadata in the same elementary stream as the base (e.g. using ITU-T T.35 metadata);
Standard defined carriages
Carriage in MPEG-2 Transport Stream (TS) and in ISO Base Media File Format are defined in amendments that have been incorporated in the relative ISO standards (see below). These methods also partially cover delivery systems that are based on them, such as HLS (HTTP Live Streaming) and MPEG-DASH. In all these use cases the standard compliant carriages entail the use of an additional ES for LCEVC.
MPEG-2 Transport Stream dual-PID
Support for carriage of LCEVC within MPEG-2 Transport Stream was introduced in ISO/IEC 13818‑1:2022/Amd 1:2023, and incorporated in the main standard starting from the 2023 edition (ISO/IEC 13818-1:2023, also as ITU-T H.222).
What the standard mandates is the carriage of the LCEVC Annex B bitstream as separate PES (Packetised Elementary Stream) PID, identified with stream type 0x36 (see Table 2-34). In the general case of a Multi Program TS there can be multiple LCEVC PIDs associated with base ESes of different programs therefore, in order to associate each LCEVC ES with its base ES, two new extension descriptors have been added. Those descriptors provide high level metadata and a tag, as a mechanism to associate LCEVC and base ES.
LCEVC and base ESes signal tags by means of two new extension descriptors. Matching tags identify which LCEVC ES enhances which base ES.
Specifically, an LCEVC_video_descriptor is used in the LCEVC ES component loop in the PMT to specify the specific tag for that base and enhancement association (the lcevc_stream_tag). The base ES component will have an LCEVC_linkage_descriptor in its PMT loop, to specify one or more lcevc_stream_tag that signal the corresponding LCEVC ES needed to enhance this base bitstream.
As a design choice, the coupling between the LCEVC and the base ES is not based on their PID values, in order for those associations to remain valid across remuxing operations. This is because upon remuxing PIDs may change, while descriptor contents are generally passed through, which keeps the stream tag matches valid.
At the sample level, matching between LCEVC and base AUs is performed by means of the Presentation Time Stamp (PTS).
ISO Base Media File Format dual-track
Carriage of LCEVC in ISO Base Media File Format (ISOBMFF) was introduced in ISO/IEC 14496-15:2022/Amd 1:2023, incorporated in the main standard starting from the 2024 edition (ISO/IEC 14496-15:2024).
Again, the LCEVC sample stream is carried in a separate track, for which a new sample entry has been defined (see Section 13). Similarly to the other MPEG standards an LCEVC DecoderConfigurationRecord has been defined (see Section 13.3.3.2), which conveys general metadata and a loop of NAL unit arrays to carry LCEVC config blocks (global config, sequence vconfig and additional info).
Here the coupling between base and enhancement (LCEVC) tracks is achieved by means of the sbas (scalable base) atom, as defined in ISO/IEC 14496-12 and Subclause 6.5.1 of the LCEVC Amendment. The sbas atom, to be placed in the LCEVC track loop, signals the track Id of the corresponding base track it enhances.
At the sample level, matching between LCEVC and base AUs is performed by means of the composition time.
CMAF profile dual-track
A CMAF profile for LCEVC has been introduced in ISO/IEC 23000-19:2024/Amd 1:2024, published in July 2024.
The LCEVC profile is built upon (i) the “dual-track” structure as described in Section 2.1.2 and (ii) the existing CMAF construct of Dependent CMAF Tracks, as defined in Clause H.1 of ISO/IEC 23000-19:2024.
Non-Scalable MPEG-DASH
In this approach, the base-layer video (AVC, HEVC, or VVC) and the LCEVC enhancement layer are carried together in a single media segment as dual-track within the ISO-BMFF or CMAF profile described above. In the DASH manifest, a single DASH Representation is used, which references this dual-track media segment.
The DASH manifest structure largely mirrors that of a single-layer codec. Please see the descriptions below for clarification of key attributes:
@codecs = <base layer codec syntax>
@width/height = <Base layer video width/height>
@bandwidth = <combined bit rate of the LCEVC + base representation>
A sample manifest file is available: https://d3mfda3gpj3dw1.cloudfront.net/Test_Streams/3.14/LCEVC_H264/BBB_DualTrack_DASH_StaticResiduals/master.mpd
Scalable MPEG-DASH (@dependencyId)
Note: This solution is pending incorporation in the next DASH-IF IOP (Interoperability Points) v5.1, see "Features and Additions on top of Latest Version" in https://dashif.org/guidelines/iop-v5/ at approved amendment: DASH-IF Feature: LCEVC in DASH (published 17 Dec 2025). The scalable LCEVC feature uses tools from the existing ISO/IEC 23009-1 DASH specification. No modifications of the DASH norm have been proposed to support this LCEVC scalable DASH solution.
This approach is "scalable" in allowing the client to either load the base only and play the base video or load both the base and the LCEVC enhancement to play enhanced, higher quality, video. Put differently, the client can also play base video only without having to load and discard additional data for the LCEVC enhancement, as would be the case in the non-scalable approach described above. This scalable feature is achieved without introducing new syntax elements in the DASH specification, making it compatible, at minimum for base only, with virtually any DASH client.
To offer scalability base and LCEVC encoded media must be delivered separately, with LCEVC only Representations and base Representations that respectively form separate Adaptation Sets. In the manifest the @dependecyId attribute is added to each LCEVC Representation to signal which base Representation it enhances. The @dependencyId aware DASH client will have to load the dependecyId signalled Representation (defined "Complementary" Representation in the DASH standard), which is the scalable base, in addition to the parent one, i.e. the LCEVC Representation.
The supplemental property “adaptation-set-switching:2016” is added to both video and LCEVC Adaptation Sets, with each one pointing at the other, to signal the client that the switching set shall be the union of all the representations of both Adaptation Sets. Clients not supporting this supplemental property, and/or not supporting LCEVC as base codec (codecs string lvc1), would only switch among the Representations found in the base Adaptation Set.
With focus on the LCEVC Adaptation Set, following are the key attributes at Adaptation Set and Representation level:
@contentType = ‘video’
@mimeType = ‘video/mp4’
@codecs = ‘lvc1’
@frameRate = <>
@dependencyId = <>
@width/height = <LCEVC enhanced video width/height>
@bandwidth = <combined bit rate of the LCEVC + base representation>
@sar = <sample aspect ratio as signalled in LCEVC Video Usability Information (VUI)>
For all the details on the LCEVC Scalable DASH solution please refer to the DASH IOP approved amendment DASH-IF Feature: LCEVC in DASH (published 17 Dec 2025).
Proprietary solutions
The carriage cases described in this section are based on proprietary solutions, that either embed LCEVC NAL units in SEI messages or interleave them with NAL units of other codecs.
ITU-T T.35 user-registered SEI
The LCEVC AUs can be embedded within an SEI (Supplemental Enhancement Information) message of other MPEG ES using the ITU-T T.35 user data registered syntax already specified in MPEG codecs. V-Nova got assigned a manufacturer code under the UK Register of Manufacturer Codes for H.221/H.245/T.120, which can be used for this purpose.
With that code, the payload has the following format.
Note that the itu_t_t35_country_code is followed by three additional fields specific to the National Register for the UK.
Table – ITU-T T.35 syntax with the values specified by the V-Nova manufacturer code registered in the UK
user_data_registered_itu_t_t35 ( payloadSize ) {
itu_t_t35_country_code
b(8)
0xB4
itu_t_t35_payload_header {
t35_uk_country_code_second_octet
b(8)
0x00
t35_uk_manufacturer_code_first_octet
b(8)
0x50
t35_uk_manufacturer_code_second_octet
b(8)
0x00
}
i = 4
do {
itu_t_t35_payload_byte
b(8)
i++
} while ( i < payloadSize )
}
The LCEVC AU is the payload of the above SEI message.
ITU-T T.35 OBU
In a similar way to MPEG standards, a LCEVC AU can be embedded as metadata in an AV1 OBU stream (see AV1 Bitstream & Decoding Process Specification). The OBU syntax comprises a header and a payload. The header is as follows:
obu_header( ) {
Descriptor
Value
obu_forbidden_bit
f(1)
0
obu_type
f(4)
obu_extension_flag
f(1)
obu_has_size_field
f(1)
obu_reserved_1bit
f(1)
0
if ( obu_extension_flag == 1 )
obu_extension_header( )
}
For the carriage of LCEVC the obu must be of metadata type, which is identified by obu_type equal to 5. Among the types of metadata OBUs defined in AV1 there is an ITU-T T.35 type that is to be used for LCEVC carriage in a similar way as for the MPEG encapsulation described above.
In the LCEVC case the OBU payload is as follows:
metadata_obu( ) {
Descriptor
Value
metadata_type /* equal to METADATA_TYPE_ITUT_T35 */
leb128()
0x04
if ( metadata_type == METADATA_TYPE_ITUT_T35 )
metadata_itut_t35( )
}
with the payload as:
metadata_itut_t35( ) {
Descriptor
Value
itu_t_t35_country_code
f(8)
0xB4
itu_t_t35_payload_uk_lcevc()
}
where the payload itu_t_t35_payload_uk_lcevc() is the itu_t_t35_payload_header() and itu_t_t35_payload_byte(s) as in user_data_registered_itu_t_t35 defined above for SEI.
Last updated
Was this helpful?