Methods, apparatus, and programs for AAC bitstream authentication

Abstract

The disclosure relates to methods of generating or modifying a bitstream comprising a plurality of data units (e.g., data packets or bitstream elements). These methods comprise providing (e.g., generating, or embedding into the bitstream) a first data unit and a second data unit. This is done in such manner that the first data unit and the second data unit are separated in the bitstream by one or more intermediate data units, among them data units for which verification / authentication shall be provided. To this end, the second bitstream element includes verification information for a subset of intermediate data units among the one or more intermediate data units. The disclosure further relates to methods of decoding such bitstream, as well as corresponding apparatus, programs, and computer-readable storage media.

Description

[0001] D24051AW001

[0002] METHODS, APPARATUS, AND PROGRAMS FOR AAC BITSTREAM AUTHENTICATION

[0003] Cross-Reference to Related Applications

[0004] This application claims the benefit of priority from U.S. Provisional Application Ser. No. 63 / 687,111, filed on 26 August 2024, European Patent Application 24216034.9, filed on 28 November 2024, and U.S. Provisional Application Ser. No. 63 / 743,510, filed on 9 January 2025, which are incorporated by reference herein in their entirety.

[0005] Technical Field

[0006] The present disclosure relates to techniques for authentication of bitstreams (e.g., packet-based or element-based bitstreams, such as media bitstreams). In particular, the present disclosure relates to authentication of MPEG-H audio, MPEG-D or MPEG-4 audio (e.g., HE- AAC, AAC- LC, USAC, etc.) bitstreams, or H.BWC bitstreams.

[0007] Relevant Standardization Documents

[0008] “MPEG-H” mentioned throughout the disclosure is defined by ISO / IEC 23008-3 and its amendments (current version ISO / IEC 23008-3:2022).

[0009] “MPEG-4” mentioned throughout the disclosure is defined by ISO / IEC 14496-3 and its amendments (current version ISO / IEC 14496-3:2019).

[0010] “USAC” mentioned throughout the disclosure is defined by ISO / IEC 23003-3 and its amendments (current version ISO / IEC 23003-3:2020).

[0011] “H.BWC” mentioned throughout the disclosure is defined by ITU-T H.BWC and its amendments, and by ISO / IEC 23003-8, Biomedical and general waveform signal coding and its amendments. The International Organization for Standardization (ISO) is an independent, nongovernmental international organization that develops and publishes international standards to ensure quality, safety, efficiency, and interoperability across industries and technologies. D24051AW001

[0012] The International Telecommunication Union (ITU) is an independent, non-governmental international organization that develops and publishes international standards to ensure quality, safety, efficiency, and interoperability across industries and technologies.

[0013] The International Electrotechnical Commission (IEC) is a global organization that prepares and publishes international standards for electrical, electronic, and related technologies.

[0014] Background

[0015] Currently, media bitstreams do not offer for authentication or verification of the media content or parts thereof. In particular, MPEG-H, MPEG-4, USAC, as well as H.BWC currently do not define the possibility to encapsulate information related to media authenticity (and provenance) into the bitstream.

[0016] There is thus need for techniques for allowing authentication (verification) of media content transported by bitstreams, for example at the decoder side.

[0017] Summary

[0018] In view of this need, the present disclosure provides methods of generating or modifying bitstreams (e.g., packet-based or element-based bitstreams), as well as corresponding apparatus, computer programs, and computer-readable storage media, having the features of respective independent claims.

[0019] One aspect of the present disclosure relates to a method of generating or modifying an audio bitstream including a plurality of bitstream elements. The bitstream may be a media bitstream, for example. In particular, the packet-based audio bitstream may be an AAC bitstream. The method may include providing a first bitstream element and a second bitstream element. This may be done such that the first bitstream element and the second bitstream element are separated in the bitstream by one or more intermediate bitstream elements. Providing bitstream elements may relate to generating said bitstream elements, and / or inserting said bitstream elements into the bitstream (e.g., a pre-existing bitstream in case of modification of said bitstream). In any case, the bitstream may include the first bitstream element and the second bitstream element. The first bitstream element may serve as an indication that the bitstream includes the subset of D24051AW001 intermediate bitstream elements after the first bitstream element and before the second bitstream element. Further, the second bitstream element may include verification information for a subset of intermediate bitstream elements among the one or more intermediate bitstream elements. The verification information may relate to an authentication signature, for example. Specifically, the verification information may comprise the authentication signature. The one or more intermediate bitstream elements may also include one or more fill elements, wherein the fill elements may not be included in the subset of intermediate bitstream elements, i.e., are not subject to verification / authentication.

[0020] Configured as described above, the proposed method allows for efficient authentication (verification) of media content (or any content in general) that is transported in an element-based audio bitstream. By defining the first and second bitstream elements, this can be done in a manner that does not affect the to-be- verified bitstream elements.

[0021] In some embodiments, the method may further include embedding information identifying the subset of intermediate bitstream elements into the first bitstream element or into another bitstream element that is in a fixed order relationship to the first bitstream element in the bitstream.

[0022] In some embodiments, the information identifying the subset of intermediate bitstream elements may include a list of bitstream element types. Further, the information identifying the subset of intermediate bitstream elements may include a syntax elements indicating whether or not bitstream element types in the list of bitstream element types shall be included into the one or more intermediate bitstream elements.

[0023] In some embodiments, the method may further include applying a hashing algorithm to the subset of intermediate bitstream elements to generate a hash value. The method may further include generating an authentication signature based on the hash value and an encryption key. Therein, the verification information may relate to the authentication signature. The method may yet further include embedding the verification information into the second bitstream element.

[0024] In some embodiments, the method may further include embedding, into the first bitstream element, one or more of information identifying the hashing algorithm, information identifying the encryption key, and / or information identifying an authentication authority in relation to the encryption key. D24051AW001

[0025] In some embodiments, the encryption key may be a private key of a private -public key pair. Alternatively, the encryption key may be identical to a decryption key, and may be exchanged in an appropriate manner between the encoder side and the decoder side before decoding.

[0026] In some embodiments, the information identifying the authentication authority in relation to the encryption key may include a Uniform Resource Identifier, URI, as defined in IETF RFC 3986.

[0027] In some embodiments, the method may further include embedding authentication identification information into the first bitstream element and / or into the second bitstream element. The authentication identification information may identify a combination of the information identifying the hashing algorithm, the information identifying the encryption key and the information identifying the authentication authority in relation to the encryption key.

[0028] In some embodiments, the first bitstream element and the second bitstream element may each include pairing information for indicating that the second bitstream element includes the verification information for the subset of intermediate bitstream elements between the first bitstream element and the second bitstream element. In this case, the one or more intermediate bitstream elements may include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding the first bitstream element. The further second bitstream element may include pairing information different from the pairing information of the first and second bitstream elements. The further second bitstream element may be among the subset of intermediate bitstream elements, so that the second bitstream element includes verification information also for the further second bitstream element.

[0029] With this, providing the pairing information allows to distinguish between different overlapping pairs of first and second bitstream elements, and thereby, to apply chained authentication for extended portions of the bitstream.

[0030] In some embodiments, the method may further include providing a third bitstream element and a fourth bitstream element. The third bitstream element and the fourth bitstream element may be separated in the bitstream by one or more second intermediate bitstream elements. Further, the fourth bitstream element may include second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements. The method may yet further include embedding information identifying subset of second intermediate bitstream elements into the third bitstream element or into another bitstream D24051AW001 element that is in a fixed order relationship to the third bitstream element in the bitstream. Therein, the one or more intermediate bitstream elements and the one or more second intermediate bitstream elements may be at least partially overlapping. The first and second bitstream elements may include matching pairing information, and the third and fourth bitstream elements may include matching pairing information, wherein the pairing information of the first and second bitstream elements is different from the pairing information of the third and fourth bitstream elements.

[0031] In some embodiments, the intermediate bitstream elements may include one or more of a single channel element, SCE, a channel pair element, CPE, and a low frequency element, LFE.

[0032] In some embodiments, the verification information may relate to a portion of an authentication signature. Then, the second bitstream element may include verification splitting information indicative of a relationship between the portion of the authentication signature and the complete authentication signature. For example, the verification splitting information may indicate storage locations of remaining / complementary portions of the authentication signature in the bitstream.

[0033] In some embodiments, the verification splitting information may include one or more of an indication that the portion of the authentication signature relates to a first segment of the authentication signature, an indication that the portion of the authentication signature relates to a last segment of the authentication signature, and an indication of a length of the portion of the authentication signature.

[0034] With this, the proposed method allows to avoid bitrate peaks that may otherwise occur of large authentication signatures are transported in a single bitstream element.

[0035] In some embodiments, the first bitstream element and the second bitstream element may be of a same bitstream element type. Further, the first bitstream element and the second bitstream element may differ in a set value of a predefined parameter or bit field. The first and second bitstream elements may be data bitstream elements (DSEs), in particular of type authentication_extension. The predefined parameter or bit field may relate to a 2-bit auth_element_type syntax element. Alternatively, the first and second bitstream elements may be USAC extension elements, in particular of type authentication_extension(). D24051AW001

[0036] In some embodiments, the subset of intermediate bitstream elements may include a bitstream element that contains timestamp information. The timestamp information may be indicative of, for example, a number (count) of seconds that have elapsed after a predefined point in time. The timestamp information may be indicative of a point in time at which the bitstream has been generated or last modified, for example.

[0037] In some embodiments, one or more of the intermediate bitstream elements (or of the subset of intermediate bitstream elements) may include authorization information. The authorization information may indicate an access restriction to (payload) data included in one or more of the remaining intermediate bitstream elements (or of the subset of intermediate bitstream elements) and / or indicative of a group of authorized recipients of the payload data. Depending on authorization values included in the authorization information, further operation to extract information from the remaining intermediate bitstream elements may be prevented. Alternatively, the authorization values may indicate an intended target audience that the content is targeting, or a group of intended / authorized recipients. The authorization values may be set by content creators or service providers, for example.

[0038] In some embodiments, the subset of intermediate bitstream elements may include a bitstream element that contains geolocation information. The geolocation information may be indicative of a geolocation at which the bitstream has been generated or last modified, for example.

[0039] In some embodiments, the subset of intermediate bitstream elements may include a bitstream element that contains identification information indicative of a Universally Unique Identifier, UUID. The UUID may be an identifier of a device or user that has generated (or modified) the bitstream, for example.

[0040] In some embodiments, the subset of intermediate bitstream elements may include a bitstream element that contains identification information indicative of a portion of a UUID and that further contains identification splitting-information indicative of a relationship between the portion of the UUID and the complete UUID. The portion of the UUID may be a segment of the UUID, for example.

[0041] In some embodiments, the identification splitting information may include one or more of an indication that the portion of the UUID relates to a first segment of the UUID, an indication that D24051AW001 the portion of the UUID relates to a last segment of the UUID, and an indication of a length of the portion of the UUID.

[0042] With this, the proposed method allows to avoid bitrate peaks that may otherwise occur of large authentication signatures are transported in a single bitstream element.

[0043] In some embodiments, the bitstream may be is an MPEG-4 bitstream.

[0044] In some embodiments, the first bitstream element may be subsequent in the bitstream to a configuration element that includes reference information referencing one or more bitstream elements among the intermediate bitstream elements as the subset of bitstream elements. Here, subsequent may be understood to mean immediately subsequent.

[0045] In some embodiments, each bitstream element of the bitstream may include an element tag. Element tags of the first bitstream element and the configuration element may be identical. The element tag may be an element instance tag (element_instance_tag), for example.

[0046] In some embodiments, the method may further include providing a third bitstream element and a fourth bitstream element. The third bitstream element and the fourth bitstream element may be separated in the bitstream by one or more second intermediate bitstream elements. Further, the fourth bitstream element may include second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements. The third bitstream element may be subsequent in the bitstream to a second configuration element that includes reference information referencing one or more bitstream elements among the second intermediate bitstream elements as the subset of second bitstream elements.

[0047] In some embodiments, element tags of the third bitstream element and the second configuration element may be identical to each other, and may be different from the element tags of the first bitstream element and the second bitstream element.

[0048] In some embodiments, the first bitstream element and the second bitstream element may each include pairing information for indicating that the second bitstream element includes the verification information for the subset of intermediate bitstream elements referenced by the configuration element preceding the first bitstream element. Then, the one or more intermediate bitstream elements may include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding said configuration D24051AW001 element. This further second bitstream element may include pairing information different from the pairing information of the first and second bitstream elements. The further second bitstream element may be among the subset of intermediate bitstream elements, so that the second bitstream element includes verification information also for the further second bitstream element.

[0049] With this, providing the pairing information allows to distinguish between different overlapping pairs of first and second bitstream elements, and thereby, to apply chained authentication for extended portions of the bitstream.

[0050] In some embodiments, the configuration element may be a program configuration element (PCE).

[0051] In some embodiments, the bitstream may be an AAC bitstream. For example, the bitstream may be one of a Low Complexity Advanced Audio Coding, AAC-LC, bitstream or a High Efficiency Advanced Audio Coding, HE- AAC, bitstream.

[0052] In some embodiments, the subset of intermediate bitstream elements may include all intermediate bitstream elements between the first bitstream element and the second bitstream element that are of a predetermined bitstream element type.

[0053] In some embodiments, the bitstream may include configuration information defining bitstream element types that shall be included into the subset of intermediate bitstream elements, he configuration information may be included in the first bitstream element, for example.

[0054] In some embodiments, the bitstream may be a Unified Speech and Audio Coding, USAC, bitstream.

[0055] Another aspect of the present disclosure relates to a method of decoding a bitstream comprising a plurality of bitstream elements. The method may include decoding, from the bitstream, a first bitstream element and a second bitstream element, and one or more intermediate bitstream elements separating the first bitstream element and the second bitstream element in the bitstream. The bitstream may include the first bitstream element and the second bitstream element. Further, the bitstream may be an AAC bitstream. The second bitstream element may include verification information for a subset of intermediate bitstream elements among the one or more intermediate bitstream elements. The method may further include verifying the subset of intermediate bitstream elements using the verification information. The verification information may relate to D24051AW001 an authentication signature. Specifically, the verification information may comprise the authentication signature verifying the subset of intermediate bitstream elements may use the authentication signature. In alternative implementations, the method may include outputting the subset of intermediate bitstream elements and the verification information, for enabling verification of the subset of intermediate bitstream elements using the verification information.

[0056] Various embodiments perform an authentication verification of protected messages in the packets. This verification can be done, for example, to ensure the authenticity of the protected messages. Embodiments may perform additional operations such as, for example, reporting the result of the verification, performing the verification until the verification is successful, updating data based on the result (for example, setting a flag or other variable), reporting the result (for example, reporting whether the result was successful), reporting additional information on the result (for example, information indicating why a result was not successful), and / or suggesting or performing further operations. Some of those further operations may be, in various embodiments, based on or in response to the verification result, whereas some of those further operations in various other embodiments are not based on nor in response to the verification result. The reporting of the verification result that is performed by various embodiments may include storing data (for example, the result, or data indicative of the result), transmitting data, and / or performing one or more additional operations that implicitly convey the result.

[0057] In some embodiments, the verifying may be in accordance to AAC audio stream verification.

[0058] In some embodiments, successful authentication results from the verification may ensure the intermediate data packets’ authenticity.

[0059] In some embodiments, the method may further include extracting information identifying the subset of intermediate bitstream elements from the first bitstream element or from another bitstream element that is in a fixed order relationship to the first bitstream element in the bitstream.

[0060] In some embodiments, the information identifying the subset of intermediate bitstream elements may include a list of bitstream element types. Further, the information identifying the subset of intermediate bitstream elements may include a binary indicator for indicating whether bitstream element types in the list of bitstream element types shall be included into or excluded from the one or more intermediate bitstream elements. D24051AW001

[0061] In some embodiments, the method may further include applying a hashing algorithm to the subset of intermediate bitstream elements to generate a hash value. The hashing algorithm may have been agreed upon previously with the encoder side or may be indicated in the first bitstream element. The method may further include extracting the verification information from the second bitstream element. Therein, the verification information may relate to an authentication signature. The method may yet further include verifying the subset of intermediate bitstream elements based on the authentication signature, the generated hash value, and a decryption key.

[0062] In some embodiments, the method may further include extracting, from the first bitstream element, one or more of information identifying the hashing algorithm, information identifying the encryption key, and / or information identifying an authentication authority in relation to the encryption key.

[0063] In some embodiments, the decryption key may be a public key of a private-public key pair. The private-public key pair may be a key pair including a private key that has been used for generating the authentication signature. The public key may be obtainable from a trusted authority, or directly from the encoder side. Alternatively, the decryption key may be identical to the encryption key, and may have been exchanged in an appropriate manner between the encoder side and the decoder side before decoding.

[0064] In some embodiments, the information identifying the authentication authority in relation to the encryption key may include a Uniform Resource Identifier, URI as defined in IETF RFC 3986.

[0065] In some embodiments, the method may further include extracting authentication identification information from the first bitstream element and / or from the second bitstream element. The authentication identification information may identify a combination of the information identifying the hashing algorithm, the information identifying the encryption key and the information identifying the authentication authority in relation to the encryption key.

[0066] In some embodiments, the first bitstream element and the second bitstream element may each include pairing information for indicating that the second bitstream element includes the verification information for the subset of intermediate bitstream elements between the first bitstream element and the second bitstream element. In this case, the one or more intermediate bitstream elements may include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding the first bitstream D24051AW001 element. This further second bitstream element may include pairing information different from the pairing information of the first and second bitstream elements. The further second bitstream element may be among the subset of intermediate bitstream elements, so that the second bitstream element includes verification information also for the further second bitstream element.

[0067] In some embodiments, the method may further include decoding, from the bitstream, a third bitstream element and a fourth bitstream element. The third bitstream element and the fourth bitstream element may be separated in the bitstream by one-or more second intermediate bitstream elements. Further, the fourth bitstream element may include second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements. The method may further include decoding, from the bitstream, information identifying the subset of second bitstream elements from the third bitstream element or from another bitstream element that is in a fixed order relationship to the third bitstream element. The method may yet further include verifying the subset of second intermediate bitstream elements using the second verification information. The one or more intermediate bitstream elements and the one or more second intermediate bitstream elements may be at least partially overlapping.

[0068] In some embodiments, the intermediate bitstream elements may include one or more of a single channel element, SCE, a channel pair element, CPE, and a low frequency element, LFE.

[0069] In some embodiments, the verification information may relate to a portion of an authentication signature. Then, the second bitstream element may include verification splitting information indicative of a relationship between the portion of the authentication signature and the complete authentication signature. The method may further include extracting the verification information and the verification splitting information. The method may yet further include reconstructing the authentication signature based at least in part on the verification information and the verification splitting information. For example, the verification splitting information may indicate storage locations of remaining / complementary portions of the authentication signature in the bitstream.

[0070] In some embodiments, the verification splitting information may include one or more of an indication that the portion of the authentication signature relates to a first segment of the authentication signature, an indication that the portion of the authentication signature relates to a D24051AW001 last segment of the authentication signature, and an indication of a length of the portion of the authentication signature.

[0071] In some embodiments, the first bitstream element and the second bitstream element may be of a same bitstream element type. Therein, the first bitstream element and the second bitstream element may differ in a set value of a predefined parameter or bit field. The first and second bitstream elements may be data bitstream elements (DSEs), in particular of type authentication_extension. The predefined parameter or bit field may relate to a 2-bit auth_element_type syntax element. Alternatively, the first and second bitstream elements may be USAC extension elements, in particular of type authentication_extension().

[0072] In some embodiments, the method may further include, upon detection of the second bitstream element in the bitstream, outputting, by a core decoder, the verification information and the subset of intermediate bitstream elements for subsequent verification of the subset of intermediate bitstream elements, using a predefined data format. In other words, a predefined interface may be used for providing this information by the core decoder.

[0073] In some embodiments, the verification information and the subset of intermediate bitstream elements may be output, using the predefined data format, separately for different pairing information.

[0074] In some embodiments, the subset of intermediate bitstream elements may include a bitstream element that contains timestamp information. Then, the method may further include extracting the timestamp information. The timestamp information may be indicative of, for example, a number (count) of seconds that have elapsed after a predefined point in time. The timestamp information may be indicative of a point in time at which the bitstream has been generated or last modified, for example.

[0075] In some embodiments, the subset of intermediate bitstream elements may include a bitstream element that contains geolocation information. Then, the method may further include extracting the geolocation information. The geolocation information may be indicative of a geolocation at which the bitstream has been generated or last modified, for example.

[0076] In some embodiments, the subset of intermediate bitstream elements may include a bitstream element that contains identification information indicative of a Universally Unique Identifier, D24051AW001

[0077] UUID. Then, the method may further include extracting the identification information. The UUID may be an identifier of a device or user that has generated (or modified) the bitstream, for example.

[0078] In some embodiments, the subset of intermediate bitstream elements may include a bitstream element that contains identification information indicative of a portion of a UUID and that further contains identification splitting information indicative of a relationship between the portion of the UUID and the complete UUID. Then, the method may further include extracting the identification information and the identification splitting information. The method may yet further include reconstructing the UUID based at least in part on the identification information and the identification splitting information. The portion of the UUID may be a segment of the UUID, for example.

[0079] In some embodiments, the identification splitting information may include one or more of an indication that the portion of the UUID relates to a first segment of the UUID, an indication that the portion of the UUID relates to a last segment of the UUID, and an indication of a length of the portion of the UUID.

[0080] In some embodiments, one or more of the intermediate bitstream elements (or of the subset of intermediate bitstream elements) may include authorization information. The authorization information may indicate an access restriction to (payload) data included in one or more of the remaining intermediate bitstream elements (or of the subset of intermediate bitstream elements) and / or indicative of a group of authorized recipients of the payload data. Depending on authorization values included in the authorization information, further operation to extract information from the remaining intermediate bitstream elements may be prevented. Alternatively, the authorization values may indicate an intended target audience that the content is targeting, or a group of intended / authorized recipients. The authorization values may be set by content creators or service providers, for example. Then, the method may further include extracting the authorization information.

[0081] In some embodiments, the bitstream may be an MPEG-4 bitstream.

[0082] In some embodiments, the method may further include decoding, from the bitstream, a configuration element preceding the first bitstream element. The configuration element may include reference information referencing one or more bitstream elements among the D24051AW001 intermediate bitstream elements as the subset of bitstream elements. Here, preceding may be understood to mean immediately preceding.

[0083] Referring to the configuration element allows to efficiently indicate the bitstream elements that are to be included into the hashing (or into the verification in general), without additional overhead for signaling this information in the first bitstream element.

[0084] In some embodiments, each bitstream element of the bitstream may include an element tag. Element tags of the first bitstream element and the configuration element may be identical. The element tags may be element instance tags (element_instance_tag), for example. Matching elements tags of the first bitstream element and the configuration element allows for the decoder to identify those first bitstream elements and configuration elements that belong together in case that multiple programs or substreams are included in the bitstream.

[0085] In some embodiments, the method may further include decoding, from the bitstream, a third bitstream element and a fourth bitstream element. The third bitstream element and the fourth bitstream element may be separated in the bitstream by one or more second intermediate bitstream elements. Further, the fourth bitstream element may include second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements. The method may further include decoding, from the bitstream, a second configuration element preceding the third bitstream element. The second configuration element may include reference information referencing one or more bitstream elements among the second intermediate bitstream elements as the subset of second bitstream elements. The method may yet further include verifying the subset of second intermediate bitstream elements using the second verification information.

[0086] In some embodiments, element tags of the third bitstream element and the second configuration element may be identical to each other, and may be different from the element tags of the first bitstream element and the second bitstream element.

