Indication of scalable video codec

Abstract

There is described a bitstream comprising an indication of a type of scalable video codec used by the bitstream. The value of the indication may be capable of being within the range of 0 to 2, inclusive. The indication may be an indication in a transport layer of the bitstream. The bitstream may be for, and / or compliant with, an Advanced Television Systems Committee (ATSC) standard, such as an ATSC 3.0 standard.

Description

[0001] Indication of scalable video codec

[0002] Field of the Disclosure

[0003] The present disclosure relates to a bitstream comprising an indication of a scalable video codec that is used by the bitstream. The present disclosure further relates to methods, apparatuses, and systems for generating and parsing the bitstream.

[0004] Background to the Disclosure

[0005] Video codecs, which are used to standardise the encoding and decoding of bitstreams, are known to use scalable or multi-layer codecs. In particular, a bitstream that defines a video may use a first, base, layer that provides a minimum quality version of the video and one or more scaling layers or enhancement layers that can be combined with the base layer to provide a higher quality video.

[0006] Therefore, in many situations it is desirable to know if a bitstream comprises a scalable codec and, if so, which particular type of scalable codec; however, this information is typically not signalled in a bitstream. Therefore, decoders are generally required to decode significant amounts of an incoming bitstream in order to determine whether a scalable codec is used in that bitstream.

[0007] Summary of the Disclosure

[0008] According to an aspect of the present disclosure, there is described a bitstream comprising an indication of a scalable video codec used by the bitstream.

[0009] According to an aspect of the present disclosure, there is described a bitstream comprising an indication of a type of scalable video codec used by the bitstream.

[0010] By indicating a type of a scalable video codec used in the bitstream, the bitstream enables a receiver, e.g. a decoder, to efficiently process the bitstream. This is in contrast to presently available bitstreams in which there is no explicit signalling of a type of scalable video codec used in the bitstream. These bitstreams there require a decoder to decode a substantial amount of the bitstream in order to identify the types of any scalable video codecs used in the bitstream.

[0011] Preferably, the indication is in a transport layer and / or a network abstraction layer (NAL) of the bitstream. Preferably, the indication is an indication, e.g. an element, in a transport layer of the bitstream.

[0012] Preferably, the indication comprises a variable field defined in the bitstream. Preferably, the indication comprises a variable scalable_type_id. Preferably, the indication comprises an n-bit unsigned integer field.

[0013] Preferably, the n-bit unsigned integer field comprises a 2-bit unsigned integer field. Preferably, wherein the value of the 2-bit unsigned integer field is one or more of: 00, 01 , 10 or 11 . Preferably, the value of the 2- bit unsigned integer field is one or more of: 00, 01 , 10.

[0014] According to an aspect of the present disclosure, there is described a bitstream comprising a 2-bit unsigned integer field in a transport layer of the bitstream, wherein the 2-bit unsigned integer field indicates a type of a scalable video codec used by the bitstream. Preferably, the indication indicates a type of scalable video codec used by video packets of the bitstream.

[0015] The indication being present in the transport layer may comprise the indication being interpretable without decoding one or more video packets also contained in the transport layer, preferably wherein the one or more video packets comprise information, e.g. one or more enhancement layers, associated with the scalable video codec. Therefore, a decoder is able to parse the indication prior to the decoding of the video packets.

[0016] Preferably, the value of the indication is within, and / or is capable of being within, the range of 0 to 2, inclusive. Preferably, the bitstream is encoded based on a codec, wherein the codec defines one or more possible values of the indication. Therefore, codec may indicate that the indication is defined for values within the range of 0 to 2, inclusive (so that the value can only be defined, by a codec-compliant encoder, as one of these values).

[0017] Preferably, the indication comprises a 4-character code to distinguish scalable codecs, more preferably, the value of the 4-character code is, or is capable of being, one or more of: wc1 , wc2, wi1 or wi2.

[0018] Preferably, the indication specifies the scalable codec, preferably the scalable codec is associated with an asset in the bitstream. Preferably, the asset is a video asset. Preferably, the video asset is a compressed video asset. Preferably, the video asset is compressed at least in part using the specified scalable codec.

[0019] Preferably, the indication is capable of indicating, and / or is arranged to indicate, one of a plurality of possible values, wherein each possible value of the indication indicates a different (e.g. particular) scalable codec.

[0020] Preferably, the indication comprises a reference to one of a plurality of possible values, more preferably wherein the possible values are defined in a predefined table.

[0021] Preferably, the indication is capable of indicating, and / or is arranged to indicate, that the bitstream uses one or more of: HEVC scalable main 10 Profile (SHVC), preferably wherein the indication having a value of 00 indicates the HEVC scalable main 10 Profile (SHVC); Multilayer VVC main Profile, preferably wherein the indication having a value of 01 indicates the Multilayer VVC main Profile; and MPEG-5 LCEVC Main Profile, preferably wherein the indication having a value of 10 indicates the MPEG-5 LCEVC Main Profile.

[0022] Preferably, the bitstream comprises a scalability flag, preferably a Boolean scalability flag, that indicates whether scalability information is present in the bitstream, preferably wherein the scalability flag comprises a scalability_info_present flag.

[0023] Preferably, the bitstream a scalabilityjnfo field, preferably wherein the scalabilityjnfo field comprises an assetjayerjd field (e.g. a 6-bit unsigned integer field) that specifies a nuhjayerjd of an asset of the bitstream. Preferably, the scalabilityjnfo field consists of the assetjayerjd field and the indication

[0024] Preferably, the scalabilityjnfo field comprises the indication.

[0025] Preferably, the bitstream a multiview flag, preferably a Boolean multiview flag, indicating whether multiview information is present in the bitstream, preferably wherein the flag is a multiview_info_present flag and a value of 1 indicates the presence of multiview information in the bitstream.

[0026] Preferably, the bitstream further comprises at least one audio asset.

[0027] Preferably, the bitstream is a television broadcast bitstream.

[0028] According to an aspect of the present disclosure, there is described a bitstream adapted to indicate to a compatible receiver the presence of, preferably a type of, a supplementary technology used in the bitstream, preferably a scalable video codec that is used with a base codec.

[0029] Preferably, the presence of the supplementary technology is indicated by a flag and / or a variable.

[0030] Preferably, the supplementary technology is a scalable video codec, preferably wherein the presence of the scalable video codec is indicated at a higher layer of signalling than a video stream signalled in the bitstream.

[0031] Preferably, the bitstream further comprises: data encoded for a / the base codec; data encoded for a / the at least one supplementary technology (e.g. scalable video codec); an indication embedded within the bitstream, the indication specifying the presence and type of the supplementary technology, preferably wherein the indication is represented as: at least one flag comprising one or more bits, each bit value corresponding to a predefined supplementary technology; and / ora variable that has a value that is one of a plurality of predefined values that denote respective supplementary technologies, preferably wherein the variable is a scalable_type_id variable.

[0032] Preferably, the bitstream is adapted for separation and decoding by a compatible receiver, the bitstream comprising: a first portion containing data encoded for a base codec; a second portion containing data encoded for at least one supplementary scalable video codec; the indication being embedded within the bitstream in a predefined portion of the bitstream, the indication: enabling the receiver to identify the scalable video codec, more preferably enabling the receiver to distinguish between the base codec and the supplementary scalable video codec portions; and / or facilitating the extraction of the supplementary scalable codec portion; and / or triggering the initialization of separate decoding instances for the respective supplementary scalable codec portions.

[0033] Preferably, the bitstream is for, and / or compliant with, an Advanced Television Systems Committee (ATSC) standard, preferably an ATSC 3.0 standard.

[0034] Preferably, the bitstream is for, and / or compliant with, a Dynamic Adaptive Streaming over HTTP (DASH or MPEG-DASH) standard.

[0035] Preferably, the bitstream comprises a Dynamic Adaptive Streaming over HTTP (DASH or MPEG-DASH) layer.

[0036] According to an aspect of the present disclosure, there is described a method of decoding the bitstream according to any aspects described herein, the method comprising: parsing the bitstream to detect the indication; and utilizing the detected indication to identify a type of supplementary technology and / or a scalable video codec used in the bitstream.

[0037] According to an aspect of the present disclosure, there is described a method of decoding a bitstream, the method comprising: parsing the bitstream to detect an indication in the bitstream, the indication indicating a type of a type of supplementary technology and / or a scalable video codec used in the bitstream; and utilizing the detected indication to identify the type of supplementary technology and / or scalable video codec used in the bitstream; more preferably wherein: the indication is in a transport layer of the bitstream; and / or the indication comprises a 2-bit unsigned integer field.

[0038] Preferably, the method comprises: identifying an indication of a scalable video codec used by the bitstream; and decoding the bitstream based on the indication; more preferably wherein: the indication is in a transport layer of the bitstream; and / or the indication comprises a 2-bit unsigned integer field.

[0039] Preferably, the method further comprises: separating a base codec bitstream and a supplementary scalable codec bitstream based on the detected indication; and extracting the supplementary scalable codec bitstream for further processing.

[0040] Preferably, the method further comprises: initiating a decoding instance for the base codec bitstream and a separate decoding instance for the scalable codec bitstream, based on the detected indication; and decoding the respective bitstreams in parallel or sequentially as required by the application.

[0041] According to an aspect of the present disclosure, there is described a transport layer signal for a bitstream, the transport layer signal comprising scalable codec information.

[0042] According to an aspect of the present disclosure, there is described transport layer signal for a bitstream, the transport layer signal comprising an indication that indicates a type of scalable video codec used in a bitstream associated with the transport layer signal.

[0043] Preferably, the transport layer signal further comprises one or more of: a specified transport stream structure; program and / or service metadata; service discovery and / or description; system time synchronization information; audio-video synchronization; forward error correction; interleaved data; packetized data; multiplexed data; and transport error indicators.

[0044] Preferably, the transport layer signal further comprises an indication of the scalable codec information.

[0045] Preferably, the transport layer signal further comprises a variable scalable_type_id.

[0046] Preferably, the variable scalable_type_id specifies a scalable video codec utilized for an asset of the signal, more preferably wherein the asset is a video asset.

[0047] According to an aspect of the present disclosure, there is described a bitstream, according to any aspects described herein, comprising the transport layer according to any aspects described herein.

[0048] According to an aspect of the present disclosure, there is described a method of generating a bitstream comprising a scalable video codec, the method comprising one or more of the following steps: determining a scalable video codec used within the bitstream; and signalling the scalable video codec within the bitstream. Preferably, the method comprises signalling the scalable video codec by including an indication in the bitstream, the indication indicating a type of the scalable video codec, preferably including the indication in a transport layer of the bitstream

[0049] Preferably, the method further comprises setting a scalable_type_id field in the bitstream based on the determined scalable codec.

[0050] Preferably, the method further comprises setting the scalable_type_id to one of one or more predetermined values to match the identified codec;

[0051] Preferably, the method further comprises signalling the scalable codec in a transport layer of the bitstream, preferably comprising including a scalable_type_id field and / or a codec code in a transport layer of the bitstream.

[0052] Preferably, the method further comprises embedding metadata in the bitstream.

[0053] Preferably, determining the scalable codec comprises identifying the presence of the scalable codec in an asset associated with the bitstream.

[0054] According to an aspect of the present disclosure, there is described a method for encoding a bitstream for transmission to a compatible receiver, the method comprising: including, within the bitstream, an indication of the presence of a supplementary technology in addition to a base codec; representing the indication as one or more bits or a variable whose value corresponds to the specific supplementary technology, more preferably, wherein: the supplementary technology is a scalable codec; and / or the one or more bits define a scalable_type_id field.

[0055] According to an aspect of the present disclosure, there is described a method for generating a bitstream comprising data for a base codec and a supplementary scalable codec, the method comprising: identifying the type of scalable codec to be transmitted alongside the base codec; embedding an indication of the scalable codec type within the bitstream in a predefined location or syntax element, preferably within a scalable_type_id field; and structuring the bitstream such that the indication facilitates separation of the base codec bitstream from the scalable codec bitstream at the receiver.

[0056] According to an aspect of the present disclosure, there is described a method for encoding a bitstream to ensure compatibility with scalable and base codec decoding at the receiver, the method comprising: generating an indication within the bitstream that signals the presence of a supplementary scalable codec technology; and associating the indication with respective decoding parameters, enabling the receiver to decode both the base codec and the supplementary codec appropriately.

[0057] Preferably, the method further comprises the step of: encoding the indication in one or more of: a flag comprising one or more bits, with each bit value corresponding to a predefined supplementary technology; or a variable to denote the type of scalable codec, more preferably wherein the variable is a scalable_type_id field.

[0058] Preferably, the method further comprises ensuring the indication is interpretable by a compatible receiver to initiate decoding instances of the respective codecs.

[0059] According to an aspect of the present disclosure, there is described a method of multiplexing bitstreams, the method being for creating a multiplexed bitstream comprising both a base codec and a supplementary scalable codec, the method comprising: encoding the base codec data and supplementary scalable codec data into separate bitstreams; embedding an indication of the supplementary scalable codec technology into the multiplexed bitstream; aligning the indication within the bitstream syntax to facilitate efficient separation, and decoding at the receiver.

[0060] According to an aspect of the present disclosure, there is described a video encoder for encoding a video comprising a scalable video codec, preferably wherein the encoder is arranged to perform the method of any preceding claim.

[0061] Preferably, the video encoder is arranged to perform operations comprising: determining a scalable video codec used within the bitstream; and signalling the scalable video codec within the bitstream

[0062] According to an aspect of the present disclosure, there is described a video decoder for decoding a video comprising a scalable video codec, preferably wherein the decoder is arranged to perform the method of any preceding claim.

[0063] Preferably, the video decoder is arranged to perform operations comprising: identifying an indication of a scalable video codec used by the bitstream; and decoding the bitstream based on the indication; more preferably wherein: the indication is in a transport layer of the bitstream; and / or the indication comprises a 2-bit unsigned integer field.

[0064] According to an aspect of the present disclosure, there is described a bitstream according to according to any aspects described herein, wherein the scalable video codec comprises a low complexity enhancement video codec (LCEVC).

[0065] Typically, the term scalable video codec (SVC) denotes a video compression standard that assists with encoding a single video stream into multiple layers, allowing the stream to be decoded at various quality levels, resolutions, and / or frame rates. Indicating a type of a scalable video codec may comprise indicating a type of an enhancement layer, where this enhancement layer can be combined with a base layer of the bitstream (the base layer being at a base quality) in order to generate a stream at a higher quality. For example, indicating the type may comprise indicating that the enhancement layer uses LCEVC. The base layer, that may use a separate base codec, may be signalled separately to the enhancement layer (and so separately to the signalling of the scalable video codec). In some embodiments, the indication indicates the presence of, and / or the type of, an enhancement codec used by the bitstream, the enhancement codec being used to encode one or more enhancement layers in the bitstream.

[0066] Signalling scalable video codec

[0067] The inventors have determined that it is advantageous to explicitly indicate the use and presence of a particular scalable video codec within a signal, particularly at a higher layer than the video stream signalling itself. This indication could include metadata at the transport layer to ensure that devices can correctly interpret, process, and optimize their operations based on the specific scalable codec being used.

[0068] For example:

[0069] Synchronization: Devices may need to synchronize multiple video layers (e.g., base and enhancement layers) using presentation timestamps. Error Protection: Different layers may require distinct error correction processes.

[0070] Multiplexing: Multiplexing schemes may vary depending on the scalable codec in use.

[0071] Embodiments of the invention thus provide a mechanism to signal the presence of scalable codecs explicitly, even within the transport layer. This contrasts with prior art approaches, which either ignore this need or rely on devices to infer the codec type.

[0072] We describe a bitstream that includes an explicit indication of the scalable video codec being used. This is implemented through the introduction of a variable scalable_type_id'.

[0073] Variable scalable_type_id'

[0074] The bitstream includes an n-bit (e.g. 2-bit) unsigned integer field named scalable_type_id'.

[0075] This field specifies the scalable profile or codec associated with the asset (e.g., video asset) in the bitstream. Possible values:

[0076] - '00': HEVC Scalable Main 10 Profile (SHVC).

[0077] 01 : MultiLayer VVC Main Profile.

[0078] - 10 : MPEG-5 LCEVC Main Profile.

[0079] 11 ': Reserved for future use.

[0080] The scalable_type_id' may reference values in a predefined table, allowing efficient codec identification.

[0081] Codec Code: An alternative or supplementary mechanism may include a 4-character code to distinguish scalable codecs:

[0082] Example codes: ' wc1 ' , ' wc2' , ' w!1 ' , ' wi2' .

[0083] Transport Layer Signal: we further describe a transport layer signal that incorporates the scalable codec information. This signal may comprise one or more of :

[0084] A specified transport stream structure.

[0085] P rog ra m a nd / o r se rvice metad ata .

[0086] Service discovery and description.

[0087] Audio-video synchronization.

[0088] System time synchronization.

[0089] Forward error correction.

[0090] Interleaving.

[0091] Packetized and multiplexed data.

[0092] - Transport error indicators.

[0093] The transport layer signal may explicitly include the variable scalable_type_id', allowing the transport mechanism to account for the unique properties of scalable codecs. For example:

[0094] Devices can optimize error correction processes specific to individual codec layers.

[0095] Multiplexing schemes can be tailored for efficient transmission of scalable codecs.

[0096] - Synchronization mechanisms can ensure smooth playback of base and enhancement layers. Method of Generating the Bitstream

[0097] The present disclosure provides a method for generating a bitstream with scalable codec signaling, the method may comprise one or more of the following steps: determining the Scalable Codec: Identify the presence of a scalable codec in the asset; setting the scalable_type_id': assigning the appropriate value to scalable_type_id' to match the identified codec; embedding Metadata in the Bitstream: including the scalable_type_id' and / or Codec code in the transport layer signal for downstream interpretation.

[0098] In a first embodiment, we describe a method for encoding a bitstream for transmission to a compatible receiver, the method comprising: including, within the bitstream, an indication of the presence of a supplementary technology in addition to a base codec; representing the indication as one or more bits or a variable, such as “scalable_type_id,” whose value corresponds to the specific supplementary technology.

[0099] In a second embodiment, we describe a method for generating a bitstream comprising data for a base codec and a supplementary scalable codec, the method comprising: identifying the type of scalable codec to be transmitted alongside the base codec; embedding an indication of the scalable codec type within the bitstream in a predefined location or syntax element; structuring the bitstream such that the indication facilitates separation of the base codec bitstream from the scalable codec bitstream at the receiver.

[0100] In a third embodiment, we describe a method for encoding a bitstream to ensure compatibility with scalable and base codec decoding at the receiver, the method comprising: generating an indication within the bitstream that signals the presence of a supplementary scalable codec technology; associating the indication with respective decoding parameters, enabling the receiver to decode both the base codec and the supplementary codec appropriately.

[0101] In a fourth embodiment, we describe a method of encoding further comprising: encoding the indication in one of the following forms: a flag composed of one or more bits, with each bit value corresponding to a predefined supplementary technology; or a variable, such as “scalable_type_id,” to denote the type of scalable codec. Additionally, ensuring the indication is interpretable by a compatible receiver to initiate decoding instances of the respective codecs.

[0102] In a fifth embodiment, we describe a method of multiplexing bitstreams, the method being for creating a multiplexed bitstream comprising both a base codec and a supplementary scalable codec, the method comprising: encoding the base codec data and supplementary scalable codec data into separate bitstreams; embedding an indication of the supplementary scalable codec technology into the multiplexed bitstream; aligning the indication within the bitstream syntax to facilitate efficient separation and decoding at the receiver.

[0103] In the present invention, we also describe a bitstream structure adapted to indicate to a compatible receiver the presence of a supplementary technology to that of a base codec, such as a scalable codec. The information can be used, for example, by a receiver to separate the base and scalable codec bitstreams and / or extract the scalable codec bitstream and / or to initiate appropriate decoding instances of the respective codecs.

[0104] The bitstream structure is adapted to include an indication of the presence of such a supplementary technology. The indication may take the form of a flag - for example, one or more bits whose values is associated with respective different technologies - or another suitable indication. In one embodiment, the indication is composed of the variable “scalable_type_id” as described above.

[0105] In the present invention, we describe a bitstream structure for use in a compatible receiver, the bitstream comprising: data encoded for a base codec; data encoded for at least one supplementary technology, such as a scalable codec; an indication embedded within the bitstream, the indication specifying the presence and type of the supplementary technology, wherein the indication is represented as: at least one flag comprising one or more bits, each bit value corresponding to a predefined supplementary technology; or a variable, such as “scalable_type_id,” with predefined values that denote respective supplementary technologies.

[0106] In the present invention, we describe a bitstream structure adapted for separation and decoding by a compatible receiver, the bitstream comprising: a first portion containing encoded data for a base codec; a second portion containing encoded data for a supplementary scalable codec; an embedded indication located in a predefined portion of the bitstream, the indication: enabling the receiverto distinguish between the base codec and the supplementary scalable codec bitstreams; facilitating the extraction of the supplementary scalable codec bitstream; triggering the initialization of separate decoding instances for the respective codecs.

[0107] In the present invention, we also describe methods of decoding the bitstream structure described above. In a first exemplary embodiment, we describe a method for decoding a bitstream in a compatible receiver, wherein the bitstream comprises a structure adapted to indicate the presence of a supplementary technology in addition to a base codec, the method comprising:

[0108] • Parsing the bitstream to detect an indication of the presence of the supplementary technology;

[0109] • Utilizing the detected indication to identify the type of supplementary technology, wherein the indication is represented as at least one flag or variable.