[0087] In some embodiments, the first bitstream element and the second bitstream element may each include pairing information for indicating that the second bitstream element includes the verification information for the subset of intermediate bitstream elements referenced by the configuration element preceding the first bitstream element. Then, the one or more intermediate bitstream elements may include a further second bitstream element that includes verification D24051AW001 information for one or more bitstream elements in the bitstream preceding said configuration element. This further second bitstream element may include pairing information different from the pairing information of the first and second bitstream elements. The further second bitstream element may be among the subset of intermediate bitstream elements, so that the second bitstream element includes verification information also for the further second bitstream element.

[0088] In some embodiments, the configuration element may be a program configuration element.

[0089] In some embodiments, the bitstream may be an AAC bitstream. For example, the bitstream may be one of a Low Complexity Advanced Audio Coding, AAC-LC, bitstream or a High Efficiency Advanced Audio Coding, HE- AAC, bitstream.

[0090] In some embodiments, the subset of intermediate bitstream elements may include all intermediate bitstream elements between the first bitstream element and the second bitstream element that are of a predetermined bitstream element type.

[0091] In some embodiments, the bitstream may include configuration information defining bitstream element types that shall be included into the subset of intermediate bitstream elements. The configuration information may be included in the first bitstream element, for example.

[0092] In some embodiments, the bitstream may be a Unified Speech and Audio Coding, USAC, bitstream.

[0093] According to another aspect, an apparatus is provided. The apparatus may include one or more processors and a memory coupled thereto and storing instructions for the one or more processors. The one or more processors may be configured to perform the methods or method steps outlined throughout the present disclosure. This apparatus may relate to an encoder, encoding apparatus, or encoding system, or to a decoder, decoding apparatus, or decoding system, as the case may be.

[0094] According to a further aspect, a computer program is described. The computer program may comprise executable instructions for performing the methods or method steps outlined throughout the present disclosure when executed by a computing device (e.g., one or more processors).

[0095] According to another aspect, a computer-readable storage medium is described. The storage medium may store a computer program adapted for execution on a computing device (e.g., one D24051AW001 or more processors) and for performing the methods or method steps outlined throughout the present disclosure when carried out on the computing device.

[0096] According to a further aspect, a bitstream is described. The bitstream may include a first bitstream element and a second bitstream element. The first bitstream element and the second bitstream element may be separated in the bitstream by one or more intermediate bitstream elements. The first bitstream element may include information indicating a subset of intermediate bitstream elements among the one or more intermediate bitstream elements for which verification information is available in the bitstream for verifying the subset of intermediate bitstream elements. The second bitstream element may include the verification information.

[0097] According to a further aspect, a bitstream is described, which is generated according to any aspects of the methods for generating the bitstream as outlined in the present disclosure.

[0098] According to a further aspect, an apparatus is described. The apparatus may include an accessing unit configured to access a bitstream including a first bitstream element and a second bitstream element. The first bitstream element and the second bitstream element may be separated in the bitstream by one or more intermediate bitstream elements. The apparatus may further include a modifying unit configured to embed verification information into the second bitstream element for verifying a subset of the intermediate bitstream elements. The modifying unit may be further configured to embed information into the first bitstream elements. The information may indicate the subset of the intermediate bitstream elements for which the verification information is available. The apparatus may further include a transmitter configured to transmit the bitstream.

[0099] According to a further aspect, a method is described. The method may include accessing a bitstream including a first bitstream element and a second bitstream element. The first bitstream element and the second bitstream element may be separated in the bitstream by one or more intermediate bitstream elements. The method may further include embedding verification information into the second bitstream element for verifying a subset of the intermediate bitstream elements and embedding information into the first bitstream element. The information may indicate the subset of the intermediate bitstream elements for which the verification information is available. The method may further include transmitting the bitstream. D24051AW001

[0100] According to a further aspect, a computer-readable medium is described. The computer-readable medium may include instructions for causing one or more processors to perform accessing a bitstream including a first bitstream element and a second bitstream element. The first bitstream element and the second bitstream element may be separated in the bitstream by one or more intermediate bitstream elements. Further, verification information may be embedded into the second bitstream element for verifying a subset of the intermediate bitstream elements. Further, information may be embedded into the first bitstream element. The information may indicate the subset of the intermediate bitstream elements for which the verification information is available. The bitstream may be transmitted.

[0101] It should be noted that the methods and apparatus including its preferred embodiments as outlined in the present disclosure may be used stand-alone or in combination with the other methods and apparatus disclosed in this document. Furthermore, all aspects of the methods, apparatus and bitstreams outlined in the present disclosure may be arbitrarily combined. In particular, the features of the claims may be combined with one another in an arbitrary manner.

[0102] It will be appreciated that apparatus features and method steps may be interchanged in many ways. In particular, the details of the disclosed method(s) can be realized by the corresponding apparatus, and vice versa, as the skilled person will appreciate. Moreover, any of the above statements made with respect to the method(s) (and, e.g., their steps) are understood to likewise apply to the corresponding apparatus (and, e.g., their blocks, stages, units), and vice versa.

[0103] Brief Description of the Drawings

[0104] The invention is explained below in an exemplary manner with reference to the accompanying drawings, wherein

[0105] Fig. 1 schematically illustrates an example framework for bitstream authentication according to embodiments of the disclosure;

[0106] Fig. 2A to Fig. 2K are flowcharts schematically illustrating methods of encoding or decoding bitstreams, or steps thereof, according to embodiments of the disclosure;

[0107] Fig. 3A to Fig. 3J schematically illustrate example mechanisms for data packet selection according to embodiments of the disclosure; D24051AW001

[0108] Fig. 4A to Fig. 4D schematically illustrate example mechanisms for bitstream element selection according to embodiments of the disclosure;

[0109] Fig. 5A and Fig. 5B schematically illustrate chained authentication according to embodiments of the disclosure;

[0110] Fig. 6A to Fig. 6C schematically illustrate further example mechanisms for bitstream element selection according to embodiments of the disclosure; and

[0111] Fig. 7 schematically illustrates an apparatus suitable for implementing techniques according to embodiments of the disclosure.

[0112] Detailed Description

[0113] In the following, example embodiments of the disclosure will be described with reference to the appended figures. Identical elements in the figures may be indicated by identical reference numbers, and repeated description thereof may be omitted.

[0114] Overview

[0115] In general, the present disclosure relates to techniques applied to the encoder or decoder side of a codec for embedding verification / authentication information into a bitstream or extracting the verification / authentication information from the bitstream, respectively.

[0116] At the encoder side, these techniques may involve methods of generating or modifying a bitstream comprising a plurality of data units (e.g., data packets or bitstream elements), as well as corresponding apparatus, programs, and computer-readable storage media. These methods comprise providing (e.g., generating, or embedding into the bitstream) a first data unit and a second data unit. This is done in such manner that the first data unit and the second data unit are separated in the bitstream by one or more intermediate data units, among them data units for which verification / authentication shall be provided. To this end, the second bitstream element includes verification information for a subset of intermediate data units among the one or more intermediate data units. A subset of the intermediate data units may be understood as a set including one of the data units, all of the data units or any value in between. Alternatively, a subset of the intermediate data units may be understood as a set that strictly does not include all of the intermediate data units. D24051AW001

[0117] The bitstream may be packet-based (e.g., with packets arranged in a sequence of segments) or may be element-based (e.g., with packets arranged in a sequence of frames). Further, the bitstream may be a media bitstream, in particular, an audio bitstream (e.g., an MPEG-H audio bitstream, an MPEG-4 audio bitstream, an AAC (e.g., HE-AAC or AAC-LC) bitstream, or a USAC bitstream) or a video bitstream (e.g., an MPEG-H video bitstream, an AVC bitstream, an HEVC bitstream, or a VVC bitstream), or a combination thereof. MPEG-4 bitstreams may also include various audio bitstreams (e.g. AAC) and / or video bitstreams (e.g. HEVC). Further, the bitstream may include, whether as part of an MPEG-4 bitstream or not, biomedical signals (e.g., biomedical waveform data), seismic signals, or haptic signals (e.g., according to ISO / IEC 23090- 31), for example. Non-limiting examples of feasible bitstream configurations will be described in the remainder of this disclosure.

[0118] At the decoder side, techniques according to the present disclosure may involve methods of decoding a bitstream comprising a plurality of data units (e.g., data packets or bitstream elements), as well as corresponding apparatus, programs, and computer-readable storage media. These methods comprise decoding, from the bitstream, a first data unit and a second data unit, and one or more intermediate data units separating the first data unit and the second data unit in the bitstream. The second data unit includes verification information for a subset of intermediate data units among the one or more intermediate data units. The methods further include verifying the subset of intermediate bitstream elements using the verification information.

[0119] Fig. 1 schematically illustrates an example framework for techniques according to the present disclosure.

[0120] As shown in the figure, a content provider may register their public key with a trusted authority and authenticate a media bitstream including media content using the corresponding private key. This may include, as shown at the bottom left of the figure, calculating a hash value for the media content and generating an authentication signature for the media content based on the generated hash value and the private key. This authentication signature is embedded into the bitstream and provided to a customer / user shown at the bottom right of the figure. The user may then obtain the public key from the trusted authority and use this key to verify the authentication signature extracted from the bitstream, using their own local calculation of the hash value. D24051AW001

[0121] Specific examples relating to different bitstream configurations and codec standards, such as MPEG-H, AAC, USAC, or for transporting biomedical waveform data (e.g., VCEG) will be described in the following.

[0122] MPEG-H Digital Media Authentication

[0123] This section describes mechanisms to efficiently transport digital signatures and other related information (e.g., time stamps, geolocation information, authorization and user identifiers) in an MPEG-H 3D audio bitstream (MHAS). The mechanisms described below are likewise applicable to other standards, including for example H.BWC, AAC, and USAC, as apparent to the skilled person.

[0124] While this section makes frequent reference to data packets and processes of operating on data packets, it is understood that the present disclosure is not so limited and is likewise applicable to other bitstream formats and codecs.

[0125] Various embodiments perform an authentication verification of protected messages in the packets. This verification can be done, for example, to ensure the authenticity of the protected messages. Embodiments may perform additional operations such as, for example, reporting the result of the verification, performing the verification until the verification is successful, updating data based on the result (for example, setting a flag or other variable), reporting the result (for example, reporting whether the result was successful), reporting additional information on the result (for example, information indicating why a result was not successful), and / or suggesting or performing further operations. Some of those further operations may be, in various embodiments, based on or in response to the verification result, whereas some of those further operations in various other embodiments are not based on nor in response to the verification result. The reporting of the verification result that is performed by various embodiments may include storing data (for example, the result, or data indicative of the result), transmitting data, and / or performing one or more additional operations that implicitly convey the result.

[0126] An example method 210 of generating or modifying a packet-based bitstream (in an MPEG-H framework, for example) is illustrated by the flowchart of Fig. 2A. The packet-based bitstream may be a media bitstream, for example. In particular, the packet-based bitstream may be an MHAS bitstream. D24051AW001

[0127] At step S211, a first data packet and a second data packet are provided. Providing data packets may relate to generating said packets, and / or inserting said packets into the bitstream.

[0128] The first data packet and the second data packet are provided such that they are separated in the bitstream by one or more intermediate data packets. Therein, the first data packet includes information indicating a subset of intermediate data packets among the one or more intermediate data packets for which verification information is available in the bitstream for verifying the subset of intermediate data packets. The first data packet itself may not include the verification information. Accordingly, the first data packet may be seen as an indication that the bitstream includes the subset of intermediate data packets after the first data packet and before the second data packet that shall be verifiable. The first and second data packets thus serve as a form of “bracket” for the data packets that shall be verifiable. The second data packet includes the aforementioned verification information. This verification information may relate to an authentication signature, for example. Specifically, the verification information may comprise the authentication signature, or at least a portion thereof.

[0129] Method 220 illustrated in Fig. 2B includes example details of method 210 for providing the first and second data packets. It is understood that the steps of method 220 may be performed in orders different from the one shown in Fig. 2B.

[0130] At step S221, one or more data packets for which verification / authentication should be provided are selected as the subset of intermediate data packets.

[0131] As noted above, the subset of intermediate data packets may relate to data packets that should be verifiable.

[0132] At step S222, information identifying the subset of intermediate data packets is embedded into the first data packet.

[0133] Without intended limitation, the embedded information identifying the subset of intermediate data packets may relate to one or more of a packet label, packet label information, and packet type information, as outlined below.

[0134] At step S223, a hashing algorithm is applied to the subset of intermediate data packets to generate a hash value. D24051AW001

[0135] Any suitable hashing algorithm may be used for this purpose, including, without intended limitation, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.

[0136] At step S224, an authentication signature is generated based on the hash value and an encryption key. The aforementioned verification information may relate to this authentication signature. In particular, it may comprise the authentication signature, or at least a portion thereof.

[0137] The encryption key used for this purpose may be a private key of a private-public key pair. Alternatively, the encryption key may be identical to a decryption key, and may be exchanged in an appropriate manner between the encoder side and the decoder side before decoding.

[0138] At step S225, the verification information is embedded into the second data packet.

[0139] In some implementations, the hash value generated at step S223 may be directly embedded into the second data packet at step S225, instead of the authentication signature. In this case, step S224 may be omitted.

[0140] An example method 240 of decoding a packet-based bitstream (in an MPEG-H framework, for example) is illustrated by the flowchart of Fig. 2D. The packet-based bitstream may be a media bitstream, for example. In particular, the packet-based bitstream may be an MHAS bitstream. Therefore, the decoding of media and auxiliary content (i.e., the authentication information) in the bitstream may be MHAS based decoding.

[0141] It is noted that methods of decoding bitstreams as described throughout the disclosure may operate on bitstreams output by corresponding methods of encoding, and that these methods may include corresponding steps, unless indicated otherwise. Detailed description of corresponding steps at decoding may be omitted, for reasons of conciseness.

[0142] At step S241, a first data packet and a second data packet, and one or more intermediate data packets separating the first data packet and the second data packet in the bitstream are decoded from the bitstream. Therein, the first data packet includes information indicating a subset of intermediate data packets among the one or more intermediate data packets for which verification information for verifying / authenticating the subset of intermediate data packets is available in the second data packet.

[0143] At step S242, the subset of intermediate data packets is verified / authenticated using the verification information. D24051AW001

[0144] In alternative implementations, method 240 may include, for example instead of step S242, a step of outputting (or otherwise providing) the subset of intermediate data packets and the verification information, for enabling verification of the subset of intermediate data packets using the verification information.

[0145] The verification information may relate to an authentication signature, as noted above. Specifically, the verification information may comprise the authentication signature or part thereof. Verifying the subset of intermediate data packets may use the authentication signature.

[0146] Method 250 illustrated in Fig. 2E includes example details of method 240 for verifying / authenticating the subset of intermediate data packets. It is understood that the steps of method 250 may be performed in orders different from the one shown in Fig. 2E.

[0147] At step S251, the information identifying the subset of intermediate data packets is extracted from the first data packet.

[0148] At step S252, one or more data packets among the intermediate data packets are selected, as the subset of intermediate data packets, based on the information identifying the subset of intermediate data packets.

[0149] At step S253, a hashing algorithm is applied to the subset of intermediate data packets to generate a hash value.

[0150] The hashing algorithm used for this purpose may have been agreed upon previously with the encoder side or may be indicated by the first data packet. It is understood that this hashing algorithm is identical to (or yields identical results as) the hashing algorithm used at step S223 above.

[0151] At step S254, the verification information is extracted from the second data packet. This verification information may relate to an authentication signature, as described above.

[0152] At step S255, the subset of intermediate data packets is verified / authenticated based on the authentication signature, the generated hash value, and a decryption key.

[0153] If the hash value had been embedded into the second data packet at step S225 of method 220, instead of the authentication signature, the subset of intermediate data packets may be verified at step S255 based on the hash value generated at step S253 and the hash value extracted from the second data packet. D24051AW001

[0154] The decryption key used at step S255 may be a public key of a private-public key pair. The private-public key pair may be a key pair including a private key that has been used for generating the authentication signature, e.g., at step S224. The public key may be obtainable from a trusted authority, or directly from the encoder side. Alternatively, the decryption key may be identical to the encryption key, and may have been exchanged in an appropriate manner between the encoder side and the decoder side before decoding.

[0155] Basic Syntax

[0156] Next, example syntax for inclusion into the current version of the MPEG-H standard is described in Table la, Table lb, Table 1c, and Table Id. D24051AW001 D24051AW001

[0157] Table lb D24051AW001

[0158] Table 1c D24051AW001

[0159] Table Id

[0160] Authentication Start Packet - PACTYP AUTH START

[0161] In some embodiments, the aforementioned first data packet may be an MHAS packet of packet type PACTYP_AUTH_START. An example of possible syntax for a packet of packet type PACTYP_AUTH_START is given in Table 2 below. D24051AW001

[0162] Table 2

[0163] Example semantics for Table 2 may be as follows. authSourceURILengthMinusl

[0164] Plus 1 indicates the length of the authSourceURI- field in bytes. authSourceURI Contains a URI with syntax and semantics as defined in as defined in IETF RFC 3986.

[0165] Further, in line with the above, the first data packet may include some, any, or all of the following items of information.

[0166] Pairing Information - authSequence First, mechanisms including examples of possible syntax for ensuring that PACTYP_AUTH_SIG and PACTYP_AUTH_START can be mapped together (e.g., linked or paired, as described above) in case they are overlapping will be described. In this case, PACTYP_AUTH_SIG may be included into verification of the following temporal segment for enabling chained authentication. For example, the syntax element authSequence may be used to signal pairing information for linking the first and second data packets, which may become necessary if multiple pairs of first and second data packets are included in the bitstream, possibly with overlap between their D24051AW001 respective intermediate data packets. It is understood that deviating from the above explicit example, other means of signaling the pairing information are feasible in the context of the present disclosure.

[0167] In general, the first data packet and the second data packet may each include pairing information for indicating that the second data packet includes the verification information for the subset of intermediate data packets indicated by the first data packet.

[0168] This allows for the one or more intermediate data packets to include a further second data packet that includes verification information for one or more data packets in the bitstream preceding the first data packet, provided that the further second data packet includes pairing information different from the pairing information of the first and second data packets.

[0169] The scheme proposed above may be used for chained authentication, in which verification information for a given set of data packets is itself made verifiable as part of a subsequent set of data packets. That said, the aforementioned further second data packet may be among the subset of intermediate data packets, so that the second data packet includes verification information also for the further second data packet.

[0170] An example of chained authentication is schematically illustrated in Fig. 5A. In the media bitstream illustrated therein, first data packet 510 and second data packet 520 are linked by matching pairing information “SEQ=0”. Further first data packet 510’ and further second data packet 520’ are linked by matching pairing information “SEQ=1” that is different from the pairing information of the first and second data packets 510, 520. Yet further first data packet 510’ ’ and yet further second data packet 520’ ’ are linked by matching pairing information “SEQ=0” that is different from the pairing information of the further first and second data packets 510’, 520’. Notably, two different possible values of the pairing information (e.g., “SEQ=0” and “SEQ=1”) are sufficient for appropriately signaling sequences of overlapping pairs of first and second data packets, so that a 1 -bit field would be sufficient for signaling the pairing information.

[0171] In the example of Fig. 5A, if further first data packet 510’ indicates the second data packet 520 to be included for verification, and further second data packet 520’ includes verification information for a (subset of) data packets including the second data packet 520, neither of the verifiable data packets between the first data packet 510 and the further second data packet 520’ D24051AW001 can be modified without being detected. This protection scheme can be extended throughout the bitstream, if needed.

[0172] Fig. 5B shows an example where the authentication chain is broken along the bitstream. While the pair of the first and second data packets 510, 520 and the pair of the further first and second data packets 510’, 520’ overlap with each other, the pair of the yet further first and second data packets 510”, 520” does not have any overlap with another pair. Hence, the authentication chain is broken after the further second data packet 520’ .

[0173] In the example of Table 2, authSequence indicates the authentication sequence to which the related authentication information belongs to.

[0174] Packet Selection - authFrameTypes

[0175] Next, mechanisms and bitstream syntax for signaling which data packets shall be included into verification / authentication (i.e., shall be hashed for purposes of generating an authentication signature) will be described.

[0176] In one implementation, all data packets between the first data packet (e.g., PACTYP_AUTH_START) and the second data packet (e.g., PACTYP_AUTH_SIG) may be hashed. Or in other words, the aforementioned subset of intermediate data packets may include all intermediate data packets in the bitstream between the first data packet and the second data packet.

[0177] This is schematically illustrated in the example of Fig. 3A, in which four intermediate data packets 330 are “enveloped” between the first data packet 310 and the second data packet 320, and all four of the intermediate data packets 330 are included in the subset of intermediate data packets 340 for hashing.

[0178] Alternatively, the first data packet may include a first packet label (or any other suitable syntax element for signaling this information), and a predefined value of the first packet label may indicate that the subset of intermediate data packets includes all intermediate data packets between the first data packet and the second data packet in the bitstream. For example, the predefined value of the first packet label may be 0x0. In this case, all intermediate data packets may be included into the hashing, independently of their own packet labels. D24051AW001

[0179] This is schematically illustrated in the example of Fig. 3B, in which four intermediate data packets 330 are “enveloped” between the first data packet 310 and the second data packet 320, and all four of the intermediate data packets 330 are included in the subset of intermediate data packets 340 for hashing, even though they have different packet labels (and different packet types).

[0180] Further, the first data packet may include a bit flag (e.g., bit flag authFrameTypes in Table 2) for toggling between different options for indicating the data packets for hashing. In general, this bit flag (e.g., bit flag authFrameTypes in Table 2) may indicate if authentication information for additional MHAS packet types is signaled.

[0181] For example, if the bit flag is set to 0 and all packets belong to the same stream (e.g., mpeghAudioStreamPacketType and mpeghAudioStreamPacketLabel of these packets are equal), all bytes from the first packet after the first data packet (e.g., PACTYP_AUTH_START) until the second data packet (e.g., PACTYP_AUTH_SIG) is received shall be included into the hash calculation. Additionally or alternatively, the second data packet (e.g., PACTYP_AUTH_SIG) from the previous temporal segment may be included into the generation of the hash, which allows verification of temporal consistency of the data and bitstream element sequence (e.g., using authSequence to signal which AUTH_START belongs to which AUTH_SIG), as described above with reference to Fig. 5 and Fig. 5B.

[0182] If the bit flag is set to 1, packet types that are signaled to be included and that belong to the same stream shall be included into the hashing.

[0183] Label-Based Packet Selection

[0184] The data packets for which verification is available in the bitstream (i.e., the subset of intermediate data packets) may be signaled using packet labels. For example, the first data packet may include a first packet label, and the subset of intermediate data packets may include all intermediate data packets that have a packet label identical to the first packet label. Also the second data packet may have a packet label identical (e.g., equal) to the first packet label.

[0185] This is schematically illustrated in the example of Fig. 3C, in which four intermediate data packets 330 are “enveloped” between the first data packet 310 and the second data packet 320, but only the first, second, and fourth of these intermediate data packets 330 are included in the D24051AW001 subset of intermediate data packets 340 for hashing. The third intermediate data packet 330 is not included because its packet label “0x2” does not match the packet label of the first data packet 310, “0x1”.

[0186] In some implementations, the first data packet may additionally include packet label information indicating one or more packet labels that are to be included for verification. Then, the subset of intermediate data packets may include all intermediate data packets that have a packet label indicated by the packet label information. The packet label information may relate to a whitelist of packet labels that are to be included for verification. Alternatively, also a blacklist of packet labels that are not to be included for verification may be defined. Whether a whitelist or a blacklist is defined may be initially agreed on between encoder side and decoder side or may be signaled by a bitflag in the first data packet.