[0110] In a second embodiment, we describe a method for processing a bitstream in a compatible receiver, wherein the bitstream includes data for a base codec and a supplementary scalable codec, the method comprising:

[0111] • Detecting an indication within the bitstream signalling the presence of the supplementary scalable codec;

[0112] • Separating the base codec bitstream and the supplementary scalable codec bitstream based on the detected indication;

[0113] • Extracting the supplementary scalable codec bitstream for further processing.

[0114] In a third embodiment, we describe a method for initiating decoding processes in a compatible receiver, the method comprising:

[0115] • Parsing a received bitstream to identify an indication of the presence of a supplementary scalable codec technology;

[0116] • Initiating a decoding instance for the base codec and a separate decoding instance for the scalable codec, based on the detected indication;

[0117] • Decoding the respective bitstreams in parallel or sequentially as required by the application.

[0118] Advantages

[0119] Embodiments of the invention provide several key advantages:

[0120] Improved Device Compatibility: Devices can explicitly recognize and process scalable codecs without inference.

[0121] Enhanced Processing Efficiency: Metadata enables optimized handling of synchronization, error protection, and multiplexing for scalable codecs.

[0122] Backward Compatibility: The transport layer remains compatible with traditional single-layer codecs while supporting new scalable codecs. Flexibility for Future Codecs: Reserved values allow for easy integration of future scalable codec standards.

[0123] By explicitly signalling scalable codecs within the transport layer, embodiments of the invention address the growing demand for scalable video technologies and resolves limitations in traditional transport mechanisms.

[0124] In other words, traditionally, video codecs were single layered codecs. The transport layer signalling and other infrastructure was bult on this concept. However, as the move towards scalable video codecs gains more traction, transport mechanisms are found to be unsuitable for catering for the growing demand for (and deployment of) scalable codecs.

[0125] The inventors have determined that it is advantageous to indicate a use and / or presence of particular scalable codec within a signal. In particular, this indicate can be at a layer than is higher than a signalling of a video stream. This is because a presence of a scalable codec and / or of a particular scalable codec may have knock-on effects relating to the processing of the signal. The inventors have determined that it is therefore advantageous to signal such an indication in the transport layer (whereas a particular use of a single layer codec may not need to be indicated at this layer). This is because the presence of a scalable codec (rather than a single layer codec) may change the fundamental processing of the signal, even at the transport layer (for example, because processing multiple layers of video is different to processing a single layer of video). In particular, it may be advantageous for a device to have an indication of the exact scalable video codec associated with a signal when operating on presentation time stamps (e.g. to sync up multiple layers of video), to process error protection details (e.g. different layers may be associated with different error correction processes) , and multiplexing information (the multiplexing of scalable codec may be specific to that scalable codec. In general, it is necessary to know the precise scalable codec in order to decode properly.

[0126] We describe a bitstream comprising an indication of a scalable video codec.

[0127] The bitstream may comprise a variable ‘scalable_type_id’. The variable ‘scalable_type_id’ may comprise a 2- bit unsigned integer field. The variable ‘scalable_type_id’ may specify the scalable profile or codec utilized for an asset. Wherein the asset may be an asset associated (e.g. contained, liked to, and so forth) with the bitstream. The asset may be a video asset, in particular a compressed video asset, in particular compressed using an (indicated) scalable codec. The bitstream may comprise further assets such as audio assets. In general, a bitstream may be a compressed media asset, which is associated with an uncompressed media asset

[0128] The value of the variable ‘scalable_type_id’ may be in the range of 0 to 2, inclusive. The value 3 may be reserved. Each (e.g. non reserved) value of the variable ‘scalable_type_id’ may indicate a particular scalable codec, optionally by referencing values of a (e.g. predetermined) table. A value of ‘00’ may indicate that HEVC Scalable Main 10 Profile (SHVC’) is present. A value of ‘01 ’ may indicate that MultiLayer VVC Main Profile is present. A value of ‘10’ may indicate that MPEG-5 LCEVC Main Profile is present.

[0129] The bitstream may be a television broadcast bitstream.

[0130] In general therefore, the inventors have determined that an explicit signal of which scalable video codec is being used is advantageous, e.g. even at the transport layer. This is counter to the teachings of the art, which either ignores this, or requires that a device should infer a scalable video codec associated with the signal.

[0131] We thus describe a transport layer signal. The signal may have a specified transport stream structure. The signal may comprise program and / or service metadata. The signal may comprise service discovery and / or description. The signal may comprise audio-video synchronization. The signal may comprise system time synchronization information. The signal may comprise forward error correction. The signal may comprise interleaved data. The signal may comprise packetized data. The signal may comprise multiplexed data. The signal may comprise transport error indicators. The signal may comprise a variable scalable_type_id specifying a scalable profile or codec utilized for an asset of the signal. For example, the signal may be associated with the asset or the signal may comprise the asset. The asset may be a video asset. The variable scalable_type_id may have a value be in the range of 0 to 2, inclusive. The value 3 may be reserved, variable scalable_type_id may be a 2-bit unsigned integer field. A value of ‘00’ may indicate that HEVC Scalable Main 10 Profile (SHVC’) is present. A value of ‘01 ’ may indicate that MultiLayer VVC Main Profile is present. A value of ‘10’ may indicate that MPEG-5 LCEVC Main Profile is present.

[0132] We further describe a method of generating the bitstream. The method may comprise determining that a scalable codec is present. The method may comprise setting a value of the variable ‘scalable_type_id’ to match the determined scalable codec.

[0133] We further describe a bitstream comprising a Codec code (i.e. a 4 character code), distinguishing between ‘wc1 ’, ‘wc2’, ‘wi1 ’ or ‘wi2’.

[0134] We describe a method, system, and apparatus for signaling scalable video codecs within a transport layer. Traditional transport mechanisms, designed for single-layer video codecs, are inadequate for supporting scalable video codecs due to their unique requirements, such as multi-layer synchronization, differentiated error protection, and codec-specific multiplexing. Embodiments of the invention introduce an explicit indication of the scalable video codec within a bitstream. The presence of this indication in the transport layer enables optimized device processing, including synchronization of multiple video layers, application of layer-specific error correction, and codec-specific multiplexing. A method for generating such a bitstream is furtherdescribed, comprising determining the scalable codec and embedding the corresponding indicator in the transport signal. This approach improves compatibility, processing efficiency, and flexibility for scalable video technologies while maintaining backward compatibility with single-layer codecs.

[0135] Any feature in one aspect of the disclosure may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa.

[0136] Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

[0137] Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory.

[0138] It should also be appreciated that particular combinations of the various features described and defined in any aspects of the disclosure can be implemented and / or supplied and / or used independently.

[0139] The disclosure also provides a computer program and a computer program product comprising software code adapted, when executed on a data processing apparatus, to perform any of the methods described herein, including any or all of their component steps.

[0140] The disclosure also provides a computer program and a computer program product comprising software code which, when executed on a data processing apparatus, comprises any of the apparatus features described herein.

[0141] The disclosure also provides a computer program and a computer program product having an operating system which supports a computer program for carrying out any of the methods described herein and / or for embodying any of the apparatus features described herein.

[0142] The disclosure also provides a computer readable medium having stored thereon the computer program as aforesaid. The disclosure also provides a signal carrying the computer program as aforesaid, and a method of transmitting such a signal.

[0143] The disclosure extends to methods and / or apparatus substantially as herein described with reference to the accompanying drawings.

[0144] The disclosure will now be described, by way of example, with reference to the accompanying drawings.

[0145] Description of the Drawings

[0146] Figure 1 shows a bitstream comprising an indication of a scalable video codec used by the bitstream.

[0147] Figure 2 shows a decoder for receiving and / or reading the bitstream of Figure 1 .

[0148] Figure 3 shows an encoder for generating and / or encoding the bitstream of Figure 1 .

[0149] Figure 4 shows a method of decoding a bitstream.

[0150] Figure 5 shows a method of generating a bitstream.

[0151] Figure 6 corresponds to Figure 4.1 of the ATSC standard A / 331 :2024-04 and shows a conceptual model of an ATSC 3.0 system.

[0152] Figure 7 corresponds to Figure 5.1 of the ATSC standard A / 331 :2024-04 and shows the ATSC 3.0 receiver protocol stack.

[0153] Figure 8 corresponds to Figure 5.2 of the ATSC standard A / 331 :2024-04 and shows the relationship between SLT and SLS for MMT Signaling.

[0154] Figure 9 corresponds to Figure B.9.1 of Annex B of the ATSC standard A / 331 :2024-04 and shows scalable coding for a linear TV Service delivered by ROUTE.

[0155] Figure 10 corresponds to Figure B.9.2 of Annex B of the ATSC standard A / 331 :2024-04 and shows scalable coding supported by a Service delivered by MMTP.

[0156] Figure 11 corresponds to Figure B.10.1 of Annex B of the ATSC standard A / 331 :2024-04 and shows a ROUTE SLT delivery path.

[0157] Figure 12 corresponds to Figure B.11.1 of Annex B of the ATSC standard A / 331 :2024-04 and shows multiple SLTs.

[0158] Figure 13 corresponds to Figure B.12.1 of Annex B of the ATSC standard A / 331 :2024-04 and shows portions of a service delivered in multiple RF channels without channel bonding.

[0159] Description of the Preferred Embodiments

[0160] Bitstreams generally provide for the transfer of data in the form of bits (e.g. binary bits). Data, such as images or frames of a video, can be converted (and, e.g. ‘encoded’) into bits at an encoder. These bits can then be transmitted (or ‘streamed’) at a given ‘bit rate’ to a decoder, where they are decoded back into the original frames for display to a user. Typically, encoders and decoders work to a common standard called a codec so that the format of the data in the bitstream is known by each of the encoder and the decoder. This enables a decoder to interpret an incoming bitstream.

[0161] In common codecs, the bitstream is formed by compressing and encoding the data using the encoder in order to reduce the amount of data (bits) required to signal the data to the decoder, and thereby reduce the required bandwidth. This compression can be performed in different ways.

[0162] Much of the video content on the Internet is encoded using well-established single-layer video coding schemes such as H.264 (also known as MPEG-4 Part 10, Advanced Video Coding - MPEG-4 AVC). For example, this format is used for between 80-90% of online video content. In a single-layer approach, content is encoded by a single monolithic encoder architecture. The encoded content is then supplied to decoding devices as a single video stream that has a one-to-one relationship with available hardware and / or software video decoders, e.g. a single stream is received, parsed, and decoded by a single video decoder to output a reconstructed video signal.

[0163] Within this context, multi-layer video coding schemes have existed for a number of years but have experienced problems with widespread adoption. Multi-layer coding schemes include the Scalable Video Coding (SVC) extension to H.264, Scalable extensions to H.265 (MPEG-H Part 2 High Efficiency Video Coding - SHVC), and newer standards such as MPEG-5 Part 2 Low Complexity Enhancement Video Coding (LCEVC). While H.265 is a development of the coding framework used by H.264, LCEVC takes a different approach to scalable video. SVC and SHVC operate by creating different encoding layers and feeding each of these with a different spatial resolution. Each layer encodes the input according to a normal AVC or HEVC encoder with the possibility of leveraging information generated by lower encoding layers. LCEVC, on the other hand, generates one or more layers of enhancement residuals (e.g. one or more enhancement layers) as compared to a base encoding, where the base encoding may be of a lower spatial resolution.

[0164] In practice, encoding a video using LCEVC may comprise encoding a low-quality base layer using another codec, such as HEVC or VVC, and then providing one or more enhancement layers using the LCEVC codec. The base layer can then be combined with the enhancement layer to provide a high-quality output.

[0165] Video packets (e.g. containing video data for the base layer and / or video data for the enhancement layer) may be combined into a transport layer and / or a network abstraction layer (NAL) that can be efficiently transmitted over a network. A decoder may then decode the transport layer and / or the NAL in order to obtain the packets of video data.

[0166] The transport layer and / or the NAL may further contain information (such as parameter sets, video parameter sets (VPS), sequence parameter sets (SPS), picture parameter sets (PPS), etc.) that enable a decoder to interpret or decode the packets of video data. The present disclosure relates, in part, to variables that may be contained in such a transport layer or a network abstraction layer so provide information relating to the video data. This enables more efficient decoding of the video data when compared to implementations where this information can only be obtained by decoding the video packets.

[0167] In particular, the present disclosure considers a transport layer that comprises one or more of: a specified transport stream structure; program and / or service metadata; service discovery and / or description; system time synchronization information; audio-video synchronization; forward error correction; interleaved data; packetized data; multiplexed data; and transport error indicators.

[0168] The transport layer may be considered to be a higher layer (e.g. a higher layer of abstraction) than the layer of the video packets or the video stream. In this regard, a decoder is arranged to process or decode the transport layer in a first step in order to obtain the video packets and any other information contained in the transport layer. The decoder is then able to decode these video packets in a second step.

[0169] One reason for the slow adoption of multi-layer coding schemes has been the difficulty adapting existing and new encoders and decoders to process multi-layer encoded streams.

[0170] Some examples of hierarchical coding are set out in the SMPTE VC-6 standard, and the MPEG-5, Part-2, LCEVC standard (the specifications for both standards, including working drafts, being incorporated herein by reference). Additional descriptions of hierarchical coding may be found in one or more of U.S. Patent No. 8,977,065, filed on July 21 , 2011 , entitled “Inheritance in a tiered signal quality hierarchy,” the contents of which are hereby incorporated by reference in their entirety.

[0171] Furthermore, examples of multi-layer coding, and systems in which multi-layer coding may be used, are set out in the ATSC standard (the specification forthe standard, including working drafts, being incorporated herein by reference). In particular, the present disclosure considers modifications to the ATSC standards that were in place prior to 20 November 2024, e.g. the ATSC 3.0 standards A / 331 :2024-04 (issued 3 April 2024). These standards, and in particular A / 331 :2024-04, are incorporated herein by reference.

[0172] Context for certain aspects of the present disclosure is provided by the documents I) ISO / IEC: 23090- 3:2023 | Rec. ITU-T H.266 (9 / 2023), “Information technology — Coded representation of immersive media — Part 3: Versatile Video Coding,” Geneva, Switzerland and ii) ISO / IEC: 23094-2:2021 , “Information technology — General video coding — Part 2: Low complexity enhancement video coding” Geneva, Switzerland that are also incorporated by reference.

[0173] U.S. Patent No. 8,948,248, filed on July 21 , 2011 , entitled “Tiered signal decoding and signal reconstruction,” the contents of which are hereby incorporated by reference in their entirety; U.S. Patent No. 8,711 ,943, filed on July 21 , 2011 , entitled “Signal processing and tiered signal encoding,” the contents ofwhich are hereby incorporated by reference in their entirety; U.S. Patent No. 9,129,411 , filed on July 21 , 2011 , entitled “Upsampling in a tiered signal quality hierarchy,” the contents of which are hereby incorporated by reference in their entirety; and U.S. Patent No. 8,531 ,321 , filed on July 21 , 2011 , entitled “Signal processing and inheritance in a tiered signal quality hierarchy,” the contents of which are hereby incorporated by reference in their entirety.

[0174] Traditionally, video codecs have been single-layer codecs, and the associated transport layer signalling and infrastructure were designed to support this concept. However, with the growing adoption of scalable video codecs, existing transport mechanisms are increasingly unsuitable for addressing the unique requirements of scalable codecs.

[0175] The lack of widespread deployment or adoption of scalable codecs in the past meant that transport layers were not designed with these capabilities in mind. Consequently, there is a need for explicit signalling mechanisms to indicate the presence and type of a scalable video codec in a transport stream.

[0176] An exemplary signalling mechanism to indicate the presence and type of a scalable video codec in a bitstream, e.g. in an ATSC 3.0 bitstream, will now be described with reference to Figures 1-13.

[0177] Scalable Type ID

[0178] Figure 1 shows a schematic diagram of a bitstream 100 comprising an indication 110 of a scalable video codec used by the bitstream.

[0179] For ease of explanation, the bitstream 100 is shown as a block, but it will be understood that this block is representative of a series of binary bits received sequentially by a decoder, such that diagrammatically the bitstream will be received and / or read by a decoder from left to right.

[0180] The present disclosure extends to a transport layer for a bitstream, where the transport layer comprises the indication 110. The transport layer may also comprise one or more of: a specified transport stream structure; program and / or service metadata; service discovery and / or description; system time synchronization information; audio-video synchronization; forward error correction; interleaved data; packetized data; multiplexed data; and transport error indicators. The transport layer may comprise both the indication and video data (e.g. video packets) that can be decoded in order to generate a video. The indication may be provided separately to this video data so that the indication can be identified prior to the decoding of the video data.

[0181] Figure 2 shows a decoder 200 for receiving, parsing, and / or reading the bitstream 100 of Figure 1 (that comprises an indication of a scalable video codec). Typically, the bitstream 100 is arranged to be provided to a demultiplexer 210 that may comprise a transport layer decoder. The demultiplexer is arranged to identify a plurality of video packets or layers in the bitstream 100 (e.g. based on the indication) so that separate packets and / or layers can be transmitted to appropriate video decoders. In particular, a first portion of bits 220a representing frames of a video asset may be passed to video decoder A 230a, a second portion of bits 220b representing frames of a video asset may be passed to video decoder B 230b and, in some embodiments, a third portion of bits 220c representing frames of an audio asset may be passed to an audio decoder 230c. The video decoder A 230a decodes the first portion of bits 220a into a first video output 240a, e.g. into a base layer for a video, the video decoder b 230b decodes the second portion of bits 220b into a second video output 240b, e.g. into an enhancement layer for the video, and the audio decoder 230c decodes the third portion of bits 220c into audio output 240c. The outputs from each decoder may then be combined to generate a final video. Each decoder may equivalently be referred to herein as a decoding ‘instance’.

[0182] It will be appreciated that in some embodiments the demultiplexer could transmit certain video packets (e.g. the entire bitstream) to one or more of the decoders, e.g. to each video decoder, where these video decoders may then parse only certain sections of the bitstream, e.g. based on the indication. Such implementations can be used so that the same video packets are transmitted to multiple different video decoders (e.g. to a HEVC and an LCEVC decoder), with each decoder only decoding a type of information that can be decoded by that decoder.

[0183] The indication 110 disclosed herein allows the decoder 200 to determine the structure of the bits encoded in the bitstream 100 and adapt the decoding process based on the indication. The indication 110 is particularly advantageous when the incoming bitstream 100 comprises multiple layers (e.g. video layers). The decoder 200 can use the indication 100 to increase the efficiency of decoding the bitstream 100 by rapidly identifying a scalable video codec used for any enhancement layers.

[0184] For example:

[0185] Synchronization: Devices may need to synchronize multiple video layers (e.g., base and enhancement layers) using presentation timestamps.

[0186] Error Protection: Different layers may require distinct error correction processes.

[0187] Multiplexing: Multiplexing schemes may vary depending on the scalable codec in use.

[0188] Specifically, the decoder 200 may assign different layers of a bitstream to different decoders to parallelize the decoding process and thereby increase the speed of decoding. For example, a bitstream may comprise a base layer encoded using a base codec and an enhancement layer encoded with an enhancement codec. The indication 110 may allow the decoder 200 to pass the base layer to video decoder A 230a and to pass the enhancement layer to video encoder B 230b, where each video encoder 230a, 230b is optimised to decode the base and enhancement codec, respectively.

[0189] The bits of the bitstream 100 representing frames of a video or audio asset 220a, 220b, 220c may be signalled at a first layer of the bitstream 100. Typically, the indication 110 is signalled in an element of a second higher layer of the bitstream 100, preferably in a transport layer of the bitstream 100. As shown in Figure 2, the transport layer may be received and / or read by a decoder 200 priorto (e.g. before) processing the bits of the bitstream 100 representing frames of a video and / or audio asset. Accordingly, this may allow the decoder 200 to adapt the decoding process (e.g. of one or more video decoders) before beginning to decode any bits representing frames of a video asset, and thereby increase the optimisation of the decoding process.

[0190] Typically, the transport layer also comprises additional information, for example a specified transport stream structure; program and / or service metadata; service discovery and / or description; system time synchronization information; audio-video synchronization; forward error correction; interleaved data; packetized data; multiplexed data; and transport error indicators. Figure 3 shows an encoder 300 for generating and / or encoding the bitstream 100 of Figure 1 comprising an indication of a scalable video codec.

[0191] The encoder 300 comprises a plurality of video component video encoders 330a, 330b and, in some embodiments, an audio encoder 330c. The component video encoders are arranged to generate a base layer and one or more enhancement layers. These layers are sent to a multiplexer 110, which combines the layers to generate the bitstream. The encoder 300, e.g. the multiplexer 310, is arranged to generate the bitstream by including the indication 110 in the bitstream, where the indication indicates the presence, and typically the type, of a scalable video codec used in the bitstream. This may comprise including the indication in a transport layer of the bitstream so that it can be readily identified by the decoder 200, e.g. by the demultiplexer 210 of the decoder.

[0192] Each of the encoder and the decoder typically comprise, or are provided by, a computer device. Such a computer device typically comprises one or more of: a processor for processing instructions, a memory, e.g. for storing instructions, standards, and / or video codecs, and a communication interface for transmitting or receiving the bitstream.

[0193] A method of decoding a bitstream comprising an indication of a scalable video codec used by the bitstream is described below with reference to Figure 4.

[0194] More generally, the method of Figure 4 can be used to detect and determine a type of supplementary technology used in the bitstream (e.g. when the type of supplementary technology is not explicitly signalled elsewhere in the bitstream and / or in a transport layer of the bitstream).