[0187] Adding to the above implementation, the subset of intermediate data packets may include all intermediate data packets that have a packet label identical to the packet label of the first data packet (i.e., the first packet label), and additionally, all intermediate data packets that have a packet label indicated by the packet label information.

[0188] This is schematically illustrated in the example of Fig. 3D, in which four intermediate data packets 330 are “enveloped” between the first data packet 310 and the second data packet 320, and all four of the intermediate data packets 330 are included in the subset of intermediate data packets 340 for hashing. Therein, third intermediate data packet 330 includes a packet label “0x11”, which differs from the packet label of the first data packet 310, “0x1”, but the packet is still included in the subset of intermediate data packets 340 for hashing, since its packet label is indicated by the packet label information held by the first data packet 310.

[0189] Packet Selection - authPactypInclusion

[0190] As noted above, packet selection for verification (i.e., hashing for purposes of calculating the authentication signature) may be based on packet types.

[0191] To this end, in one implementation, the first data packet may include packet type information indicating one or more packet types that are to be included for verification (e.g., hashing), Then, the subset of intermediate data packets may include all intermediate data packets that have a packet type indicated by the packet type information. D24051AW001

[0192] This may relate to the case of authFrameTypes==l described above.

[0193] Referring to the example syntax of Table 2, authPactypInclusion signals whether the listed PACTYPES should be included into or excluded from the hashing function. If set to 1, all packet types signaled in authPacketType shall be included into the hash-calculation. If set to 0, all packet types signaled in authPacketType shall be excluded from the hash-calculation.

[0194] Further example semantics for the syntax of Table 2 in relation to packet selection may be as follows. authPactypListLengthMinus 1

[0195] Plus 1 indicates the length of the list of authPacketType. authPacketType Indicates the MHAS packet type to be included or excluded for the calculation of the authentication information.

[0196] In general, the aforementioned packet type information included in the first data packet (e.g., PACTYP_AUTH_START) may relate to a whitelist of packet types that are to be included for verification. Alternatively, also a blacklist of packet types that are not to be included for verification may be defined. Whether a whitelist or a blacklist is defined may be initially agreed on between encoder side and decoder side or may be signaled by a bitflag in the first data packet.

[0197] This inclusion or exclusion of packet types may be used in the context of a label-based selection, so that all intermediate data packets with the same packet label as the first data packet are included into the subset of intermediate data packets for hashing, but certain data packets are still included or excluded depending on their packet types.

[0198] This is schematically illustrated in the example of Fig. 3E, in which four intermediate data packets 330 are “enveloped” between the first data packet 310 and the second data packet 320, but only the first, second, and fourth of these intermediate data packets 330 are included in the subset of intermediate data packets 340 for hashing. The third intermediate data packet 330 is not included because, even though its packet label “0x1” matches the packet label of the first data packet 310, “0x1, its packet type “PACTYP_GENDATA” is indicated by the packet type information included in the first data packet to be excluded from hashing.

[0199] Notably, the example of Fig. 3E corresponds to the aforementioned blacklist case. In an alternative implementation, which corresponds to the whitelist case, a certain intermediate data D24051AW001 packet may be included into the subset of intermediate data packets for hashing, even though its packet label may not match the first packet label of the first data packet, as long as its packet type is indicated by the packet type information included in the first data packet to be included for hashing.

[0200] Returning to the example of Table 2, mpegh3daAuthStart() can define which MHAS-Packets should be included into the hashing. For instance, the hashing can include config and frames, but exclude “features”.

[0201] As has been described above, a second data packet that includes verification information for a previous set of data packets may also be included into the subset of intermediate data packets for hashing. Whether or not this further second data packet is included may depend, for example, on any of the selection criteria described above. Fig. 3F schematically illustrates an example where a (further) second data packet for a previous segment is among the subset of intermediate data packets 330 between the first data packet 310 and the second data packet 320, and is moreover included in the subset of intermediate data packets 340 for hashing, so as to enable chained authentication. For purposes of comparison, Fig. 3G shows an example where there is no overlap between the previous and current segments, so that there is no chained authentication.

[0202] Hashing Algorithm Identification - auth.Hash.Type

[0203] To ensure that the encoder and the decoder apply the same hashing function, method 210 of Fig. 2A or method 220 of Fig. 2B may further include embedding information identifying the hashing algorithm into the first data packet (e.g., PACTYP_AUTH_START).

[0204] At decoding, this may entail a step of extracting, from the first data packet, the information identifying the hashing algorithm.

[0205] Table 3 gives an example of bitstream semantics that may be used for this purpose.

[0206] Table 3 D24051AW001

[0207] In the syntax example of Table 2, authHashType indicates the hashing algorithm used.

[0208] Key Identification - authKeylD

[0209] To ensure that the encoder and the decoder apply the same or corresponding keys, method 210 of Fig. 2A or method 220 of Fig. 2B may further include embedding information identifying the encryption key into the first data packet (e.g., PACTYP_AUTH_START).

[0210] At decoding, this may entail a step of extracting, from the first data packet, the information identifying the encryption key.

[0211] Table 4 gives an example of bitstream semantics that may be used for this purpose.

[0212] Table 4

[0213] The value of the authKeylD field identifies the authentication key used to calculate the value of the signature in mpegh3daAuthSig(). The values of authKeylD are implementation dependent (e.g., dependent on the authentication provider) and are not defined in the present disclosure. The value of authKeylD shall be set to 0 in case there is no key needed of the underlying hashfunction.

[0214] Authentication Provider Identification - authProvID

[0215] To ensure that the decoder can, if the encoder uses a private key of a private-public key pair, obtain the corresponding public key as the decryption key, method 210 of Fig. 2A or method 220 of Fig. 2B may further include embedding information identifying an authentication authority in relation to the encryption key into the first data packet (e.g., PACTYP_AUTH_START).

[0216] At decoding, this may entail a step of extracting, from the first data packet, the information identifying the authentication authority in relation to the encryption key.

[0217] Table 5 gives an example of bitstream semantics that may be used for this purpose. D24051AW001

[0218] Table 5

[0219] The value of the authProvID field identifies the provider of the authentication system, e.g. C2PA.

[0220] In case authProvID equals 1, there is no provider. This mode can be used to create the message digest only by using the method identified by authHashType, but without verification. This method can for example be used in closed ecosystems, where keys can be made available without a third party involved, e.g., by appropriate key exchange techniques.

[0221] Authentication Identification - authlD authlD may be used to identify the combination of authHashType, authProvID and authKeylD to which the related authentication information belongs to. This may enable authentication of one authentication sequence with different authentication configurations.

[0222] Consideration of Multiple Sub-Streams - authPacketLabel

[0223] In the above example, the value of authPacketLabel indicates that the MHAS sub- stream with this packet label shall be included in the calculation of the authentication hash in addition to the MHAS stream with the same MHASPacketLabel as assigned to the PACTYP_AUTH_START packet. Even with multiple sub-streams, hashing of packets shall be calculated in order of appearance in the stream.

[0224] Example semantics for the syntax example of Table 2 in relation to multiple sub-streams may be as follows. authMultiStreams Indicates if authentication information for multi-stream scenarios is signaled. authMSInclusion If set to 1, all packet with the labels signaled in authPacketLabel shall be included into the calculation of the authentication information. If set to 0, all packet types signaled in authPacketLabel shall be excluded from the calculation of the authentication information. D24051AW001 authMSLabelsListLengthMinusl

[0225] Plus 1 indicates the length of the list of authPacketLabel. authPacketLabel Indicates the MHASPacketLabel to be included or excluded for the calculation of the authentication information. If authMSInclusion is equal to ‘1’, the value of authPacketLabel indicates that the substream with this packet label shall be included in the calculation of the authentication information.

[0226] If authMSInclusion is equal to ‘O’, the value of authPacketLabel indicates that the sub-stream with this packet label shall be excluded from the calculation of the authentication information.

[0227] Notably, authPacketLabel equal to 0 already indicates that all sub-streams are included. In this case, authPackLabels are not needed.

[0228] Authentication Signature Packet - PACTYP AUTH SIG

[0229] In some embodiments, the aforementioned second data packet may be an MHAS packet of packet type PACTYP_AUTH_SIG. An example of possible syntax for a packet of packet type PACTYP_AUTH_SIG is given in Table 6 below. As noted above, the second data packet (e.g., PACTYP_AUTH_SIG) includes the verification / authentication information needed for verifying / authenticating the relevant bitstream packets at the decoder.

[0230] Table 6 D24051AW001

[0231] In some embodiments, the verification / authentication information may be split over several second data packets to avoid bitrate peaks in case of larger authentication signatures.

[0232] Then, verification information may relate to a portion of an authentication signature (e.g., authPartialSig in the example of Table 6). For enabling reconstruction of the complete authentication signature, the second data packet may also include verification splitting information (e.g., sigSegmentStart, sigSegmentStop, and / or sigSegmentLengthMinus 1 in the example of Table 6) indicative of a relationship between the portion of the authentication signature and the complete authentication signature. For example, the verification splitting information may indicate storage locations of remaining / complementary portions of the authentication signature in the bitstream.

[0233] At decoding, the decoding method may include additional steps of extracting the verification information and the verification splitting information from the second data packet, and reconstructing the authentication signature based at least in part on the verification information and the verification splitting information. As noted above, the verification splitting information may for example indicate storage locations of remaining / complementary portions of the authentication signature in the bitstream, so as to allow reconstruction of the complete authentication signature.

[0234] In the example of Table 6, fields authPartialSig, sigComplete carry the protection bits resulting from the hashing algorithm signaled via authHashType, using the key which is signaled via authKeylD. Protection values shall be written into this field LSB of hash = LSB of the signature in mpegh3daAuthSig().

[0235] Verification of the signature in mpegh3daAuthSig() may happen comparing only a subset of the bits resulting from the hashing algorithm. For example, only the 8 LSBs of a 256-bit hash value may be verified by comparing to the signature in mpegh3daAuthSig() with a length of 8 bits.

[0236] However, a definition of data going into the authentication function is out of scope of the present disclosure and it is understood that the skilled person will readily implement such data depending on circumstances.

[0237] Further example semantics for the syntax of Table 3 may be as follows. authPartialSig If set to ‘1’, indicates that the signature is transmitted partially. D24051AW001 sigSegmentStart Indicates that the following sigPartial is the first segment of a signature. sigSegmentStop Indicates that the following sigPartial is the last segment of a signature.

[0238] Note: If both sigSegmentStart and sigSegmentStop are equal to ‘1’, sigPartial contains a signature which is complete, but shorter than a full signature resulting from the related hashing algorithm. sigSegmentLengthMinusl Plus 1 indicates the length of the sigPartial field. sigPartial This field carries a segment of the signature resulting from the used verification mechanism. sigPartial shall be calculated in the same way as sigComplete. sigPartial may be created by truncating sigComplete.

[0239] Note: Verification may happen comparing only a subset the bits resulting from the hashing algorithm. sigLengthMinus 1 Plus 1 indicates the length of the sigComplete field in bytes. sigComplete This field carries the signature resulting from the used verification mechanism. sigComplete is calculated by applying the hashing algorithm and configuration as signaled in the mpegh3daAuthStart() syntax element. The input data to the hashing algorithm are created as described elsewhere in the disclosure.

[0240] Features and Advantages

[0241] The following features and advantages may apply to the techniques described above.

[0242] • Segmentation of the digital signature enables smoothing bitrate peaks, which is essential for lower-bitrate applications (such as audio or biomedical signals).

[0243] • In case the signature is segmented and only partially received (in other words, the transmitted part of the signature does not have the same number of bits as a signature resulting from the selected digital signature process), the system may compare the least- D24051AW001 significant bits of the calculated digital signature for verification against the signaturebits received in the bitstream. This enables a tradeoff between bitrate and security.

[0244] • Security gradually increases the more segments are received, up to the point in time when the full signature is received.

[0245] • Protection bits sent can be less than the full digital signature.

[0246] • Only the number of bits sent via the bitstream are compared for validity check, with less security the fewer bits are packed into the bitstream.

[0247] • In case the transmitted signature does not have the same number of bits as a signature resulting from the selected digital signature process, the system may compare the leastsignificant bits of the calculated digital signature for verification against the signaturebits received in the bitstream. This enables a tradeoff between bitrate and security.

[0248] • This mechanism may be used in combination with the system time to have more security. A content creator can include PACTYP_TIMESTAMP packets after PACTYP_AUTH_START to have time included in the hash. In case PACTYP_TIMESTAMP is included, even if the private key is exposed after the time indicated in PACTYP_TIMESTAMP, the signature may be treated as valid.

[0249] Identifier Packages - PACTYP UUID

[0250] In some cases, it may be desirable to include an indication of an origin or creator of the bitstream into the bitstream and to provide authentication for this information.

[0251] Accordingly, for the methods proposed herein, the subset of intermediate data packets may include a data packet that contains identification information indicative of a Universally Unique Identifier (UUID). This UUID may be an identifier of a device or user (e.g., content creator) that has generated (or modified) the bitstream, for example.

[0252] This is schematically illustrated in the example of Fig. 3H, in which four intermediate data packets 330 are “enveloped” between the first data packet 310 and the second data packet 320, the intermediate data packets 330 include a data packet of packet type “PACTYP_UUID”, and all four of the intermediate data packets 330 are included in the subset of intermediate data packets 340 for hashing. D24051AW001

[0253] At decoding, the method proposed herein may further comprise extracting the identification information from the bitstream (e.g., from the aforementioned data packet).

[0254] Also the UUID may be segmented and distributed over multiple data packets to avoid bitrate peaks.

[0255] To this end, the subset of intermediate data packets may include a data packet that contains identification information indicative of a portion of a UUID and that further contains identification splitting information indicative of a relationship between the portion of the UUID and the complete UUID. The portion of the UUID may be a segment of the UUID, for example.

[0256] This is schematically illustrated in the example of Fig. 31, in which for two (or more) different segments, four intermediate data packets 330 are “enveloped” between the respective first data packet 310 and the respective second data packet 320, the respective intermediate data packets 330 include a respective data packet of packet type “PACTYP_UUID”, and all of the intermediate data packets 330 are included in respective subsets of intermediate data packets 340 for hashing. In addition to the partial UUID, the data packets of packet type “PACTYP_UUID” include identification splitting information that allows to reconstruct the complete UUID from its segments, here for example “uuidSegmentStart 0x1” or “uuidSegmentStart 0x0”, respectively, and “uuidSegmentLengthMinusl 0x40”.

[0257] At decoding, this may entail additional steps of extracting the identification information and the identification splitting information, and reconstructing the UUID based at least in part on the identification information and the identification splitting information.

[0258] Table 7 gives an example of bitstream syntax that may be used for this purpose.

[0259] Table 7

[0260] This syntax can be used to identify a provider of the bitstream stream (e.g., used encoder), as D24051AW001 noted above. It may be particularly useful in case no signature but only the hash value is used.

[0261] Example semantics for the syntax of Table 7 may be as follows. uuidSegmentStart If set to ‘1’, indicates if the bytes in uuid are the first bytes of a uuid- segment. uuidSegmentStop If set to ‘1’, indicates if the bytes in uuid are the last bytes of a uuid- segment.

[0262] Note: If both uuidSegmentStart and uuidSegmentStop are set to ‘1’ the uuid-field contains the full uuid. uuidSegmentLengthMinus 1

[0263] Plus 1 indicates the length of the uuid-field in bytes. uuid This field contains the uuid of the related (sub-)stream of MHAS packets. It may be used to map the MHAS stream to other media types, such as a related video stream.

[0264] Features and Advantages

[0265] The following features and advantages may apply to the techniques described above.

[0266] • Segmentation of the UUID enables smoothing bitrate peaks, which is essential for lower- bitrate applications (such as audio or biomedical signals, for example).

[0267] • The UUID can be used to map and audio bitstream to other related media streams, such as video or haptics, while it still can be verified on its own.

[0268] Timestamp Packages - PACTYP TIMESTAMP

[0269] In some cases, it may be desirable to include an indication of point in time at which the bitstream has been generated or last modified, and to provide authentication for this information.

[0270] Accordingly, for the methods proposed herein, the subset of intermediate data packets may include a data packet that contains timestamp information. The timestamp information may be indicative of, for example, a number of seconds that have elapsed after a predefined point in time. The timestamp information may be indicative of a point in time at which the bitstream has been generated or last modified, for example. D24051AW001

[0271] This is schematically illustrated in the example of Fig. 3J, in which four intermediate data packets 330 are “enveloped” between the first data packet 310 and the second data packet 320, the intermediate data packets 330 include a data packet of packet type “PACTYP_TIMESTAMP”, and all four of the intermediate data packets 330 are included in the subset of intermediate data packets 340 for hashing.

[0272] At decoding, this may entail an additional step of extracting the timestamp information from the bitstream (e.g., from the aforementioned data packet).

[0273] Table 8 gives an example of bitstream syntax that may be used for this purpose.

[0274] Table 8 In Table 8, field authTimeType may be defined for example as shown in Table 9.

[0275] Table 9 D24051AW001 authTime may be counted in seconds and the count may start on January 1st, 2024 at UTC, for example. authTimeS may give the time elapsed since the last “authTimeType == 0”-update. authTimeOffset and authTimeOffsetS may give an offset in milliseconds, where authTime + authTimeOffset (authTimeOffsetS) indicates the timestamp of the first sample of the following PACTYP_FRAME.

[0276] Field TAI_timestamp may be according to 23001-17. Two data structures support TAI timestamps:

[0277] 1) TAIClocklnfoBox: describes the TAI clock generating timestamps.

[0278] 2) TAITimestampPacket: contains a timestamp and quality status for the timestamp.

[0279] Field status_bits may be according to 23001-17.

[0280] Further example semantics for the syntax of Table 9 may be as follows. authTimeType Indicates the type of the time- signaling. authT imeOffestT ype Indicates the unit of authTimeOffset value. This shall be set to ‘0’ if the unit is milliseconds, and shall be set to ‘1’ for using the sampling rate configured for the underlying signal type as base time. authTime Indicates the base time. This is counted in seconds and the count starts on January 1st, 2025 at 00.00.01 UTC. authTimeOffset Indicates the time offset compared to the value indicated in authTime. The time shall be set in a way that authTime + authTimeOffset indicates the time when the first sample of following related mpegh3daFrame() has been recorded. authTimeS Indicates the base time elapsed in seconds since the last time update of type ‘authTimeLong’. authTimeOffsetS Indicates the time offset compared to the value indicated in authTimeS. The time shall be set in a way that authTime + D24051AW001 authTimeOffset + authTimeS + authTimeOffsetS indicates the time when the first sample of following related mpegh3daFrame() has been recorded.

[0281] TAI_timestamp Indicates the TAI_timestamp according to ISO / IEC 23001-17. status_bits Indicates the bits synchronization_state, timestamp_generation_failure, timestamp_is_modified and reserved according to ISO / IEC 23001-17.

[0282] Geolocation Packages - PACTYP GEOLOCATION

[0283] In some cases, it may be desirable to include an indication of an origin location (e.g., geolocation) of the bitstream into the bitstream and to provide authentication for this information.

[0284] Accordingly, for the methods proposed herein, the subset of intermediate data packets may include a data packet that contains geolocation information. The geolocation information may be indicative of a geolocation at which the bitstream has been generated or last modified, for example.

[0285] At decoding, this may entail an additional step of extracting the geolocation information from the bitstream (e.g., from the aforementioned data packet).

[0286] Table 10 gives an example of bitstream syntax that may be used for this purpose.

[0287] Table 10 D24051AW001

[0288] This syntax can be used to geolocate the bitstream. For example, if signed directly by a GPS- enabled camera, the signature proposed herein may authenticate the location. In general, the proposed data packet (e.g., MHAS data packet) should offer the possibility to geotag the media.

[0289] Authorization Packages - PACTYP AUTHORIZATION

[0290] In some cases, it may be desirable to include authorization information into the bitstream and to provide authentication for this information.

[0291] Accordingly, for the methods proposed herein, the intermediate data packets or the subset of intermediate data packets may include a data packet that contains authorization information. The authorization information may indicate an access restriction to (pay load) data included in one or more of the remaining intermediate data packets (or of remaining ones among the subset of intermediate data packets). The authorization information may also be indicative of the intended target audience or group of recipients that the data or media or content transported by the bitstream is targeting. This information may be set by the content creators or service providers upon examining the nature of the content, for example.

[0292] In particular, the authorization information in a data packet among the intermediate data packets may be indicative of a group of authorized recipients of the payload data of one or more data packets among the intermediate data packets (or among the subset of intermediate data packets), or may be indicative of any other form of access restriction to said pay load data.

[0293] At decoding, this may entail an additional step of extracting the authorization information from the bitstream (e.g., from the aforementioned data packet).

[0294] Table 11 gives an example of bitstream syntax that may be used for this purpose.

[0295] Table 11 D24051AW001

[0296] This syntax can be used to protect the content of the bitstream. For example, if the content creator intends to make the content private (or if the content shall be private for any other reason), this information may be directly embedded into the bitstream. In general, the proposed data packet (e.g., MHAS data packet) may offer the possibility to set the authorization value of the media.

[0297] Authentication Interface

[0298] To be able to verify digital signatures in bitstreams, it may be advantageous to define a specific data format or data interface that the (core) decoder can use to provide decoded data to the higher-level system, since the (core) decoder is typically not able to calculate hash values and verify authentication signatures, while the higher-level system is typically not able to correctly parse and decode the MHAS bitstream. This interface may be called whenever a second data packet is encountered in the bitstream and may be pre-stored at the (core) decoder. The interface shall be provided by the decoder to the system.

[0299] Accordingly, methods proposed herein, such as method 240 of Fig. 2D, may further include the step of method 260 as shown in Fig. 2F. Method 260 includes step S261.

[0300] At step S261, upon detection of the second data packet in the bitstream, the verification information and the subset of intermediate data packets are output, by a core decoder, for subsequent verification of the subset of intermediate data packets, using a predefined data format. In other words, a predefined interface may be used for providing this information by the core decoder.

[0301] When there are pairs of first and second data packets with different sequence label (or pairing information), the verification information and the subset of intermediate data packets may be output, using the predefined data format, separately for different (values of) pairing information.

[0302] Table 12a gives an example of bitstream syntax that may be used for this purpose. D24051AW001

[0303] Table 12b

[0304] Field gad_bytesLengthMinusl may give the length of bytes (minus 1) of the gad_bytes field. The gad_bytes field includes all bytes relevant for the creation of the authentication information according to the configuration described in mpegh3daAuthStart(). The decoder shall concatenate all bytes (gad_bytes) relevant for creating the hash (as signaled in mpegh3daAuthStart()) and provide it to the system.

[0305] One example embodiment of using the authentication interface may be as follows. The MPEG-H 3D audio decoder shall extract the MHAS packets related to media authentication for every authentication sequence as indicated by authlD and authSequence, and populate the respective fields in mpegh3da_GetAuthData(). mpegh3daAuthStart() and mpegh3daAuthSig(), for the related authentication sequence (as indicated by the respective authlD and authSequence) shall be copied from the respective bitstream elements. authTimestamp() having the same authlD as the current authentication sequence and authUUID() syntax elements shall always be copied from the latest occurrences in bitstream. The gad_bytes field shall be populated by concatenating all bytes of all packets starting from the packet with MHASPacketType equal to ‘PACTYP_ AUTH_START’ for the related authentication sequence and having the same MHASPacketLabel up until but excluding the packet with MHASPacketType equal to ‘PACTYP_AUTH_SIG’ in which either D24051AW001 sigSegmentStop equals ‘1’ or authPartialSig equals ‘O’, unless the MHASPacketType of the related packet is excluded by default or signaled to be excluded. Packets with MHASPacketType equal to ‘PACTYP_AUTH_SIG’ belonging to the respective authentication sequence shall not be populated into gad_bytes. Packets with MHASPacketType equal to ‘PACTYP_ AUTH_START’ or ‘PACTYP_AUTH_SIG’ with the same authlD value as the current authentication sequence and a different authSequence value shall be populated into gad_bytes. Packets with MHASPacketType equal to ‘PACTYP_ AUTH_START’ or ‘PACTYP_AUTH_SIG’ with a different authlD value than the current authentication sequence shall not be populated into gad_bytes. In addition to the above, packets with the following packet types shall be excluded by default and not be populated into gad_bytes:

[0306] - PACTYP_SYNCGAP

[0307] - PACTYP_MARKER

[0308] - PACTYP_CRC16

[0309] - PACTYP_CRC32

[0310] - PACTYP_GLOBAL_CRC16

[0311] - PACTYP_GLOBAL_CRC32

[0312] - PACTYP_USERINTERACTION

[0313] - PACTYP_AUDIOTRUNCATION

[0314] - PACTYP_GENDATA

[0315] - PACTYP_EARCON

[0316] - PACTYP_PCMCONFIG

[0317] - PACTYP_PCMDATA

[0318] If the related packet with the MHASPacketType equal to ‘PACTYP_AUTH_START’ contains a MHASPacketLabel equal to ‘O’, all bytes of all packets shall be concatenated as described above, independent of their MHASPacketLabel (all sub streams).

[0319] The input data for the hashing algorithm are created by concatenating gad_bytes with the bytes contained in the uuid field, if existing.

[0320] In general, the predefined interface may output the relevant information (e.g., the verification information and / or the information identifying the subset of data packets) as part of a D24051AW001

[0321] GetAuthDataQ data structure, for example in a gad_bytes field into which the relevant information is populated.

[0322] MHAS Packet Types considerations

[0323] It may be appreciated that some packet types should not be considered for authentication because they could get inserted or removed by subsequent stream processing stages, which would hinder authentication of other bitstream content.

[0324] Based on these considerations, in some embodiments, the following packet types should be included for authentication:

[0325] - PACTYP_MPEGH3DAFRAME

[0326] - PACTYP_AUDIOTRUNCATION

[0327] New packets o TIMESTAMP o GEOLOCATION o UUID o AUTHORIZATION

[0328] In some embodiments, the following packet types should be excluded from authentication:

[0329] - PACTYP_FILLDATA

[0330] - PACTYP_SYNC

[0331] - PACTYP_SYNCGAP

[0332] - PACTYP_CRC 16 / PACTYP_32

[0333] - PACTYP-GLOB AL_CRC 16 / PACTYP_GLOB AL_CRC32

[0334] - PACTYPJJSERINTERACTION

[0335] - PACTYP_GENDATA

[0336] - PACTYP_EARCON

[0337] PACTYP_PCMCONFIG D24051AW001

[0338] PACTYP_PCMDATA

[0339] The following packet types may be included or excluded, depending on circumstances and implementation requirements:

[0340] - PACTYP_MPEGH3DACFG

[0341] - PACTYP_AUDIOSCENEINFO

[0342] - PACTYP_MARKER

[0343] - PACTYP_DESCRIPTOR

[0344] - PACTYP_LOUDNESS_DRC

[0345] - PACTYP_BUFFERINFO

[0346] - PACTYP_GENDATA

[0347] MPEG-H MHAS Labels and Multistream

[0348] If authentication is deemed necessary for a complete MPEG-H stream (i.e., the sequence of complete MHAS PACTYP_FRAME), multi-stream use cases may need to be taken into account.

[0349] As a general consideration, MHASPacketLabels have assigned special purposes. Packets having their label set to 0 (e.g., 0x0) have a “global scope” (“Global authentication” - Label = 0).

[0350] Therefore, if authentication packets have their label set to 0, they apply to all media in the stream. This may imply multiple “main” streams.

[0351] When setting the MHASPacketLabel to a value different from 0, the authentication applies only to this “MHAS substream” (Multistream - Labels). While the main stream (which contains at least one complete experience per DVB) may get authenticated on its own, an auxiliary stream should only get authenticated in conjunction with its associated main stream, according to the association given by Table 13.

[0352] D24051AW001

[0353] Table 230 — Meaning of MHASPacketLabel in multi-stream environments

[0354] Table 13

[0355] For example, MHAS packets of type PACTYP_MPEGH3DAFRAME and MHASPacketLabel 0x13 shall require the time-aligned packet of same type and MHASPacketLabel 0x03.

[0356] Features and Advantages

[0357] The following features and advantages may apply to the techniques described above.

[0358] • The present disclosure proposes signaling to indicate which types of packets (e.g., MHAS packets) should be included in the hash calculation. This enables explicitly excluding packets which may be modified later by the system. Such a modified bitstream can still be verified, even if altered.

[0359] • Having the time-packet (e.g., PACTYP_TIMESTAMP) separate enables choice in using this as part of the authentication and therefore increases security by keeping flexibility.

[0360] • The present disclosure proposes to indicate in the auth-start and auth-sig package to signal a one-bit sequence number to indicate which auth-start and auth-sig belong together. This enables inclusion of one auth(sequence 1) packet into the hashing of auth(sequence 0) to enable chained authentication.

[0361] • The MHAS packet-label enables multiplexing different streams (with different packetlabel) to be in one bitstream but being secured individually. This may optionally include that sub-streams (marked e.g. by MHASPacketLabel in the range 0x11-0x20) are only validated in conjunction with their respective main stream (marked e.g. by MHASPacketLabel in the range 0x01-0x10) D24051AW001

[0362] Signaling of authProvID = 0 enables hashing without signature. This enables another tradeoff of between security and a mode that can work while being offline. Combination with the key-id (which may be distributed separately but securely) is another tradeoff.

[0363] • It is not necessarily the whole signature that is transported in the bitstream, but parts of it only. The method therefore differs in the way that the verification of a stream can also happen against (only) the bits which are transported. This enables a tradeoff between security and bitrate efficiency.

[0364] • In verification at the decoder side, in case the number of bits in the signature in mpegh3daAuthSig() (e.g., mhasProtBits) (e.g., 40 bits) is smaller than the number of bits in a digital signature according to the used algorithm (e.g., 256 bits), verification will only compare the value of the signature in mpegh3daAuthSig() with the least significant 40 bits of the digital signature resulting from the used algorithm. This enables the system to be more flexible and take tradeoffs between security and bitrate efficiency.

[0365] • The UUID may be used as a way to relate audio and video and other media to each other. However, transporting the UUID in one piece can cause high peak values of bitrate, because transporting 128 bytes in a single frame frequently will have a high impact on bitrate. Therefore, the present disclosure proposes to enable splitting up the UUID (e.g., 128 bytes) into chunks (or segments, or portions), so the impact on bitrate is lowered and bitrate is not “peaky”.

[0366] • The present disclosure provides an interface to the system that can be used to verify digital signatures in bitstreams. This is needed, since it cannot be expected by the system to be able to parse the MHAS bitstream correctly. Its structure is only known by the decoder.

[0367] Enumerated. Example Embodiments

[0368] Aspects and implementations of the present disclosure may also be appreciated from the following enumerated example embodiments (EEEs).

[0369] EEE-A1. A method to create (encode) or modify (insert) a media bitstream to include a digital signature information and a digital signature, in a way that the digital signature information and D24051AW001 the digital signature is split up into two different bitstream packets / payloads (authentication-start packet (e.g., first data packet) and an authentication-signature packet (e.g., second data packet)).

[0370] EEE-A2. The method of EEE-A1, wherein the authentication-start package contains at least one of types of bitstream packets to be taken into consideration and labels of sub-streams to be taken into consideration.

[0371] EEE- A3. The method of EEE- Al or EEE-A2, wherein the authentication stop-packet contains a digital signature or digital hash, or a subset of those.

[0372] EEE-A4. The method according to any one or EEE-A1 to EEE-A3, wherein the authenticationstart package indicates the beginning of the calculation of a hash or digital signature value.

[0373] EEE-A5. The method according to any one or EEE- Al to EEE-A4, wherein the authenticationstop package (e.g., as per EEE-A3) indicates the end of the calculation of a hash or digital signature value.

[0374] EEE-A6. The method according to any one or EEE- Al to EEE-A5, wherein the authentication package contains a sequence identifier allowing multiple concurrent or overlapping and chained authentication calculations.

[0375] EEE-A7. The method according to EEE-A6, wherein the sequence identifier is coded into one single bit.

[0376] EEE-A8. An apparatus or method to receive media bitstream, wherein the media bitstream contains digital signatures or hash values.

[0377] EEE-A9. The apparatus or method according to EEE-A7, wherein the digital signature or hash is divided into two packets; one of the packets called “Start” (e.g., as per EEE-A2) and one “stop” package (e.g., as per EEE-A3).

[0378] EEE-A10. The apparatus or method according to any one or EEE-A8 to EEE-A9, wherein the receiving device upon reception of a signature start package instantiates a signature or hash calculation module from the incoming media stream using the configuration parameters contained in the start package.

[0379] EEE-A11. The apparatus or method according to any one or EEE-A8 to EEE- A 10, wherein the receiving device upon reception of a signature stop package compares the received signature or D24051AW001 hash value from that package with the state of its calculation module and indicates a match of the received versus the calculated value.

[0380] EEE-A12. The apparatus or method according to any one or EEE-A8 to EEE-A11, wherein the receiving device supports multiple simultaneous calculations of digital signature or hash values.

[0381] EEE-A13. The apparatus or method according to any one or EEE-A8 to EEE-A12, wherein the individual calculations relate to identifiers in the authentication packets.

[0382] EEE-A14. The apparatus or method according to any one or EEE-A8 to EEE-A13, wherein start and stop packet of individual identifiers overlap in transmission to take a preceding signature or hash into the calculation of the subsequent value.

[0383] EEE-A15. The apparatus or method according to any one or EEE-A8 to EEE-A14, wherein the apparatus or method outputs additional side information received with the incoming media stream.

[0384] EEE-A16. The apparatus or method according to EEE-A15, wherein the additional side information contains information about at least one of time, geolocation, originator, authorization, or other data.

[0385] The EEE-As as set out above enable comparison of relevant bits of a digital signature against the transported signature bits.

[0386] Coding of Medical Signals (CoMS)

[0387] Authentication as defined above may be used not only for media signals (e.g., audio signals), but also for other signals, such as medical signals (MS), in particular medical or biomedical waveform data, such as medical sensor data, etc., haptic waveform data, or even seismic waveform data. Also here, authentication of this data, including for example their creator (e.g., sensor ID, sensor manufacturer, etc.), their time of creation, and / or their geolocation of creation, authorization, may be desirable.

[0388] While the description below may make reference to (bio)medical data, it is understood that this shall not be limiting and that the features described below may likewise apply to other data (e.g., waveform data), such as haptic and seismic signals, for example. D24051AW001

[0389] In line with the above, one or more of the aforementioned intermediate data packets may include (bio)medical signals or (bio)medical data. The data packets including the medical signals or medical data may be similar to MHAS data packets (in the sense that they use the structure of MHAS data packets as a blueprint), for example. This means that the signaling structures used for MHAS data packets may be repurposed for signaling (bio)medical signals, along with the authentication mechanism described above. The medical signals / data may relate to biomedical waveforms, for example.

[0390] In line with the above, techniques and mechanisms described in this section may be used to efficiently transport digital signatures and other related information (e.g., time stamps, geolocation information, authorization and user identifiers) in a bitstream including medical signals (e.g., medical or biomedical waveform data), for example a bitstream according to the H.BWC standard.

[0391] To deal with medical data (e.g., waveforms) and allow for meaningful encoding and authentication, a predefined data format or interface may be provided to the (core) encoder.

[0392] Accordingly, encoder side methods according to embodiments of the disclosure, such as method 210 of Fig. 2A may further include, when applied to (bio)medical signals or (bio)medical data, the steps of method 230 as shown in Fig. 2C. Method 230 includes steps S231 through S236. It is understood that the steps of method 230 may be performed in orders different from the one shown in Fig. 2C.

[0393] At step S231, the medical signals or medical data are received. The signals or data may be received for example from a medical sensor.

[0394] At step S232, the medical signals or medical data are provided together with the verification information to a core encoder, using a predefined data format.

[0395] The verification information may be determined (e.g., calculated) as described above, for example by calculating a hash value over the subset of intermediate data packets and either directly using the hash value as / for the verification information, or determining an authentication signature based on the hash value and using the authentication signature as / for the verification information. D24051AW001

[0396] Further, authorization information may be provided to the core encoder for embedding into the bitstream. For example, the authorization information may be embedded into one or more of the intermediate data packets. At decoding, after successful authentication, the authorization information may indicate whether the remaining data packets may be extracted or not, and / or whether they may be passed to the higher- level system. Alternatively, the authorization information may provide some guidance to the intended target audience that the content is targeting, or in general a group of intended / authorized recipients.

[0397] At step S233, the information indicating the subset of intermediate data packets is provided to the core encoder using the predefined data format.

[0398] In other words, a predefined interface may be used for providing the aforementioned items of information to the core encoder.

[0399] At step S234, the medical signals or medical data are embedded, by the core encoder, into one or more of the subset of intermediate data packets.

[0400] At step S235, the verification information is embedded, by the core encoder, into the second data packet.

[0401] At step S236, the information indicating the subset of intermediate data packets is embedded, by the core encoder, into the first data packet.

[0402] Basic Syntax

[0403] Similarly to MHAS, bitstream packets intended to be used for the above purpose may have a Type, Length, Value structure. Bitstream syntax examples are given in Table 14, Table 15, and Table 16 below.

[0404] Table 14 D24051AW001

[0405] Table 15

[0406] A possible alternative to the syntax example of Table 16 is given in Table 16a. The following definitions may apply to the syntax given above. msStreamPacketLabel This element provides an indication of which packets belong together. For example, with using different labels, different configuration structures may be assigned to particular sequences of access units. msStreamPacketLength This element indicates the length of the msStreamPacketPayload() in Bytes. D24051AW001 msStreamPacketPayload() The payload for the actual msStreamPacket. Table 17 provides an example of possible syntax.

[0407] Table 17

[0408] Field msStreamPacketType may be defined for example as shown in Table 18. D24051AW001

[0409] Table 18

[0410] Authentication Start Packet - MS AUTH START

[0411] The authentication start packet (as an example of the first data packet) may have properties and syntax as defined above for MHAS, with readily apparent modifications. An explicit example of syntax for the MS_AUTH_START packet is given in Table 19. D24051AW001

[0412] Table 19 aust_id indicates the combination of aust_hash_type, aust_prov_id and aust_key_id to which the related authentication information belongs to. This can be used to enable authentication of one authentication sequence with different authentication configurations. An example of alternative syntax for the MS_AUTH_START packet is given in Table 19a.

[0413] Table 19a D24051AW001

[0414] In line with the above, the first data packet may include some, any, or all of the following items of information.

[0415] Pairing Information - aust_sequence_id

[0416] First, mechanisms including examples of possible syntax for ensuring that MS_AUTH_START and MS_AUTH_SIG packets can be mapped together (e.g., linked or paired, as described above) in case they are overlapping will be described. In this case, packets of type MS_AUTH_SIG may be included into verification of the following temporal segment for enabling chained authentication.

[0417] For example, the syntax element sequence may be used to signal pairing information for linking the first and second data packets, which may become necessary if multiple pairs of first and second data packets are included in the bitstream, possibly with overlap between their respective intermediate data packets. It is understood that deviating from the above explicit example, other means of signaling the pairing information are feasible in the context of the present disclosure.

[0418] In general, the first data packet and the second data packet may each include pairing information for indicating that the second data packet includes the verification information for the subset of intermediate data packets indicated by the first data packet.

[0419] This allows for the one or more intermediate data packets to include a further second data packet that includes verification information for one or more data packets in the bitstream preceding the first data packet, provided that the further second data packet includes pairing information different from the pairing information of the first and second data packets.

[0420] The scheme proposed above may be used for chained authentication, in which verification information for a given set of data packets is itself made verifiable as part of a subsequent set of data packets. That said, the aforementioned further second data packet may be among the subset of intermediate data packets, so that the second data packet includes verification information also for the further second data packet.

[0421] For further details, reference is made to the above description for MHAS, with readily apparent modifications. D24051AW001

[0422] Packet Selection

[0423] Packet selection may be signaled and performed as described above for MHAS, with readily apparent modifications.

[0424] Hashing Algorithm Identification - aust_hash_type To ensure that the encoder and the decoder apply the same hashing function, method 210 of Fig. 2A or method 220 of Fig. 2B may further include embedding information identifying the hashing algorithm into the first data packet also when transporting and authenticating medical signals.

[0425] At decoding, this may entail a step of extracting, from the first data packet, the information identifying the hashing algorithm.

[0426] Table 20 gives an example of bitstream semantics that may be used for this purpose.

[0427] Table 20

[0428] Table 20a gives an example of alternative bitstream semantics that may be used for this purpose.

[0429] Table 20a For further details, reference is made to the above description for MHAS, with readily apparent modifications. D24051AW001

[0430] Key Identification - aust_key_id

[0431] To ensure that the encoder and the decoder apply the same or corresponding keys, method 210 of Fig. 2A or method 220 of Fig. 2B may further include embedding information identifying the encryption key into the first data packet also when transporting and authenticating medical signals.

[0432] At decoding, this may entail a step of extracting, from the first data packet, the information identifying the encryption key.

[0433] Table 21 gives an example of bitstream semantics that may be used for this purpose.

[0434] Table 21

[0435] The value of the aust_key_id field identifies the authentication key used to calculate the value of the signature field in authentication_signature_rbsp(). The values of aust_key_id are implementation dependent and are not defined in the present disclosure. This value shall be set to 0 in case there is no key needed of the underlying hash-function.

[0436] Table 21a gives an example of alternative bitstream semantics that may be used for this purpose.

[0437] Table 21a

[0438] For further details, reference is made to the above description for MHAS, with readily apparent modifications.

[0439] Authentication Provider Identification - aust_prov_id

[0440] To ensure that the decoder can, if the encoder uses a private key of a private-public key pair, obtain the corresponding public key as the decryption key, method 210 of Fig. 2A or method 220 of Fig. 2B may further include embedding information identifying an authentication authority in relation to the encryption key into the first data packet also when transporting and authenticating medical signals. D24051AW001

[0441] At decoding, this may entail a step of extracting, from the first data packet, the information identifying the authentication authority in relation to the encryption key.

[0442] Table 22 gives an example of bitstream semantics that may be used for this purpose.

[0443] Table 22

[0444] The value of aust_prov_id field identifies the provider of the authentication system, e.g. C2PA.

[0445] In case aust_prov_id equals 1, there is no provider. This mode can be used to create the message digest only by using the method identified by aust_hash_type, but without verification. This method can for example be used in closed ecosystems, where keys can be made available without a third party involved, e.g., by appropriate key exchange techniques.

[0446] Table 22a gives an example of alternative bitstream semantics that may be used for this purpose.

[0447] Table 22a

[0448] For further details, reference is made to the above description for MHAS, with readily apparent modifications.

[0449] Consideration of Multiple Sub-Streams - aust_add_packet_label

[0450] In the above example, the value of aust_add_packet_label indicates that the MS sub- stream with this packet label shall be included in the calculation of the authentication hash in addition to the MS stream with the same msPacketLabel as assigned to the MS_AUTH_START packet. Even with multiple sub-streams, hashing of packets shall be calculated in order of appearance in the stream.

[0451] Notably, MSPacketLabel equal to 0 already indicates that all sub-streams are included. In this case, aust_add_packet_label are not needed. D24051AW001

[0452] For further details, reference is made to the above description for MHAS, with readily apparent modifications.

[0453] Authentication Signature Packet - MS A UTH SIG

[0454] The authentication signature packet (as an example of the second data packet) may have properties and syntax as defined above for MHAS, with readily apparent modifications.

[0455] An explicit example of syntax for the MS_AUTH_SIG packet is given in Table 23.

[0456] Table 23

[0457] For a description of ausig_id, see aust_id.

[0458] An example of alternative syntax for the MS_AUTH_SIG packet is given in Table 23a. D24051AW001

[0459] Table 23a

[0460] Also when transporting and authenticating medical signals, in some embodiments, the verification / authentication information may be split over several second data packets to avoid bitrate peaks in case of larger authentication signatures. For further details, reference is made to the above description for MHAS, with readily apparent modifications.

[0461] Identifier Packets - MS UUID U and MS UUID S

[0462] Also when transporting and authenticating medical signals, the bitstream may include data packets including a UUID or a partial UUID. Table 24 and Table 25 give examples of possible syntax, with the syntax of Table 25 allowing for a partial UUID.

[0463] Table 24

[0464] Table 25

[0465] Table 24a and Table 25a give examples of alternative syntax, with the syntax of Table 25a allowing for a partial UUID. D24051AW001

[0466] Table 24a

[0467] Table 25a

[0468] For further details, reference is made to the above description for MHAS, with readily apparent modifications. Timestamp Packages - MS TIMESTAMP

[0469] Also when transporting and authenticating medical signals, the bitstream may include data packets including a timestamp. Table 26 gives an example of bitstream syntax that may be used for this purpose. D24051AW001

[0470] Table 26

[0471] In Table 26, field ts_timc_typc may be defined for example as shown in Table 27.

[0472] Table 27 ts_offset_type_flag may indicate the unit of ts_timc_offsct value. May be set to ‘0’ if the unit is miliseconds. May be set to ‘1’ for using the configured sampling rate of the underlying signal type as base time. ts_time may be counted in seconds and the count may start on January 1st, 2025 at 00.00.01 UTC, for example. D24051AW001 ts_time_offset may specify an offset of time, added to ts_timc or ts_timc_short respectively, in unit signaled by ts_offest_type_flag. ts_time_short may indicate the time, in seconds, elapsed since last “ts_time_type = = TimeLong”-update. ts_time_tai may be specified according to ISO / IEC 23001-17. ts_status_bits may be specified according to the bits synchronization_state, timestamp_generation_failure, timestamp_is_modified and reserved according to ISO / IEC 23001-17.

[0473] The time may be be set in a way that ts_time + ts_timc_offsct indicates the time when the first sample of following IF_SPT or DF_SPT with the same stream_packet_label has been recorded.

[0474] In case the stream_packet_label is set to a value of 0, the time may apply to the first sample of the first IF_SPT packet of any stream_packet_label.

[0475] Table 26a gives an example of alternative bitstream syntax that may be used for this purpose. D24051AW001

[0476] J

[0477] Table 26a

[0478] In Table 26a, field msTimeType may be defined for example as shown in Table 27a.

[0479] Table 27a msTime may be counted in seconds and the count may start on January 1st, 2024 at UTC, for example. msTimeS may give the time elapsed since the last “msTimeType == 0”-update. msTimeOffsetMS may give an offset in milliseconds, where msTime + msTimeOffsetMS indicates the timestamp of the first sample of the following PACTYP_FRAME. Field TAI_timestamp may be according to 23001-17. Two data structures support TAI timestamps:

[0480] 1) TAIClocklnfoBox: describes the TAI clock generating timestamps.

[0481] 2) TAITimestampPacket: contains a timestamp and quality status for the timestamp.

[0482] Field status_bits may be according to ISO / IEC 23001-17. D24051AW001

[0483] For further details, reference is made to the above description for MHAS, with readily apparent modifications.