[0195] This method is typically performed by a computer device that provides a decoder. In particular, the method may be performed by a computer device that is decoding a bitstream (that comprises bits representing at least one frame of a video).

[0196] In a first step 410, the computer device parses the bitstream to detect the indication.

[0197] In a second step 420, the computer device utilizes the detected indication to identify a type of supplementary technology and / or a scalable video codec used in the bitstream.

[0198] The method of decoding the bitstream may comprise separating a base codec bitstream and a supplementary scalable codec bitstream based on the detected indication; and extracting the supplementary scalable codec bitstream for further processing.

[0199] The method of decoding the bitstream may comprise initiating a decoding instance for the base codec bitstream and a separate decoding instance for the scalable codec bitstream, based on the detected indication; and decoding the respective bitstreams in parallel or sequentially (e.g. as required by an application).

[0200] A method of generating a bitstream comprising a scalable video codec is described below with reference to Figure 5.

[0201] More generally, the method of Figure 5 can be used to embed an indication of a scalable video codec in a bitstream (e.g. where otherwise the bitstream does not explicitly indicate and / or signal the scalable video signal).

[0202] This method is typically performed by a computer device. In particular, the method may be performed by a computer device that is generating and / or encoding a bitstream (that comprises bits representing at least one frame of a video).

[0203] In a first step 510, the computer device determines a scalable video codec used within the bitstream.

[0204] In a second step 420, the computer device signals the scalable video codec within the bitstream. The method of generating the bitstream may comprise including, within the bitstream, an indication of the presence of a supplementary technology (e.g. a scalable video codec) in addition to a base codec; representing the indication as one or more bits or a variable whose value corresponds to the specific supplementary technology.

[0205] The method of generating the bitstream may comprise: identifying the type of scalable codec to be transmitted alongside the base codec; and embedding an indication of the scalable codec type within the bitstream in a predefined location or syntax element, preferably within a scalable_type_id field; and structuring the bitstream such that the indication facilitates separation of the base codec bitstream from the scalable codec bitstream at the receiver.

[0206] The method of generating the bitstream may comprise: generating an indication within the bitstream that signals the presence of a supplementary scalable codec technology; and associating the indication with respective decoding parameters, enabling the receiver to decode both the base codec and the supplementary codec appropriately.

[0207] The method of generating the bitstream may comprise: encoding the indication in one or more of: a variable (or flag) comprising one or more bits, with each bit value corresponding to a predefined supplementary technology; or a variable to denote the type of scalable codec, preferably wherein the variable is a scalable_type_id field.

[0208] The method of generating the bitstream may comprise: ensuring the indication is interpretable by a compatible receiver to initiate decoding instances of the respective codecs.

[0209] The method of generating the bitstream may comprise creating a multiplexed bitstream comprising both a base codec and a supplementary scalable codec. The method may comprise: encoding the base codec data and supplementary scalable codec data into separate bitstreams; embedding an indication of the supplementary scalable codec technology into the multiplexed bitstream. The method may comprise aligning the indication within the bitstream syntax to facilitate efficient separation and decoding at the receiver.

[0210] Advanced Television Systems Committee (ATSC) Standard

[0211] A specific implementation of the indication disclosed herein, e.g. a scalable_type_ID variable, will now be described with reference to its use the ATSC standard. Excerpts of the ATSC standard A / 331 :2024-04 are copied below. As will be described below, the present disclosure considers modifications to this standard to include a scalable_type_id variable (or field) and / or to modify the codec_code field.

[0212] It will be appreciated that the features described with reference to this ATSC standard may also be applied to other standards and technologies and that the disclosures herein are not limited to ATSC implementations.

[0213] Introduction and Background

[0214] This standard specifies the technical mechanisms and procedures pertaining to Service signaling and IP-based delivery of a variety of ATSC 3.0 Services and contents to ATSC 3.0-capable receivers over broadcast, broadband and hybrid broadcast / broadband networks. The Service signaling functionality defines the data formats and information elements necessary to discover and acquire user Services. The IP-based delivery functionality specifies two application transport protocols forthe carriage of media content and Service signaling data over broadcast and / or broadband networks to receivers. The delivery functionality also includes mechanisms for the synchronization of Components delivered on the same or different transport networks, and application-layer forward error correction methods that enable error-free reception and consumption of media streams or discrete file objects. SYSTEM OVERVIEW

[0215] An overview of the signaling, delivery, synchronization, and Application-Layer FEC (AL-FEC) protocols specified in the ATSC 3.0 Standard is provided below, starting with a conceptual model of the system.

[0216] System Conceptual Model

[0217] A conceptual model of the system is shown in Figure 6, which corresponds to Figure 4.1 of the ATSC standard A / 331 :2024-04.

[0218] Two methods of broadcast Service delivery are specified in this Standard. The method depicted on the left side of Figure 4.1 of the ATSC standard A / 331 :2024-04 is based on Moving Picture Experts Group (MPEG) Media Transport (MMT), International Standards Organization (ISO) / International Electrotechnical Commission (IEC) 23008-1 and uses MMT protocol (MMTP) to deliver Media Processing Units (MPU). The method shown in the center is based on the Dynamic Adaptive Streaming over HTTP - Industry Forum (DASH-IF) profile, which is based on MPEG DASH. It uses Real-time Object delivery over Unidirectional Transport (ROUTE) protocol to deliver DASH Segments. Content not intended for rendering in real time as it is received, for example, a) a downloaded application, b) a file comprising continuous or discrete media and belonging to an app-based feature, c) a file containing Electronic Service Guide (ESG) or Emergency Alert (EA) information, ord) a file containing (opaque) data to be consumed by a Digital Rights Management (DRM) system client is also delivered by ROUTE. Signaling may be delivered over MMTP and / or ROUTE, while Bootstrap Signaling information is provided by the means of the Service List Table (SLT).

[0219] To support hybrid Service delivery, in which one or more program elements are delivered via the broadband path, the DASH-IF [profile over Hypertext Transfer Protocol (HTTP) / Transmission Control Protocol (TCP) / lnternet Protocol (IP) is used on the broadband side. Media files in the DASH-IF profile based on the ISO Base Media File Format (ISO BMFF) are used as the delivery, media encapsulation and synchronization format for both broadcast and broadband delivery.

[0220] Features

[0221] The protocols specified herein provide support for system features including:

[0222] • Real-time streaming of broadcast media (Broadcast Configuration).

[0223] • Efficient and robust delivery of file-based objects.

[0224] • Support for fast Service acquisition by receivers (fast channel change).

[0225] • Support for hybrid (broadcast / broadband) Services.

[0226] • Highly efficient Forward Error Correction (FEC).

[0227] • Compatibility within the broadcast infrastructure, with formats and delivery methods developed for (and in common use within) the Internet.

[0228] • Support for DRM, content encryption, and security.

[0229] • Support for Broadband Configuration.

[0230] • Signaling to support state-of-the-art audio and video codecs.

[0231] • Non-real-time delivery of media content.

[0232] • Non-multiplexed delivery of Service Components (e.g., video and audio in separate streams).

[0233] • Support for adaptive streaming on broadband-delivered streaming content.

[0234] • Appropriate linkage to application-layer features such as ESG and Interactive Content.

[0235] SERVICE SIGNALING OVERVIEW

[0236] Receiver Protocol Stack

[0237] ATSC 3.0 Services are delivered using three functional layers. These are the Physical layer, the Delivery layer and the Service Management layer. The Physical layer provides the mechanism by which signaling, Service announcement and IP packet streams are transported over the Broadcast Physical layer and / or Broadband Physical layer. The Delivery layer provides object and object flow transport functionality. It is enabled by the MPEG Media Transport Protocol (MMTP) as defined in “ISO / IEC: “Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 1 : MPEG media transport (MMT),” Doc. ISO / IEC 23008-1 :2017(E), International Organization for Standardization / International Electrotechnical Commission, Geneva, Switzerland” or the Real-Time Object Delivery over Unidirectional Transport (ROUTE) protocol as defined in the present document, operating on a UDP / IP multicast over the Broadcast Physical layer, and enabled by the HTTP protocol on a TCP / IP unicast over the Broadband Physical layer. The Service Management layer primarily supports the means for Service discovery and acquisition to enable different types of Services, such as linear TV and / or HTML5 application Service, to be carried by the underlying Delivery and Physical layers. Figure 7, which corresponds to Figure

[0238] 5.1 of the ATSC standard A / 331 :2024-04, shows the ATSC 3.0 receiver protocol stack.

[0239] Service Signaling provides Service discovery and description information, and comprises two functional elements: Bootstrap Signaling via the Service List Table (SLT) and Service Layer Signaling (SLS). These represent the information that is necessary to discover and acquire ATSC 3.0 Services. The SLT enables the receiverto build a basic Service list, and bootstrap the discovery of the SLS for each ATSC 3.0 Service.

[0240] The SLT can enable very rapid acquisition of basic Service information. The SLS enables the receiver to discover and access ATSC 3.0 Services and their Components. The relationship between SLT and SLS for ROUTE Signaling (for ROUTE / DASH Services) and the relationship between SLT and SLS for MMT Signaling (for Services using MMTP / MPU streaming) are shown in Figure 8, which corresponds to Figure

[0241] 5.2 of the ATSC standard A / 331 :2024-04.

[0242] For ROUTE / DASH Services delivered over broadcast, the SLS is carried either on a Signaling Server or by ROUTE / UDP / IP in one of the LCT transport channels comprising a ROUTE session, at a suitable carousel rate to support fast channel join and switching. For MMTP / MPU streaming delivered over broadcast, the SLS is carried by MMTP Signaling Messages, at a suitable carousel rate to support fast channel join and switching.

[0243] Various sections of the ATSC standard describe technologies that can be used with ATSC. For example:

[0244] DASH Media Presentation Description (MPD)

[0245] The DASH Media Presentation Description is an SLS metadata fragment corresponding to a linear Service of a given duration defined by the broadcaster (for example a single TV program, or a set of contiguous linear TV programs over a period of time). The contents of the MPD provide the resource identifiers for Segments and the context for the identified resources within the DASH Media Presentation. The data structure and semantics of the MPD shall be identical to the data structure and semantics of the DASH Media Presentation Description as defined in DASH-IF.

[0246] To ensure seamless playback across Period boundaries, ahead of the Period boundary an MPD must be provided which includes both the current Period and the next Period. The MPD describing the next Period must be provided at minimum some amount of time before the end of the current Period (i.e., the Period for which DASH Media Segments are currently being presented). The minimum timing is specified in DASH- IF profile.

[0247] In the context of ATSC 3.0 Services, an MPD delivered by an MMTP session shall only describe Representations delivered over broadband, e.g. in the case of a hybrid Service, or to support Service continuity in handoff from broadcast to broadband due to broadcast signal degradation (e.g. driving under a mountain or through a tunnel). MMTP-Specific Signaling Message

[0248] When MMTP sessions are used to carry an ATSC 3.0 streaming Service, MMTP-specific signaling messages specified in Clause 10 of ISO / IEC 23008-1 are delivered in binary format by MMTP packets according to Signaling Message Mode specified in subclause 9.3.4 of ISO / IEC 23008-1

[0038] . The value of the packetjd field of MMTP packets carrying Service Layer Signaling shall be set to 0x0000 except for MMTP packets carrying MMTP-specific signaling messages specific to an Asset, which shall be set to 0x0000 or to the same packetjd value as the MMTP packets carrying the Asset. Identifiers referencing the appropriate Package for each ATSC 3.0 Service are signaled by the USBD fragment as described in Table 7.8. MMT Package Table (MPT) messages with matching MMT_packageJd shall be delivered on the MMTP session signaled in the SLT. Each MMTP session carries MMTP-specific signaling messages specific to its session or each asset delivered by the MMTP session.

[0249] The following MMTP messages shall be delivered by the MMTP session signaled in the SLT:

[0250] • MMT Package Table (MPT) message: This message carries an MP (MMT Package) table which contains the list of all Assets and their location information as specified in subclause 10.3.4 of ISO / IEC 23008-1)