[0484] Geolocation Packages - MS GEOLOCATION

[0485] Also when transporting and authenticating (bio)medical signals, the bitstream may include data packets including an indication of a geolocation. Table 28 gives an example of bitstream syntax that may be used for this purpose.

[0486] Table 28

[0487] For further details, reference is made to the above description for MHAS, with readily apparent modifications.

[0488] Authorization Packages

[0489] Also when transporting and authenticating medical signals, the bitstream may include data packets including authorization information. For details, reference is made to the above description for authorization information in the context of MHAS.

[0490] Features and Advantages

[0491] In addition to the features and advantages listed above for MHAS, the following features and advantages apply when transporting and authenticating medical signals.

[0492] • The bitstream is not limited to a media bitstream, but can be medical, haptic, seismic, etc. waveforms.

[0493] • The bitstream can also include a user-id, to authenticate the user, a combination of user and device, and / or a device. D24051AW001

[0494] AAC Digital Media Authentication

[0495] This section describes mechanisms to efficiently transport digital signatures and other related information (e.g., time stamps and user identifiers) in AAC bitstreams. Part of what is described below analogously applies to US AC bitstreams.

[0496] While this section makes frequent reference to bitstream elements and processes of operating on bitstream elements, it is understood that the present disclosure is not so limited and is likewise applicable to other bitstream formats and codecs.

[0497] An example method 2010 of generating or modifying a bitstream comprising a plurality of bitstream elements (as in an AAC framework, for example) is illustrated by the flowchart of Fig. 2G. The packet-based bitstream may be a media bitstream, for example. In particular, the packet-based bitstream may be an MPEG-4 bitstream. Further, the bitstream may be an AAC bitstream (e.g., AAC-LC or HE-AAC). It is noted however that method 2010 may be likewise applied to a USAC bitstream, unless indicated otherwise.

[0498] At step S2011, a first bitstream element and a second bitstream element are provided. Providing bitstream elements may relate to generating said bitstream elements, and / or inserting said bitstream elements into the bitstream.

[0499] The first and second bitstream elements are provided such that they are separated in the bitstream by one or more intermediate bitstream elements. Therein, the second bitstream element includes verification information for a subset of intermediate bitstream elements among the one or more intermediate bitstream elements. The first bitstream element may be seen as an indication that the bitstream includes the subset of intermediate bitstream elements after the first bitstream element and before the second bitstream element that shall be verifiable. The first and second bitstream elements thus serve as a form of “bracket” for the bitstream elements that shall be verifiable. This verification information may relate to an authentication signature, for example. Specifically, the verification information may comprise the authentication signature, or at least a portion thereof.

[0500] The one or more intermediate bitstream elements may also include one or more fill elements.

[0501] These fill elements are not included in the subset of intermediate bitstream elements, i.e., are not subject to verification / authentication. D24051AW001

[0502] Method 2020 illustrated in Fig. 2H includes example details of method 2010 for providing the first and second bitstream elements. It is understood that the steps of method 2020 may be performed in orders different from the one shown in Fig. 2H.

[0503] At step S202 I . a hashing algorithm is applied to the subset of intermediate bitstream elements to generate a hash value.

[0504] Any suitable hashing algorithm may be used for this purpose, including, without intended limitation, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.

[0505] At step S2022, an authentication signature is generated based on the hash value and an encryption key. The aforementioned verification information may relate to this authentication signature. In particular, it may comprise the authentication signature, or at least a portion thereof.

[0506] The encryption key used for this purpose may be a private key of a private-public key pair. Alternatively, the encryption key may be identical to a decryption key, and may be exchanged in an appropriate manner between the encoder side and the decoder side before decoding.

[0507] At step S2023, the verification information is embedded into the second bitstream element.

[0508] In some implementations, the hash value generated at step S2021 may be directly embedded into the second bitstream element at step S2023, instead of the authentication signature. In this case, step S2022 may be omitted.

[0509] Although not shown in Fig. 2H, the method may further include a step of embedding information identifying the subset of intermediate data packets into the first bitstream element or into another bitstream element that is in a fixed order relationship to the first bitstream element in the bitstream. Here, embedding the information identifying the subset of intermediate data packets into another bitstream element that is in a fixed order relationship to the first bitstream element may relate to an AAC bitstream, where the other bitstream element that is in a fixed order relationship to the first bitstream element may be a program configuration element (PCE). On the other hand, embedding the information identifying the subset of intermediate data packets into the first bitstream element may relate to a USAC bitstream.

[0510] Although not shown in Fig. 2H, method 2010 may also foresee providing overlapping pairs of first and second bitstream elements. In other words, the method may further comprise providing a third bitstream element and a fourth bitstream element, wherein the third bitstream element and D24051AW001 the fourth bitstream element are separated in the bitstream by one or more second intermediate bitstream elements, and wherein the fourth bitstream element includes second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements. In this case, the method may also include embedding information identifying the subset of second intermediate data packets into the third bitstream element or into another bitstream element that is in a fixed order relationship to the third bitstream element in the bitstream. In this configuration, the one or more intermediate bitstream elements and the one or more second intermediate bitstream elements may be at least partially overlapping. This partial overlap allows for providing chained authentication throughout the bitstream or extended portions thereof.

[0511] An example method 2030 of decoding a bitstream comprising a plurality of bitstream elements (in an MPEG-4 and / or A AC framework, for example) is illustrated by the flowchart of Fig. 21. The bitstream may be a media bitstream, for example. In particular, the bitstream may be an AAC bitstream (e.g., HE-AAC or AAC-LC). Therefore, the decoding of media and auxiliary content (i.e., the authentication information) in the bitstream may be MPEG-4 / AAC based decoding. It is noted however that method 2030 may be likewise applied to a USAC bitstream, unless indicated otherwise.

[0512] It is noted that methods of decoding bitstreams as described throughout the disclosure may operate on bitstreams output by corresponding methods of encoding, and that these methods include corresponding steps, unless indicated otherwise. Detailed description of corresponding steps at decoding may be omitted, for reasons of conciseness.

[0513] At step S2031, a first bitstream element and a second bitstream element, and one or more intermediate bitstream elements separating the first bitstream element and the second bitstream element in the bitstream are decoded from the bitstream. Therein, the second bitstream element includes verification information for a subset of intermediate bitstream elements among the one or more intermediate bitstream elements.

[0514] At step S2032, the subset of intermediate bitstream elements is verified / authenticated using the verification information.

[0515] The verification information may relate to an authentication signature, as noted above.

[0516] Specifically, the verification information may comprise the authentication signature or part D24051AW001 thereof. Verifying the subset of intermediate bitstream elements at step S2032 may use the authentication signature.

[0517] In case the encoding operation includes providing third and fourth bitstream elements, this may be mirrored by the decoding method 2030 including a step of decoding, from the bitstream, a third bitstream element and a fourth bitstream element, wherein the third bitstream element and the fourth bitstream element are separated in the bitstream by one or more second intermediate bitstream elements, and wherein the fourth bitstream element includes second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements. As described above, the one or more intermediate bitstream elements (between the first and second bitstream elements) and the one or more second intermediate bitstream elements may be at least partially overlapping.

[0518] Further, method 2030 may include decoding, from the bitstream, information identifying the subset of second bitstream elements from the third bitstream element or from another bitstream element that is in a fixed order relationship to the third bitstream element. Finally, the method may also include verifying the subset of second intermediate bitstream elements using the second verification information.

[0519] Method 2040 illustrated in Fig. 2J includes example details of method 2030 for verifying / authenticating the subset of intermediate bitstream elements. It is understood that the steps of method 2040 may be performed in orders different from the one shown in Fig. 2J.

[0520] Method 2040 may include a preparatory step (not shown in Fig. 2J) of extracting information identifying the subset of intermediate data packets from the first bitstream element or from another bitstream element that is in a fixed order relationship to the first bitstream element in the bitstream.

[0521] The former option may relate to US AC. For AAC, the information identifying the subset of intermediate data packets may be extracted from the other bitstream element that is in a fixed order relationship to the first bitstream element. In particular, the first bitstream element may be subsequent in the bitstream to a configuration element (e.g., PCE) that includes reference information referencing one or more bitstream elements among the intermediate bitstream elements as the subset of bitstream elements. Here, subsequent may be understood to mean immediately subsequent. D24051AW001

[0522] At step S204 I . a hashing algorithm is applied to the subset of intermediate bitstream elements to generate a hash value.

[0523] The hashing algorithm used for this purpose may have been agreed upon previously with the encoder side or may be indicated by the first bitstream element. It is understood that this hashing algorithm is identical to (or yields identical results as) the hashing algorithm used at step S2021 above.

[0524] At step S2042. the verification information is extracted from the second bitstream element. This verification information may relate to an authentication signature, as described above.

[0525] At step S2043, the subset of intermediate bitstream elements is verified / authenticated based on the authentication signature, the generated hash value, and a decryption key.

[0526] If the hash value instead of the authentication signature had been embedded into the second data packet at step S2023, instead of the authentication signature, the subset of intermediate bitstream elements may be verified at step S2043 based on the hash value generated at step S2031 and the hash value extracted from the second bitstream element.

[0527] The decryption key used for the aforementioned purpose may be a public key of a private-public key pair. The private-public key pair may be a key pair including a private key that has been used for generating the authentication signature, e.g., at step S2022. The public key may be obtainable from a trusted authority, or directly from the encoder side. Alternatively, the decryption key may be identical to the encryption key, and may have been exchanged in an appropriate manner between the encoder side and the decoder side before decoding.

[0528] Program Configuration Elements

[0529] As noted above, method 2020 may include a step (not shown in Fig. 2H) of embedding information identifying the subset of intermediate data packets into the first bitstream element or into another bitstream element that is in a fixed order relationship to the first bitstream element in the bitstream. Of these two options, the latter option may relate to an A AC bitstream, where the other bitstream element that is in a fixed order relationship to the first bitstream element may be a PCE. The former option may relate to a USAC bitstream.

[0530] Specifically, in AAC, the first bitstream element may be subsequent (i.e., immediately subsequent) in the bitstream to a configuration element (e.g., PCE) that includes reference D24051AW001 information referencing one or more bitstream elements among the intermediate bitstream elements as the subset of bitstream elements.

[0531] While the first bitstream element may immediately follow the configuration element, they may be additionally linked by their element tags. That is, each bitstream element of the bitstream may include an element tag, and element tags of the first bitstream element and the configuration element may be identical. The element tag may be an element instance tag (element_instance_tag), for example.

[0532] Fig. 4A shows an example of using the PCE for referencing the bitstream elements that shall be verifiable. This example may be applicable to AAC-LC.

[0533] In this example, the first bitstream element 410 (DSE) is preceded by PCE 450, both of which have element instance tag el_inst_tag==2. The matching element instance tag can be used to determine which PCE belongs to which first bitstream element, especially if (unlike in the present example) more than one PCE should be present in the frame of interest. The bitstream also includes a second bitstream element (not shown), and bitstream elements between the first and second bitstream elements are shown as intermediate bitstream elements 430 in the figure. PCE 450 references a subset of intermediate bitstream elements 440, for which the second bitstream element will include the verification information. The PCE 450 may reference bitstream elements by counting them in order of appearance (i.e., include a set of numbers corresponding to order positions of respective bitstream elements). Notably, the subset of intermediate bitstream elements 440 does not include the channel pair element (CPE) that relates to a mixdown channel (the last bitstream element before “TERM” in Fig. 4A).

[0534] In the example of Fig. 4A, the element instance tags of the intermediate bitstream elements 330 are not used.

[0535] Fig. 4B shows another example of using the PCE for referencing the bitstream elements that shall be verifiable. This example may be applicable to HE-AAC. Description of details that are similar to Fig. 4A may be omitted for reasons of conciseness.

[0536] Again, the first bitstream element 410 is preceded by PCE 450, both of which have element instance tag el_inst_tag==2. The bitstream also includes a second bitstream element (not shown), and bitstream elements between the first and second bitstream elements are shown as D24051AW001 intermediate bitstream elements 430 in the figure. Different from Fig. 4A, the intermediate bitstream elements 430 now include a plurality of fill elements (FIL) 460 that may or may not occur between certain bitstream elements. PCE 450 again references a subset of intermediate bitstream elements 440, for which the second bitstream element will include the verification information. The PCE 450 may reference bitstream elements by counting them in order of appearance (i.e., include a set of numbers corresponding to order positions of respective bitstream elements). Notably, the subset of intermediate bitstream elements 440 does not include any fill elements 460, and it does not include the channel pair element (CPE) that relates to a mixdown channel (the last bitstream element before “TERM” in Fig. 4B).

[0537] Also in the example of Fig. 4B, the element instance tags of the intermediate bitstream elements 330 are not used.

[0538] With regard to decoding, method 2040 may include a preparatory step (not shown in Fig. 2J) of decoding, from the bitstream, a configuration element preceding (i.e., immediately preceding) the first bitstream element, wherein the configuration element includes reference information referencing one or more bitstream elements among the intermediate bitstream elements as the subset of bitstream elements. In other words, information identifying the subset of intermediate data packets may be extracted from the configuration element (which is a bitstream element that is in a fixed order relationship to the first bitstream element in the bitstream). Apart from (immediately) preceding the first bitstream element, the configuration element may be identified by the fact that element tags (e.g., element instance tags (element_instance_tag)) of the first bitstream element and the configuration element are identical.

[0539] Fig. 4C shows an example that uses multiple PCEs. Details as described below may apply to both a bitstream with and without fill elements.

[0540] Contrary to Fig. 4A and Fig. 4B, the element instance tags are now used to define different programs (e.g., stereo programs), one with el_inst_tag==O (here denoted program A) and one with el_inst_tag==l (here denoted program B). The first bitstream element 410 of program A has el_inst_tag==O and is preceded by its corresponding PCE 450 that also has el_inst_tag==O. The first bitstream element 410’ for program B has el_inst_tag==l and is preceded by its corresponding PCE 450’ that also has el_inst_tag==l. Both first bitstream elements 410, 410’ have respective corresponding second bitstream elements that are not shown in the figure. D24051AW001

[0541] Importantly, the second bitstream element of program A (that corresponds to the first bitstream element 410 of program A) includes verification information for the subset of intermediate bitstream elements 440 (with el_inst_tag==O) referenced by PCE 450 of program A, and the second bitstream element of program B (that corresponds to the first bitstream element 410’ of program B) includes verification information for the subset of intermediate bitstream elements 440’ (with el_inst_tag==l) referenced by PCE 450’ of program B.

[0542] Basic Syntax: Authentication Extension Payload.

[0543] The first bitstream element and the second bitstream element introduced above may be of a same bitstream element type (e.g., in an MPEG-4 framework). For example, both may be a data_stream_element() (DSE), in particular a DSE of type auth_extension. To distinguish these bitstream elements from one another, the first bitstream element and the second bitstream element may differ in a set value of a predefined parameter or bit field. The predefined parameter or bit field may relate to an authExtType syntax element, for example, such as a 7-bit syntax element. An example of possible syntax for the auth_extension() element is given in Table 29a. D24051AW001

[0544] Table 29a

[0545] An example of possible syntax for the authExtConfigAAC() element is given in Table 29b.

[0546] Table 29b

[0547] In the example of Table 29b, authExtlnclusion signals whether the listed extension types (e.g., extension types according to 14496-3:2019, Table 4.127) should be included into or excluded from the hashing function. If set to 1, all packet types signaled in authExtType shall be included into the hash-calculation. If set to 0, all packet types signaled in authExtType shall be excluded from the hash-calculation.

[0548] Further functionalities and semantics for authExtensionTypes in Table 29b may be in analogy to what has been described above for MHAS in relation to Table 2.

[0549] Semantics for the above syntax example may be as follows. ext_payload_sync set to OxXX (OxBD is used for MPEG4_ancillary_data() ); only needed for DSE, not FIL_element D24051AW001

[0550] If program_config_elements (PCE) are used, the element carrying the authentication data shall directly follow the PCE it refers to. In this case, the following may apply:

[0551] The element_instance_tag of the extension shall be equal to that of the PCE. only those SCE, CPE, CCE and LFE elements that are referred to in the PCE via their element_instance_tag shall be used to calculate the hash. Other elements including the FIL elements carrying extension like SBR data, mixdown channel elements and other associated data elements shall not be used to calculate the hash value.

[0552] Authentication Start Element -AUTH START

[0553] In some embodiments, the aforementioned first bitstream element packet may be an auth_extension DSE where field authExtType is set to indicate AUTH_START.

[0554] Compared to MPEG-H, AAC does not provide the concept of MHAS Packet Types, nor Labels. Therefore, compared to the syntax example of Table 2, authPacketType and authPacketLabel (including their list-length indicators) can be removed from (the AAC equivalent of) mpegh3daAuthStart for AAC.

[0555] Still, AAC provides multi-program capabilities through the Program Config Element. Therefore, if PCE elements are used, an AUTH_START-element immediately following the PCE shall take only those elements into account for hash calculation that are listed in the PCE.

[0556] Thus, as noted above, in AAC the first bitstream element may be subsequent (i.e., immediately subsequent) in the bitstream to a configuration element (e.g., PCE) that includes reference information referencing one or more bitstream elements among the intermediate bitstream elements as the subset of bitstream elements.

[0557] Unless indicated otherwise, details as described above for MPEG-H / MHAS are understood to apply to AAC as well, with evident replacement of data packets by bitstream elements.

[0558] Pairing Information - sequence

[0559] As in the MPEG-H case, the first and second bitstream elements may include pairing information (e.g., sequence bit flag in the above example syntax for the auth_extension DSE) for indicating that the second bitstream element includes the verification information for the subset of intermediate data packets between the first bitstream element and the second bitstream element, D24051AW001 specifically, the verification information for the subset of intermediate data packets referenced by the configuration element preceding the first bitstream element. This allows to determine which second bitstream element belongs to which first bitstream element even in an overlapping sequential arrangement of pairs of respective first and second bitstream elements. By such sequential arrangement of pairs of respective first and second bitstream elements, chained authentication throughout the entire bitstream or portions thereof beyond segments / frames can be achieved, as described above with reference to, for example, Fig. 5A.

[0560] When using the pairing information, the one or more intermediate bitstream elements may include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding the first bitstream element (and preceding the aforementioned configuration elements), provided that the further second bitstream element includes pairing information different from the pairing information of the first and second bitstream elements. If the further second bitstream element is among the subset of intermediate bitstream elements, so that the second bitstream element includes verification information also for the further second bitstream element, this may correspond to chained authentication.

[0561] When using pairing information and configuration elements in AAC, the following details may apply to the case of providing first to fourth bitstream elements as described above for method 2010. As noted above, the fourth bitstream element includes second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements. The subset of second bitstream elements are identified by the third bitstream element being subsequent in the bitstream to a second configuration element that includes reference information referencing one or more bitstream elements among the second intermediate bitstream elements as the subset of second bitstream elements.

[0562] In term of pairing information, the first and second bitstream elements may include matching pairing information (e.g., authSequence==0x0), and also the third and fourth bitstream elements may include matching pairing information (e.g., authSequence==Oxl), but the pairing information of the first and second bitstream elements is different from the pairing information of the third and fourth bitstream elements.

[0563] Element tags may be used to ensure that the configuration elements can be correctly mapped to pairs of first and second bitstream elements (e.g., AUTH_START and AUTH_SIG elements). In D24051AW001 the above illustrative example, element tags of the third bitstream element and the second configuration element may be identical, and may be different from the element tags of the first bitstream element and the second bitstream element.

[0564] Fig. 4D shows an example of overlapping pairs of first and second bitstream elements and chained authentication for AAC. The figure shows two temporal frames of the bitstream. A first bitstream element (e.g., AUTH_START element) 410 is preceded by a PCE 450 and is separated from a second bitstream element (e.g., AUTH_STOP or AUTH_SIG) 420 by a number of intermediate bitstream elements 430. Both the first and second bitstream elements 410, 420 have matching pairing information “authSequence=0”. Importantly, the intermediate bitstream elements 330 include a (further) second bitstream element 420’ from a preceding pair of first and second bitstream elements, as well as a (further) first bitstream element 410” from a subsequent pair of first and second bitstream elements. This (further) first bitstream element 410” has a corresponding (further) PCE 450”. The second bitstream element 420 includes verification information for a subset of intermediate bitstream elements among the intermediate bitstream elements 330. This subset includes, in addition to any bitstream elements referenced by the PCE 450, at least the (further) second bitstream element 420’ from the preceding pair of first and second bitstream elements.

[0565] To avoid repetition, reference is made to the above description of MHAS or further details on pairing information.

[0566] Element Selection

[0567] In AAC, the intermediate bitstream elements may include one or more of a single channel element, SCE, a channel pair element, CPE, and a low frequency element, LFE.

[0568] If necessary, a selection among the aforementioned bitstream elements may be made via configuration elements (e.g., PCEs), as described above.

[0569] In some embodiments, if the aforementioned elements include a CPE corresponding to a mixdown channel, said mixdown channel may be excluded from verification, i.e., the CPE corresponding to the mixdown channel shall not be included in the subset of intermediate bitstream elements. D24051AW001

[0570] Hashing Algorithm Identification - authHashType

[0571] To ensure that the encoder and the decoder apply the same hashing function, method 2020 of Fig. 2G may further include embedding information identifying the hashing algorithm into the first bitstream element (e.g., auth_extension DSE with authExtType==AUTH_START). This may be done using field authHashType in the above example syntax for the auth_extension DSE.

[0572] At decoding, this may entail a step of extracting, from the first bitstream element, the information identifying the hashing algorithm.

[0573] To avoid repetition, reference is made to the above description of MHAS for further details on hashing algorithm identification, with evident replacement of data packets by bitstream elements.

[0574] Key Identification - authKeylD

[0575] To ensure that the encoder and the decoder apply the same or corresponding keys, method 2020 of Fig. 2G may further include embedding information identifying the encryption key into the first bitstream element (e.g., auth_extension DSE with authExtType==AUTH_START). This may be done using field authkeylD in the above example syntax for the auth_extension DSE.

[0576] At decoding, this may entail a step of extracting, from the first bitstream element, the information identifying the encryption key.

[0577] To avoid repetition, reference is made to the above description of MHAS for further details on key identification, with evident replacement of data packets by bitstream elements.

[0578] Authentication Provider Identification - authAuthProvID

[0579] To ensure that the decoder can, if the encoder uses a private key of a private-public key pair, obtain the corresponding public key as the decryption key, method 2020 of Fig. 2G may further include embedding information identifying an authentication authority in relation to the encryption key into the first bitstream element (e.g., auth_extension DSE with authExtType==AUTH_START). This may be done using field authAuthProvID in the above example syntax for the auth_extension DSE.

[0580] At decoding, this may entail a step of extracting, from the first bitstream element, the information identifying the authentication authority in relation to the encryption key. D24051AW001

[0581] To avoid repetition, reference is made to the above description of MHAS for further details on authentication provider information, with evident replacement of data packets by bitstream elements.

[0582] Authentication Identification - authlD authlD may be used to identify the combination of authHashType, authProvID and authKeylD to which the related authentication information belongs to. This may enable authentication of one authentication sequence with different authentication configurations.

[0583] Authentication Signature Element -AUTH SIG

[0584] In some embodiments, the aforementioned second bitstream element may be an auth_extension DSE where field authExtType is set to indicate AUTH_SIG.

[0585] As noted above, the second bitstream element (e.g., auth_extension DSE with authExtType==AUTH_SIG) includes the verification / authentication information needed for verifying / authenticating the relevant bitstream packets at the decoder.

[0586] In some embodiments, the verification / authentication information may be split over several second bitstream elements to avoid bitrate peaks in case of larger authentication signatures.