[0038] ,

[0251] • MMT ATSC3 (MA3) message mmt_atsc3_message0: This message carries system metadata specific for ATSC 3.0 Services including Service Layer Signaling as specified in Section 7.2.3.1 of the ATSC 3.0 standard A / 331 :2024-04.

[0252] The following MMTP messages shall be delivered by the MMTP session signaled in the SLT, if required:

[0253] • Media Presentation Information (MPI) message: This message carries an MPI table which contains the whole document or a subset of a document of presentation information. An MP table associated with the MPI table also can be delivered by this message (see subclause 10.3.3 of ISO / IEC 23008- 1).

[0254] The following MMTP messages shall be delivered by the MMTP session carrying an associated Asset, and the value of the packetjd field of MMTP packets carrying them shall be set to the same as the MMTP packets carrying the Asset:

[0255] • Hypothetical Receiver Buffer Model message: This message carries information required by the receiver to manage its buffer (see subclause 10.4.2 of ISO / IEC 23008-1);

[0256] • Hypothetical Receiver Buffer Model Removal message: This message carries information required by the receiver to manage its MMT de-capsulation buffer (see subclause 10.4.9 of ISO / IEC 23008- 1). mmt_atsc3_message() MMTP-Specific Signaling Message

[0257] An MMTP-specific signaling message mmt_atsc3_message0 is defined to deliver information specific to ATSC 3.0 Services. The value assigned to messagejd for the mmt_atsc3_message0 is in the “user private” range per subclause 10.7 of ISO / IEC 23008-1

[0038] . The syntax of this message shall be as provided in Table 1 , which corresponds to table 7.9 of the ATSC standard A / 331 :2024-04.

[0258] The semantics of each field in mmt_atsc3_message0 shall be as described in the text following Table 1 , which corresponds to Table 7.9 of the ATSC standard A / 331 :2024-04.

[0259] Table 1 message id - A 16-bit unsigned integer field that shall uniquely identify the mmt_atsc3_messageO- The value of this field shall be 0x8100. version - An 8-bit unsigned integer field that shall be incremented by 1 any time there is a change in the information carried in this message. When the version field reaches its maximum value of 255, its value shall wrap around to 0. length - A 32-bit unsigned integer field that shall provide the length of mmt_atsc3_message0 in bytes, counting from the beginning of the next field to the last byte of the mmt_atsc3_message0- service_id - A 16-bit unsigned integer field that shall associate the message payload with the Service identified in the servi ceid attribute given in the SLT. atsc3_message_content_type - A 16-bit unsigned integer field that shall uniquely identify the type of message content in the mmt_atsc3_message0 payload.

[0260] Table 2 atsc3_message_content_version - An 8-bit unsigned integer field that shall be incremented by 1 any time there is a change in the mmt_atsc3_message content identified by a servicejd, and atsc3_message_content_type pair and Uniform Resource Identifier (URI) if present. When the atsc3_message_content_version field reaches its maximum value, its value shall wrap around to 0. atsc3_message_content_compression - An 8-bit unsigned integer field coded per Table 7.11 of the ATSC standard A / 331 :2024-04, that shall identify the type of compression applied to the data in atsc3_message_content_byte.

[0261] Table 3

[0262] URIJength - An 8-bit unsigned integer field that shall provide the length of the URI uniquely identifying the message payload across Services. When the URI is not present, the value of this field shall be set to 0. When this mmt_atsc3_message0 carries an MPD (i.e. atsc3_message_content_type = 0x0002), the URI shall be present.

[0263] URI_byte - An 8-bit unsigned integer field that shall contain a UTF-8 character of the URI associated with the content carried by this message excluding the terminating null character, as per RFC 3986. This field, when present, shall be used to identify delivered message payloads. The URI can be used by system tables to reference tables made available by delivered message payloads. atsc3_message_content_length - A 32-bit unsigned integer field that shall provide the length of the content carried by this message. atsc3_message_content_byte - An 8-bit unsigned integer field that shall contain a byte of the content carried by this message.

[0264] Video Stream Properties Descriptor

[0265] Each video asset video_stream_properties_descriptor() provides information about its associated video stream. This includes information about resolution, chroma format, bit depth, temporal scalability, bit-rate, picture-rate, 3D, color characteristics, profile, tier, and level.

[0266] Syntax

[0267] The syntax for the video_stream_properties_descriptorO shall conform to Table 4, which corresponds to Table 7.12 of the ATSC standard A / 331 :2024-04. The semantics of the fields in the video_stream_properties_descriptorO shall be as given immediately below the table. asset_id_byte 8 uimsbf