[0587] Then, verification information may relate to a portion of an authentication signature. For enabling reconstruction of the complete authentication signature, the second bitstream element may also include verification splitting information indicative of a relationship between the portion of the authentication signature and the complete authentication signature. For example, the verification splitting information may indicate storage locations of remaining / complementary portions of the authentication signature in the bitstream.

[0588] At decoding, the decoding method may include additional steps of extracting the verification information and the verification splitting information from the second bitstream element, and reconstructing the authentication signature based at least in part on the verification information and the verification splitting information. As noted above, the verification splitting information may for example indicate storage locations of remaining / complementary portions of the authentication signature in the bitstream, so as to allow reconstruction of the complete authentication signature. D24051AW001

[0589] Unless indicated otherwise, details as described above for MPEG-H / MHAS are understood to apply to AAC as well, with evident replacement of data packets by bitstream elements.

[0590] Identifier Elements - A UTH UU1D

[0591] In some cases, it may be desirable to include an indication of an origin or creator of the bitstream into the bitstream and to provide authentication for this information.

[0592] Accordingly, for the methods proposed herein, the subset of intermediate bitstream elements may include a bitstream element that contains identification information indicative of a UUID (e.g., auth_extension DSE with authExtType==AUTH_UUID). This UUID may be an identifier of a device or user (e.g., content creator) that has generated (or modified) the bitstream, for example.

[0593] At decoding, the method proposed herein may further comprise extracting the identification information from the bitstream (e.g., from the aforementioned bitstream element).

[0594] Also the UUID may be segmented and distributed over multiple bitstream elements to avoid bitrate peaks.

[0595] To this end, the subset of intermediate bitstream elements may include a bitstream element that contains identification information indicative of a portion of a UUID and that further contains identification splitting information indicative of a relationship between the portion of the UUID and the complete UUID. The portion of the UUID may be a segment of the UUID, for example.

[0596] At decoding, this may entail additional steps of extracting the identification information and the identification splitting information, and reconstructing the UUID based at least in part on the identification information and the identification splitting information.

[0597] Embedding the UUID into the bitstream can be used to identify provider of stream (e.g., used encoder). This may be useful in case no authentication signature but only the hash value is embedded in the second bitstream elements.

[0598] In some embodiments, the aforementioned bitstream element may be an auth_extension DSE where field authExtType is set to indicate AUTH_UUID.

[0599] Table 29c gives an example of possible syntax for signaling the UUID. D24051AW001

[0600] Table 29c

[0601] Unless indicated otherwise, details as described above for MPEG-H / MHAS are understood to apply to AAC as well, with evident replacement of data packets by bitstream elements.

[0602] Timestamp Elements - AUTH TIME

[0603] In some cases, it may be desirable to include an indication of point in time at which the bitstream has been generated or last modified, and to provide authentication for this information.

[0604] Accordingly, for the methods proposed herein, the subset of intermediate bitstream elements may include a bitstream element that contains timestamp information. The timestamp information may be indicative of, for example, a number of seconds that have elapsed after a predefined point in time. The timestamp information may be indicative of a point in time at which the bitstream has been generated or last modified, for example.

[0605] At decoding, this may entail an additional step of extracting the timestamp information from the bitstream (e.g., from the aforementioned bitstream element).

[0606] In some embodiments, the aforementioned bitstream element may be an auth_extension DSE where field authExtType is set to indicate AUTH_TIME.

[0607] Unless indicated otherwise, details as described above for MPEG-H / MHAS are understood to apply to AAC as well, with evident replacement of data packets by bitstream elements.

[0608] Geolocation Elements - AUTH GEOLOCATION

[0609] In some cases, it may be desirable to include an indication of an origin location (e.g., geolocation) of the bitstream into the bitstream and to provide authentication for this information.

[0610] Accordingly, for the methods proposed herein, the subset of intermediate bitstream elements may include a bitstream element that contains geolocation information. The geolocation information D24051AW001 may be indicative of a geolocation at which the bitstream has been generated or last modified, for example.

[0611] At decoding, this may entail an additional step of extracting the geolocation information from the bitstream (e.g., from the aforementioned bitstream element).

[0612] In some embodiments, the aforementioned bitstream element may be an auth_extension DSE where field authExtType is set to indicate AUTH_GEOLOCATION.

[0613] Unless indicated otherwise, details as described above for MPEG-H / MHAS are understood to apply to AAC as well, with evident replacement of data packets by bitstream elements.

[0614] Authorization Elements -AUTH AUTHORIZATION

[0615] In some cases, it may be desirable to include authorization information into the bitstream and to provide authentication for this information.

[0616] Accordingly, for the methods proposed herein, the intermediate bitstream elements (or the subset of intermediate bitstream elements) may include a bitstream element that contains authorization information. The authorization information may indicate an access restriction to (payload) data included in one or more of the remaining intermediate bitstream elements (or of remaining ones of the subset of intermediate bitstream elements). The authorization information may be indicative of the intended target audience or group of recipients that the data or media or content transported by the bitstream is targeting. This information may be set by the content creators or service providers upon examining the nature of the content, for example.

[0617] In particular, the authorization information in a bitstream element among the intermediate data packets may be indicative of a group of authorized recipients of the payload data of one or more bitstream elements among the intermediate bitstream elements (or among the subset of intermediate bitstream elements), or may be indicative of any other form of access restriction to said payload data.

[0618] At decoding, this may entail an additional step of extracting the authorization information from the bitstream (e.g., from the aforementioned data packet). D24051AW001

[0619] Authentication Interface

[0620] Also for AAC, it may be advantageous to define a specific data format or data interface that the (core) decoder can use to provide decoded data to the higher-level system, to be able to verify digital signatures in bitstreams, since the (core) decoder is typically not able to calculate hash values and verify authentication signatures, while the higher-level system is typically not able to correctly parse and decode the bitstream. This interface may be called whenever a second bitstream element is encountered in the bitstream and may be pre-stored at the (core) decoder. The interface shall be provided by the decoder to the system.

[0621] Accordingly, methods proposed herein, such as method 2030 of Fig. 21, may further include the step of method 2050 as shown in Fig. 2K. Method 2050 includes step S2051.

[0622] At step S2051, upon detection of the second bitstream element in the bitstream, the verification information and the subset of intermediate bitstream element are output, by a core decoder, for subsequent verification of the subset of intermediate data packets, using a predefined data format. In other words, a predefined interface may be used for providing this information by the core decoder.

[0623] When there are pairs of first and second bitstream elements with different sequence label (or pairing information), the verification information and the subset of intermediate bitstream elements may be output, using the predefined data format, separately for different (values of) pairing information.

[0624] Table 29d gives an example of bitstream syntax that may be used for this purpose.

[0625] Table 29d

[0626] Field gad_bytesLengthMinusl may give the length of bytes (minus 1) of the gad_bytes field. The gad_bytes field includes all bytes relevant for the creation of the authentication information D24051AW001 according to the configuration described in authExtConfigAAC(). The decoder shall concatenate all bytes (gad_bytes) relevant for creating the hash (as signaled in authExtConfigAAC()) and provide it to the system.

[0627] One example embodiment of using the authentication interface may be as follows. The decoder shall extract all data related to media authentication for every authentication sequence as indicated by authlD and authSequence, and populate the respective fields in mpeg4audio_GetAuthData() . authExtConfigAACO and authExtSigO for the related authentication sequence (as indicated by the respective authlD and authSequence) shall be copied from the respective bitstream elements. authTimestampO having the same authlD as the current authentication sequence and authUUID() syntax elements shall always be copied from the latest occurrences in bitstream. The gad_bytes field shall be populated by concatenating all bytes of all access units starting from the access unit which includes the related authExtConfigAACO syntax element up until and including the access unit which contains the related authExtSigO syntax element in which either sigSegmentStop equals ‘1’ or authPartialSig equals ‘O’. The authExtConfigAACO syntax element of the respective authentication sequence shall be populated into gad_bytes. The authExtSigO syntax element of the respective authentication sequence shall not be populated into gad_bytes. If any of the access units related to the current authentication sequence contains authExtConfigAACO or authExtSigO syntax elements with the same authlD as the current authentication sequence and a different authSequence value, they shall be populated into gad_bytes. authExtConfigAACO and authExtSigO syntax elements with a different authlD than the current authentication sequence and authUUID() elements shall not be populated into gad_bytes. The following extension types indicated by extension_type shall be excluded by default and not be populated into gad_bytes:

[0628] - EXT_FILL

[0629] - EXT_FILL_DATA

[0630] - EXT_DATA_ELEMENT

[0631] - EXT_DATA_LENGTH

[0632] All other extension types shall be included and populated into gad_bytes, unless they are signaled to be excluded via authAddExtType and authAddExtlnclusion equal to ‘O’. The D24051AW001 extension types excluded by default may be signaled to be included using authAddExtlnclusion equal to ‘1’ and setting the respective authAddExtType value.

[0633] Unless indicated otherwise, details as described above for MPEG-H / MHAS are understood to apply to AAC as well, with evident replacement of data packets by bitstream elements.

[0634] Features and Advantages

[0635] The following features and advantages may apply to the techniques described above.

[0636] • It is not necessarily the whole signature that is transported in the bitstream, but parts of it only. The method therefore differs in the way that the verification of a stream can only happen against the bits which are transported. This enables a tradeoff between security and bitrate efficiency.

[0637] • The present disclosure proposes signaling to indicate which elements should be included in the hash calculation.

[0638] • The present disclosure proposes to indicate in the AUTH_START and AUTH_SIG package to signal a one-bit sequence number to indicate which AUTH_START and AUTH_SIG belong together. This enables inclusion of one auth(sequence 1) packet into the hashing of auth(sequence 0).

[0639] • The configuration element (e.g., Program Config Element), if present, is used to determine which of the subsequent elements in the bitstream are secured. If multiple PCEs are present, the elements forming these programs are secured separately. Signaling of authAuthProvID = 0 enables hashing only without signature. This enables another tradeoff of between security and a mode that can work while being offline.

[0640] • Combination with the key-id (which may be distributed separately but securely) is another tradeoff.

[0641] Enumerated Example Embodiments

[0642] Aspects and implementations of the present disclosure may also be appreciated from the following enumerated example embodiments (EEEs).

[0643] EEE-B 1. A method to create (encode) or modify (insert) a media bitstream to include a digital signature information and a digital signature, in a way that the digital signature information and D24051AW001 the digital signature is split up into two different bitstream packets / payloads (authentication-start packet and an authentication- signature package).

[0644] EEE-B2. The method of EEE-B1, wherein the authentication-start package contains:

[0645] • a flag that indicates overlapping portions of the bitstream to be included into the hashcalculation; and / or

[0646] • types of bitstream packets to be take into consideration.

[0647] EEE-B3. The method of EEE-B1 or EEE-B2, wherein the authentication stop-package contains the digital signature.

[0648] EEE-B4. A method for generating a modified bitstream on a source device, wherein the method includes the steps of: a) receiving, by a receiver, a bitstream including coded media data; b) generating a payload of authentication data and embedding the payload in the bitstream for obtaining a modified bitstream including the coded media data and the payload of the authentication data; and c) outputting the modified bitstream to a sink device.

[0649] EEE-B5. The method according to EEE-B4, wherein the modified bitstream is in MPEG-4 audio format; and wherein the generated payload is embedded in the bitstream by transporting the payload in the modified bitstream via an MPEG-4 audio bitstream extension mechanism.

[0650] EEE-B6. The method according to EEE-B4 or EEE-B5, wherein the MPEG-4 audio bitstream extension mechanism is a data stream element (DSE); or wherein the MPEG-4 audio bitstream extension mechanism is a Fill Element (ID_FIL), and wherein optionally the generated payload is transported via a generic extension payload element or a new extension payload element inside the Fill Element.

[0651] EEE-B7. The method according to any one or EEE-B4 to EEE-B6, wherein the authentication data includes a type identifier, wherein the type identifier is indicative for an authentication start or authentication stop type of the authentication data. D24051AW001

[0652] EEE-B8. The method according to any one or EEE-B4 to EEE-B7, wherein the authentication data contains a sequence identifier.

[0653] EEE-B9. The method according to any one or EEE-B4 to EEE-B8, wherein the data identified as “authentication start” contains information about the Digital Signature or Hashing Algorithm and / or an authentication provider.

[0654] EEE-B10. The method according to any one or EEE-B4 to EEE-B9, wherein the data identified as “authentication stop” contains authentication data.

[0655] EEE-B11. The method according to EEE-B10, wherein the authentication data is partially provided.

[0656] VS AC Digital Media Authentication

[0657] Background

[0658] Any details presented above for AAC, including, without limitation, description of methods 2010, 2020, 2030, 2040, and 2050, description of pairing information, partial authentication signatures, UUID elements, timestamp elements, geolocation elements, authorization information, and chained authentication, may likewise apply to USAC digital media authentication, unless indicated otherwise. An explicit exception is that specific syntax examples presented above may not apply to USAC and that USAC does not use PCEs for identifying the subset of intermediate bitstream elements for verification.

[0659] Instead, in USAC, the subset of intermediate bitstream elements may include all intermediate bitstream elements between the first bitstream element and the second bitstream element that are of a predetermined bitstream element type.

[0660] An example thereof is illustrated in Fig. 6A, in which the first bitstream element 610 and the second bitstream element 620 are separated by intermediate bitstream elements 630, all of which are included into the subset of intermediate bitstream elements 640 for verification. In the example of Fig. 6A, the second bitstream element 620 is followed by another first bitstream element 610’. As can be seen, the concept of pairing information likewise applies to USAC, which foresees different pairing information for the first bitstream element 610 and the further first bitstream element 610’ (i.e., AUTHSEQUENCE 0x0 as opposed to AUTHSEQUENCE 0x1). D24051AW001

[0661] Further, unlike AAC, USAC may use extension mechanisms for signaling the subset of intermediate bitstream elements.

[0662] There are two different types of extension mechanisms in USAC:

[0663] Configuration extensions (ID_CONFIG_EXT_*) o Example: Configuration extensions are carried in UsacConfigO -> UsacConfigExtension() -> usacConfigExtType -> ID_CONFIG_EXT_LOUDNESS_INFO -> loudness!nfoSet()

[0664] Extension elements (ID_EXT_ELE_*) o Example: Extension elements also have an extension configuration, which are carried in UsacConfigO -> UsacDecoderConfigO -> UsacExtElementConfigO -> usacExtElementType -> ID_EXT_ELE_UNI_DRC -> uniDrcConfig() o Example: Extension elements are carried in UsacFrame(usacElementType) -> ID_USAC_EXT -> UsacExtElementO -> usacExtElementSegmentData() -> ID_EXT_ELE_UNI_DRC -> uniDrcGain() as defined in 23003-4

[0665] For authentication of a USAC / xHE-AAC bitstream, it may be desirable to enable a content creator to provide means to signal which elements of a USAC bitstreams should be included into the hashing algorithm as basis for authentication. One example could be that a content creator wants to include loudness information (transmitted in loudness!nfoSet() as shown above) into the hashing, but wants to exclude DRC gain sequences (transmitted in uniDrcGain() as shown above).

[0666] This would ensure that nobody can change the loudness value (e.g., for regulatory reasons as the CALM act in the US) without breaking authenticity, while still allowing downstream devices to change / add / remove DRC Gain sequences without breaking authenticity.

[0667] Syntax

[0668] The first bitstream element and the second bitstream element for USAC may be of a same bitstream element type. To distinguish these bitstream elements from one another, the first bitstream element and the second bitstream element may differ in a set value of a predefined parameter or bit field. D24051AW001

[0669] For example, the first and second bitstream elements may be USAC extension elements, in particular of type authExtensionQ.

[0670] Table 30a

[0671] An example of alternative syntax for the authExtensionQ element is given in Table 30b.

[0672] D24051AW001

[0673] Table 30b

[0674] An example of possible syntax for the authExtension() element where authExtType is set to indicate AUTH_START is given in Table 31a. D24051AW001

[0675] Table 31a

[0676] Authentication Identification - authlD authlD may be used to identify the combination of authHashType, authProvID and authKeylD to which the related authentication information belongs to. This may enable authentication of one authentication sequence with different authentication configurations.

[0677] An example of possible syntax for the authExtension() element where authExtType is set to indicate AUTH_SIG is given in Table 31b.

[0678] Table 31b

[0679] Extension Types - authExtensionTypes In general, the USAC bitstream may include configuration information defining bitstream element types that shall be included into the subset of intermediate bitstream elements. This configuration information may be included in the first bitstream element, for example.

[0680] Using the above syntax, the field authExtensionTypes may enable different options for identifying or indicating the subset of intermediate bitstream elements that shall be included into the hash value. D24051AW001

[0681] Specifically, authExtensionTypes may be used to signal inclusion or exclusion of USAC extension elements (e.g., identified by usacExtElementType as defined in Table 33 (or 23003- 3:2020, Table 78)). If set to 0, all bytes from all UsacFrame() elements, starting from the UsacFrame() with AUTH_START until the UsacFrame() with AUTH_SIG and have the usacElementType ID_USAC_SCE, ID_USAC_CPE and ID_USAC_LFE may be included into the hash calculation. UsacFrame() elements with usacElementType of ID_USAC_EXT and USAC configuration extensions (ID_CONFIG_EXT_*) may be excluded. This may correspond to the example case illustrated in Fig. 6A.

[0682] If set to 1, usacExtElementType-elements (config_ext = 0) and usacConfigExtType-elements (config_ext =1), which are signaled to be included shall be included into hashing.

[0683] Notably, this implicitly also means that UsacFrame() elements with usacElementType of ID_USAC_EXT will be (partially) included into hashing.

[0684] Table 32 shows example of different usacElementType elements. usacEIementType[elemldx] Defines the USAC channel element type of the element at position elemldx in the bitstream. Four element types exist, one for each of the four basic bitstream elements: UsacSingleChannelElementQ, UsacChannelPairElenientQ, UsacLfeElement(),UsacExtElement(). These elements provide the necessary top level structure while maintaining all needed flexibility. The meaning of usacElementType is defined in Table 76.

[0685] Table 76 — Value of usacElementType

[0686] Table 32 authExtlnclusion

[0687] If set to 1, all extension types signaled in authExtType shall be included into the hashcalculation.

[0688] If set to 0, all extension types signaled in authExtType shall be excluded from the hashcalculation. D24051AW001 authExtConfigExt authExtConfigExt = 0 (i.e., authExtConfigExt[i] = 0) signals that the signaled authExtType (i.e., the value in authExtType[i]) is one of usacExtElementType - values as defined in Table 33 below (or 23003-3:2020, Table 78). usacExtElementType this element allows to signal bitstream extensions types. The meaning of usacExtElementType is defined in Table 78.

[0689] Table 78 — Value of usacExtElementType

[0690] Table 33 authExtConfigExt = 1 (i.e., authExtConfigExt[i] = 1) signals that the signaled authExtType (i.e., the value of authExtType[i]) is one of usacConfigExtType - values as defined in Table 34 below (23003-3:2020, Table 79). usacConfigExtType This element allows to signal configuration extension types. The meaning of usacConfigExtType is defined in Table 79.

[0691] Table 79 — Value of usacConfigExtType

[0692] Table 34

[0693] Further functionalities and semantics for authExtensionTypes in Table 31a may be in analogy to what has been described above for MHAS in relation to Table 2. D24051AW001

[0694] Fig. 6B shows an example where different USAC extension elements 670, 680 between the first bitstream element 610 and the second bitstream element 620 are or are not included into the hashing, depending on the configuration information held by the first bitstream element.

[0695] Examples • usacElementType - default all included besides ID_USAC_EXT, unless signaled o Is signaled by: authExtensionTypes = 1 o Further signaling may be needed as per Table 35 below, for example. usacElementType[elem!dx] Defines the USAC channel element type of the element at position elemldx in the bitstream. Four element types exist, one for each of the four basic bitstream elements: UsacSingleChannelElementQ, UsacChannelPairEIementQ, UsacLfeElement(),UsacExtElement(). These elements provide the necessary top level structure while maintaining all needed flexibility. The meaning of usacElementType is defined in Table 76.

[0696] Table 76 — Value of usacElementType

[0697] Table 35 • usacExtElementType inclusion o For inclusion, signaling would be:

[0698] ■ authExtensionTypes = 1

[0699] ■ authExtlnclusion = 1

[0700] ■ authExtConfigExt = 0

[0701] ■ authExtType = ID_EXT_ELE_UNI_DRC (4)

[0702] Table 36 below gives an example of possible USAC extension element types. D24051AW001 usacExtElementType this element allows to signal bitstream extensions types. The meaning of usacExtElementType is defined in Table 78.

[0703] Table 78 — Value of usacExtElementType

[0704] Table 36

[0705] • usacConfigExtType inclusion o For inclusion, signaling would be: ■ authExtensionTypes = 1

[0706] ■ authExtlnclusion = 1

[0707] ■ authExtConfigExt = 1

[0708] ■ authExtType = ID_CONFIG_EXT_LOUDNESS_INFO (2)

[0709] Table 37 below gives an example of possible USAC ConfigExtTypes. usacConfigExtType This element allows to signal configuration extension types. The meaning of usacConfigExtType is defined in Table 79.

[0710] Table 79 — Value of usacConfigExtType

[0711] Table 37 D24051AW001

[0712] Pairing Information - sequence

[0713] As in the MPEG-H and AAC cases, the first and second bitstream elements may include pairing information (e.g., sequence bit flag in the above example syntax of Table 30) for indicating that the second bitstream element includes the verification information for the subset of intermediate data packets between the first bitstream element and the second bitstream element, specifically, the verification information for the subset of intermediate data packets. This allows to determine which second bitstream element belongs to which first bitstream element even in an overlapping sequential arrangement of pairs of respective first and second bitstream elements. By such sequential arrangement of pairs of respective first and second bitstream elements, chained authentication throughout the entire bitstream or portions thereof beyond segments / frames can be achieved, as described above with reference to, for example, Fig. 5A.

[0714] When using the pairing information, the one or more intermediate bitstream elements may include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding the first bitstream element (and preceding the aforementioned configuration elements), provided that the further second bitstream element includes pairing information different from the pairing information of the first and second bitstream elements. If the further second bitstream element is among the subset of intermediate bitstream elements, so that the second bitstream element includes verification information also for the further second bitstream element, this may correspond to chained authentication.

[0715] Fig. 6C shows an example of overlapping pairs of first and second bitstream elements and chained authentication for US AC. The figure shows two temporal segments of the bitstream. A first bitstream element (e.g., authExtension element with authExtType=AUTH_START) 610 is separated from a second bitstream element (e.g., authExtension element with authExtType=AUTH_SIG) 620 by a number of intermediate bitstream elements 630. Both the first and second bitstream elements 610, 620 have matching pairing information “AUTHSEQUENCE 0x1”. Importantly, the intermediate bitstream elements 630 include a (further) second bitstream element 620’ from a preceding pair / segment of (further) first and second bitstream elements 610’, 620’ (with matching pairing information “AUTHSEQUENCE 0x0”). The second bitstream element 620 includes verification information for the subset of intermediate bitstream elements 640 among the intermediate bitstream elements 630, including D24051AW001 the further second bitstream element 620’ . In return, the subset of intermediate bitstream elements 640’ among the intermediate bitstream elements 630’ between the (further) first and second bitstream elements 610,’ 620’ may include the first bitstream element 610. As can be seen, this arrangement of first and second bitstream elements 610, 620 and (further) first and second bitstream elements 610’, 620’ achieves chained authentication throughout the aforementioned two temporal segments of the bitstream. This chained authentication scheme can be extended to an arbitrary number of segments, if needed.