[0268] } codec_code 4*8 uimsbf temporal_scalability_present 1 bslbf scalability_info_present 1 bslbf multiview_info_present 1 bslbf res_cf_bd_info_present 1 bslbf pr_info_present 1 bslbf br_info_present 1 bslbf color_info_present 1 bslbf reserved 1 ‘1 ’ if (temporal_scalability_present) { max_sub_layers_instream / * s * / 6 uimsbf sub_layer_profile_tier_level_info_present 1 bslbf temporal_filter_present 1 bslbf tid_max 3 uimsbf tid_min 3 uimsbf

[0269] If (temporal_filter_present) { tfweight 2 uimsbf

[0270] } else { reserved2 2 ‘11 ’

[0271] }

[0272] } if (scalability_info_present) { scalability_info() 8 Table 7.14 of the ATSC standard A / 331 :2024-04

[0273] } if (multiview_info_present) { multiview_info() 40 Table 7.16 of the ATSC standard A / 331 :2024-04

[0274] } if (res_cf_bd_info_present) { res_cf_bd_prop_info() 48

[0275] } if (pr_info_present) { if (sub_layer_profile_tier_level_info_present) { pr_info(max_sub_layers_instream-1) var

[0276] } else { pr_info(0) var

[0277] }

[0278] } if (br_info_present) { if (sub_layer_profile_tier_level_info_present) { br_info(max_sub_layers_instream-1) 32*(s-1)

[0279] } else { br_info(0) 32

[0280] }

[0281] } if (color_info_present) { color_info() var descriptor_tag - This 16-bit unsigned integer shall have the value 0x0005, identifying this descriptor as the video_stream_properties_descriptor(). descriptor ength - This 16-bit unsigned integer shall specify the length (in bytes) immediately following this field up to the end of this descriptor. number_of_assets -An 8-bit unsigned integer field that shall specify the number of video assets described by this descriptor. asset_id_length - This 32-bit unsigned integer field shall specify the length in bytes of the video asset id. asset_id_byte - An 8-bit unsigned integer field that shall contain a byte of the video asset id. codec_code - According to the present disclosure, this field shall specify a 4-character code for a codec. The value of these four characters shall be one of 'hev1 ', 'hev2', 'hvc1 ', 'hvc2', 'Ihv1 ', 'Ihe1 ', ‘wcT, ‘wc2’, ‘wi1 ’ or ‘wi2’. Semantic meaning for these codes may be as specified in ISO / IEC: “Information technology - Coding of audio-visual objects - Part 15: Carriage of network abstraction layer (NAL) unit structured video in ISO base media file format,” Doc. ISO / IEC 14496-15:202214 with Cor. 1 :2015, International Organization for Standardization / International Electrotechnical Commission, Geneva, Switzerland.

[0282] We note that in the ATSC standard A / 331 :2024-04, the codec_code is defined to specify a 4-character code for a codec. The value of these four characters shall be one of 'hev1 ', 'hev2', 'hvc1 ', 'hvc2', 'Ihv1 ' or 'Ihe1 ' with semantic meaning for these codes as specified in ISO / IEC 14496-15 as amended.

[0283] The present disclosure considers a codec_code that is further capable of signalling wcT, ‘wc2’, ‘wi1 ’ or ‘wi2’, where the inventors have identified that these values can be signalled without changing the type or format of the codec_code field.

[0284] It will be appreciated that various different codecs could be specified by the codec_code variable and that the codecs specified herein are exemplary.

[0285] Furthermore, it will be appreciated that the HEVC, VVC, LCEVC, etc. codecs may be updated and that the specific instances of the codecs provided here are merely exemplary.

[0286] In an embodiment, the present disclosure considers a codec code that is capable of signalling a VVC codec (that may be compatible with and / or defined by the ISO / IEC 14496-15 standard or by any other standard). temporal_scalability_present - This 1 -bit Boolean flag shall indicate, when set to ‘1 ’, that the elements max_sub_layers_present and sub_layer_profile_tier_level_info_present are present and temporal scalability is provided in the asset. When set to ‘O’, the flag shall indicate that the elements max_sub_layers_present and sub_layer_profile_tier_level_info_present are not present and temporal scalability is not provided in the asset. scalability_info_present - This 1 -bit Boolean flag shall indicate, when set to ‘1 ’, that the elements in the scalabilityJnfoO structure are present. When set to ‘O’, the flag shall indicate that the elements in the scalabilityJnfoO structure are not present. multiview_info_present - This 1 -bit Boolean flag shall indicate, when set to ‘1 ’, that the elements in the multiviewJnfoO structure are present. When set to ‘O’, the flag shall indicate that the elements in the multiviewJnfoO structure are not present. res_cf_bd_info_present - This 1 -bit Boolean flag shall indicate, when set to ‘1 ’, that the elements in the res_cf_bd_info() structure are present. When set to ‘O’, the flag shall indicate that the elements in the res_cf_bd_info() structure are not present. pr_info_present - This 1 -bit Boolean flag shall indicate, when set to ‘1 ’, that the elements in the prJnfoQ structure are present. When set to ‘O’, the flag shall indicate that the elements in the prJnfoQ structure are not present. br_info_present - This 1 -bit Boolean flag shall indicate, when set to ‘1 ’, that the elements in the brJnfoQ structure are present. When set to ‘O’, the flag shall indicate that the elements in the brJnfoQ structure are not present. color_info_present - This 1-bit Boolean flag shall indicate, when set to ‘1 ’, that the elements in the colorJnfoO structure are present. When set to ‘O’, the flag shall indicate that the elements in the colorJnfoO structure are not present. max_sub_layers_instream - This 6-bit unsigned integer shall specify the maximum number of temporal sub-layers that may be present in each Coded Video Sequence (CVS) in the asset. The value of max_sub_layers_instream shall be in the range of 1 to 7, inclusive. The values 0x00 and 0x08 to 0x3F are reserved. sub_layer_profile_tier_level_info_present - This 1-bit Boolean flag shall indicate, when set to ‘1 ’, that profile, tier, and level information is present for temporal sub-layers in the asset. When set to ‘O’, the flag shall indicate that the profile, tier, and level information is not present for temporal sub-layers in the asset. When not present sub_layer_profile_tier_level_info_present shall be inferred to be equal to 0. temporal_filter_present - This 1-bit Boolean flag shall indicate, when set to ‘1 ’, that the element tfweight is present and temporal filtering information is provided for the asset. When set to ‘O’, the flag shall indicate that the element tfweight is not present and temporal filtering information is not provided for the asset. tid_max - This 3-bit field shall indicate the maximum value of Temporalld (as defined in Rec. ITU-T H.265) of all access units for this video asset. tid_max shall be in the range of 0 to 6, inclusive. tid_max shall be greater than or equal to tid_min. The value 7 is reserved. tid_min - This 3-bit field shall indicate the minimum value of Temporalld (as defined in Rec. ITU-T H.265) of all access units for this video asset. tid_min shall be in the range of 0 to 6, inclusive. The value 7 is reserved. tfweight - This 2-bit unsigned integer field shall indicate the values of temporal filtering parameters temporal_filter_w1 and temporal_filter_w2 as shown in Table 7.13 of the ATSC standard A / 331 :2024-04. temporal_filter_w1 parameter shall indicate the weight of the temporally preceding temporal sub-layer 1 picture that contributes to the current temporal sub-layer 0 picture. The value of temporal_filter_w1 shall be as shown in Table 7.13 of the ATSC standard A / 331 :2024-04. temporal_filter_w2 parameter shall indicate the weight of the high frame rate picture (not provided in the raw stream) in the current temporal position that contributes to the current temporal sub-layer 0 picture. The value of temporal_filter_w2 shall be as shown in Table 7.13 of the ATSC standard A / 331 :2024-04.

[0287] Table 5

[0288] The value of temporal_filter_w1 plus temporal_filter_w2 shall equal 1 . profile_tier_level(profileFPResentFlag, maxSubLayersMinusI) - This variable-sized field shall provide the profile, tier, level syntax structure as described in H.265 (10 / 2014) HEVC specification Section 7.3.3.

[0289] Scalability Information

[0290] In relation to Scalability information, Table 6 below, which is Table 7.14, of the ATSC standard A / 331 :2024-04, indicates that:

[0291] Table 6

[0292] The ATSC standard A / 331 :2024-04 then defines: asset_layer_id - This 6-bit unsigned integer field shall specify the nuhjayerjd for this asset. The value of assetjayerjd shall be in the range of 0 to 62, inclusive. The value 63 is reserved.

[0293] The present disclosure has identified that the two reserved bits of the scalabilityJnfoQ variable of this ATSC standard can beneficially be used to signal scalability information. This does not require the addition of new variables to the standard and so provides an efficient, effective, and straightforward way to provide desirable scalability type information in an ATSC bitstream.

[0294] In particular, the present disclosure considers a modification to the Table 6 (Table 7.14 of the ATSC 3.0 Standard) and the surrounding passages to provide the novel Table 6A and the new parameter (or variable, or field) scalable_type_id that is defined below:

[0295] Table 6A assetjayerjd - This 6-bit unsigned integer field shall specify the nuhjayerjd for this asset. The value of assetjayerjd shall be in the range of 0 to 62, inclusive. The value 63 is reserved. scalablejypejd - This 2-bit unsigned integer field shall specify the scalable profile or codec utilized for this asset. The value of scalablejypejd shall be in the range of 0 to 2, inclusive. The value 3 is reserved.

[0296] It will be appreciated that in some embodiments different ranges of scalable ypejd may be used. For example, the scalable ypejd may be able to use values in the range of 0 to 1 , inclusive or in the range of O to 3, inclusive. For example, the value 3 that is presently reserved may be assigned to a further scalable video codec.

[0297] Typically, the scalable_type_id and the possible values of the scalable_type_id are defined in a standard or a codec that is known to a decoder that receives the bitstream. Therefore, the decoder can receive the bitstream and match a value of the scalable_type_id to a meaning of this value. Table 7 below shows a specific implementation of such a definition.

[0298] Table 7

[0299] It will be appreciated that Table 7 provides a specific implementation of this scalable_type_id variable and that various different implementations (and various potential codecs) may be signalled using the scalable_type_id variable.

[0300] In general, the scalable_type_id variable is useable to provide an indication that a scalable video codec is used within a bitstream and / or to indicate a type of a scalable video codec that is used within a bitstream.

[0301] Indicating HEVC Scalable Main 10 Profile (SHVC’) may indicate the standard defined in ISO / IEC: “Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 2: High Efficiency Video Coding,” Doc. ISO / IEC 23008 2:2015, International Organization for Standardization / International Electrotechnical Commission, Geneva, Switzerland.

[0302] Indicating may indicate the MultiLayer VVC Main Profile defined in

[0073] ISO / IEC: 23090-3:2023 | Rec. ITU- T H.266 (9 / 2023), “Information technology — Coded representation of immersive media — Part 3: Versatile Video Coding,” Geneva, Switzerland.

[0303] Indicating the MPEG-5 LCEVC Main Profile may indicate the MPEG-5 LCEVC Main Profile defined in ISO / IEC: 23094-2:2021 , “Information technology — General video coding — Part 2: Low complexity enhancement video coding” Geneva, Switzerland.

[0304] It will be appreciated that codecs, such as those indicated in Table 7 may be developed and updated so that the scalable_type_id may refer to codecs different to those defined in the documents indicated above (e.g. due to these codecs being updated).

[0305] Tables 6A and 7, and the information contained in these tables, are not present in the ATSC standards available at the priority date of this application. These tables, and this information, provide novel functionality that represents an improvement to prior ATSC standards (as well as other standards that can use scalable video technologies).

[0306] When the value of scalable_info_present is equal to 1 or the value of multiview_info_present is equal to 1 , the Dependency Descriptor specified in subclause 10.5.3 of MMT specification shall be included in MPT for each asset. In this case the num_dependencies element in MMT Dependency Descriptor shall indicate the number of layers that the assetjayerjd for this asset is dependent on. MultiView Information

[0307] Table 8 view_nuh_layer_id - This 6-bit unsigned integer field shall specify the nuhjayerjd for the view represented by this asset. The value of view_nuh_layer_id shall be in the range of 0 to 62, inclusive. The value 63 is reserved. view_pos - This 6-bit unsigned integer field shall specify the order of the view with nuhjayerjd equal to view_nuh_layer_id among all the views from left to right for the purpose of display, with the order for the left-most view being equal to 0 and the value of the order increasing by 1 for next view from left to right. The value of view_pos[ i ] shall be in the range of 0 to 62, inclusive. The value 63 is reserved.

[0308] Note: Multiple video assets having the same view_nuh_layer_id value can have different view_pos values. min_disp_with_offset - The value of this 11 -bit unsigned integer field minus 1024 shall specify the minimum disparity, in units of luma samples, between pictures of any spatially adjacent views among the applicable views in an access unit. The value of min_disp_with_offset shall be in the range of 0 to 2047, inclusive. max_disp_range - The value of this 11 -bit unsigned integer field shall specify the maximum disparity, in units of luma samples, between pictures of any spatially adjacent views among the applicable views in an access unit. The value of max_dispjange shall be in the range of 0 to 2047, inclusive.

[0309] SCALABLE CODING (CAPABILITY IN THE SLT)

[0310] According to the ATSC standard A / 331 :2024-04, receivers can do scalable coding using one Service delivery by ROUTE.

[0311] Figure 9, which corresponds to Figure B.9.1 of Annex B of the ATSC standard A / 331 :2024-04, shows Scalable coding for a linear TV Service delivered by ROUTE (capability in SLT).

[0312] 1) The SLT may include all capabilities that are essential to render the Service. In this example, the video resolution is the essential capability to decode the video, so the capability in the SLT will have the value ‘HD or UHD’ (as well as capabilities for other Components, such as audio or closed captions or perhaps applications). It means that this program will serve the HD or UHD Service now.

[0313] 2) Receivers can determine which Component can be presented to render a UHD Service or an HD Service by using the MPD.

[0314] The scalable coding can also be supported by a Service delivered by MMTP as illustrated in Annex B of the ATSC standard A / 331 :2024-04.

[0315] 1) The SLT may include all capabilities that are essential to render the Service. In this example, the video resolution is the essential capability to decode the video, so the capability in the SLT will have the value ‘HD or UHD’ (as well as capabilities for other Components, such as audio or closed captions or perhaps applications). It means that this program will serve the HD or UHD Service now.

[0316] 2) Receivers can know which Component will be presented to render UHD Service or HD Service by using the MP table.

[0317] SLT DELIVERY PATH

[0318] The PLP carrying the SLT can be used to deliver Service Components as well.

[0319] Figure 11 , which corresponds to Figure B.10.1 of Annex B of the ATSC standard A / 331 :2024-04, shows a ROUTE SLT delivery path.

[0320] MULTIPLE SLTs IN A BROADCAST STREAM

[0321] Multiple SLTs can be present in one broadcast stream.

[0322] Figure 12, which corresponds to Figure B.11.1 of Annex B of the ATSC standard A / 331 :2024-04, shows Multiple SLTs

[0323] PORTIONS OF A SERVICE DELIVERED IN MULTIPLE RF CHANNELS WITHOUT CHANNEL BONDING

[0324] The SLT.Service element associated with the essential portion of the Service has OtherBsid element which has the value of @type attribute equal to 2. The S-TSID describes LCT channels and ROUTE sessions for the Components delivered in the Broadcast Stream which delivers S-TSID itself.

[0325] Figure 13, which corresponds to Figure B.12.1 of Annex B of the ATSC standard A / 331 :2024-04, shows Portions of a Service delivered in multiple RF channels without channel bonding (first RF channel).

[0326] Alternatives and modifications

[0327] It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

[0328] For example, while the detailed description primarily considers video encoders and the ATSC standard, it will be appreciated that the indication disclosed herein may be used in various situations. For example, the indication may be used within various different video codecs or by various video encoders and decoders. Furthermore, the indication may be used in other situations where scalable or supplementary technologies are used. For example, the indication may be used within a bitstream that provides an audio output, where the indication may indicate a scalable audio codec used within such a bitstream.