[0716] To avoid repetition, reference is made to the above description of MHAS or AAC or further details on pairing information.

[0717] Authentication Interface

[0718] Also for USAC, it may be advantageous to define a specific data format or data interface that the (core) decoder can use to provide decoded data to the higher-level system, to be able to verify digital signatures in bitstreams, since the (core) decoder is typically not able to calculate hash values and verify authentication signatures, while the higher-level system is typically not able to correctly parse and decode the bitstream. This interface may be called whenever a second bitstream element is encountered in the bitstream and may be pre-stored at the (core) decoder. The interface shall be provided by the decoder to the system.

[0719] An example of syntax that may be used for this purpose is given in Table 38a below.

[0720] Table 38a

[0721] Another example of syntax that may be used for this purpose is given in Table 38b below. D24051AW001

[0722] Table 38b

[0723] AuthBytesLength

[0724] Length of bytes of AuthPacketBytes.

[0725] AuthPacketBytes The decoder shall concatenate all bytes relevant for creating the hash (as signaled in AUTH_START) and provide it to the system.

[0726] Yet another example of syntax that may be used for this purpose is given in Table 38c below.

[0727] Table 38c

[0728] Field gad_bytesLengthMinusl may give the length of bytes (minus 1) of the gad_bytes field. The gad_bytes field includes all bytes relevant for the creation of the authentication information according to the configuration described in authExtConfig(). The decoder shall concatenate all bytes (gad_bytes) relevant for creating the hash (as signaled in authExtConfigO) and provide it to the system. D24051AW001

[0729] One example embodiment of using the authentication interface may be as follows. The decoder shall extract all data related to media authentication for every authentication sequence as indicated by authlD and authSequence, and populate the respective fields in usac_GetAuthData(). authExtConfig() and authExtSigO for the related authentication sequence (as indicated by the respective authlD and authSequence) shall be copied from the respective bitstream elements. authTimestampO having the same authlD as the current authentication sequences and authUUID() syntax elements shall always be copied from the latest occurrences in bitstream. The gad_bytes field shall be populated by concatenating all bytes of the UsacConfigO syntax element and UsacFrame() syntax elements starting from the UsacFrame() which includes the related authExtConfig() syntax element up until and including the UsacFrame() which contains the related authExtSigO syntax element in which either sigSegmentStop equals ‘ 1’ or authPartialSig equals ‘0’ . The authExtConfig() syntax element of the respective authentication sequence shall be populated into gad_bytes. The authExtSigO syntax element of the respective authentication sequence shall not be populated into gad_bytes. If any of the UsacFrame() syntax elements related to the current authentication sequence contains authExtConfig() or authExtSigO syntax elements with the same authlD as the current authentication sequence and a different authSequence value, they shall be populated into gad_bytes. authExtConfig() and authExtSigO syntax elements with a different authlD than the current authentication sequence and authUUID() elements shall not be populated into gad_bytes. The following extension types indicated by usacExtElementType and usacConfigExtType shall be excluded by default and not be populated into gad_bytes:

[0730] ID_EXT_ELE_FILL (usacExtElementType)

[0731] - ID_CONFIG_EXT_FILL (usacConfigExtType)

[0732] All other extension types shall be included and populated into gad_bytes, unless they are signaled to be excluded via authAddExtType and authAddExtlnclusion equal to ‘O’. The extension types excluded by default may be signaled to be included using authAddExtlnclusion equal to ‘1’ and setting the respective authAddExtType value. D24051AW001

[0733] In the case an extension type or syntax element is excluded, the respective bits of the corresponding UsacExtElement(), UsacConfigExtension() or syntax element shall be replaced with ‘0’s before population into gad_bytes.

[0734] The input data for the hashing algorithm are created by concatenating gad_bytes with the bytes contained in the uuid field, if existing.

[0735] For further non-syntax-related details, reference is made to the respective descriptions for MHAS and A AC above.

[0736] Enumerated. Example Embodiments

[0737] Aspects and implementations of the present disclosure may also be appreciated from the following enumerated example embodiments (EEEs).

[0738] EEE-C1. A method for generating a modified bitstream on a source device, wherein the method includes the steps of: a) receiving, by a receiver, a bitstream including coded media data; b) generating a payload of authentication data and embedding the payload in the bitstream for obtaining a modified bitstream including the coded media data and the payload of the authentication data; and c) outputting the modified bitstream to a sink device.

[0739] EEE-C2. The method according to EEE-C1, wherein the modified bitstream is an MPEG-D USAC -based bitstream; and wherein the generated payload is embedded in the bitstream by transporting the payload in the bitstream via a USAC-type bitstream extension mechanism.

[0740] EEE-C3. The method according to EEE-C2, wherein the USAC-type bitstream extension mechanism is a new USAC-type bitstream extension element including a unique identifier.

[0741] EEE-C4. A method according to any of the preceding EEE-Cs wherein the authentication data includes a type identifier, wherein the type identifier is indicative for an authentication start or authentication stop type of the authentication data.

[0742] EEE-C5. The method according to EEE-C4, wherein the authentication data contains a sequence identifier. D24051AW001

[0743] EEE-C6. The method according to EEE-C4 or EEE-C5, wherein the data identified as “authentication start” contains information about the Digital Signature or Hashing Algorithm, and / or an authentication provider.

[0744] EEE-C7. The method according to any one of EEE-C4 to EEE-C6, wherein the data identified as “authentication stop” contains authentication data.

[0745] EEE-C8. The method according to EEE-C7, wherein the authentication data is partially provided.

[0746] Apparatus, Programs, and Recording Media

[0747] While methods and processing chains have been described above, it is understood that the present disclosure likewise relates to apparatus (e.g., computer apparatus or apparatus having processing capability in general) for implementing these methods and neural networks (or techniques in general).

[0748] An example of such apparatus 700 is schematically illustrated in Fig. 7 The apparatus 700 comprises a processor 710 and a memory 720 coupled to the processor 710. The memory 720 may store instructions for execution by the processor 710. The processor 710 may be adapted to implement the apparatus described throughout the disclosure and / or to perform methods (e.g., methods of encoding or decoding, methods of generating or modifying bitstreams) described throughout the disclosure. The apparatus 700 may receive inputs (e.g., media content, or medical, haptic, or seismic data / signals / waveforms) and generate outputs (e.g., bitstreams, media content, medical, haptic, or seismic data / signals / waveforms, verification results) as described throughout the disclosure.

[0749] In another example, the apparatus may comprise an accessing unit configured to access a bitstream including a first bitstream element and a second bitstream element. The first bitstream element and the second bitstream element may be separated in the bitstream by one or more intermediate bitstream elements. The apparatus may further comprise a modifying unit configured to embed verification information into the second bitstream element for verifying a subset of the intermediate bitstream elements. The modifying unit may be further configured to embed information into the first bitstream element, wherein the information indicates the subset D24051AW001 of the intermediate bitstream elements for which the verification information is available. The apparatus may further comprise a transmitter configured to transmit the bitstream.

[0750] The present disclosure further relates to programs (e.g., computer programs) comprising instructions that, when executed by a processor (or multiple processors), cause the processor (or multiple processors) to carry out any of the methods described throughout the disclosure, and to computer-readable storage media storing such programs.

[0751] For MPEG-H, an implementation of the bitstream (and the generation and modification thereof) as specified throughout the disclosure may be defined in Draft Amendment ISO 23008-3 :202x AMD1(X), 4 July 2025, which is incorporated herein by reference in its entirety.

[0752] For USAC, an implementation of the bitstream (and the generation and modification thereof) as specified throughout the disclosure may be defined in Draft Amendment ISO / IEC 23003-3:2020 AMD2(X), which is incorporated herein by reference in its entirety.

[0753] For MPEG-4 / AAC, an implementation of the bitstream (and the generation and modification thereof) as specified throughout the disclosure may be defined in Draft Amendment ISO / IEC 14496-3:2019 AMD1(X), which is incorporated herein by reference in its entirety.

[0754] For H.BWC, an implementation of the bitstream (and the generation and modification thereof) as specified throughout the disclosure may be defined in Draft Amendment ISO / IEC 23003-8 CD, which is incorporated herein by reference in its entirety.

[0755] Interpretation

[0756] Aspects of the systems described herein may be implemented in an appropriate computer-based sound processing network environment (e.g., server or cloud environment) for processing digital or digitized audio files. Portions of these systems may include one or more networks that comprise any desired number of individual machines, including one or more routers (not shown) that serve to buffer and route the data transmitted among the computers. Such a network may be built on various different network protocols, and may be the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), or any combination thereof.

[0757] One or more of the components, blocks, processes or other functional components may be implemented through a computer program that controls execution of a processor-based computing device of the system. It should also be noted that the various functions disclosed D24051AW001 herein may be described using any number of combinations of hardware, firmware, and / or as data and / or instructions embodied in various machine-readable or computer-readable media, in terms of their behavioral, register transfer, logic component, and / or other characteristics. Computer-readable media in which such formatted data and / or instructions may be embodied include, but are not limited to, physical (non-transitory), non-volatile storage media in various forms, such as optical, magnetic or semiconductor storage media.

[0758] Specifically, it should be understood that embodiments may include hardware, software, and electronic components or modules that, for purposes of discussion, may be illustrated and described as if the majority of the components were implemented solely in hardware. However, one of ordinary skill in the art, and based on a reading of this detailed description, would recognize that, in at least one embodiment, the electronic -based aspects may be implemented in software (e.g., stored on non-transitory computer-readable medium) executable by one or more electronic processors, such as a microprocessor and / or application specific integrated circuits (“ASICs”). As such, it should be noted that a plurality of hardware and software-based devices, as well as a plurality of different structural components, may be utilized to implement the embodiments. For example, computer-implemented neural networks described herein can include one or more electronic processors, one or more computer-readable medium modules, one or more input / output interfaces, and various connections (e.g., a system bus) connecting the various components.

[0759] While one or more implementations have been described by way of example and in terms of the specific embodiments, it is to be understood that one or more implementations are not limited to the disclosed embodiments. To the contrary, it is intended to cover various modifications and similar arrangements as would be apparent to those skilled in the art. Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.

[0760] Also, it is to be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having” and variations thereof are meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless specified or limited otherwise, the terms “mounted,” “connected,” “supported,” and “coupled” and variations thereof are used broadly and D24051AW001 encompass both direct and indirect mountings, connections, supports, and couplings.

[0761] Enumerated Example Embodiments

[0762] Various Aspects and implementations of the invention may also be appreciated from the following enumerated example embodiments (EEEs), which are not claims.

[0763] EEE-E1. A method of generating or modifying an audio bitstream comprising a plurality of bitstream elements, the method comprising: providing a first bitstream element and a second bitstream element, wherein the bitstream comprises the first bitstream element and the second bitstream element; wherein the first bitstream element and the second bitstream element are separated in the bitstream by one or more intermediate bitstream elements; and wherein the second bitstream element includes verification information for a subset of intermediate bitstream elements among the one or more intermediate bitstream elements.

[0764] EEE-E2. The method according to EEE-E1, further comprising: embedding information identifying the subset of intermediate bitstream elements into the first bitstream element or into another bitstream element that is in a fixed order relationship to the first bitstream element in the bitstream.

[0765] EEE-E3. The method according to EEE-E2, wherein the information identifying the subset of intermediate bitstream elements includes a list of one or more bitstream element types.

[0766] EEE-E4. The method according to EEE-E3, wherein the information identifying the subset of intermediate bitstream elements further includes a binary indicator for indicating whether bitstream element types in the list of bitstream element types shall be included into or excluded from the one or more intermediate bitstream elements.

[0767] EEE-E5. The method according to any one of the preceding EEE-Es, further comprising: applying a hashing algorithm to the subset of intermediate bitstream elements to generate a hash value; generating an authentication signature based on the hash value and an encryption key, wherein the verification information relates to the authentication signature; and embedding the verification information into the second bitstream element. D24051AW001

[0768] EEE-E6. The method according to EEE-E5, further comprising embedding, into the first bitstream element, one or more of: information identifying the hashing algorithm; information identifying the encryption key; and / or information identifying an authentication authority in relation to the encryption key.

[0769] EEE-E7. The method according to EEE-E5 or EEE-E6, wherein the encryption key is a private key of a private-public key pair.

[0770] EEE-E7A. The method according to EEE-E6, wherein the information identifying the authentication authority in relation to the encryption key comprises a Uniform Resource Identifier, URI as defined in IETF RFC 3986.

[0771] EEE-E7B. The method according to EEE-E6 or EEE-E7A, further comprising embedding, into the first bitstream element and / or into the second bitstream element: authentication identification information, wherein the authentication identification information identifies a combination of the information identifying the hashing algorithm, the information identifying the encryption key and the information identifying the authentication authority in relation to the encryption key.

[0772] EEE-E8. The method according to any one of the preceding EEE-Es, wherein the first bitstream element and the second bitstream element each include pairing information for indicating that the second bitstream element includes the verification information for the subset of intermediate bitstream elements between the first bitstream element and the second bitstream element; the one or more intermediate bitstream elements include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding the first bitstream element; and the further second bitstream element includes pairing information different from the pairing information of the first and second bitstream elements.

[0773] EEE-E9. The method according to any one of the preceding EEE-Es, wherein the method further comprises: providing a third bitstream element and a fourth bitstream element, wherein the third bitstream element and the fourth bitstream element are separated in the bitstream by one or more second intermediate bitstream elements, and wherein the fourth bitstream element includes second D24051AW001 verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements; and embedding information identifying subset of second intermediate bitstream elements into the third bitstream element or into another bitstream element that is in a fixed order relationship to the third bitstream element in the bitstream, wherein the one or more intermediate bitstream elements and the one or more second intermediate bitstream elements are at least partially overlapping.

[0774] EEE-E10. The method according to any one of the preceding EEE-Es, wherein the intermediate bitstream elements include one or more of a single channel element, SCE, a channel pair element, CPE, and a low frequency element, LFE.

[0775] EEE-E11. The method according to any one of the preceding EEE-Es, wherein the verification information relates to a portion of an authentication signature; and the second bitstream element includes verification splitting information indicative of a relationship between the portion of the authentication signature and the complete authentication signature.

[0776] EEE-E12. The method according to EEE-E11, wherein the verification splitting information includes one or more of an indication that the portion of the authentication signature relates to a first segment of the authentication signature, an indication that the portion of the authentication signature relates to a last segment of the authentication signature, and an indication of a length of the portion of the authentication signature.

[0777] EEE-E13. The method according to any one of the preceding EEE-Es, wherein the first bitstream element and the second bitstream element are of a same bitstream element type; and wherein the first bitstream element and the second bitstream element differ in a set value of a predefined parameter or bit field.

[0778] EEE-E14. The method according to any one of the preceding EEE-Es, wherein the subset of intermediate bitstream elements includes a bitstream element that contains timestamp information. D24051AW001

[0779] EEE-E15. The method according to any one of the preceding EEE-Es, wherein the subset of intermediate bitstream elements includes a bitstream element that contains geolocation information.

[0780] EEE-E16. The method according to any one of the preceding EEE-Es, wherein the subset of intermediate bitstream elements includes a bitstream element that contains identification information indicative of a Universally Unique Identifier, UUID.

[0781] EEE-E17. The method according to any one of the preceding EEE-Es, wherein the subset of intermediate bitstream elements includes a bitstream element that contains identification information indicative of a portion of a UUID and that further contains identification splitting information indicative of a relationship between the portion of the UUID and the complete UUID.

[0782] EEE-E18. The method according to EEE-E17, wherein the identification splitting information includes one or more of an indication that the portion of the UUID relates to a first segment of the UUID, an indication that the portion of the UUID relates to a last segment of the UUID, and an indication of a length of the portion of the UUID.

[0783] EEE-E19. The method according to any one of the preceding EEE-Es, wherein the subset of intermediate bitstream elements includes a bitstream element that contains authorization information indicative of an access restriction for pay load data included in one or more of the subset of intermediate bitstream elements and / or indicative of a group of authorized recipients of the payload data.

[0784] EEE-E20. The method according to any one of the preceding EEE-Es, wherein the bitstream is an MPEG-4 bitstream.

[0785] EEE-E21. The method according to any one of the preceding EEE-Es, wherein the first bitstream element is subsequent in the bitstream to a configuration element that includes reference information referencing one or more bitstream elements among the intermediate bitstream elements as the subset of bitstream elements.

[0786] EEE-E22. The method according to EEE-E21, wherein each bitstream element of the bitstream includes an element tag; and wherein element tags of the first bitstream element and the configuration element are identical. D24051AW001

[0787] EEE-E23. The method according to EEE-E21 or EEE-E22, wherein the method further comprises providing a third bitstream element and a fourth bitstream element, wherein the third bitstream element and the fourth bitstream element are separated in the bitstream by one or more second intermediate bitstream elements; wherein the fourth bitstream element includes second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements; and wherein the third bitstream element is subsequent in the bitstream to a second configuration element that includes reference information referencing one or more bitstream elements among the second intermediate bitstream elements as the subset of second bitstream elements.

[0788] EEE-E24. The method according to EEE-E23 when depending on EEE-E22, wherein element tags of the third bitstream element and the second configuration element are identical, and are different from the element tags of the first bitstream element and the second bitstream element.

[0789] EEE-E25. The method according to any one of EEE-E21 to EEE-E24, wherein the first bitstream element and the second bitstream element each include pairing information for indicating that the second bitstream element includes the verification information for the subset of intermediate bitstream elements referenced by the configuration element preceding the first bitstream element; the one or more intermediate bitstream elements include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding said configuration element; and the further second bitstream element includes pairing information different from the pairing information of the first and second bitstream elements.

[0790] EEE-E26. The method according to any one of EEE-E21 to EEE-E25, wherein the configuration element is a program configuration element, PCE.

[0791] EEE-E27. The method according to any one of EEE-E21 to EEE-E26, wherein the bitstream is an AAC bitstream.

[0792] EEE-E28. The method according to any one of EEE-E1 to EEE-E20, wherein the subset of intermediate bitstream elements includes all intermediate bitstream elements between the first D24051AW001 bitstream element and the second bitstream element that are of a predetermined bitstream element type.

[0793] EEE-E29. The method according to EEE-E28, wherein the bitstream includes configuration information defining bitstream element types that shall be included into the subset of intermediate bitstream elements.

[0794] EEE-E30. The method according to EEE-E28 or EEE-E29, wherein the bitstream is a Unified Speech and Audio Coding, USAC, bitstream.

[0795] EEE-E31. A method of decoding an audio bitstream comprising a plurality of bitstream elements, the method comprising: decoding, from the bitstream, a first bitstream element and a second bitstream element, and one or more intermediate bitstream elements separating the first bitstream element and the second bitstream element in the bitstream, wherein the bitstream comprises the first bitstream element and the second bitstream element, and wherein the second bitstream element includes verification information for a subset of intermediate bitstream elements among the one or more intermediate bitstream elements; and verifying the subset of intermediate bitstream elements using the verification information.

[0796] EEE-E31A. The method according to EEE-E31, wherein the verifying is in accordance to AAC audio stream verification.

[0797] EEE-E31B. The method according to EEE-E31A, wherein successful authentication results from the verification ensure the intermediate data packets’ authenticity.

[0798] EEE-E32. The method according to and one of EEE-E31, EEE-E31A, and EEE-E31B, further comprising: extracting information identifying the subset of intermediate bitstream elements from the first bitstream element or from another bitstream element that is in a fixed order relationship to the first bitstream element in the bitstream.

[0799] EEE-E33. The method according to EEE-32, wherein the information identifying the subset of intermediate bitstream elements includes a list of bitstream element types.

[0800] EEE-E34. The method according to claim 33, wherein the information identifying the subset of intermediate bitstream elements further includes a binary indicator for indicating whether D24051AW001 bitstream element types in the list of bitstream element types shall be included into or excluded from the one or more intermediate bitstream elements.

[0801] EEE-E35. The method according to any one of EEE-E31 to EEE-E34, further comprising: applying a hashing algorithm to the subset of intermediate bitstream elements to generate a hash value; extracting the verification information from the second bitstream element, wherein the verification information relates to an authentication signature; and verifying the subset of intermediate bitstream elements based on the authentication signature, the generated hash value, and a decryption key.

[0802] EEE-E36. The method according to EEE-E35, further comprising extracting, from the first bitstream element, one or more of: information identifying the hashing algorithm; information identifying the encryption key; and / or information identifying an authentication authority in relation to the encryption key.

[0803] EEE-E37. The method according to EEE-E35 or EEE-E36, wherein the decryption key is a public key of a private-public key pair.

[0804] EEE-E37A. The method according to EEE-E36, wherein the information identifying the authentication authority in relation to the encryption key comprises a Uniform Resource Identifier, URI as defined in IETF RFC 3986.

[0805] EEE-E37B. The method according to EEE-E36 or EEE-E37A, further comprising extracting, from the first bitstream element and / or from the second bitstream element: authentication identification information, wherein the authentication identification information identifies a combination of the information identifying the hashing algorithm, the information identifying the encryption key and the information identifying the authentication authority in relation to the encryption key.

[0806] EEE-E38. The method according to any one of EEE-E31 to EEE-E37B, wherein the first bitstream element and the second bitstream element each include pairing information for indicating that the second bitstream element includes the verification information for the subset D24051AW001 of intermediate bitstream elements between the first bitstream element and the second bitstream element; the one or more intermediate bitstream elements include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding the first bitstream element; and the further second bitstream element includes pairing information different from the pairing information of the first and second bitstream elements.

[0807] EEE-E39. The method according to any one of EEE-E31 to EEE-E38, further comprising: decoding, from the bitstream, a third bitstream element and a fourth bitstream element, wherein the third bitstream element and the fourth bitstream element are separated in the bitstream by one or more second intermediate bitstream elements, and wherein the fourth bitstream element includes second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements; decoding, from the bitstream, information identifying the subset of second bitstream elements from the third bitstream element or from another bitstream element that is in a fixed order relationship to the third bitstream element; and verifying the subset of second intermediate bitstream elements using the second verification information, wherein the one or more intermediate bitstream elements and the one or more second intermediate bitstream elements are at least partially overlapping.

[0808] EEE-E40. The method according to any one of EEE-E31 to EEE-E39, wherein the intermediate bitstream elements include one or more of a single channel element, SCE, a channel pair element, CPE, and a low frequency element, LFE.

[0809] EEE-E41. The method according to any one of EEE-E31 to EEE-E40, wherein the verification information relates to a portion of an authentication signature; the second bitstream element includes verification splitting information indicative of a relationship between the portion of the authentication signature and the complete authentication signature; and the method further comprises: extracting the verification information and the verification splitting information; and D24051AW001 reconstructing the authentication signature based at least in part on the verification information and the verification splitting information.

[0810] EEE-E42. The method according to EEE-E41, wherein the verification splitting information includes one or more of an indication that the portion of the authentication signature relates to a first segment of the authentication signature, an indication that the portion of the authentication signature relates to a last segment of the authentication signature, and an indication of a length of the portion of the authentication signature.

[0811] EEE-E43. The method according to any one of EEE-E31 to EEE-E42, wherein the first bitstream element and the second bitstream element are of a same bitstream element type; and wherein the first bitstream element and the second bitstream element differ in a set value of a predefined parameter or bit field.

[0812] EEE-E44. The method according to any one of EEE-E31 to EEE-E43, further comprising: upon detection of the second bitstream element in the bitstream, outputting, by a core decoder, the verification information and the subset of intermediate bitstream elements for subsequent verification of the subset of intermediate bitstream elements, using a predefined data format.

[0813] EEE-E45. The method according to EEE-E44, wherein the verification information and the subset of intermediate bitstream elements are output, using the predefined data format, separately for different pairing information.

[0814] EEE-E46. The method according to any one of EEE-E31 to EEE-E47, wherein the subset of intermediate bitstream elements includes a bitstream element that contains timestamp information; and the method further comprises extracting the timestamp information.

[0815] EEE-E47. The method according to any one of EEE-E31 to EEE-E46, wherein the subset of intermediate bitstream elements includes a bitstream element that contains geolocation information; and the method further comprises extracting the geolocation information.

[0816] EEE-E48. The method according to any one of EEE-E31 to EEE-E47, wherein the subset of intermediate bitstream elements includes a bitstream element that contains authorization information indicative of an access restriction for pay load data included in one or more of the D24051AW001 subset of intermediate bitstream elements and / or indicative of a group of authorized recipients of the payload data; and the method further comprises extracting the authorization information.

[0817] EEE-E49. The method according to any one of EEE-E31 to EEE-E48, wherein the subset of intermediate bitstream elements includes a bitstream element that contains identification information indicative of a Universally Unique Identifier, UUID; and the method further comprises extracting the identification information.

[0818] EEE-E50. The method according to any one of EEE-E31 to EEE-E49, wherein the subset of intermediate bitstream elements includes a bitstream element that contains identification information indicative of a portion of a UUID and that further contains identification splitting information indicative of a relationship between the portion of the UUID and the complete UUID; and the method further comprises: extracting the identification information and the identification splitting information; and reconstructing the UUID based at least in part on the identification information and the identification splitting information.

[0819] EEE-E51. The method according to EEE-E50, wherein the identification splitting information includes one or more of an indication that the portion of the UUID relates to a first segment of the UUID, an indication that the portion of the UUID relates to a last segment of the UUID, and an indication of a length of the portion of the UUID.

[0820] EEE-E52. The method according to any one of EEE-E31 to EEE-E51, wherein the bitstream is an MPEG-4 bitstream.

[0821] EEE-E53. The method according to any one of EEE-E31 to EEE-E52, further comprising: decoding, from the bitstream, a configuration element preceding the first bitstream element, wherein the configuration element includes reference information referencing one or more bitstream elements among the intermediate bitstream elements as the subset of bitstream elements.

[0822] EEE-E54. The method according to EEE-E53, wherein each bitstream element of the bitstream includes an element tag; and D24051AW001 wherein element tags of the first bitstream element and the configuration element are identical.

[0823] EEE-E55. The method according to EEE-E53 or EEE-E54, further comprising: decoding, from the bitstream, a third bitstream element and a fourth bitstream element, wherein the third bitstream element and the fourth bitstream element are separated in the bitstream by one or more second intermediate bitstream elements, and wherein the fourth bitstream element includes second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements; decoding, from the bitstream, a second configuration element preceding the third bitstream element, wherein the second configuration element includes reference information referencing one or more bitstream elements among the second intermediate bitstream elements as the subset of second bitstream elements; and verifying the subset of second intermediate bitstream elements using the second verification information.

[0824] EEE-E56. The method according to EEE-E55 when depending on EEE-E54, wherein element tags of the third bitstream element and the second configuration element are identical, and are different from the element tags of the first bitstream element and the second bitstream element.

[0825] EEE-E57. The method according to any one of EEE-E53 to EEE-E56, wherein the first bitstream element and the second bitstream element each include pairing information for indicating that the second bitstream element includes the verification information for the subset of intermediate bitstream elements referenced by the configuration element preceding the first bitstream element; the one or more intermediate bitstream elements include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding said configuration element; and the further second bitstream element includes pairing information different from the pairing information of the first and second bitstream elements.

[0826] EEE-E58. The method according to any one of EEE-E53 to EEE-E57, wherein the configuration element is a program configuration element, PCE. D24051AW001

[0827] EEE-E59. The method according to any one of EEE-E53 to EEE-E58, wherein the bitstream is an AAC bitstream.

[0828] EEE-E60. The method according to any one of EEE-E31 to EEE-E52, wherein the subset of intermediate bitstream elements includes all intermediate bitstream elements between the first bitstream element and the second bitstream element that are of a predetermined bitstream element type.

[0829] EEE-E61. The method according to EEE-E60, wherein the bitstream includes configuration information defining bitstream element types that shall be included into the subset of intermediate bitstream elements.

[0830] EEE-E62. The method according to any one of EEE-E60 to EEE-E61, wherein the bitstream is a Unified Speech and Audio Coding, USAC, bitstream.

[0831] EEE-E63. An encoding apparatus comprising one or more processors and a memory coupled thereto, wherein the one or more processors are configured to perform the method according to any one of EEE-E1 to EEE-E30.

[0832] EEE-E64. A decoding apparatus comprising one or more processors and a memory coupled thereto, wherein the one or more processors are configured to perform the method according to any one of EEE-E31 to EEE-E62.

[0833] EEE-E65. A computer program including instructions that when executed by one or more processors, cause the one or more processors to perform the method according to any one of EEE-E1 to EEE-E62.

[0834] EEE-E66. A computer-readable storage medium storing the computer program according to EEE-E66.

[0835] EEE-E67. A bitstream comprising: a first bitstream element and a second bitstream element, wherein the first bitstream element and the second bitstream element are separated in the bitstream by one or more intermediate bitstream elements; wherein the first bitstream element includes information indicating a subset of intermediate bitstream elements among the one or more intermediate bitstream elements for which verification information is available in the bitstream for verifying the subset of D24051AW001 intermediate bitstream elements; and wherein the second bitstream element includes the verification information.

[0836] EEE-E68. A bitstream comprising data generated according to the method of any one of EEE-E1 to EEE-E30.

[0837] EEE-E69. An apparatus comprising: an accessing unit configured to access a bitstream including a first bitstream element and a second bitstream element, wherein the first bitstream element and the second bitstream element are separated in the bitstream by one or more intermediate bitstream elements; a modifying unit configured to embed verification information into the second bitstream element for verifying a subset of the intermediate bitstream elements, and configured to embed information into the first bitstream element, wherein the information indicates the subset of the intermediate bitstream elements for which the verification information is available; and a transmitter configured to transmit the bitstream.

[0838] EEE-E70. A method comprising: accessing a bitstream including a first bitstream element and a second bitstream element, wherein the first bitstream element and the second bitstream element are separated in the bitstream by one or more intermediate bitstream elements; embedding verification information into the second bitstream element for verifying a subset of the intermediate bitstream elements; embedding information into the first bitstream element, wherein the information indicates the subset of the intermediate bitstream elements for which the verification information is available; and transmitting the bitstream.

[0839] EEE-E71. A computer-readable medium including instructions for causing one or more processors to perform: accessing a bitstream including a first bitstream element and a second bitstream element, wherein the first bitstream element and the second bitstream element are separated in the bitstream by one or more intermediate bitstream elements; embedding verification information into the second bitstream element for verifying a subset of the intermediate bitstream elements; embedding information into the first bitstream element, wherein the information indicates the subset of the intermediate bitstream elements for which the verification information is available; and transmitting the bitstream.

Claims

D24051AW001CLAIMS1. A method of generating or modifying an audio bitstream comprising a plurality of bitstream elements, the method comprising: providing a first bitstream element and a second bitstream element, wherein the bitstream comprises the first bitstream element and the second bitstream element, and wherein the bitstream is an AAC bitstream, wherein the first bitstream element and the second bitstream element are separated in the bitstream by one or more intermediate bitstream elements; wherein the second bitstream element includes verification information for a subset of intermediate bitstream elements among the one or more intermediate bitstream elements; and embedding information identifying the subset of intermediate bitstream elements into the first bitstream element.

2. The method according to claim 1, wherein the information identifying the subset of intermediate bitstream elements includes a list of one or more bitstream element types.

3. The method according to claim 2, wherein the information identifying the subset of intermediate bitstream elements further includes a binary indicator for indicating whether bitstream element types in the list of bitstream element types shall be included into or excluded from the one or more intermediate bitstream elements.

4. The method according to any one of the preceding claims, further comprising: applying a hashing algorithm to the subset of intermediate bitstream elements to generate a hash value; generating an authentication signature based on the hash value and an encryption key, wherein the verification information relates to the authentication signature; and embedding the verification information into the second bitstream element.

5. The method according to claim 4, further comprising embedding, into the first bitstream element, one or more of:D24051AW001 information identifying the hashing algorithm; information identifying the encryption key; and / or information identifying an authentication authority in relation to the encryption key.

6. The method according to claim 4 or 5, wherein the encryption key is a private key of a private-public key pair.

7. The method according to claim 5, wherein the information identifying the authentication authority in relation to the encryption key comprises a Uniform Resource Identifier, URI as defined in IETF RFC 3986.

8. The method according to claim 5 or 7, further comprising embedding, into the first bitstream element and / or into the second bitstream element: authentication identification information, wherein the authentication identification information identifies a combination of the information identifying the hashing algorithm, the information identifying the encryption key and the information identifying the authentication authority in relation to the encryption key.

9. The method according to any one of the preceding claims, wherein the first bitstream element and the second bitstream element each include pairing information for indicating that the second bitstream element includes the verification information for the subset of intermediate bitstream elements between the first bitstream element and the second bitstream element; the one or more intermediate bitstream elements include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding the first bitstream element; and the further second bitstream element includes pairing information different from the pairing information of the first and second bitstream elements.

10. The method according to any one of the preceding claims, wherein the method further comprises:D24051AW001 providing a third bitstream element and a fourth bitstream element, wherein the third bitstream element and the fourth bitstream element are separated in the bitstream by one or more second intermediate bitstream elements, and wherein the fourth bitstream element includes second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements; and embedding information identifying subset of second intermediate bitstream elements into the third bitstream element or into another bitstream element that is in a fixed order relationship to the third bitstream element in the bitstream, wherein the one or more intermediate bitstream elements and the one or more second intermediate bitstream elements are at least partially overlapping.

11. The method according to any one of the preceding claims, wherein the intermediate bitstream elements include one or more of a single channel element, SCE, a channel pair element, CPE, and a low frequency element, LFE.

12. The method according to any one of the preceding claims, wherein the verification information relates to a portion of an authentication signature; and the second bitstream element includes verification splitting information indicative of a relationship between the portion of the authentication signature and the complete authentication signature.

13. The method according to claim 12, wherein the verification splitting information includes one or more of an indication that the portion of the authentication signature relates to a first segment of the authentication signature, an indication that the portion of the authentication signature relates to a last segment of the authentication signature, and an indication of a length of the portion of the authentication signature.

14. The method according to any one of the preceding claims, wherein the first bitstream element and the second bitstream element are of a same bitstream element type; and wherein the first bitstream element and the second bitstream element differ in a set value of a predefined parameter or bit field.D24051AW00115. The method according to any one of the preceding claims, wherein the subset of intermediate bitstream elements includes a bitstream element that contains timestamp information.

16. The method according to any one of the preceding claims, wherein the subset of intermediate bitstream elements includes a bitstream element that contains geolocation information.

17. The method according to any one of the preceding claims, wherein the subset of intermediate bitstream elements includes a bitstream element that contains identification information indicative of a Universally Unique Identifier, UUID.

18. The method according to any one of the preceding claims, wherein the subset of intermediate bitstream elements includes a bitstream element that contains identification information indicative of a portion of a UUID and that further contains identification splitting information indicative of a relationship between the portion of the UUID and the complete UUID.

19. The method according to claim 18, wherein the identification splitting information includes one or more of an indication that the portion of the UUID relates to a first segment of the UUID, an indication that the portion of the UUID relates to a last segment of the UUID, and an indication of a length of the portion of the UUID.

20. The method according to any one of the preceding claims, wherein the subset of intermediate bitstream elements includes a bitstream element that contains authorization information indicative of an access restriction for pay load data included in one or more of the subset of intermediate bitstream elements and / or indicative of a group of authorized recipients of the payload data.128D24051AW00121. The method according to any one of the preceding claims, wherein the bitstream is an MPEG-4 bitstream.

22. The method according to any one of the preceding claims, wherein the first bitstream element is subsequent in the bitstream to a configuration element that includes reference information referencing one or more bitstream elements among the intermediate bitstream elements as the subset of bitstream elements.

23. The method according to claim 22, wherein each bitstream element of the bitstream includes an element tag; and wherein element tags of the first bitstream element and the configuration element are identical.

24. The method according to claim 22 or 23, wherein the method further comprises providing a third bitstream element and a fourth bitstream element, wherein the third bitstream element and the fourth bitstream element are separated in the bitstream by one or more second intermediate bitstream elements; wherein the fourth bitstream element includes second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements; and wherein the third bitstream element is subsequent in the bitstream to a second configuration element that includes reference information referencing one or more bitstream elements among the second intermediate bitstream elements as the subset of second bitstream elements.

25. The method according to claim 24 when depending on claim 23, wherein element tags of the third bitstream element and the second configuration element are identical, and are different from the element tags of the first bitstream element and the second bitstream element.129D24051AW00126. The method according to any one of claims 22 to 24, wherein the first bitstream element and the second bitstream element each include pairing information for indicating that the second bitstream element includes the verification information for the subset of intermediate bitstream elements referenced by the configuration element preceding the first bitstream element; the one or more intermediate bitstream elements include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding said configuration element; and the further second bitstream element includes pairing information different from the pairing information of the first and second bitstream elements.

27. The method according to any one of claims 22 to 26, wherein the configuration element is a program configuration element, PCE.

28. A method of decoding an audio bitstream comprising a plurality of bitstream elements, the method comprising: decoding, from the bitstream, a first bitstream element and a second bitstream element, and one or more intermediate bitstream elements separating the first bitstream element and the second bitstream element in the bitstream, wherein the bitstream comprises the first bitstream element and the second bitstream element, wherein the bitstream is an AAC bitstream, and wherein the second bitstream element includes verification information for a subset of intermediate bitstream elements among the one or more intermediate bitstream elements; extracting information identifying the subset of intermediate bitstream elements from the first bitstream element; and verifying the subset of intermediate bitstream elements using the verification information.

29. The method according to claim 28, wherein the verifying is in accordance to AAC audio stream verification.

30. The method according to claim 29, wherein successful authentication results from the verification ensure the intermediate data packets’ authenticity.130D24051AW00131. The method according to any one of claims 28 to 30, wherein the information identifying the subset of intermediate bitstream elements includes a list of bitstream element types.

32. The method according to claim 31, wherein the information identifying the subset of intermediate bitstream elements further includes a binary indicator for indicating whether bitstream element types in the list of bitstream element types shall be included into or excluded from the one or more intermediate bitstream elements.

33. The method according to any one of claims 28 to 32, further comprising: applying a hashing algorithm to the subset of intermediate bitstream elements to generate a hash value; extracting the verification information from the second bitstream element, wherein the verification information relates to an authentication signature; and verifying the subset of intermediate bitstream elements based on the authentication signature, the generated hash value, and a decryption key.

34. The method according to claim 33, further comprising extracting, from the first bitstream element, one or more of: information identifying the hashing algorithm; information identifying the encryption key; and / or information identifying an authentication authority in relation to the encryption key.

35. The method according to claim 33 or 34, wherein the decryption key is a public key of a private-public key pair.

36. The method according to claim 34, wherein the information identifying the authentication authority in relation to the encryption key comprises a Uniform Resource Identifier, URI as defined in IETF RFC 3986.131D24051AW00137. The method according to claim 34 or 36, further comprising extracting, from the first bitstream element and / or from the second bitstream element: authentication identification information, wherein the authentication identification information identifies a combination of the information identifying the hashing algorithm, the information identifying the encryption key and the information identifying the authentication authority in relation to the encryption key.

38. The method according to any one of claims 28 to 37, wherein the first bitstream element and the second bitstream element each include pairing information for indicating that the second bitstream element includes the verification information for the subset of intermediate bitstream elements between the first bitstream element and the second bitstream element; the one or more intermediate bitstream elements include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding the first bitstream element; and the further second bitstream element includes pairing information different from the pairing information of the first and second bitstream elements.

39. The method according to any one of claims 28 to 38, further comprising: decoding, from the bitstream, a third bitstream element and a fourth bitstream element, wherein the third bitstream element and the fourth bitstream element are separated in the bitstream by one or more second intermediate bitstream elements, and wherein the fourth bitstream element includes second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements; decoding, from the bitstream, information identifying the subset of second bitstream elements from the third bitstream element or from another bitstream element that is in a fixed order relationship to the third bitstream element; and verifying the subset of second intermediate bitstream elements using the second verification information, wherein the one or more intermediate bitstream elements and the one or more second intermediate bitstream elements are at least partially overlapping.132D24051AW00140. The method according to any one of claims 28 to 39, wherein the intermediate bitstream elements include one or more of a single channel element, SCE, a channel pair element, CPE, and a low frequency element, LFE.

41. The method according to any one of claims 28 to 40, wherein the verification information relates to a portion of an authentication signature; the second bitstream element includes verification splitting information indicative of a relationship between the portion of the authentication signature and the complete authentication signature; and the method further comprises: extracting the verification information and the verification splitting information; and reconstructing the authentication signature based at least in part on the verification information and the verification splitting information.

42. The method according to claim 41, wherein the verification splitting information includes one or more of an indication that the portion of the authentication signature relates to a first segment of the authentication signature, an indication that the portion of the authentication signature relates to a last segment of the authentication signature, and an indication of a length of the portion of the authentication signature.

43. The method according to any one of claims 28 to 42, wherein the first bitstream element and the second bitstream element are of a same bitstream element type; and wherein the first bitstream element and the second bitstream element differ in a set value of a predefined parameter or bit field.

44. The method according to any one of claims 28 to 43, further comprising: upon detection of the second bitstream element in the bitstream, outputting, by a core decoder, the verification information and the subset of intermediate bitstream elements for subsequent verification of the subset of intermediate bitstream elements, using a predefined data format.133D24051AW00145. The method according to claim 44, wherein the verification information and the subset of intermediate bitstream elements are output, using the predefined data format, separately for different pairing information.

46. The method according to any one of claims 28 to 45, wherein the subset of intermediate bitstream elements includes a bitstream element that contains timestamp information; and the method further comprises extracting the timestamp information.

47. The method according to any one of claims 28 to 46, wherein the subset of intermediate bitstream elements includes a bitstream element that contains geolocation information; and the method further comprises extracting the geolocation information.

48. The method according to any one of claims 28 to 47, wherein the subset of intermediate bitstream elements includes a bitstream element that contains authorization information indicative of an access restriction for pay load data included in one or more of the subset of intermediate bitstream elements and / or indicative of a group of authorized recipients of the payload data; and the method further comprises extracting the authorization information.

49. The method according to any one of claims 28 to 48, wherein the subset of intermediate bitstream elements includes a bitstream element that contains identification information indicative of a Universally Unique Identifier, UUID; and the method further comprises extracting the identification information.

50. The method according to any one of claims 28 to 49, wherein the subset of intermediate bitstream elements includes a bitstream element that contains identification information indicative of a portion of a UUID and that further contains identification splitting information indicative of a relationship between the portion of the UUID and the complete UUID; and134D24051AW001 the method further comprises: extracting the identification information and the identification splitting information; and reconstructing the UUID based at least in part on the identification information and the identification splitting information.

51. The method according to claim 50, wherein the identification splitting information includes one or more of an indication that the portion of the UUID relates to a first segment of the UUID, an indication that the portion of the UUID relates to a last segment of the UUID, and an indication of a length of the portion of the UUID.

52. The method according to any one of claims 28 to 51, wherein the bitstream is an MPEG-4 bitstream.

53. The method according to any one of claims 28 to 52, further comprising: decoding, from the bitstream, a configuration element preceding the first bitstream element, wherein the configuration element includes reference information referencing one or more bitstream elements among the intermediate bitstream elements as the subset of bitstream elements.

54. The method according to claim 53, wherein each bitstream element of the bitstream includes an element tag; and wherein element tags of the first bitstream element and the configuration element are identical.

55. The method according to claim 53 or 54, further comprising: decoding, from the bitstream, a third bitstream element and a fourth bitstream element, wherein the third bitstream element and the fourth bitstream element are separated in the bitstream by one or more second intermediate bitstream elements, and wherein the fourth bitstream element includes second verification information for a subset of second intermediate bitstream elements among the one or more second intermediate bitstream elements;135D24051AW001 decoding, from the bitstream, a second configuration element preceding the third bitstream element, wherein the second configuration element includes reference information referencing one or more bitstream elements among the second intermediate bitstream elements as the subset of second bitstream elements; and verifying the subset of second intermediate bitstream elements using the second verification information.

56. The method according to claim 55 when depending on claim 54, wherein element tags of the third bitstream element and the second configuration element are identical, and are different from the element tags of the first bitstream element and the second bitstream element.

57. The method according to any one of claims 53 to 56, wherein the first bitstream element and the second bitstream element each include pairing information for indicating that the second bitstream element includes the verification information for the subset of intermediate bitstream elements referenced by the configuration element preceding the first bitstream element; the one or more intermediate bitstream elements include a further second bitstream element that includes verification information for one or more bitstream elements in the bitstream preceding said configuration element; and the further second bitstream element includes pairing information different from the pairing information of the first and second bitstream elements.

58. The method according to any one of claims 53 to 57, wherein the configuration element is a program configuration element, PCE.

59. An encoding apparatus comprising one or more processors and a memory coupled thereto, wherein the one or more processors are configured to perform the method according to any one of claims 1 to 27.136D24051AW00160. A decoding apparatus comprising one or more processors and a memory coupled thereto, wherein the one or more processors are configured to perform the method according to any one of claims 28 to 58.

61. A computer program including instructions that when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 1 to 58.

62. A computer-readable storage medium storing the computer program according to claim 61.

63. An AAC bitstream comprising: a first bitstream element and a second bitstream element, wherein the first bitstream element and the second bitstream element are separated in the bitstream by one or more intermediate bitstream elements; wherein the first bitstream element includes information indicating a subset of intermediate bitstream elements among the one or more intermediate bitstream elements for which verification information is available in the bitstream for verifying the subset of intermediate bitstream elements; and wherein the second bitstream element includes the verification information for verifying the subset of the intermediate bitstream elements.

64. An AAC bitstream comprising data generated according to the method of any one of claims 1 to 27.

65. An apparatus comprising: an accessing unit configured to access a bitstream including a first bitstream element and a second bitstream element, wherein the first bitstream element and the second bitstream element are separated in the bitstream by one or more intermediate bitstream elements, and wherein the bitstream is an AAC bitstream;D24051AW001 a modifying unit configured to embed verification information into the second bitstream element for verifying a subset of the intermediate bitstream elements, and configured to embed information into the first bitstream element, wherein the information indicates the subset of the intermediate bitstream elements for which the verification information is available; and a transmitter configured to transmit the bitstream.

66. A method comprising: accessing a bitstream including a first bitstream element and a second bitstream element, wherein the first bitstream element and the second bitstream element are separated in the bitstream by one or more intermediate bitstream elements, and wherein the bitstream is an AAC bitstream; embedding verification information into the second bitstream element for verifying a subset of the intermediate bitstream elements; embedding information into the first bitstream element, wherein the information indicates the subset of the intermediate bitstream elements for which the verification information is available; and transmitting the bitstream.

67. A computer-readable medium including instructions for causing one or more processors to perform: accessing a bitstream including a first bitstream element and a second bitstream element, wherein the first bitstream element and the second bitstream element are separated in the bitstream by one or more intermediate bitstream elements, and wherein the bitstream is an AAC bitstream; embedding verification information into the second bitstream element for verifying a subset of the intermediate bitstream elements; embedding information into the first bitstream element, wherein the information indicates the subset of the intermediate bitstream elements for which the verification information is available; and transmitting the bitstream.

Images