[0329] Certain methods and encoder or decoder components as described herein may be performed by instructions that are stored upon a non-transitory computer readable medium. The non-transitory computer readable medium stores code comprising instructions that, if executed by one or more computers, would cause the computer to perform steps of methods or execute operations of encoder components as described herein. The non-transitory computer readable medium may comprise one or more of a rotating magnetic disk, a rotating optical disk, a flash random access memory (RAM) chip, and other mechanically moving or solid-state storage media. Some examples may be implemented as: physical devices such as semiconductor chips; hardware description language representations of the logical or functional behaviour of such devices; and one or more non-transitory computer readable media arranged to store such hardware description language representations. Descriptions herein reciting principles, aspects, and embodiments encompass both structural and functional equivalents thereof.

[0330] Patent and non-patent documents that are referenced herein are deemed to be incorporated by reference into the present document. Certain examples have been described herein and it will be noted that different combinations of different components from different examples may be possible. Salient features are presented to better explain examples; however, it is clear that certain features may be added, modified and / or omitted without modifying the functional aspects of these examples as described. Elements described herein as “coupled” or “communicatively coupled” have an effectual relationship realizable by a direct connection or indirect connection, which uses one or more other intervening elements. Examples described herein as “communicating” or “in communication with” another device, module, or elements include any form of communication or link. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims. Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

Claims1 . A bitstream comprising an indication of a type of scalable video codec used by the bitstream.

2. The bitstream of claim 1 , wherein the indication is present in a transport layer of the bitstream.

3. The bitstream of claim 1 or 2, wherein the value of the indication is capable of being within the range of O to 2, inclusive.

4. The bitstream of any preceding claim, wherein the indication comprises an n-bit unsigned integer field.

5. The bitstream of claim 4, wherein the n-bit unsigned integer field comprises a 2-bit unsigned integer field, preferably wherein the value of the 2-bit unsigned integer field is capable of signalling a value of or more of: 00, 01 , 10 or 11 , more preferably wherein the value of the 2-bit unsigned integer field is capable of signalling a value of: 00, 01 , or 10.

6. A bitstream comprising a 2-bit unsigned integer field in a transport layer of the bitstream, wherein the 2-bit unsigned integer field indicates a type of a scalable video codec used by the bitstream, preferably by video packets of the bitstream.

7. The bitstream of any preceding claim, wherein the indication comprises a variable field defined in the bitstream.

8. The bitstream of any preceding claim, wherein the indication comprises a variable scalable Jype_id.

9. The bitstream of any preceding claim, being a bitstream that is for, and / or compliant with, an Advanced Television Systems Committee (ATSC) standard, preferably an ATSC 3.0 standard.

10. The bitstream of any preceding claim, comprising a scalabilityjnfo field, wherein the scalabilityjnfo field comprises the indication; preferably, wherein the scalabilityjnfo field further comprises an assetjayerjd field, more preferably wherein the scalabilityjnfo field consists of the assetjayerjd field and the indication.11 . The bitstream of any preceding claim, wherein the scalable video codec is associated with an asset in the bitstream, preferably wherein the asset is a video asset, more preferably wherein the video asset is a compressed video asset, yet more preferably wherein the video asset is compressed at least in part using the specified scalable codec.

12. The bitstream of any preceding claim, wherein the indication is capable of being one of a plurality of possible, values, preferably: wherein each possible value of the indication indicates a different scalable video codec; and / or wherein the indication comprises a reference to one of a plurality of possible values, preferably wherein the possible values are defined in a predefined table.

13. The bitstream of any preceding claim, wherein the indication is capable of indicating and / or is arranged to indicate and / or indicates that the bitstream uses one or more of:HEVC scalable main 10 Profile (SHVC), preferably wherein the indication having a value of 00 indicates the HEVC scalable main 10 Profile (SHVC);Multilayer VVC main Profile, preferably wherein the indication having a value of 01 indicates the Multilayer VVC main Profile; andMPEG-5 LCEVC Main Profile, preferably wherein the indication having a value of 10 indicates the MPEG-5 LCEVC Main Profile.

14. The bitstream of any preceding claim, wherein the bitstream is a television broadcast bitstream.

15. A bitstream adapted to indicate to a compatible receiver the presence of, and type of, a supplementary technology, preferably a scalable video codec, and a base codec.

16. The bitstream of any preceding claim, wherein the type of the scalable video codec is indicated at a higher layer of signalling than a video stream signalled in the bitstream.

17. The bitstream of any preceding claim, further comprising: data encoded for a / the base codec; data encoded for a / the at least one supplementary technology, preferably a scalable video codec; an indication embedded within the bitstream, the indication specifying the presence and type of the supplementary technology, preferably wherein the indication is represented as: at least one flag comprising one or more bits, each bit value corresponding to a predefined supplementary technology; and / or a variable that has a value that is one of a plurality of predefined values that denote respective supplementary technologies, preferably wherein the variable is a scalable_type_id variable.

18. The bitstream of claim 17, wherein the bitstream is adapted for separation and decoding by a compatible receiver, the bitstream comprising: a first portion containing data encoded for a base codec; a second portion containing data encoded for at least one supplementary scalable video codec.

19. The bitstream of any preceding claim, wherein the indication is embedded within the bitstream in a predefined portion of the bitstream, the indication: enabling the receiver to identify the scalable video codec, preferably enabling the receiver to distinguish between portions ofthe bitstream relating to a / the base codec in the bitstream and portions of the video relating to the supplementary scalable video codec; and / or facilitating the extraction of the supplementary scalable codec portions; and / or triggering the initialization of separate decoding instances for the respective supplementary scalable codec portions.

20. The bitstream of any preceding claim, wherein the scalable video codec comprises a low complexity enhancement video codec, LCEVC.21 . A transport layer signal for a bitstream, the transport layer signal comprising an indication that indicates a type of scalable video codec used in a bitstream associated with the transport layer signal.

22. The transport layer signal of claim 21 , further comprising one or more of: a specified transport stream structure; program and / or service metadata; service discovery and / or description; system time synchronization information;audio-video synchronization; forward error correction; interleaved data; packetized data; multiplexed data; and transport error indicators.

23. A bitstream according to any of claims 1 to 20 comprising the transport layer of claim 21 or 22.

24. A method of decoding the bitstream of any of claims 1 to 20 or 23, the method comprising: parsing the bitstream to detect the indication; and utilizing the detected indication to identify a type of supplementary technology and / or a scalable video codec used in the bitstream.

25. A method of decoding a bitstream, the method comprising: parsing the bitstream to detect an indication in the bitstream, the indication indicating a type of a type of supplementary technology and / or a scalable video codec used in the bitstream; and utilizing the detected indication to identify the type of supplementary technology and / or scalable video codec used in the bitstream; preferably wherein: the indication is in a transport layer of the bitstream; and / or the value of the indication is capable of being within the range of 0 to 2, inclusive.

26. A method of decoding a bitstream, the method comprising: identifying an indication of a scalable video codec used by the bitstream; and decoding the bitstream based on the indication; preferably wherein: the indication is in a transport layer of the bitstream; and / or the indication comprises a 2-bit unsigned integer field.

27. The method of any of claims 24 to 26, the method further comprising: separating a base codec bitstream and a supplementary scalable codec bitstream based on the detected indication; and extracting the supplementary scalable codec bitstream for further processing.

28. The method of claim 27, the method further comprising: initiating a decoding instance for the base codec bitstream and a separate decoding instance for the scalable codec bitstream, based on the detected indication; and decoding the respective bitstreams in parallel or sequentially.

29. A method of generating a bitstream comprising a scalable video codec, the method comprising one or more of the following steps: determining a scalable video codec used within the bitstream; and signalling the scalable video codec within the bitstream, preferably signalling the scalable video codec by including an indication in the bitstream, the indication indicating a type of the scalable video codec, more preferably including the indication in a transport layer of the bitstream.

30. The method of claim 29, comprising setting a scalable_type_id field in the bitstream based on the determined scalable codec, preferably comprising setting the scalable_type_id to one of one or more predetermined values to match the identified codec;31 . A method for encoding a bitstream for transmission to a compatible receiver, the method comprising: including, within the bitstream, an indication of the presence of a supplementary technology in addition to a base codec; representing the indication as one or more bits or a variable whose value corresponds to the specific supplementary technology, preferably, wherein: the supplementary technology is a scalable codec; and / or the one or more bits define a scalable_type_id field.

32. A method for generating a bitstream comprising data for a base codec and a supplementary scalable codec, the method comprising: identifying the type of scalable codec to be transmitted alongside the base codec; embedding an indication of the scalable codec type within the bitstream in a predefined location or syntax element, preferably within a scalable_type_id field; and preferably, structuring the bitstream such that the indication facilitates separation of the base codec bitstream from the scalable codec bitstream at the receiver.

33. A method for encoding a bitstream to ensure compatibility with scalable and base codec decoding at the receiver, the method comprising: generating an indication within the bitstream that signals the presence of a supplementary scalable codec technology; and associating the indication with respective decoding parameters, enabling the receiver to decode both the base codec and the supplementary codec appropriately; preferably, further comprising the step of: encoding the indication in one or more of: a flag comprising one or more bits, with each bit value corresponding to a predefined supplementary technology; or a variable to denote the type of scalable codec, preferably wherein the variable is a scalable_type_id field.

34. A method of multiplexing bitstreams, the method being for creating a multiplexed bitstream comprising both a base codec and a supplementary scalable codec, the method comprising: encoding the base codec data and supplementary scalable codec data into separate bitstreams; embedding an indication of the supplementary scalable codec technology into the multiplexed bitstream; aligning the indication within the bitstream syntax (e.g. to facilitate efficient separation, and decoding at the receiver).

35. A computer program product comprising software code that, when executed on a computer device, causes the computer device to perform the method of any of claims 24 to 34.

36. A machine-readable storage medium that includes instructions that, when executed by one or more processors of a machine, cause the machine to perform the method of any of claims 24 to 34.

37. A video decoder for decoding a video comprising a scalable video codec, preferably wherein the decoder is arranged to decode the bitstream of any of claims 1 to 20 or 23 or to perform the method of any of claims 24 to 28.

38. The video decoder of claim 37, being arranged to perform operations comprising: identifying an indication of a scalable video codec used by the bitstream; and decoding the bitstream based on the indication; preferably wherein: the indication is in a transport layer of the bitstream; and / or the indication comprises a 2-bit unsigned integer field.

39. A video encoder for encoding a video comprising a scalable video codec, preferably wherein the encoder is arranged to encode the bitstream of any of claims 1 to 20 or 23 or to perform the method of any of claims 29 to 34.

40. The video encoder of claim 39, being arranged to perform operations comprising: determining a scalable video codec used within the bitstream; and signalling the scalable video codec within the bitstream.

Images