Trustworthiness of video data stream

Abstract

To check a video data stream on trustworthiness, and provide a good tradeoff between security level, implementation effort, and signaling overhead.SOLUTION: A method for checking a video data stream having a video encoded thereinto on trustworthiness comprises: subjecting a predetermined portion of the video data stream, or data derived therefrom, to a hash function to obtain a hash value; deriving a digital signature from the video data stream; and checking whether the hash value fits to the digital signature to determine whether the video data stream is trustworthy.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] Embodiments of the present invention relate to an apparatus, e.g. a video decoder, for checking a video data stream for reliability, an apparatus, e.g. a video encoder, for rendering a video data stream in which video that can be checked for reliability is encoded, a method for checking a video data stream for reliability, a method for rendering a video data stream in which video that can be checked for reliability is encoded, video, and / or a video data stream. [Background technology]

[0002] Today, the creation, distribution, and consumption of video content plays an important role in people's lives. International standards such as ITU-T Recommendations H.264, H.265, and H.266 enable the reliable and interoperable exchange of such content worldwide. As such, they form a key technology for modern, interconnected societies. Recent rapid developments in artificial intelligence (AI) enable new methods of artificial video content generation, thus enabling new data formats and innovative ways of user experience. Summary of the Invention [Problem to be solved by the invention]

[0003] However, at the same time, AI-based methods also carry the risk of being used in deceptive and potentially harmful ways. An example of such misuse is deepfakes, which create false perceptions about the origin or authorship of multimedia content. This can lead to devastating consequences, such as infringement of copyright or personal rights, fraud through falsified evidence, or undermining public trust in the integrity of public institutions. Therefore, there is a need for a concept to check video data streams for authenticity and provide a good trade-off between security level, implementation effort, and signaling overhead. [Means for solving the problem]

[0004] This object is achieved by the subject matter of the independent claims. An embodiment of the present invention relies on the idea of ​​rendering a video data stream that can be checked for authenticity by hashing a predetermined portion of the video data stream and calculating a digital signature based on the obtained hash value. The digital signature is transmitted within the video data stream. The authenticity of the video data stream can then be checked by subjecting the predetermined portion of the video data stream to a hash function to obtain a hash value and checking the hash value against the digital signature. Basing the authenticity check on the predetermined portion allows for a flexible and robust design of the authenticity check, for example, by allowing the predetermined portion to include or exclude certain parts of the data stream, thus enabling the authenticity check, and / or by maintaining certain functionality, such as random access, by selecting the predetermined portion according to a randomly accessible portion of the data stream, e.g., a coded video sequence, CVS. Furthermore, hashing the predetermined portion provides the advantage of reducing the data size of the digital signature and keeping the signaling overhead for transmitting the digital signature low. For example, a fundamental principle underlying embodiments of the present invention is that of digitally signing compressed video bitstreams.

[0005] One embodiment of the present invention provides an apparatus for checking the authenticity of a video data stream in which video is encoded, the apparatus being configured to apply a hash function to a predetermined portion of the video data stream, or data derived therefrom, to obtain a hash value, derive a digital signature from the video data stream, and check whether the hash value matches the digital signature to determine whether the video data stream is authentic.

[0006] A further embodiment of the present invention provides a decoder for decoding video from a video data stream, the decoder being configured to decode a digital signature from the video data stream, the decoder being further configured to subject the digital signature to a check on authenticity of the video data stream by subjecting a predetermined portion of the video data stream, or data derived therefrom, to a hash function to obtain a hash value, and checking whether the hash value matches the digital signature to determine whether the video data stream can be trusted. A further embodiment of the present invention provides an apparatus for rendering a video data stream in which video that can be checked for authenticity is encoded, the apparatus being configured to subject a predetermined portion of the video data stream, or data derived therefrom, to a hash function to obtain a hash value, calculate a digital signature based on the hash value to digitally sign the hash function, and insert the digital signature into the video data stream, thereby making it possible to determine whether the video data stream is authentic by checking whether the hash value matches the digital signature.

[0007] A further embodiment of the present invention provides a method for checking a video data stream in which video is encoded for authenticity, the method comprising: subjecting a predetermined portion of the video data stream, or data derived therefrom, to a hash function to obtain a hash value, deriving a digital signature from the video data stream, and checking whether the hash value matches the digital signature to determine whether the video data stream can be trusted. A further embodiment of the present invention provides a method for decrypting video from a video data stream, the method including decoding a digital signature from the video data stream, the method further including subjecting the digital signature to a check on authenticity of the video data stream by subjecting a predetermined portion of the video data stream, or data derived therefrom, to a hash function to obtain a hash value, and checking whether the hash value matches the digital signature to determine whether the video data stream can be trusted.

[0008] A further embodiment of the present invention provides a method for rendering a video data stream in which video that can be checked for authenticity is encoded, the method including subjecting a predetermined portion of the video data stream, or data derived therefrom, to a hash function to obtain a hash value, calculating a digital signature based on the hash value to digitally sign the hash function, and inserting the digital signature into the video data stream, thereby making it possible to determine whether the video data stream is authentic by checking whether the hash value matches the digital signature. A further embodiment of the present invention provides a video data stream having encoded video, the video data stream being rendered checkable for authenticity using the above method, in particular the video data stream including a digital signature for a predetermined portion of the video data stream.

[0009] The above video coding standards do not support any method by which a standard-compliant decoder can determine whether a standard-compliant compressed bitstream was actually generated by a trusted source or whether it was generated by someone merely falsely claiming to be such a source, for example, by using deepfakes. Because these standards may already be widely deployed in devices around the world, often with dedicated hardware supporting their efficient use, embodiments of the present invention provide a technical solution that can modify already deployed mechanisms for standard-compliant decoding of bitstreams to enable trusted data exchange without changing them. Embodiments of the present invention ensure robustness and flexibility against future developments in the field of security-related hashing and signature algorithms, and provide a method that easily and independently enables data transmission from content providers to content consumers based on a mutual understanding of trust between both parties. Embodiments follow any general design principles of the underlying specification texts of the corresponding standards to enable easy implementation and deployment of the proposed technology. Furthermore, embodiments provide solutions for trusted data exchange that can be used in combination according to the core features and functionality of the underlying video coding standards when used in practical applications. Advantageous implementations are defined by the subject matter of the dependent claims. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will now be described with reference to the accompanying drawings. [Brief explanation of the drawings]

[0010] [Figure 1] 1 illustrates an apparatus for checking a data stream for reliability, according to one embodiment. [Figure 2] 1 illustrates a decoder according to one embodiment. [Figure 3] 1 illustrates a verification module, according to one embodiment. [Figure 4]1 illustrates an apparatus for rendering a data stream that can be checked for authenticity, according to one embodiment. [Figure 5] 1 shows a schematic diagram of a trust verification process according to one embodiment. [Figure 6A] 1 illustrates data selection for a signature process, according to one embodiment. [Figure 6B] 1 illustrates content hashing for a signature process, according to one embodiment. [Figure 6C] 1 illustrates a signature generation of a signature process according to one embodiment. [Figure 7] 1 illustrates a signature verification of the verification process according to one embodiment. [Figure 8] 1 illustrates the formation of a hash value, according to one embodiment. [Figure 9A] 1 illustrates a method for locating chunks according to an embodiment. [Figure 9B] 1 illustrates a method for locating chunks according to an embodiment. [Figure 9C] 1 illustrates a method for locating chunks according to an embodiment. [Figure 10A] 1 illustrates chunk-structured packet selection (eg, H.264) via markers into a single chunk using chunk-structured GOPs, according to one embodiment. [Figure 10B] 1 illustrates chunk-structured packet selection (e.g., H.265 / H.266) via markers into a single chunk using chunk-structured GOPs, according to one embodiment. [Figure 11A] 1 illustrates chunk-structured packet selection (eg, H.264) via markers using chunk-structured GOPs that divide a temporal layer into two chunks, according to one embodiment. [Figure 11B] 1 illustrates chunked packet selection via markers (e.g., H.265 / H.266) using chunked GOPs that divide a temporal layer into two chunks, according to one embodiment. [Figure 12]1 illustrates chunk organization into chunks and recommended hash dependencies and recommended chunk dependencies in two-layer protection with bitstream packets, according to one embodiment. [Figure 13] 1 illustrates possible configurations of an identification string IdString according to one embodiment. [Figure 14] 1 illustrates an apparatus for predictively coding pictures into a data stream, illustratively using transform-based residual coding, according to one embodiment. [Figure 15] 10 illustrates a corresponding decoder configured to predictively decode pictures from a data stream, also using transform-based residual decoding, according to one embodiment. [Figure 16] 1 illustrates the relationship between a reconstructed signal and a combination of a prediction residual signal and a prediction signal signaled in a data stream according to one embodiment. [Figure 17] 1 illustrates a method for checking a data stream for reliability, according to one embodiment. [Figure 18] 1 illustrates a method for decoding video, according to one embodiment. [Figure 19] 1 illustrates a method for rendering a data stream that can be checked for authenticity, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] Before describing the embodiments of the present invention below based on the accompanying drawings, it should be noted that elements and structures having the same effect are given the same reference numerals so that their descriptions can be applied to each other or can be exchanged. Moreover, the features of different embodiments described herein can be combined with each other unless otherwise specified.

[0012] FIG. 1 illustrates an apparatus 16 for checking the authenticity of a data stream 14 according to one embodiment. The data stream 14 contains encoded video therein, e.g., the data stream 14 is a video data stream. The apparatus 16 either subjects a predetermined portion 13 of the data stream 14 to a hash function 31 to obtain a hash value 33, or alternatively, the apparatus 16 subjects data 62 derived from the predetermined portion 13 to the hash function 31 to obtain the hash value 33. The latter option is exemplarily visualized in FIG. 1 by an optional block 61 that can derive data 62 to be subjected to the hash function 31 from the predetermined portion 13. The apparatus 16 derives a digital signature 43 from the data stream 14. Furthermore, the apparatus 16 includes a verification block 41 that checks whether the hash value 33 matches the digital signature 43 to determine whether the data stream is authentic. For example, if the digital signature 43 matches the hash value 33, the data stream or a predetermined portion thereof is considered authentic. For example, authenticity may mean that the content and / or content provider of a data stream or a given portion thereof is successfully verified as authentic.

[0013] Figure 2 shows a decoder 20 for decoding video 11 from data stream 14 according to one embodiment. Decoder 20 includes the functionality of device 16 of Figure 1. Decoder 20 comprises a decoding module 63 that decodes digital signature 43 from data stream 14, and decoder 20 subjects digital signature 43 to authenticity checks as described with respect to device 16 of Figure 1. In other words, according to one embodiment, device 16 of Figure 1 may be, for example, a decoder as shown in Figure 2.

[0014] According to one embodiment, the decoding module 63 decodes the video 11 from the data stream 14 . According to one embodiment, decoder 20 reconstructs video 11 with respect to predetermined portion 13 to obtain a reconstructed portion of the video. In other words, for example, decoder 20 reconstructs the portion of the video represented by predetermined portion 13 to obtain a reconstructed portion of the video. According to this embodiment, decoder 20 subjects the reconstructed portion to a hash function 31. For example, the reconstruction may be represented by block 61 in FIG. 2, in which case blocks 61 and 63 may be combined. In other words, data 62 derived from predetermined portion 13 may be the reconstructed portion of the video or data derived therefrom.

[0015] Further details of device 16 are provided below, but these details may optionally also be applied to decoder 20 of FIG. For example, the predetermined portion 33 may be a contiguous portion of the data stream 14. Alternatively, the predetermined portion may be made up of multiple subsections or sections of the data stream that may be interspersed with or interspersed with additional portions of the data stream that are not part of the predetermined portion. For example, the predetermined portion 13 may be referred to as a chunk. In subjecting the predetermined portion 13 to the hash function 31, the device 16 may subject the predetermined portion to the hash function 31 in the form of raw data from the data stream. This may mean, for example, that data is parsed from the data stream 14 and subjected to the hash function without further decoding.

[0016] According to one embodiment, the hash value 33 depends on all bits of the predetermined portion 13 of the data stream. According to one embodiment, the hash value 33 depends on all bits of a given portion of the data stream in the entropy coded domain. According to one embodiment, the predetermined portion 13 of the data stream 14 spans more than one access unit of the data stream. The hash value depends on bits of more than one access unit. For example, an access unit can refer to a portion of the data stream in which one, e.g., exactly one time frame of video is encoded. According to one embodiment, the predetermined portion 33 consists of one or more video coding layer portions of the data stream in which motion vectors and intra prediction modes for predictive blocks and transform coefficients for residual blocks are coded.

[0017] 3 shows a verification module 41 according to one exemplary embodiment. According to this embodiment, the verification module 41 comprises a decryption block 45 that decrypts the digital signature 43 to obtain a check value 47, and the verification module 41 further comprises a verification block 49 that checks whether the hash value 33 matches, e.g., whether it matches, the check value 47. For example, the generation of the digital signature 43 may be performed on the encoder side by forming a check value and signing it using a private key. For example, the signature may include a further hashing, i.e. hashing the check value using a further hash function to obtain a further hash value and signing the further hash value. In this example, it may not be possible to reconstruct the check value from the digital signature 43 on the decoder side, but instead it can only be checked if the check value formed using the hash value 33 matches the digital signature. In this case, verification by the verification module 41 may include hashing the check value using a further hash function to obtain a further hash value and checking whether the further hash value matches the digital signature, for example by decrypting the digital signature using the public key and checking whether the resulting decrypted further hash value is equal to the further hash value.

[0018] In other words, according to one embodiment, checking whether the hash value 33 matches or matches the check value 47 may involve forming a verification string using the hash value 33, e.g., by concatenating the hash value 33 with further information, such as a further hash value or a hash function identifier, as described below, and hashing the verification string, e.g., using the further hash function. The verification module 41 may then check whether the hashed verification string is equal to the check value 47 decrypted from the digital signature. On the encoder side, according to this embodiment, the digital signature may be generated by forming a verification string in the same way as on the decoder side, hashing it using the further hash function, and signing the hashed verification string to obtain the digital signature 43.

[0019] According to alternative embodiments, check value 47 may correspond to hash value 33 or may correspond to the concatenation of hash value 33 with further information, such as a further hash value or a hash function identifier. In other words, decryption of the digital signature in this case may yield hash value 33 as part of check value 47 (or the entire check value 47). In this case, the digital signature may be larger due to the omission of further hashing. For example, whether one or the other of the above alternatives is used may depend on the hash function selected.

[0020] For example, verification block 49 may check whether hash value 33 is equal to check value 47 or a portion thereof to determine whether hash value 33 matches check value 47. In other words, from another perspective, check value 47 may be the entire value or a portion thereof obtained from decrypting the digital signature, and verification block 49 may check whether hash value 33 matches or is equal to the check value.

[0021] In other words, what it means for a digital signature to match is, for example, according to one embodiment, a digital signature is matched by a predetermined value, e.g., a hash value, if the predetermined value and a check value obtained by decrypting digital signature 42 are equal. Alternatively, digital signature 42 is matched by a predetermined value, e.g., a hash value, if the predetermined value and a predetermined portion of the check value associated with the predetermined value are equal. According to one embodiment, the verification module 41 performs the check by using an asymmetric decryption scheme using a public key.

[0022] FIG. 4 illustrates an apparatus 15 according to one embodiment for rendering a data stream 14, e.g., a video data stream 14 in which video that can be checked for authenticity is encoded. The apparatus 15 is configured to apply a predetermined portion 13 of the data stream, or data 62 derived therefrom, to a hash function 31 to obtain a hash value 33. In this respect, the description of the apparatus 16 of FIG. 1 also applies, e.g., with respect to optional block 61. The apparatus 15 comprises a signature module 71 configured to calculate a digital signature 43 based on the hash value 33 and digitally sign the hash value 33. The apparatus 15 further comprises an inserter 77 configured to insert (77) the digital signature 43 into the data stream 14, thereby enabling a determination of whether the data stream is authentic by checking whether the hash value 33 matches the digital signature 43.

[0023] It should be noted that any description of apparatus 16 may optionally equally apply to apparatus 15, in the sense that any information derived by apparatus 16 from data stream 14 may be inserted by apparatus 15 into data stream 14. For example, with respect to a description of how apparatus 16 uses SEI messages as markers to locate predetermined portions 13, apparatus 15 may insert these messages into data stream 14 accordingly.

[0024] According to one embodiment, device 15 reconstructs video 11 with respect to predetermined portion 13 to obtain a reconstructed portion of the video. In other words, for example, decoder 20 reconstructs the portion of the video represented by predetermined portion 13 to obtain a reconstructed portion of the video. According to this embodiment, encoder 20 subjects the reconstructed portion to a hash function 31. According to one embodiment, device 15 is an encoder configured to encode video into a data stream and to encode a digital signature into the data stream.

[0025] According to one embodiment, signing module 71 calculates digital signature 43 based on hash value 33 by forming check value 47 based on hash value 33 and encrypting check value 47 to obtain digital signature 43. In other words, signing module 71 may be the counterpart of verification module 41 of FIG. For example, in encrypting check value 47, signing module 71 may use the private key of a public-private key pair of an asymmetric cryptography scheme, or may use the private key and the public key, and verification block 49 may use the public key in decrypting the digital signature.

[0026] In the following, further aspects, details and features of embodiments are described which may optionally be implemented individually or in any combination in any of the above-described embodiments of device 15 and device 16. According to one embodiment, the device 16 is configured to provide a hash value for subjecting the data stream combined with the media stream to an authenticity check, together with a further hash value obtained by subjecting a portion of the media stream accompanying the data stream, or further data derived therefrom, to a hash function or a different hash function.

[0027] In other words, the actual check, e.g., hashing and / or verification of the hash value against the digital signature, may be performed by yet another entity, rather than by device 16 or decoder 20 itself. For example, device 16 may provide either predetermined portion 13 or hash value 33, along with the digital signature and, optionally, further information obtained from data stream 14 for verification, e.g., any of the information described as derived from a supplemental information message as disclosed herein, to another entity, which may then perform the check.

[0028] FIG. 5 shows a schematic diagram of the authenticity verification process according to one embodiment. According to this embodiment, the encoder, e.g., device 15, possesses a private (and public) key for a fixed signature algorithm. The decoder, e.g., decoder 20, possesses only the public key, not the private key. According to one embodiment, the bitstream, e.g., data stream 14, itself may contain a pointer to the public key, but the public key itself must be obtained by invoking a trusted, independent method, rather than being obtained from the bitstream alone. For example, the bitstream may contain information identifying the encoder as a particular entity or as belonging to a particular entity. Given this information, the decoder may obtain the public key corresponding to this entity from a third-party trust center (e.g., by downloading it from a trusted, secure URL, such as a PKI). Furthermore, a fixed cryptographic hash function is agreed upon by the encoder and decoder. Here, the hash function may be pre-fixed or obtained from the bitstream and third-party trust center in the same way as the public key, or obtained from the bitstream, in which case the hash function may be part of the digital signature. Next, a unique byte range is determined from the bitstream for which a cryptographic hash value will be calculated using a given hash function by the decoder. Finally, a digital signature is transmitted in the bitstream that can be considered an alleged digital signature of the hash value calculated for the given byte range. To check authenticity, the decoder then processes this digital signature using a given public key. If the result of this processing is found to be a digital signature of the calculated hash value of the byte range, the decoder can consider this byte range as information that reliably belongs to the entity associated with the given public key, but should consider it fake if the opposite is true.

[0029] Below, individual aspects of embodiments of the disclosed concepts are described, the details of which features may be optionally combined with any of the embodiments described with respect to FIGS. First, a signature process that may be implemented by example device 15, according to one embodiment, will be described with respect to Figures 6A-6C.

[0030] 6A illustrates chunk construction according to one embodiment. For example, device 15 may construct a given portion 13 from multiple portions or sections of data stream 14. For example, as shown in FIG. 6A, chunk 13 may be part of multiple chunks, and given portion 13 may be referred to as the current chunk. For example, an order may be defined between the chunks, in other words the chunks may form a sequence, and a chunk 13 may have a preceding chunk 13' and / or a succeeding chunk 13''. For example, each of the chunks may be checkable for authenticity, e.g., data stream 14 may include an individual digital signature for each chunk, in other words, data stream 14 may be checkable for authenticity on a chunk-by-chunk basis.

[0031] Figure 6B illustrates hashing of chunks according to one embodiment. As shown in Figure 6B, chunk 13 may be subjected to a hash function 31, e.g., referred to as a hashing core, to derive a hash value 33. Optionally, the hash function may be selected using an index, e.g., HIdx, as described in more detail below.

[0032] 6C illustrates signature generation (71) according to one embodiment, as may optionally be performed, for example, by signing module 71 of FIG. 4. According to this embodiment, signing module 71 forms check value 47 by concatenating previous hash value 33′ of previous chunk 13′ with hash value 33 of current chunk 13 and hash function identifier 37 indicating the hash function used to derive hash value 33. Optionally, if previous chunk 13′ does not exist, for example, if given portion 13 is the initial (first) portion of the encoded video sequence, previous hash value 33′ may take a predetermined value, for example, as described in more detail below. According to the embodiment of FIG. 6C, the signing module comprises a signing block 73 that signs check value 47 using the private key of a public-private key pair of an asymmetric cryptography scheme to derive digital signature 43.

[0033] The following describes a verification process that may be implemented by example device 16, according to one embodiment. For example, for verification, device 16 can implement the chunk configuration of Figure 6A. For example, device 16 can derive the configuration of chunks 13 from the data stream. In other words, data stream 14 can include instructions or information that reveal the configuration of chunks, as described in more detail below. Additionally, device 16 may perform hashing of the chunks of Figure 6B. For example, an indication of the hash function may be transmitted within data stream 14.

[0034] 7 illustrates a signature verification (41) according to one embodiment, which may be optionally performed, for example, by the verification module 41. According to this embodiment, the decryption block 45 decrypts the digital signature 43 derived from the data stream 14 using the public key 79 of the public-private key pair of the asymmetric cryptography to derive the check value 47. According to this embodiment, the check value 47 includes a first portion 53, a second portion 53′, and, optionally, an instruction 37 for a hash function. The first portion 53 is related to the hash value 33 of the chunk 13, and the second portion 53′ is related to the hash value 33′ of the previous chunk 13′, for example, in that the related values ​​are checked against each other to verify authenticity. According to this embodiment, upon reviewing the block 51, the verification block 49 checks whether the first portion 53 is equal to the hash value 33. For example, if they are equal, it can be concluded that the given portion is authentic. Additionally, looking at block 51', verification block 49 checks whether second portion 53' is equal to hash value 33'. For example, if they are equal, it can be concluded that no additional data has been inserted between chunks 13', 13. Additionally, looking at block 51'', verification block 49 checks whether the hash function index is equal to the hash function index used to derive the hash value. For example, if they are equal, it can be ensured that the verification scheme has not been circumvented, as will be explained in more detail below.

[0035] Note that in other embodiments, fewer or additional pieces of information may be part of the check value. More generally, the verification process may include an identifier for the hash function, as described with respect to Figures 6C and 7. For example, the identifier may indicate the type and / or parameterization of the hash function 31. In other words, according to one embodiment, the verification module 41 is configured to further check the authenticity of the data stream by checking whether the hash function is correct by checking whether the parameterization or identifier of the hash function matches the digital signature.

[0036] Below, individual aspects of embodiments of the disclosed concepts are described, the details of which features may be optionally combined with any of the embodiments described with respect to FIGS. <Robustness against future security risks by enabling assignment of digital signature methods and hash functions via a trust center> The ability of the above process to guarantee authenticity depends on the following properties of the signature algorithm and hash algorithm:

[0037] First, it must be impossible to compute the private key given only the public key, since anyone in possession of the private key can generate video content that is reliably considered to belong to the entity associated with a given public key. Second, the cryptographic hash function used must be robust to collision attacks, since otherwise the byte ranges above could be manipulated while still matching the encoded and digitally signed hash value.

[0038] It has been observed that efforts to break the security of signature algorithms or hash functions are constantly underway worldwide, while at the same time new algorithms are being proposed that can be considered secure, at least for a certain time horizon. To take this observation into account, one aspect of the present invention is to propose that the signature algorithm and / or hash function be signaled within the bitstream and obtained from an external trust center by using an index that points to a specific entity to which content should be reliably assigned. The latter entity can then flexibly upgrade the signature algorithm and / or hash function to be used by decoders that attempt to verify that a given bitstream certainly belongs to it. For a corresponding security upgrade of the bitstream, the content providing entity only needs to update the digital signature of the hash value, leaving all other parts of the bitstream unchanged. More generally, and referring to the description of device 16 with respect to Figures 1-7, according to one embodiment, device 16 derives an asymmetric decryption scheme using first information derived from data stream 14.

[0039] According to one embodiment, the first information includes a decryption scheme identifier, for example, an identifier that identifies the decryption scheme. According to an alternative embodiment, the first information includes a first pointer to a first location, e.g., a network location, from which the asymmetric decryption scheme can be determined. For example, the first information may be a URI that points to a network location from which the certificate can be obtained. According to a further alternative embodiment, the first information includes an identifier of an entity that encoded the video into the data stream. According to one embodiment, device 16 derives the public key using second information derived from the data stream.

[0040] According to one embodiment, the second information includes a second pointer to a second location from which the public can be obtained. For example, the second information may include, for example, an identifier of a public key among a plurality of keys derivable from a network location, e.g., the network location to which the pointer of the first information points. According to an alternative embodiment, the second information includes an identifier of the entity that encoded the video into the data stream. According to one embodiment, device 16 is configured to derive a public key by deriving from data stream 14 a first syntax element, e.g., twci_use_key_register_idx_flag, and a second syntax element, e.g., twci_key_source_uri, where the second syntax element indicates a pointer to a location, e.g., a URI, from which the public key can be derived. According to this embodiment, device 16 is configured to infer, if the first syntax element has a first state, that the location identifies exactly one public key and derive that exactly one public key from the location, and, if the first syntax element has a second state, infer that the location indicates a list of keys, derive from the data stream a third syntax element, e.g., twci_key_register_idx, that indicates a pointer to an entry in the list of keys, and derive the public key from the entry in the list of keys indicated by the pointer.

[0041] For example, the location to which the pointer points may hold one or more certificates. For example, a certificate may contain one or more keys. A certificate may additionally indicate one or more decryption schemes, e.g., one or more hash functions, for one or more keys. For example, a certificate may optionally be associated with a particular content provider.

[0042] According to one embodiment, the location pointed to by the pointer holds exactly one certificate containing one key, so that the information in the second syntax element may be sufficient to obtain the public key. According to another embodiment, the location pointed to by the pointer holds a certificate containing one or more keys, in which case the third syntax element can point to a key within the certificate that will be used for the trust check. According to another embodiment, the location pointed to by the pointer holds one or more certificates, each containing exactly one key. In this case, the third syntax element may point to a certificate from which the public key and optionally the decryption scheme will be derived. A combination with the previous embodiment is also possible, in that the third syntax element indicates one certificate of the one or more certificates and, within the indicated certificate, one key of the one or more keys of the indicated certificate.

[0043] According to one embodiment, device 16 derives hash function 31 using third information derived from the data stream. According to one embodiment, the third information includes a hash function identifier or a third pointer to a third location from which the hash function can be determined. According to an alternative embodiment, the third information includes an identifier of the entity that encoded the video into the data stream.

[0044] <Robustness against future collision attacks on hash functions by digitally signing supported hash functions> As another solution to the problem of potentially successful future collision attacks against hash functions, it has also been proposed that the bitstream may contain an index to a particular hash function; for security reasons, this index is also part of the message whose digital signature is part of the bitstream, and can therefore also be reliably verified. To check authenticity, the decoder then performs a joint signature verification of the received digital signature against the pair of hash value and hash function index. An embodiment utilizing joint signature verification is described above with respect to FIGS. 6C and 7.

[0045] <Chunk-level digital signatures for efficient compression of video content> While the above method allows for the reliable exchange of digital video content using widely deployed video coding standards, it also imposes an additional rate burden on the bitstream to which it is applied, since additional information, in particular the digital signature, must be transmitted. For example, if the digital signature is based on the RSA-2048 algorithm, the digital signature requires a size of 400 bytes within the bitstream.

[0046] Therefore, instead of transmitting a new digital signature for each sub-portion of a bitstream belonging to, for example, one coded slice or picture (e.g., a video coding layer NAL unit), it may be more rate-efficient to transmit a single digital signature in which the authenticity of several coded slices or pictures is jointly guaranteed by the above method. However, in the core functionality of widely deployed video coding standards such as H.264 or H.265, for a single bitstream, different decoders may only have access to a portion of the coded slices or pictures of the bitstream. Then, if only one hash value calculated for the entire bitstream is sufficient to verify the authenticity, any decoder that does not have access to all coded slices or pictures is excluded from applying the above method for authenticity verification. As a further observation, it should be noted that, on the one hand, there are generally a great many ways in which a subset of the set of all coded slices or pictures can be combined into a sub-bitstream by a decoder, and, on the other hand, there may be an efficient way for an encoder to determine, based on a given content and a given total bitstream, which subset can be expected to occur in a given situation. Therefore, for the purpose of authenticity verification by the above method, a flexible syntax is proposed that allows flexible assignment of coded slices or pictures to one of a possibly multiple set of coded slices or pictures. In the present application, such a set of coded slices or pictures for which joint authenticity verification can be performed by the above method is called a chunk of data. In the current setting, such a chunk of data is therefore characterized by the property that all of its bytes are used to calculate a hash value, and for this chunk a digitally signed value is transmitted that must be verified against the calculated hash value using a public key for authenticity verification.

[0047] <Bitstream integrity across multiple chunks> To ensure that the decoder can verify the continuity between single chunks used and to prevent attacks by removing, inserting, or shuffling data chunks in the protected bitstream, the present invention proposes that the hash value of the previous chunk be incorporated into the digital signature of the current chunk, as illustrated in Figures 6C and 7. Thus, for the current chunk, a digital signature of the combination of the hash value of the current chunk and the claimed hash value of the previous chunk must be part of the bitstream. Then, to verify the authenticity of the integrity of the current chunk with the previous chunk, the calculated hash values ​​of the previous chunk and the current chunk are jointly verified against this digital signature using a public key. Note that the hash value of the current chunk and the hash value of the previous chunk must be jointly signed with the current chunk so that only an entity that owns the private key can generate their co-occurrence as the digital signature of the current chunk.

[0048] A very important application scenario for such a guarantee of temporal integrity is the fact that video bitstreams made trustworthy by the above method should also enable random access capability for their decoding. However, if a bitstream is already considered trustworthy simply by checking the temporal subsegments between random access points individually and independently of each other, fake content can easily be generated by patching together temporal subsegments from different bitstreams originally generated from completely different video sequences. Note that the proposed solution, which guarantees the joint authenticity of multiple chunks or random access segments, still guarantees random access capability. A decoder that switches to decoding at a given random access segment but ignores earlier parts of the bitstream can simply ignore the hash values ​​identifying these earlier parts of the bitstream and focus only on verifying that part of the received bitstream.

[0049] More generally, described in this section and with reference to Figures 6C and 7 are embodiments in which checks on the authenticity of data stream 14 can be performed sequentially on multiple portions or chunks of data stream 14. In the following, generalized embodiments of the present disclosure are described. For example, one portion of the plurality of portions may be a portion of a subsequent segment of data stream 14. In other words, two portions of the plurality of portions that are checked sequentially may be portions from subsequent segments of the data stream, as shown, for example, in Figure 6A. Additionally or alternatively, portions of the plurality of portions may be portions from the same temporal segment of data stream 14, i.e., sub-portions of portions may be interleaved within the data stream, as described, for example, with respect to Figures 11A and 11B.

[0050] In other words, each portion may be associated with one of one or more sub-streams on which reliability checks may be performed, as described below. For example, the sequential check may be performed by sequentially checking subsequent segments of data stream 14, and within a segment, sequentially checking substreams according to a defined order between the substreams. For example, segments of data stream 14 may be defined or depicted as described below with respect to FIGS. 9A-10B. Thus, for example, in the following embodiments, the previous portion 13' may be understood as the previous portion in the sequential check, whether it is a portion of a lower-ranked substream of the same segment of the data stream 14 or a portion of a previous segment of the data stream 14.

[0051] According to one embodiment, the verification module 41 checks whether the hash value 33 and a further hash value 33' obtained by applying the hash function 31 to a previous portion 13' of the plurality of portions or further data derived therefrom, for example as described with respect to Figures 6C and 7, matches the digital signature 43. For example, the further data may be derived from the previous portion 13' as described with respect to the given portion 13. According to this embodiment, the hash value 33 and the further hash value 33' may be checked against respective relevant portions, eg substrings, of the check value 47, eg as described with respect to FIG.

[0052] Alternatively, hash value 33 and further hash value 33' may be combined, e.g., concatenated, and the resulting combined hash value (combined hash value) may be checked against check value 47, or a portion thereof, e.g., a substring. In other words, according to one embodiment, device 16 may combine hash value 33 and further hash value 33' to obtain a combined hash value and check whether the combined hash value matches digital signature 43.

[0053] 8 shows an alternative embodiment for forming a hash value to be used as input to the verification module 41. According to this embodiment, the device 16 comprises a combiner 82 that forms a combination 85, e.g., a concatenation, of the predetermined portion 13 and the previous hash value 33′. This combination 85 is subjected to a hash function 31, resulting in a combined hash value 33* that is then verified by the verification module 41. For example, according to this embodiment, the verification module 41 can check the combined hash value 33* against a combined check value, e.g., a value or string obtained from decrypting (45) the signature 43, or a portion thereof, e.g., whether the combined hash value 33* is equal to the value or string obtained from decrypting (45) the signature 43, or a portion thereof. In this alternative embodiment, instead of the predetermined portion 13, data 62 derived therefrom, as described with reference to FIG. 1, can be used as input to the combiner 82.

[0054] More generally, according to one embodiment, the verification module 41 checks whether a combined hash value 33* derived by hashing the predetermined portion 13, or data 62 derived therefrom, and a further hash value 33' obtained by subjecting a previous portion 13' of the data stream, or further data derived therefrom, to a hash function 31, matches the digital signature 43. In other words, according to this embodiment, the hash value obtained for the previous portion may be combined, e.g. concatenated, with the predetermined portion 13, or data 62 derived therefrom, and the obtained combination may be subjected to the hash function 31 to derive a hash value for the predetermined portion.

[0055] According to one embodiment, the device 16 can combine a predetermined portion 13 of the data stream 14 with a further hash value 33' obtained by applying a hash function 31 to the previous portion 13' or further data derived therefrom to obtain a combined hash value and check whether the combined hash value matches the digital signature. It should be noted here again that the method for deriving the hash value to be subjected to the verification module 41 may be performed in the same way on the encoder side and on the decoder side, for example in the device 15 and the device 16.

[0056] The following description discloses an embodiment where the data stream 14 does not include any portion before the predetermined portion 13, for example, where the data stream 14 is accessed at the predetermined portion by random access. According to one embodiment, two different digital signatures are transmitted in the data stream 14 for a given portion 13. According to this embodiment, the device 16 performs checks on authenticity on several portions of the data stream sequentially. According to one embodiment, if the data stream includes a previous portion relative to the given portion, device 16 is configured to perform a check regarding authenticity with respect to the first of two different digital signatures. For example, in this case, a check is performed according to any of the embodiments described above, such as the embodiment of Figure 7 or Figure 8. If the data stream does not include a previous portion relative to the given portion, device 16 checks whether hash value 33 matches the second of the two different digital signatures to determine whether the data stream can be trusted.

[0057] According to a further embodiment, the device 16 is configured to check, if the data stream includes a previous portion for a given portion, whether the hash value 33 and a further hash value 33' obtained by applying the hash function 31 to the previous portion 13' of the data stream or further data derived therefrom, match the digital signature 43, or whether the hash value 33 and a still further hash value transmitted in the data stream for the given portion match the digital signature (e.g., in concatenated form or further in the hash region) and the still further hash value is equal to a still further hash value 33' obtained by applying the hash function 31 to the previous portion 13' of the data stream or further data derived therefrom. Additionally, according to this embodiment, if the data stream includes a portion 13' before the predetermined portion 13, device 16 checks whether a combined hash value derived by hashing the predetermined portion 13 on the one hand and a further hash value 33' obtained by applying a hash function to the previous portion 13' of the data stream or further data derived therefrom matches the first of two different digital signatures, or whether a combined hash value derived by hashing the hash value and a still further hash value transmitted in the data stream for the predetermined portion matches the digital signature (e.g., in concatenated form or in a further hash field) and the still further hash value is equal to a still further hash value obtained by applying a hash function to the previous portion of the data stream or further data derived therefrom. According to this embodiment, if the data stream does not include a portion before the predetermined portion 13, device 16 checks whether the hash value matches the digital signature to determine whether the data stream can be trusted.

[0058] For example, if the data stream does not include a previous portion for a given portion, device 16 can determine whether the data stream can be trusted by checking whether the hash value matches the digital signature, for example, by checking whether the hash value and any further hash values ​​transmitted in the data stream for the given portion match the digital signature (e.g., in concatenated form or in further hash fields).

[0059] <Special processing of the first chunk of the bitstream to generate secure padding in the signature> According to one embodiment, at the beginning of a video where no preceding chunks exist, the proposed structure of the digital signature requires that some padding values ​​be inserted in the positions reserved for the hash values ​​of the previous chunks. It is proposed that these padding values ​​are specified solely for security against attacks that attempt to generate fake content matching such padding values, and that bitstreams or chunks whose actual calculated hash value matches such padded hash values ​​do not need to be accepted as authentic. In the event that an encoder generates a chunk that it wishes to mark as authentic but whose hash value happens to match the reserved padding hash value, the encoder can simply add so-called stuffing bytes to the bitstream, which, on the one hand, do not change the reconstructed content obtained from the bitstream, but, on the other hand, due to the design properties of typical hash functions, result in a hash value that is completely different from the hash value reserved for padding.

[0060] <Supporting delayed-time consistency verification for signature algorithms with small signatures> To further save bitrate when transmitting a digital signature, a signature algorithm that requires fewer bytes for the signature, such as the elliptic curve-based ECDSA P-256, can be selected. However, when doing so, the value that needs to be signed by the proposed technique, which is obtained by concatenating at least two hash values, may require too many bytes for the signature algorithm used. For this purpose, the encoder can hash this value before signature generation using a private key. Thus, for verification, the decoder first calculates a hashed value from the bitstream, then forms a concatenation with the hashed value of the previous chunk and, optionally, the index of the cryptographic hash function, then calculates a second hashed value of the combination, and compares this value with the transmitted digital signature using its public key.

[0061] Note that with this mechanism, the above-mentioned reliable random accessibility still holds, with the difference that any decoder that starts decoding the bitstream at a segment that is not the start segment cannot directly verify the authenticity of this segment, but can only do so when verifying the joint authenticity of the next segment together with the first segment. Thus, in terms of what it means to match a digital signature in general terms, for example, according to one embodiment, a digital signature is matched by a given value if it is equal to a check value in a further hash field arrived at by a further hash function applied to the given value or a concatenation of values ​​including the given value.

[0062] <Exclusion of post-processing tools sent to ensure reliability> The application of the present reliability verification algorithm focuses on the part of the bitstream containing video coding layer NAL units that directly belong to coded sample values ​​(e.g., coded slices or pictures). The reason for this is that other parts of the bitstream are often transmitted out-of-band. However, while this does not pose a significant reliability problem if such other information simply consists of information like sequence or picture parameter sets, it can become very problematic for the target application if this information is, for example, an SEI message that suggests the application of post-processing tools. An example of the latter kind of information is a neural network-based postfilter SEI message that can transmit the parameters of a postfilter. With the help of this SEI message, it may be possible to significantly modify the displayed content compared to the originally intended content assumed when generating a reliable bitstream by the above method.

[0063] For these reasons, one possible solution is that the proposed reliability verification be completely exclusive with some SEI messages, such as the neural network-based postfilter. This means that if a bitstream indicates that the reliability verification of the present invention should be applied, the neural network-based postfilter SEI message of this bitstream must indicate that the neural network-based postfilter will not be used. Instead, it is suggested that the specification text should include a note that the entire verification process produced by the proposed TWC-SEI is only intended to ensure the authenticity of the decoded image (and not the output image after the application of possible post-processing tools).

[0064] As another possible solution, it is proposed that instead of parts of the bitstream, chunks of the entire reconstructed picture or slice should be used to calculate the hash value in the above proposed process. Any post-processing applied to such chunks of reconstructed video sample values, not intended by the original generator of the content, would then result in this chunk being marked as untrusted.

[0065] <Enabling the proposed authenticity verification process via supplemental extension messages> It has been proposed to add three Supplemental Extension Information (SEI) messages, namely, Trustworthy Content Start SEI message (TWC-Start SEI), Trustworthy Content Selection SEI message (TWC-Select SEI), and Trustworthy Content Verification SEI message (TWC-Verify SEI) (see Figures 10A to 12), which can achieve the above trust verification process, to the SEI specification texts of H.264, H.265, and H.266.

[0066] The TWC-Start SEI first contains the syntax element twci_hash_method_type, which references the specific hash function to be used to generate a hash value from the bytes of a Video Coding Layer (VCL) NAL unit. The number of different chunks or substreams for which the hash value is to be calculated is then represented by the syntax element twci_num_verification_substreams_minus1. Finally, the URI from which the public key can be obtained, possibly combined with an index to a specific key listed in the URI, is coded by the syntax elements twci_key_source_uri, twci_use_key_register_idx_flag, and twci_key_register_idx. Here, the envisaged application when twci_use_key_register_idx_flag is true, is a situation where the URI represents a large trust center where possibly multiple content providers can register their keys.

[0067] If a reliable content selection SEI message is signaled, the hash value of the substream corresponding to twcs_verification_substream_id shall be updated using the hash function specified in the preceding TWC-Start SEI message. If no TWC-Start SEI message was sent, the bitstream shall also not contain a reliable content selection SEI message. For a given access unit, if a TWC-Start SEI message is sent but no reliable content selection SEI message is sent, the verification substream corresponding to index 0 shall be updated using the hash function specified in the preceding TWC-Start SEI message.

[0068] When a TWC verification SEI message is sent within an access unit, it contains a digital signature of the assumed hash value corresponding to the verification substream to which the video coding layer of the access unit belongs. Thus, if the access unit also contains a trusted content selection SEI message, this is the verification substream specified by this SEI message. If it does not contain a trusted content selection SEI message, this is the 0th verification substream. This digital signature should then be considered as a joint signature of the verification substream, the previous verification substream (in bitstream order), and the hash function index, as described above. Here, if the verification substream index is equal to k, where k>0, the previous verification substream is verification substream k-1. If the verification substream index is equal to 0, the previous substream is the last substream with index 0.

[0069] For the TWC validation SEI message, two cases need to be distinguished. If the underlying specification allows SEI messages to be sent only at the beginning of an access unit (prefix SEI only), especially before any VCL NAL units are sent, the TWC validation SEI is also sent before any VCL-NAL units are sent for the current access unit. This is the case in the H.264 specification. Furthermore, the TWC validation SEI indicates that the bytes of the VCL NAL units belonging to the current access unit must still be used in the on-the-fly calculation of a hash value that is performed on all VCL-NAL units belonging to the same chunk as the current VCL-NAL unit according to the corresponding TWC-Selection SEI. Then, the TWC validation SEI contains a digital signature that serves to verify (by invoking a public key) the authenticity of the current chunk of the VCL-NAL unit together with the preceding chunk of the VCL-NAL unit and, optionally, together with a hash function index, according to the process described above and as illustrated in Figures 5 to 7.

[0070] If the underlying specification also allows an SEI message to be sent within an access unit after a VCL-NAL unit (suffix SEI), the TWC validation SEI is sent as a suffix SEI. This is the case in the H.265 and H.266 specifications. The TWC validation SEI then again contains the same type of digital signature as before, which is applied to all preceding VCL-NAL units that belong to the same chunk as the VCL-NAL unit of the current access unit.

[0071] The reasons for the proposed differentiation in the positioning of the TWC validation SEI are as follows. First, conceptually, it seems more appropriate to position the TWC validation SEI after all bytes that will be used to calculate the hash value verified by the TWC validation SEI. Otherwise, an encoder generating trusted content would have to switch back and forth in the bitstream during encoding, i.e., first finish calculating the hash value, and then switch to the prefix SEI position to insert a digital signature of the hash value (using its private key) into the TWC validation SEI. Therefore, it also seems natural to position the TWC validation SEI as a suffix SEI whenever a suffix SEI is already supported. On the other hand, to conform to the general design philosophy of the underlying standards and specification texts to enable quick and easy deployment of the proposed technology, it does not seem reasonable to insert an entirely new mechanism, a suffix SEI, for authenticity verification if the standard does not already support it. The reason is that the security quality of the latter verification procedure, which is the main target of the proposed technology, is not affected by the issue of whether the TWC verification SEI is positioned as a prefix SEI or a suffix SEI.

[0072] The features, functionality, and advantages previously described in this section will now be restated in more general terms, with further details and variations. Any of the aforementioned features, functionality, and advantages may optionally be combined individually or in combination with any of the embodiments described below. The details and features described below may be combined with any of the embodiments described above, for example, with any of the embodiments described with respect to Figures 1-8.

[0073] For example, data stream 14 may include or consist of a sequence of packets, e.g., Network Abstraction Layer units (NAL units). The sequence of packets may include packets carrying coded video data, which may be referred to as coded video packets, or, as in the aforementioned video codecs, coded video layer (CVL) NAL units. In addition, the sequence of packets may include supplemental information messages, e.g., packets carrying information indicating coding parameters for the decoding process and / or coding options for decoding the data stream. In the aforementioned video codecs, the latter packets may be called supplemental enhancement information (SEI) messages. In the aforementioned video codecs, these messages may be carried as so-called non-VCL NAL units. For example, a predetermined portion may include a plurality of encoded video packets and, optionally, one or more supplemental information messages or supplemental information packets carrying one or more supplemental information messages.

[0074] According to one embodiment, the digital signature 42 is transmitted in a supplemental extension information message of the data stream 14, for example, in a supplemental extension information message following a predetermined portion 13 in the data stream 14 or interspersed between predetermined portions 13 in the data stream. According to this embodiment, a decryption module 63 decrypts the digital signature 42 from the supplemental enhancement information message. According to one embodiment, device 16 locates a predetermined portion 13 within data stream 14 by using one or more SEI messages interspersed within data stream 14 to determine the predetermined portion to be a section of the data stream that spans between or extends from one or more SEI messages.

[0075] 9A illustrates a method for locating a predetermined portion 13 according to one embodiment. According to this embodiment, device 16 locates a predetermined portion 13 within a data stream through the use of a first SEI message 25 and a second SEI message 27 interspersed within the data stream. For example, device 26 determines the predetermined portion to be a section of the data stream that spans or is located between the first and second SEI messages. In other words, predetermined portion 13 may be a section of data stream 14 that spans from the first SEI message 25 to the second SEI message 27. Alternatively, predetermined portion 13 may be a portion of this section, i.e., a contiguous portion, or may be composed of multiple sub-portions.

[0076] 9A, the first SEI message 25 may be a prefix SEI message and the second SEI message 27 may be a suffix SEI message. For example, the prefix SEI message may be an SEI message that precedes the coded video packet, and the suffix SEI message may be an SEI message that is added to the coded video packet. In other words, the suffix SEI message may be used to indicate the end of the section of the data stream 14 in which the given portion 13 is located. For example, the second SEI message may carry a digital signature 43 and / or the first SEI message may carry an indication of a hash function and / or an indication of a public key. For example, the first SEI message may be an initialization SEI message, described below, and the second SEI message may be a content verification SEI message, described below.

[0077] 9B illustrates another method of locating the predetermined portion 13, according to one embodiment. According to this embodiment, the predetermined portion 13 is determined using one SEI message 21 as a portion or section of the data stream 14 extending from the SEI message 21. For example, according to this embodiment, the section of data stream 14 in which given portion 13 is located extends to one end of data stream 14 or to one end of an encoded video sequence of data stream 14. For example, the encoded video sequence is an independently decodable section of the data stream. Alternatively, the section ends with another occurrence of SEI message 21. Alternatively, the end of a given portion 13 may be determined based on the length of the section.

[0078] 9C illustrates another method of locating predetermined portion 13 according to one embodiment, which is an alternative to the embodiment of FIG. 9A. According to this embodiment, device 16 locates predetermined portion 13 within the data stream through the use of first SEI message 25 and second SEI message 27 interspersed within the data stream. According to this embodiment, device 16 may determine the predetermined portion to be a section of the data stream that spans or is located between first SEI message 25 and a point 19 within the data stream that is located downstream of second SEI message 27. In other words, according to this embodiment, the section in which the predetermined portion is located may extend across the second SEI message, for example, this embodiment can be used for codecs that do not expect a suffix SEI message as described above.

[0079] According to one embodiment, device 16 determines a point 19 in data stream 14 downstream of second SEI message 27 as being at one end of a video coding layer portion of the data stream that includes the access unit containing the second SEI message. For example, point 19 is the end of the coded video data, or VCL data, in the access unit that includes the second SEI message. For example, the second SEI message may carry a digital signature 43 and / or the first SEI message may carry an indication of a hash function and / or an indication of a public key. For example, the first SEI message may be an initialization SEI message and the second SEI message may be a content verification SEI message, described below. In other words, the above-described variations for locating a predetermined portion 13 within a data stream 14 may be used to determine the section of the data stream 14 in which the predetermined portion 13 is located. Optionally, one or more further criteria may be applied to select data to be included in the predetermined portion from the sections indicated by one or more supplemental information messages. For example, packets to be included in a given portion may be selected by package type.

[0080] A further selection criterion may be the temporal layer to which the coded video data belongs. For example, each frame of a video may be associated with one of one or more temporal layers defined in the data stream. For example, frames of a first temporal layer may be interspersed in time with frames of a second temporal layer, such that, for example, a substream consisting of the first temporal layer has a lower frame rate than a substream including the first and second temporal layers.

[0081] FIG. 10A illustrates the configuration of a predetermined portion 13 according to one embodiment, where a group of pictures (GOP) is assigned to the predetermined portion 13. For example, the group of pictures may include multiple pictures that may be assigned to different temporal layers of a data stream, shown as TL0-TL4 in FIG. 10A. According to this embodiment, a check for authenticity may be performed jointly on all pictures of the GOP in that they are all part of the predetermined portion that is subjected to the hash function 31. According to the embodiment of FIG. 10A, the predetermined portion 13 may be identified using a first SEI message 25 and a second SEI message 27, as described with respect to FIG. 9C, where the predetermined portion extends from the first SEI message to the end of the video coding layer of the access unit in which the second SEI message is located.

[0082] 10A-12, each section assigned to any one of TL0-TL4 may represent data for one access unit or picture unit, e.g., coded video (layer) data. For example, the illustrated SEI messages may belong to the same access unit or picture unit as the subsequent coded video data, except for the second SEI message 27 in the case of FIGS. 10B, 11B, and 12, where the second SEI message 27 may belong to the access unit or picture unit preceding it. For example, the embodiment of FIG. 10A may be an example of a simple GOP signature that may be implemented in H.264.

[0083] Figure 10B shows an alternative to the embodiment of Figure 10A in that the predetermined portion 13 terminates in a second SEI message 27. According to the embodiment of Figure 10B, the predetermined portion 13 can be located as described with respect to Figure 9A. For example, the embodiment of Figure 10B can be an example of a simple GOP signature that can be implemented in H.265 or H.266.

[0084] The following describes embodiments in which a check for authenticity is performed on one or more substreams of a data stream. These substreams may be referred to as verification substreams. For example, the concept of verification substreams may allow different portions, e.g., packets, from one section of a data stream to be assigned to different verification substreams. For example, the verification substreams may be checked for authenticity separately or independently of each other. However, in examples, a hierarchy may be defined between substreams such that verification of a lower substream may require verifying data, e.g., hash values, of a higher substream. Furthermore, for example, at least the highest substream may be verified independently from the other substreams, such that such a substream may remain verifiable without updating its digital signature and without additional substreams after being extracted from the data stream. Thus, for example, the definition of a verification substream may correspond to the definition of a substream of independently decodable data stream 14.

[0085] For example, the verification substreams, eg, the number or count thereof, may be indicated in an SEI message, eg, the first SEI message 25, eg, an initialization SEI message. For example, the concept of a substream may be combined with the concept of defining the beginning and end of a portion on which a reliability check may be performed, such as a predetermined portion 13. In other words, the predetermined portion 13 may be a part of one of the substreams.

[0086] FIG. 11A illustrates the configuration of an exemplary number of portions of two substreams according to one embodiment. In particular, in FIG. 11A, a first portion 131 of a data stream is assigned to a first substream, and a second portion 132 is assigned to a second substream. In FIG. 11A, the allocation of pictures or access units to substreams is performed according to temporal layers, with access units of temporal layers 0-2 assigned to the first portion and access units of temporal layers 3-4 assigned to the second portion. However, this aspect should be understood as an example, and other allocations based on temporal layers or other criteria may be used. In other words, the separation by temporal layers should not be understood as limiting the mechanism for signaling the allocation of packets, pictures, access units, or units in general of a data stream to substreams.

[0087] According to one embodiment, device 16 locates a portion of data stream 14 (see portion 132 in FIG. 11A ) to check a given one of the substreams, e.g., the second substream in the example of FIG. 11A , for reliability using one or more third SEI messages 29. According to this embodiment, device 16 determines portion 132 to be the portion of data stream 14 formed by a subsection of the data stream, or the portion of these subsections that follows each of one or more third SEI messages 29 and extends to the coded video layer end of the access unit or picture unit in which the respective third SEI message is located. See, for example, FIG. 11A , where each of the pictures assigned to second portion 132 is preceded by one of the third SEI messages 29. In other words, for example, the allocation of sections of a data stream to one or more substreams may be performed at a picture-by-picture or access-by-access granularity.

[0088] For example, a picture unit carries coded video data of one picture and optionally supplementary information for decoding the picture, and an access unit carries one or more picture units belonging to one common time frame, e.g. pictures of different layers such as a base layer and an enhancement layer, and optionally supplementary information for the access units. For example, the third SEI message 29 is a TWC selection SEI message as described below, and the third SEI message 29 has a substream_id with a predetermined value associated with a predetermined substream.

[0089] The first substream in FIG. 11A is another example of a mechanism by which a portion for checking a further predetermined one of the substreams, here portion 131 for checking the first substream for reliability, can be located. According to one embodiment, for each picture unit or access unit in a section of a data stream (e.g., the section is determined as described above, e.g., as in FIGS. 9A-10B), device 16 determines the portion of the further predetermined substream by checking whether the picture unit or access unit includes an SEI message of a predetermined type; if not, the picture unit or access unit, or a portion thereof, is assigned to that portion. If the picture unit or access unit includes an SEI message of the predetermined type, device 16 can check whether the SEI message indicates that the picture unit or access unit belongs to the further predetermined substream. If so, the picture unit or access unit, or a portion thereof, is assigned to that portion; otherwise, the picture unit or access unit, or a portion thereof, is not assigned to that portion.

[0090] More generally, according to one embodiment, device 16 is configured to derive a summary SEI message from a data stream, the summary SEI message indicating one or more substreams of the data stream for which it is possible to check the data stream for reliability based on one or more portions within an individual substream. According to this embodiment, device 16 can perform a check for reliability of the data stream for a subset of one or more substreams of the one or more substreams.

[0091] According to one embodiment, device 16 performs a reliability check on a given substream of a subset of one or more substreams by locating a portion 132 of the given substream of the data stream through the use of one or more third SEI messages 29 interspersed within the data stream. According to this embodiment, device 16 determines the portion of the given substream to be a section of the data stream formed by concatenating subsections of the data stream that follow each of one or more third SEI messages and extend to the end of the video coding layer of the access unit in which the respective third SEI message is contained. According to this embodiment, optionally, device 16 can additionally use a second SEI message 27 (e.g., the second SEI message described above) to locate portion 132 by forming a section by additionally concatenating subsections that precede the second SEI message and extend to the start of the video coding layer of the access unit in which the second SEI message is contained, or that follow the second SEI message and extend to the end of the video coding layer of the access unit in which the second SEI message is contained.

[0092] As already mentioned, for each substream, the reliability check may be performed in units of one or more portions, e.g., temporally subsequent portions of data stream 14. For example, in the case of the example of FIG. 11A, the beginning and end of the substream portions are determined in the manner described with reference to FIG. 9C or FIG. 10A. See, for example, the first second SEI message 27*, e.g., the TWC verification SEI message, signaled before subportion 131*. For example, first second SEI message 27* may be part of the same access unit or picture unit as subportion 131*. As mentioned above, the end point 191 of the section of data stream 14 in which first portion 131 is located may end at the video coding layer end of the access unit or picture unit in which first second SEI message 27* is located. Similarly, for second portion 132, termination point 192 of the section of data stream 14 in which second portion 132 is located may terminate at the video coding layer termination of the access unit or picture unit in which second SEI message 27** is located. For example, second SEI message 27** may be part of the same access unit or picture unit as sub-portion 132*. For example, the embodiment of FIG. 11A may be an example of a grouped temporal layer signature that may be implemented in H.264.

[0093] Figure 11B shows an alternative to the embodiment of Figure 11A in that the termination of the portions is determined according to the embodiment of Figure 9A or Figure 10B. For example, the section of data stream 14 in which first portion 131 is located may terminate with a first secondary SEI message 27*, and the section of data stream 14 in which second portion 132 is located may terminate with a second secondary SEI message 27**. For example, the embodiment of FIG. 11B may be an example of a grouped temporal layer signature that may be implemented in H.265 or H.266. In the following, for the case of multiple verification substreams, optional concepts are presented for verifying authenticity across part boundaries, in units where digital signatures are signaled.

[0094] Figure 12 shows an example of verification dependencies for portions of two substreams. Data stream 14 in Figure 12 may follow the scheme of Figure 11B, but shows two subsequent time segments. In other words, Figure 12 shows, for each of the two substreams, two portions in which the respective substreams can be checked for authenticity: portions 131 and 133 of the first substream and portions 132 and 134 of the second substream, where first portion 131 and second portion 132 belong to a first segment of data stream 14 that precedes, for example, in transmission order or stream order, the second segment of data stream 14 to which third portion 133 and fourth portion 134 belong.

[0095] For example, the substreams may have dependencies defined between them, e.g., a second substream may depend on a first substream for verification, and for example, the substreams may have a hierarchical order defined between them, where a lower-ranked substream depends on a higher-ranked substream.

[0096] 12 further illustrates four portions of check values ​​471 to 474 to which the above description of check value 47 can optionally be applied. For the highest ranked substream, e.g., the first substream in FIG. 12, Verification Substream 0, boundary crossing verification can be performed as described above, i.e., using the hash value of the portion of the same substream belonging to the preceding segment for verification. See, for example, third portion 133, where the hash value of first portion 131 is included in check value 473.

[0097] The check value 471 in the first portion 131 may, for example, contain a default value instead of the hash value of the previous segment, as described above, since the previous segment is not available. In the case of a second substream that is dependent on a first substream, instead of using a hash value of a previous portion of the same substream, the check value may include, for example, a hash value of the first substream of the same segment of the data stream, see check values ​​472 and 474 of second portion 132 and fourth portion 134.

[0098] 12 allows for the first substream to be verified independently of the second substream, for example, after extracting the first substream from data stream 14 without the second substream, or after dropping the second substream from data stream 14. Furthermore, in the case of a second substream, it can be verified that the first substream on which it depends has not been manipulated.

[0099] The following describes syntax and semantics according to one embodiment. The syntax and semantics described below may be optionally modified or extended according to any of the previous embodiments. The previous embodiments may be combined with any of the syntax and semantics details and features described below. <Reliable Content Initialization SEI message> <Syntax of reliable content initialization SEI message> JPEG2025157186000002.jpg40161

[0100] <Reliable Content Initialization SEI Message Semantics> The Trusted Content Initialization SEI message, the Trusted Content Selection SEI message, and the Trusted Content Verification SEI message provide mechanisms for verifying that the coded video was generated by a trusted content provider. The Trusted Content Initialization SEI message provides information about the secure hash algorithm used to compute a message digest that is used together with the digital signature present in the Trusted Content Verification SEI message to verify the authenticity of the VCL NAL units present in the coded video sequence. This message also provides information about the digital signature algorithm used and the content provider's public key.

[0101] If any of a trusted content initialization SEI message, a trusted content selection SEI message, or a trusted content verification SEI message is present in a coded video sequence, it is a requirement for bitstream conformance that a trusted content initialization SEI message be present in all access units of the coded video sequence, including IDR access units and CRA pictures. It is a requirement for bitstream conformance that any trusted content selection SEI message and any trusted content verification SEI message in an access unit be preceded by a trusted content initialization SEI message.

[0102] The reliable content initialization SEI message applies to the current coded picture and all subsequent coded pictures until one or more of the following conditions become true: - The bitstream ends. - The start of a new coded video sequence. - Receiving a new reliable content initialization SEI message.

[0103] twci_hash_method_type indicates the secure hash algorithm used to compute a message digest of a subset of the VCL NAL units of the coded video sequence. Based on these message digests and the digital signature present in the Trusted Content Verification SEI message, a decoder can verify that the coded video was generated by the content originator indicated by the syntax elements twci_use_key_register_idx_flag, twci_key_source_uri, and, if twci_key_register_idx_flag is equal to 1, additionally indicated by twci_key_register_idx. Supported values ​​of the syntax element twci_hash_method_type, the size of the block used to compute the message digest, and the size of the computed message digest are specified in Table 1. Values ​​of twci_hash_method_type not listed in the table are reserved for future use by ITU-T|ISO / IEC and shall not be present in payload data conforming to this version of this specification. Decoders shall ignore Trusted Initialization SEI messages that contain reserved values ​​of twci_hash_method_type. The secure hash algorithms listed in Table 1 are specified in the "Secure Hash Standard," FIPS PUB 180-4. Table 1 Supported values ​​for twci_has_method_type JPEG2025157186000003.jpg61169 twci_num_verification_substreams_minus1+1 indicates the number of substreams for which the message digest is calculated and the number of signatures that may be present in the subsequent trusted content verification SEI message. The variable NumVerificationSubstream is derived as follows: NumVerificationSubstream=twci_num_verification_substreams_minus1+1. twci_use_key_register_idx_flag equal to 1 indicates that the URI contained in twci_key_source_uri specifies a certificate register and the syntax element twci_key_register_idx is present in the SEI message. twci_use_key_register_idx_flag equal to 0 indicates that the URI contained in twci_key_source_uri specifies a certificate and the syntax element twci_key_register_idx is not present in the SEI message.

[0104] twci_key_source_uri contains a URI with syntax and semantics specified in IETF Internet Standard 66. If twci_use_key_register_idx_flag is equal to 0, the URI identifies the content provider's certificate that can be used to verify the signature present in the following trusted verification SEI message. Otherwise (twci_use_key_register_idx_flag is equal to 1), the URI identifies the certificate register and content provider's certificate that can be used to verify the signature present in the following trusted verification SEI message indicated by twci_key_register_idx.

[0105] twci_key_register_idx contains an index within the certificate register indicated by twci_key_source_uri that specifies the content provider's certificate, which can be used to verify the signature present in the following trusted verification SEI message. The certificate indicated by the syntax elements twci_use_key_register_idx_flag, twci_key_source_uri, and, if twci_use_key_register_idx_flag is equal to 1, also by twci_key_register_idx, shall specify a digital signature method with associated parameters (if applicable) and the public key of the content provider. The format in which this information is provided is outside the scope of this specification. It is suggested to use a digital signature algorithm that complies with the "Digital Signature Standard", FIPS 186-5.

[0106] When a reliable content initialization SEI message is received, the calculation of the NumVerificationSubstream message digests is initialized according to the FIPS PUB 180-4 specification for the specified twci_hash_method_type. Each VCL NAL unit following the reliable content initialization SEI message is associated with one of the NumVerificationSubstream message digests. The verification substream id is indicated by the reliable content selection SEI message or is inferred to be equal to 0 if no reliable content selection SEI message is present for the coded picture. The message used to calculate the kth message digest (k is in the range 0 to twci_num_verification_substreams_minus1) is obtained by concatenating all VCL NAL units associated with the kth verification substream. The message digest calculation is performed on a block-by-block basis, and the size of the block is specified in Table 1 depending on the value of twci_hash_method_type. For each VCL NAL unit, the associated message digest is updated according to the algorithm specified in FIPS PUB 180-4 for the specified twci_hash_method_type. Note that since the message digest is calculated over the concatenation of all VCL NAL units of the verification substream, some of the processing blocks typically span two or more consecutive VCL NAL units.

[0107] <Trusted Content Selection SEI Message> <Syntax of the trusted content selection SEI message> JPEG2025157186000004.jpg19169 <Semantics of the Reliable Content Selection SEI Message> The trusted content selection SEI message provides a mechanism for associating a coded picture with one of the verification substreams indicated in the trusted content initialization SEI message. It is a bitstream conformance requirement that any reliable content selection SEI message be preceded by a reliable content initialization SEI message within the same coded video sequence.

[0108] twcs_verification_substream_id indicates the verification substream to which the VCL NAL units of the current coded picture are assigned. If there was a reliable content initialization SEI message in the current coded video sequence but no reliable content selection SEI message for the coded picture, the value of twcs_verification_substream_id is inferred to be equal to 0. The value of twcs_verification_substream_id shall be in the range from 0 to twci_num_verification_substream_minus1, inclusive.

[0109] The message digest of the verification substream with id equal to twcs_verification_substream_id is updated in the VCL NAL unit of the current coded picture according to the twci_hash_method_type specified in the preceding Reliable Content Initialization SEI message, as specified in Section 1.1.2.

[0110] <Trusted Content Validation SEI Message> <Syntax of Trusted Content Verification SEI Message> JPEG2025157186000005.jpg25169 <Reliable Content Validation SEI Message Semantics> The trusted content verification SEI message provides a mechanism for verifying the authenticity of video content. It is a bitstream conformance requirement that any trusted content verification SEI message be preceded by a trusted content initialization SEI message within the same coded video sequence. When a coded video sequence includes a reliable content initialization SEI message, it is a requirement of bitstream conformance that the last coded picture of the verification substream in the coded video sequence is associated with the reliable content verification SEI message.

[0111] twcv_signature_length_in_octets_minus1+1 specifies the length of the syntax element twcv_signature in octets (an octet consists of 8 bits). twcv_signature contains the digital signature for the verification substream indicated by twcs_verification_substream_id, which is sent in a trusted content selection SEI message preceding the trusted content verification SEI message in the same access unit or is assumed to be equal to 0. If VerificationSubstreamId is the value of twcs_verification_substream_id associated with a trusted content verification SEI message, then verification consists of the following ordered steps:

[0112] 1. The computation of the message digest, called CurrDigest, is completed as follows: The concatenation of VCL NAL units for the verification substream with id equal to VerificationSubstreamId is padded according to the specifications of FIPS PUB 180-4. Note that it is sufficient to pad the last VCL NAL unit of the verification substream. - The calculation of the message digest CurrDigest is completed according to the FIPS PUB 180-4 specification. The length of the message digest (in bits) is shown in Table 1.

[0113] 2. The reference message digest, RefDigest, is determined as follows: If VerificationSubstreamId is greater than 0, the reference message digest RefDigest is the last calculated message digest for the verification substream with id equal to VerificationSubstreamId-1. It is a bitstream conformance requirement that any trusted content verification SEI associated with verification substream id equal to VerificationSubstreamId-1 precedes any trusted content verification SEI message with verification substream id equal to VerificationSubstreamId.

[0114] - Otherwise, if the current trusted content verification SEI message is the first trusted content verification SEI message in the coded video sequence with verification id equal to 0 and the preceding coded video sequence did not contain a trusted content initialization SEI message (this includes the case where the current coded video sequence is the first coded video sequence in the bitstream), then RefDigest is set equal to a bitstring consisting of DigestSize bits equal to 1, where DigestSize is the size of the message digest as specified in Table 1. Otherwise, the reference message digest, RefDigest, is the last calculated message digest for the validation substream with id equal to 0.

[0115] 3. The identification string IdString is constructed by concatenating the reference message digest RefDigest, the current message digest, and the binary representation of twci_hash_method_type, as illustrated in FIG. The number of bits in RefDigest is determined by the value of twci_hash_method_type that was in effect when the value of RefDigest was calculated, and the number of bits in CurrDigest is determined by the current value of twci_hash_method_type, which is represented by 8 bits.

[0116] 4. The identification string IdString represents the message used to verify the signature. The signature verification algorithm and public key used to verify the signature are indicated by the syntax elements twci_use_key_register_idx_flag, twci_key_source_uri, and, if twci_use_key_register_idx_flag is equal to 1, also by twci_key_register_idx.

[0117] NOTE 1 - Because the bitstream used for signature verification includes the RefDigest, it is possible not only to verify that the VCL NAL unit used to compute the current message digest is correct, but also to additionally verify that no additional VCL NAL units were added to the bitstream, nor that no VCL NAL units were removed from the bitstream.

[0118] NOTE 2 - When a decoder tunes into the bitstream, it cannot correctly calculate the value of RefDigest and therefore cannot verify the configured IdString for the first trusted content verification SEI message. However, it can verify the signature starting from the second trusted content verification SEI message. After verification, the message digest of the verification substream with id equal to VerificationSubstreamId is reinitialized for the specified twci_hash_method_type according to the FIPS PUB 180-4 specification.

[0119] <Video coding method> The following describes an embodiment of a video encoding scheme that is an example of a video codec that can be used in combination with the above scheme for reliability checking. In other words, device 15 can be a video encoder, such as encoder 10 described below, and device 16 can be a video decoder, such as decoder 20 described below. The encoding codec used to encode the video into the video data stream may be one of those mentioned above, such as H.264, H.265, or H.266, but may generally be any type of video codec. An embodiment of such a codec is presented below. Here, it is block-based predictive coding using block-based transform coding, but as mentioned above, it may be another one.

[0120] Figure 14 shows an apparatus for predictively coding picture 12 into data stream 14, illustratively using transform-based residual coding. The apparatus or encoder is indicated using reference numeral 10. Figure 15 shows a corresponding decoder 20, i.e., apparatus 20 configured to predictively decode picture 12' from data stream 14, also using transform-based residual decoding, with an apostrophe used to indicate that picture 12' reconstructed by decoder 20 deviates from picture 12 originally coded by apparatus 10 in terms of coding loss introduced by quantization of the predicted residual signal.

[0121] The encoder 10 is configured to subject the prediction residual signal to a spatial-to-spectral transformation and to encode the prediction residual signal thus obtained into a data stream 14. Similarly, the decoder 20 is configured to decode the prediction residual signal from the data stream 14 and to subject the prediction residual signal thus obtained to a spectral-to-spatial transformation.

[0122] Internally, the encoder 10 may comprise a prediction residual signal former 22 that generates a prediction residual 24 to measure the deviation of a prediction signal 26 from the original signal, i.e., from the picture 12. The prediction residual signal former 22 may, for example, be a subtractor that subtracts the prediction signal from the original signal, i.e., from the picture 12. The encoder 10 then further comprises a transformer 28 that subjects the prediction residual signal 24 to a spatial-to-spectral transformation to obtain a spectral-domain prediction residual signal 24′, which is subjected to quantization by a quantizer 32 also included in the encoder 10. The prediction residual signal 24″ thus quantized is coded into the bitstream 14. For this purpose, the encoder 10 may optionally comprise an entropy coder 34 that entropy codes the prediction residual signal that is transformed and quantized into the data stream 14. The prediction signal 26 is generated by a prediction stage 36 of the encoder 10 based on the prediction residual signal 24″ that is coded into the data stream 14 and decodable therefrom. For this purpose, the prediction stage 36 may internally comprise, as shown in FIG. 14 , an inverse quantizer 38 that inversely quantizes the prediction residual signal 24″ to obtain a spectral-domain prediction residual signal 24′″ that corresponds to the signal 24′ without the quantization losses, followed by an inverse transformer 40 that subjects the latter prediction residual signal 24′″ to an inverse transform, i.e., a spectral-to-spatial transform, to obtain a prediction residual signal 24′″ that corresponds to the original prediction residual signal 24 without the quantization losses. A combiner 42 of the prediction stage 36 then recombines the prediction signal 26 and the prediction residual signal 24′″, for example by addition, to obtain a reconstructed signal 46, i.e., a reconstruction of the original signal 12. The reconstructed signal 46 may correspond to the signal 12′. A prediction module 44 of the prediction stage 36 then generates a prediction signal 26 based on the signal 46, for example by using spatial prediction, i.e., intra-picture prediction, and / or temporal prediction, i.e., inter-picture prediction.

[0123] Similarly, decoder 20 is internally composed of components that correspond to prediction stage 36 and are interconnected in a manner corresponding to prediction stage 36, as shown in Figure 15. In particular, entropy decoder 50 of decoder 20 is able to entropy decode quantized spectral domain prediction residual signal 24'' from the data stream, with inverse quantizer 52, inverse transformer 54, combiner 56, and prediction module 58 interconnected and cooperating in the manner described above with respect to the modules of prediction stage 36 to recover a reconstructed signal based on prediction residual signal 24'' such that the output of combiner 56 provides the reconstructed signal, i.e., picture 12', as shown in Figure 15.

[0124] Although not specifically described above, it is readily apparent that the encoder 10 can set several coding parameters, including, for example, prediction modes, motion parameters, etc., according to several optimization schemes, such as, for example, a method for optimizing rate- and distortion-related criteria, i.e., encoding cost. For example, the encoder 10 and the decoder 20 and corresponding modules 44, 58 can each support different prediction modes, such as intra-coding and inter-coding modes. The granularity at which the encoder and decoder switch between these prediction mode types may correspond to the subdivision of the pictures 12 and 12′, respectively, into coding segments or coding blocks. For example, in units of these coding segments, a picture may be subdivided into intra-coded blocks and inter-coded blocks. The intra-coded blocks are predicted based on the individual blocks' spatially already-coded / decoded neighbors, as outlined in more detail below. Several intra-coding modes may exist and be selected for individual intra-coded segments, including directional or angular intra-coding modes in which each segment is filled by extrapolating neighboring sample values ​​along a specific direction specific to the individual directional intra-coding mode to the individual intra-coded segment. The intra-coding modes may also include one or more further modes, such as, for example, a DC coding mode in which the prediction of an individual intra-coded block assigns a DC value to all samples in the individual intra-coded segment, and / or a planar intra-coding mode in which the prediction of an individual block is approximated or determined to be a spatial distribution of sample values ​​described by a two-dimensional linear function over the sample positions of the individual intra-coded block with a planar driving slope and offset defined by the two-dimensional linear function based on neighboring samples. In comparison, inter-coded blocks may, for example, be predicted temporally.For inter-coded blocks, motion vectors may be signaled within the data stream, indicating the spatial displacement of portions of previously coded pictures of the video to which picture 12 belongs, and the previously coded / decoded pictures are sampled to obtain prediction signals for the respective inter-coded blocks. This means that in addition to the residual signal coding included in data stream 14, such as entropy-coded transform coefficient levels representing the quantized spectral-domain prediction residual signal 24", data stream 14 may also have coded therein optional further parameters, such as coding mode parameters for assigning coding modes to various blocks, motion parameters for inter-coded segments, and some prediction parameters for the blocks, as well as parameters for controlling and signaling the subdivision of pictures 12 and 12' into their respective segments. Decoder 20 uses these parameters to subdivide the picture in the same way as the encoder did, assign the same prediction modes to the segments, and perform the same predictions, resulting in the same prediction signals.

[0125] FIG. 16 illustrates the relationship between, on the one hand, a reconstructed signal, i.e., a reconstructed picture 12′, and, on the other hand, a combination of a prediction residual signal 24″″ and a prediction signal 26 signaled in the data stream 14, according to one embodiment. As already mentioned above, the combination may be additive. In FIG. 16, the prediction signal 26 is illustrated as a subdivision of the picture area into intra-coded blocks, exemplarily shown with hatching, and inter-coded blocks, exemplarily shown without hatching. The subdivision may be any subdivision, such as a regular subdivision of the picture area into rows and columns of square or non-square blocks, or a multi-tree subdivision of the picture 12 from a tree-root block into multiple leaf blocks of various sizes, such as a quad-tree subdivision, or a mixture thereof, as shown in FIG. 16, in which the picture area is first subdivided into rows and columns of tree-root blocks, which are then further subdivided into one or more leaf blocks according to a recursive multi-tree subdivision.

[0126] Again, data stream 14 may have encoded therein an intra-coding mode that assigns one of several supported intra-coding modes for intra-coded blocks 80 to each individual intra-coded block 80. For inter-coded blocks 82, data stream 14 may have encoded therein one or more motion parameters. Generally speaking, inter-coded blocks 82 are not limited to being temporally coded. Instead, inter-coded blocks 82 may be any block predicted from a previously coded portion beyond current picture 12 itself, such as a previously coded picture of the video to which picture 12 belongs, or, if the encoder and decoder are scalable encoder and decoder, respectively, a picture of another view or a hierarchically lower layer.

[0127] The prediction residual signal 24"" in Figure 16 is also shown as a subdivision of the picture area into blocks 84. These blocks are sometimes called transform blocks to distinguish them from the coding blocks 80 and 82. In fact, Figure 16 shows that the encoder 10 and decoder 20 may use two different subdivisions of the picture 12 and the picture 12' into blocks: one subdivision into coding blocks 80 and 82, respectively, and the other subdivision into transform blocks 84. While both subdivisions may be the same, i.e., each coding block 80 and 82 may simultaneously form a transform block 84, Figure 16 also shows the case where, for example, the subdivision into transform blocks 84 forms an extension of the subdivision into coding blocks 80, 82, such that any boundary between the two blocks 80 and 82 covers the boundary between the two blocks 84, or instead, each block 80, 82 coincides with one of the transform blocks 84 or with a cluster of transform blocks 84. However, these subdivisions may also be determined or selected independently of one another, such that the transformation blocks 84 may instead cross the block boundaries between the blocks 80, 82. Thus, as far as the subdivision into transformation blocks 84 is concerned, similar statements are true as those presented with regard to the subdivision into blocks 80, 82, i.e., the blocks 84 may be the result of a regular subdivision of the picture area into blocks (with or without arrangement into rows and columns), a recursive multi-tree subdivision of the picture area, or a combination thereof, or any other type of blocking. It should be noted that the blocks 80, 82, and 84 are not limited to quadratic shapes, rectangles, or any other shape.

[0128] 16 further illustrates that the combination of the prediction signal 26 and the prediction residual signal 24'''' directly results in the reconstructed signal 12'. However, it should be noted that, according to alternative embodiments, more than one prediction signal 26 can be combined with the prediction residual signal 24''' to result in the picture 12'.

[0129] In Figure 16, the transform blocks 84 have the following meaning: The transformer 28 and the inverse transformer 54 perform transforms in units of these transform blocks 84. For example, many codecs use some kind of DST or DCT for all transform blocks 84. Some codecs allow for skipping the transform for some of the transform blocks 84, so that the prediction residual signal is directly coded in the spatial domain. However, according to the embodiments described below, the encoder 10 and the decoder 20 are configured so that they support several transforms. For example, the transforms supported by the encoder 10 and the decoder 20 may include:

[0130] DCT-II (or DCT-III), where DCT stands for Discrete Cosine Transform DST-IV, where DST stands for discrete sine transform DCT-IV DST-VII Identity Transformation (IT) Of course, the transformer 28 supports all of the forward transform versions of these transforms, while the decoder 20 or inverse transformer 54 supports the corresponding backward or inverse versions. Inverse DCT-II (or Inverse DCT-III) Reverse DST-IV ·Inverse DCT-IV Reverse DST-VII Identity Transformation (IT) Different examples for coding the residual blocks representing spatial residual blocks in the transform domain and their transform blocks respectively are given below. Although a codec may support only one of them, the video data stream may also contain an entropy coding mode identifier indicating whether the prediction residual data of the residual blocks should be decoded from the video data stream using a context-adaptive variable length coding mode or a context-adaptive binary arithmetic coding mode, examples of which can be derived from the following description.

[0131] <Context-based adaptive variable length coding (CAVLC)> This is the method used to code residual blocks of zigzag-ordered 4x4 (and 2x2) transform coefficients. CAVLC is designed to take advantage of several properties of quantized 4x4 blocks. 1. After prediction, transformation, and quantization, blocks are usually sparse (contain mostly zeros). CAVLC uses run-level coding to compactly represent strings of zeros. 2. The highest non-zero coefficient after zigzag scanning is often a sequence of + / - 1. CAVLC compactly signals the number of frequent + / - 1 coefficients ("trailing 1" or "T1"). 3. The number of non-zero coefficients in adjacent blocks is correlated. The number of coefficients is coded using a lookup table. The choice of lookup table depends on the number of non-zero coefficients in the adjacent blocks. 4. The levels (magnitudes) of non-zero coefficients tend to be high at the beginning of the sorted sequence (near the DC coefficient) and decrease towards higher frequencies. CAVLC exploits this by adapting the VLC lookup table selection of the "level" parameter depending on the magnitude of the most recently coded level.

[0132] CAVLC coding of a block of transform coefficients proceeds as follows. 1. Encode the number of coefficients and trailing ones (coeff_token). The first VLC, coeff_token, encodes both the total number of non-zero coefficients (TotalCoeffs) and the number of trailing + / - 1 values ​​(T1). TotalCoeffs is 0 (no coefficients in a 4x4 block). 1T1 can be anywhere from 0 to 16 (16 non-zero coefficients). T1 can be anywhere from 0 to 3; if there are more than three trailing + / - 1's, only the last three are treated as a "special case" and the rest are coded as normal coefficients. Note: The coded_block_pattern (see above) indicates which 8x8 blocks in a macroblock contain non-zero coefficients; however, within a coded 8x8 block, there may be 4x4 sub-blocks that do not contain any coefficients, and therefore TotalCoeff can be 0 in any 4x4 sub-block. In practice, this value of TotalCoeff occurs most frequently and is assigned the shortest VLC.

[0133] There are four choices of lookup tables to use to encode the coeff_token, described as Num-VLC0, Num-VLC1, Num-VLC2, and Num-FLC (three variable length code tables and one fixed length code). The choice of table depends on the number of non-zero coefficients in the previously coded blocks above and to the left, Nu and NL. The parameter N is calculated as follows: If blocks U and L are available (i.e., within the same coded slice), then N=(Nu+NL) / 2; if only block U is available, then N=NU; if only block L is available, then N=NL; and if neither is available, then N=0.

[0134] N selects a lookup table (Table 34), and in this way the VLC selection is adapted depending on the number of coded coefficients in the neighboring block (context adaptation). Num-VLC0 is "biased" towards a small number of coefficients: low values ​​of TotalCoeff (0 and 1) are assigned particularly short codes, and high values ​​of TotalCoeff are assigned particularly long codes. Num-VLC1 is biased towards a medium number of coefficients (relatively short codes are assigned to TotalCoeff values ​​around 2-4), Num-VLC2 is biased towards a higher number of coefficients, and FLC assigns a fixed 6-bit code to all values ​​of TotalCoeff. Table 34. Coeff_token lookup table selection JPEG2025157186000006.jpg29112

[0135] 2. Encode the code of each T1. For each T1 (trailing + / - 1) signaled by the coeff_token, encode the sign with a single bit (0=+, 1=-). These are coded in reverse order, starting with the most frequent T1.

[0136] 3. Encode the levels of the remaining non-zero coefficients. The level (sign and magnitude) of each remaining non-zero coefficient in the block is coded in reverse order, starting with the most frequent and working back towards the DC coefficient. The selection of the VLC table for coding each level is adapted according to the magnitude of each successive coding level (context adaptation). There are seven VLC tables to choose from: Level_VLC0 to Level_VLC6. Level_VLC0 is biased towards lower magnitudes. Level_VLC1 is biased towards slightly higher magnitudes, etc. The table selection is adapted as follows: (a) Initialize the table to Level_VLC0 (unless there are more than 10 non-zero coefficients and not less than 3 trailing + / - 1's, then start at Level_VLC1). (b) Encode the most frequent non-zero coefficients. (c) If the magnitude of this coefficient is greater than a predetermined threshold, move to the next VLC table. In this way, the level selection corresponds to the magnitude of the most recently coded coefficient. The thresholds are listed in Table 35. The first threshold is 0, which means that the table is always incremented after the first coefficient level is coded. Table 35. Thresholds for determining whether to increment the level table number JPEG2025157186000007.jpg46126

[0137] 4. Encode the total number of zeros before the last coefficient. TotalZeros is the sum of all zeros preceding the highest non-zero coefficient in the sorted array. This is coded in the VLC. The reason for sending a separate VLC t indicating TotalZeros is that many blocks contain some non-zero coefficients at the beginning of the array, and (as we'll see below) this technique means that the run of zeros at the beginning of the array does not need to be coded.

[0138] 5. Code each run of zeros. The number of zeros preceding each non-zero coefficient (run_before) is coded in reverse order: the run_before parameter is coded for each non-zero coefficient, starting with the most frequent, with two exceptions: (a) If there are no more zeros left to encode (ie, Σ[run_before]=TotalZeros), then there is no need to encode any more run_before values. (b) There is no need to code the run_before of the last (least frequent) non-zero coefficient. The VLC for each run of zeros is selected according to (a) the number of zeros yet to be encoded (ZerosLeft) and (b) run_before. For example, if there are only 2 zeros left to be encoded, run_before can only take 3 values (0, 1, or 2), and thus the VLC need not exceed 2 bits in length. If there are 6 zeros yet to be encoded, run_before can take 7 values (0 - 6), and the VLC table needs to be made larger accordingly.

[0139] <Example of CAVLC> In all of the following examples, it is assumed that table Num-VLC0 is used to encode the coeff_token. · Example 1 4x4 block: JPEG2025157186000008.jpg2459 Shuffled block: 0, 3, 0, 1, -1, -1, 0, 1, 0... TotalCoeff = 5 (indexed from highest frequency [4] to lowest frequency [0]) TotalZeros = 3 T1s = 3 (although there are actually 4 trailing 1s, only 3 can be encoded as a "special case") Encoding: JPEG2025157186000009.jpg80169 The transmitted bitstream for this block is 000010001110010111101101.

[0140] Decoding: The output array is "constructed" from the decoded values as shown below. The values added to the output array at each stage are shown within []. JPEG2025157186000010.jpg77169 The decoder inserts 2 zeros. However, TotalZeros is equal to 3, and thus another 0 is inserted before the lowest coefficient to form the final output array. [0], 3, 0, 1, -1, -1, 0, 1

[0141] Example 2 4x4 blocks: JPEG2025157186000011.jpg2353 Sorted blocks: -2, 4, 3, -3, 0, 0, -1, ... TotalCoeffs=5 (indexed from most frequent [4] to least frequent [0]) TotalZeros=2 T1s=1 <encoding>: JPEG2025157186000012.jpg62168 The transmitted bitstream for this block is 000000011010001001000010111001100.

[0142] NOTE 1: Level (3) with a value of -3 is coded as a special case. If there are less than three T1s, the first non-T1 level does not have a value of + / -1 (it would otherwise have been coded as T1). To save bits, this level is incremented if negative (decremented if positive), so that + / -2 maps to + / -1, + / -3 maps to + / -2, and so on. In this way, shorter VLCs are used.

[0143] Note 2: After encoding level (3), the level_VLC table is incremented because the magnitude of this level is greater than the first threshold (which is 0). After encoding level (1), with a magnitude of 4, the table number is incremented again because level (1) is greater than the second threshold (which is 3). Note that the final level (-2) uses a different code than the first encoding level (also -2). <Decryption>: JPEG2025157186000013.jpg78169 Now all zeros have been decoded, so the output array is: -2, 4, 3, -3, 0, 0, -1 (This example shows how bits are saved by encoding all zeros; even though there are five non-zero coefficients, only one run needs to be encoded.)

[0144] <cabac> In CABAC, encoding and decoding can be done as follows. 1) The position of the first non-zero transform coefficient encountered when traversing the transform coefficients along a predetermined scan order is coded / decoded. 2) The transform coefficients, including the non-zero transform coefficients in the coded / decoded positions that follow in scan order, are coded / decoded from the data stream.

[0145] Alternatively, in CABAC, encoding and decoding may be performed as follows: 1) A significance map indicating the location of a non-zero transform coefficient is coded / decoded by using a significance flag and a last significance flag. In a forward scan traversing the locations of the transform coefficients, a significance flag indicating whether a non-zero transform coefficient is located at a particular location is coded / decoded, and if so, and if the location is not the end of the forward scan, a last significance flag indicating whether the non-zero transform coefficient located at the particular location is the last non-zero transform coefficient of the forward scan is coded / decoded; 2) The values ​​of the non-zero transform coefficients are coded / decoded sequentially in a reverse scan order, which reverses the forward scan order.

[0146] In CABAC, encoding and decoding can alternatively be done as follows: 1) encoding / decoding coordinates of a location within a transform block representing prediction residual data at which a last non-zero transform coefficient is encountered when traversing the transform coefficients of the transform block along a predetermined scan order; 2) sequentially encoding / decoding the values ​​of ranked transform coefficients included between the last non-zero transform coefficient and the first scanned transform coefficient along a predetermined scanning order; 3) A predetermined scan order from among the diagonal scan order, horizontal scan order, and vertical scan order is selected according to the intra prediction mode of the intra predicted block using a mapping that maps each of a plurality of corresponding intra prediction modes, for example, 33, to the corresponding diagonal scan order, horizontal scan order, and vertical scan order.

[0147] In CABAC, encoding and decoding can alternatively be done as follows: 1) context-adaptive binary arithmetic coding / decoding of quantization indices of transform coefficients of a transform block representing a residual block; and 2) by using a successive quantization to obtain a quantization index, where the value of the current transform coefficient is quantized depending on the parity of the quantization index of the previous quantization index, or a successive inverse quantization of a quantization index, where the value of the current transform coefficient depends on the parity of the quantization index of the previous quantization index; This function encodes / decodes prediction residual data of residual blocks from a video data stream.

[0148] 17 shows a flowchart of a method 160 for checking the authenticity of a video data stream in which video is encoded, according to one embodiment, performed, for example, by device 16. The method includes subjecting a predetermined portion of the video data stream, or data derived therefrom, to a hash function to obtain a hash value (131), deriving a digital signature from the video data stream (161), and checking whether the hash value matches the digital signature to determine whether the video data stream can be trusted (141).

[0149] 18 shows a flowchart of a method 200 for decoding video from a video data stream according to one embodiment, performed by, for example, device 20. The method includes decrypting (163) the digital signature from the video data stream. The method further includes subjecting (160) the digital signature to a check on authenticity of the video data stream by applying (131) a hash function to a predetermined portion of the video data stream, or data derived therefrom, to obtain a hash value, and checking whether the hash value matches the digital signature to determine (141) whether the video data stream can be trusted.

[0150] 19 shows a flowchart of a method 150 for rendering a video data stream in which video that can be checked for authenticity is encoded, performed, for example, by device 15. The method includes subjecting a predetermined portion of the video data stream, or data derived therefrom, to a hash function to obtain a hash value (131), calculating a digital signature based on the hash value to digitally sign the hash function (171), and inserting the digital signature into the video data stream, thereby making it possible to determine whether the video data stream can be trusted by checking whether the hash value matches the digital signature (177).

[0151] Further embodiments In the following, embodiments are described in general terms which may optionally be combined with any of the features described above. 1. An apparatus 16 for checking the authenticity of a video data stream 14 in which video is encoded, the apparatus comprising: applying a predetermined portion 13 of the video data stream, or data derived therefrom, to a hash function 31 to obtain a hash value 33; Deriving a digital signature 43 from the video data stream; configured to determine 41 whether the video data stream is authentic by checking whether the hash value 33 matches the digital signature 43; a first syntax element indicating a total number of non-zero transform coefficients in a transform block representing a residual block, and a trailing ones number indicating the number of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; one or more second syntax elements that indicate the signs of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; and one or more third syntax elements indicating values ​​of the non-zero transform coefficients, excluding the number of non-zero transform coefficients having an absolute value of one when traversing the coefficients along the scan order; and a fourth syntax element indicating the total number of zero-valued transform coefficient levels in the transform block following the first encountered non-zero transform coefficient in scan order; and encoding the video into the video data stream by block-based predictive coding and transform-based residual coding; and encoding predictive residual data of residual blocks into the video data stream by use of context-adaptive variable length coding using one or more fifth syntax elements that indicate a position of non-zero transform coefficients along the scan order by indicating a number of consecutive zero-valued transform coefficients in the scan order between successively encountered non-zero transform coefficients.

[0152] 2. The apparatus of embodiment 1, wherein the digital signature is transmitted within a supplemental enhancement information message of the video data stream. 3. Checking whether the hash value matches the digital signature to determine whether the video data stream is authentic; Decrypt the digital signature to obtain the check value 47,45 3. The apparatus of embodiment 1 or 2, configured to check 49 whether the hash value 33 matches a check value 47. 4. Applying a predetermined portion 22 of the video data stream, or data derived therefrom, to a hash function to obtain a hash value; reconstructing the video with respect to the predetermined portion to obtain a reconstructed portion of the video; 4. An apparatus according to any one of embodiments 1 to 3, configured to subject the reconstructed portion to a hash function.

[0153] 5. The device is Decodes video from the video data stream, 5. The apparatus according to any one of embodiments 1 to 4, wherein the apparatus is a decoder 20 configured to decode a digital signature from a video data stream. 6. configured to decode the digital signature from the supplemental enhancement information message of the video data stream; 6. The device of embodiment 5.

[0154] 7. configured to locate a predetermined portion within a video data stream by using one or more SEI messages 21, 25, 27 interspersed within the video data stream to determine the predetermined portion to be a section of the video data stream that spans or extends between one or more SEI messages; 7. The device of embodiment 5 or 6. 8. configured to decrypt a digital signature from one of the one or more SEI messages of a video data stream; 8. The device of embodiment 7. 9. configured to locate a predetermined portion 13 within a video data stream by using prefix SEI messages 25 and suffix SEI messages 27 interspersed within the video data stream to determine the predetermined portion to be a section of the video data stream that spans or is located between the prefix SEI message and the suffix SEI message; 7. The device of embodiment 5 or 6.

[0155] 10. configured to locate a predetermined portion 13 within a video data stream by using prefix SEI messages 25 and suffix SEI messages 27 interspersed within the video data stream, by determining that the predetermined portion is located between the prefix SEI message and the suffix SEI message; 7. The device of embodiment 5 or 6. 11. The apparatus of embodiment 9 or 10, configured to decrypt a digital signature from a suffix SEI message. 12. An apparatus as described in embodiment 5 or 6, configured to locate a predetermined portion 13 within a video data stream by using a first SEI message 25 and a second SEI message 27 interspersed within the video data stream to determine that the predetermined portion is a section of the video data stream that spans or is located between the first SEI message and the second SEI message, or a section of the video data stream that spans between the first SEI message and the second SEI message, or a point in the data stream that is located downstream of the first SEI message and the second SEI message.

[0156] 13. An apparatus as described in embodiment 5 or 6, configured to locate a predetermined portion 13 within a video data stream by using a first SEI message 25 and a second SEI message 27 interspersed within the video data stream to determine that the predetermined portion is located between the first SEI message and the second SEI message, or between a point in the data stream located downstream of the first SEI message and the second SEI message. 14. An apparatus as described in embodiment 12 or 13, configured to determine a point in the data stream located downstream of the second SEI message based on the length of the section or as being located at the end of a video coding layer portion having an access unit of the video data stream in which the second SEI message is contained.

[0157] 15. The apparatus of any one of embodiments 12-14, configured to decrypt the digital signature from the second SEI message. 16. Deriving from the video data stream a summary SEI message indicating one or more substreams of the video data stream, each of which is capable of checking the video data stream for reliability based on one or more portions within an individual substream; For a given substream of the subset, configured to perform checking the video data stream for reliability with respect to a subset of one or more of the one or more substreams by locating a portion of the video data stream by using one or more first and second SEI messages interspersed within the video data stream to determine that the portion of the given substream is a section of the video data stream formed by concatenating a subsection of the video data stream that follows each of the one or more first SEI messages and extends to a video coding layer end of the access unit in which the respective first SEI message is contained, and a subsection that precedes the second SEI message and extends to a video coding layer start of the access unit in which the second SEI message is contained, or that follows the second SEI message and extends to a video coding layer end of the access unit in which the second SEI message is contained; 7. The device of embodiment 5 or 6.

[0158] 17. Deriving from the video data stream a summary SEI message indicating one or more substreams of the video data stream, for each of which the video data stream can be checked for reliability based on one or more portions within an individual substream; For a given substream of the subset, configured to perform checking the video data stream for reliability with respect to a subset of one or more of the one or more substreams by locating a portion of the video data stream of interest by using one or more first SEI messages interspersed within the video data stream to determine that the portion of the given substream is a section of the video data stream formed by concatenating subsections of the video data stream that follow each of the one or more first SEI messages and extend up to a video coding layer end of the access unit in which the respective first SEI message is contained; 7. The device of embodiment 5 or 6.

[0159] 18. Deriving from the video data stream a summary SEI message indicating one or more substreams of the video data stream, for each of which the video data stream can be checked for reliability based on one or more portions within an individual substream; For a picture unit of the video data stream, checking whether the video data stream includes a sub-stream selection SEI message for the picture unit; if the video data stream does not include a sub-stream selection SEI message for the picture unit, assigning video coded layer payload packets of the picture unit to a first sub-stream of the one or more sub-streams; If the video data stream includes a substream selection SEI message for the picture unit, by assigning video coded layer payload packets of the picture unit to one or more substreams, the substreams indicated by the substream selection SEI message; determining a respective portion of the video data stream for one or more substreams; 7. The apparatus of embodiment 5 or 6, configured to perform checking the video data stream for reliability with respect to a subset of the one or more substreams of the one or more substreams.

[0160] 19. Checking the video data stream for reliability with respect to a subset of one or more substreams; An apparatus as described in any of embodiments 16 to 18, configured to further perform by subjecting the determined portions for one or more substreams of the subset of one or more substreams to a hash function to derive respective hash values. 20. An apparatus as described in any of embodiments 16 to 19, further configured to determine the portion of each substream of a subset of one or more substreams by using a first SEI message 25 and a second SEI message 27 interspersed within the video data stream to determine that the portion is located between the first SEI message and the second SEI message, or between a point in the data stream located downstream of the first SEI message and the second SEI message.

[0161] 21. An apparatus described in any of embodiments 16 to 20, further configured to determine that each portion of a substream of a subset of one or more substreams terminates at or before one end of the encoded video sequence. 22. One or more substreams have a defined order therein, and the apparatus determines that a given portion is part of a given substream of a subset of the one or more substreams; whether the hash value and a further hash value obtained by applying a hash function to the previous portion of the predetermined portion, or further data derived from it, match the digital signature; or by checking whether a combined hash value derived by hashing the predetermined portion and a further hash value obtained by applying a hash function to a previous portion of the video data stream, or further data derived therefrom, matches the digital signature; configured to sequentially perform a check of the video data stream for authenticity with respect to each portion of the video data stream derived for one or more substreams; the previous part precedes the given part in the defined sequence order between the parts; An apparatus described in any one of embodiments 17 to 20.

[0162] 23. Whether the hash value and a further hash value obtained by applying a hash function to an earlier portion of the video data stream, or further data derived therefrom, match the digital signature; or and checking whether a combined hash value derived by hashing the predetermined portion and a further hash value obtained by applying a hash function to a previous portion of the video data stream, or further data derived therefrom, matches the digital signature. configured to sequentially perform checking the video data stream for authenticity with respect to a plurality of portions of the video data stream; An apparatus according to any one of embodiments 1 to 21.

[0163] 24. Combining the hash value with a further hash value to obtain a combined hash value, and checking whether the combined hash value matches the digital signature; or configured to apply a hash function to the predetermined portion and a previous portion of the video data stream, or further data derived therefrom, to obtain a combined hash value by applying the resulting further hash value to the predetermined portion and a previous portion of the video data stream, or further data derived therefrom, and to check whether the combined hash value matches the digital signature; 24. A device according to embodiment 22 or 23. 25. The device of embodiment 24, wherein the combination is a linkage. 26. The device of embodiment 22, 23, 24, or 25, configured to check whether parameters or identifiers of a hash function match the digital signature to further determine whether the video data stream is authentic.

[0164] 27. Two different digital signatures are transmitted within the video data stream for a given portion, and the device: If the video data stream contains a previous part for a given part, whether the hash value and a further hash value obtained by applying a hash function to an earlier portion of the video data stream, or further data derived therefrom, matches the first of two different digital signatures; or checking whether a combined hash value derived by hashing the predetermined portion and a further hash value obtained by applying a hash function to a previous portion of the video data stream, or further data derived therefrom, matches a first of the two different digital signatures; If the video data stream does not contain any previous parts for a given part, By checking whether the hash value matches the second of two different digital signatures to determine whether the video data stream can be trusted. configured to sequentially perform checking the video data stream for authenticity with respect to a plurality of portions of the video data stream; An apparatus described in any one of embodiments 1 to 26.

[0165] 28. The device is If the video data stream contains a previous part for a given part, checking whether the hash value and a further hash value obtained by applying a hash function to an earlier portion of the video data stream or further data derived therefrom match the digital signature, or whether the hash value and a still further hash value obtained by applying a hash function to an earlier portion of the video data stream or further data derived therefrom, which is transmitted in the video data stream for a given portion, match the digital signature and the still further hash value is equal to a still further hash value obtained by applying a hash function to the earlier portion of the video data stream or further data derived therefrom; checking whether a combined hash value derived by hashing the predetermined portion on the one hand and a further hash value obtained by applying a hash function to an earlier portion of the video data stream or further data derived therefrom on the other hand matches the first of the two different digital signatures, or whether a combined hash value obtained by applying a hash function to the hash value and a further hash value transmitted in the video data stream for the predetermined portion matches the digital signature and the further hash value is equal to a further hash value obtained by applying a hash function to an earlier portion of the video data stream or further data derived therefrom, If the video data stream does not contain any previous parts for a given part, By checking if the hash value matches the digital signature to determine if the video data stream can be trusted. 27. An apparatus as described in any one of embodiments 1 to 26, configured to sequentially perform checking of the video data stream for reliability for multiple portions of the video data stream.

[0166] 29. The device is If the video data stream does not contain any previous parts for a given part, 29. The apparatus of claim 28, configured to determine whether the video data stream is trustworthy by checking whether the hash value matches the digital signature by checking whether the hash value and a further hash value transmitted within the video data stream for a given portion match the digital signature.

[0167] 30. The predetermined value is equal to the check value obtained by decrypting the digital signature or a predetermined portion of the check value related to the predetermined value; or If the predetermined value is equal to a check value in a further hash field, arrived at by a further hash function applied to the predetermined value or to a concatenation of values ​​including the predetermined value, The digital signature is matched by a predetermined value, An apparatus described in any one of embodiments 1 to 29. 31. The apparatus of any one of embodiments 1 to 30, configured to perform the check by using an asymmetric decryption scheme using a public key. 32. The apparatus of embodiment 31, configured to derive an asymmetric decryption scheme using first information derived from the data stream. 33. The apparatus of embodiment 32, wherein the first information includes a decryption scheme identifier or a first pointer to a first location from which the asymmetric decryption scheme can be determined, or an identifier of an entity that encoded the video into the video data stream. 34. The apparatus of any one of embodiments 31-33, configured to derive a public key using second information derived from the data stream. 35. The apparatus of embodiment 34, wherein the second information includes a second pointer to a second location from which the public key can be obtained, or an identifier of the entity that encoded the video into the video data stream.

[0168] 36. An apparatus configured to derive a public key by deriving a first syntax element and a second syntax element from a video data stream, the second syntax element indicating a pointer to a location from which the public key can be derived, the apparatus comprising: if the first syntax element has a first state, inferring that the location identifies exactly one public key, deriving exactly one public key from the location; An apparatus as described in any of embodiments 31 to 35, configured to infer that the position indicates a list of keys when the first syntax element has the second state, derive from the video data stream a third syntax element indicating a pointer to an entry in the list of keys, and derive a public key from the entry in the list of keys indicated by the pointer.

[0169] 37. The apparatus of any one of embodiments 1-36, configured to derive a hash function using third information derived from the data stream. 38. The apparatus of embodiment 37, wherein the third information includes a hash function identifier or a third pointer to a third location from which the hash function can be determined, or an identifier of the entity that encoded the video into the video data stream. 39. An apparatus as described in any one of embodiments 1-38, wherein the hash value depends on all bits of a predetermined portion of the video data stream. 40. An apparatus as described in any one of embodiments 1 to 39, wherein the hash value depends on all bits of a predetermined portion of the video data stream within the entropy-coded domain. 41. An apparatus as described in any of embodiments 1 to 40, wherein the predetermined portion of the video data stream spans more than one access unit of the video data stream such that the hash value depends on bits of more than one access unit.

[0170] 42. By checking whether the hash function is correct by checking whether the parameterization or identifier of the hash function matches the digital signature. An apparatus as described in any of embodiments 1 to 41, configured to further check the authenticity of the video data stream. 43. An apparatus described in any of embodiments 1 to 42, wherein the predetermined portion consists of one or more video coding layer portions of a video data stream in which motion vectors and intra prediction modes for predictive blocks and transform coefficients for residual blocks are coded. 44. Providing a hash value for checking the authenticity of a video data stream combined with a media stream, together with a further hash value obtained by subjecting a portion of the media stream accompanying the video data stream, or further data derived therefrom, to a hash function or a different hash function; An apparatus described in any one of embodiments 1 to 43.

[0171] 45. A first syntax element indicating the total number of non-zero transform coefficients in a transform block representing a residual block, and a trailing ones number indicating the number of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; one or more second syntax elements that indicate the signs of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; and one or more third syntax elements indicating values ​​of the non-zero transform coefficients, excluding the number of non-zero transform coefficients having an absolute value of one when traversing the coefficients along the scan order; and a fourth syntax element indicating the total number of zero-valued transform coefficient levels in the transform block following the first encountered non-zero transform coefficient in scan order; and one or more fifth syntax elements indicating the position of the non-zero transform coefficients along the scan order by indicating the number of consecutive zero-valued transform coefficients in the scan order between consecutively encountered non-zero transform coefficients. or decoding a significance flag indicating whether a non-zero transform coefficient is located at a current position in a forward scan traversing the transform coefficients of the transform block, and if so and if the current position is not the last in the forward scan, decoding a last significance flag indicating whether the non-zero transform coefficient located at the current position is the last non-zero transform coefficient in the forward scan, thereby decoding a significance map indicating the positions of the non-zero transform coefficients in the transform block representing the residual block; sequentially decoding the values ​​of the non-zero transform coefficients in a reverse scan order by reversing the forward scan order, thereby By using context-adaptive binary arithmetic decoding, By decoding the prediction residual data of the residual block from the video data stream, 45. The apparatus of any one of embodiments 1 to 44, wherein the apparatus is a decoder configured for decoding video from a video data stream by block-based predictive decoding and transform-based residual decoding.

[0172] 46. ​​Decode coordinates of a location within the transform block representing prediction residual data at which a last non-zero transform coefficient is encountered when traversing the transform coefficients of the transform block along a predetermined scan order; sequentially decoding values ​​of ranked transform coefficients included between the last non-zero transform coefficient and the first scanned transform coefficient along a predetermined scan order; By using context-adaptive binary arithmetic decoding, by selecting a predetermined scan order from among a diagonal scan order, a horizontal scan order, and a vertical scan order according to an intra prediction mode of the intra predicted block using a mapping that maps each of the 33 intra prediction modes to a corresponding diagonal scan order, a horizontal scan order, and a vertical scan order. By decoding the prediction residual data of the intra-predicted block from the video data stream, A decoder configured to decode video from a video data stream by block-based predictive decoding and transform-based residual decoding, An apparatus described in any one of embodiments 1 to 44.

[0173] 47. By using context-adaptive binary arithmetic coding / decoding of quantization indices of transform coefficients of a transform block representing a residual block and successive inverse quantization of quantization indices in which the value of a current transform coefficient depends on the parity of the quantization indices of the previous quantization indices. By decoding the prediction residual data of the residual block from the video data stream, 45. The apparatus of any one of embodiments 1 to 44, wherein the apparatus is a decoder configured for decoding video from a video data stream by block-based predictive decoding and transform-based residual decoding.

[0174] 48. A decoder 20 configured to decode video from a video data stream 14, the decoder comprising: Decrypting (63) the digital signature 43 from the video data stream; applying a predetermined portion 13 of the video data stream, or data 62 derived therefrom, to a hash function 31 to obtain a hash value 33; By checking whether the hash value matches the digital signature to determine whether the video data stream is authentic (41), configured to subject the digital signature to a check on the authenticity of the video data stream; The decoder a first syntax element indicating a total number of non-zero transform coefficients in a transform block representing a residual block, and a trailing ones number indicating the number of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; one or more second syntax elements that indicate the signs of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; and one or more third syntax elements indicating values ​​of the non-zero transform coefficients, excluding the number of non-zero transform coefficients having an absolute value of one when traversing the coefficients along the scan order; and a fourth syntax element indicating the total number of zero-valued transform coefficient levels in the transform block following the first encountered non-zero transform coefficient in scan order; and one or more fifth syntax elements indicating the position of the non-zero transform coefficients along the scan order by indicating the number of consecutive zero-valued transform coefficients in the scan order between consecutively encountered non-zero transform coefficients. By decoding the prediction residual data of the residual block from the video data stream, A decoder configured for decoding video from a video data stream by block-based predictive decoding and transform-based residual decoding.

[0175] 49. A decoder as described in embodiment 48, wherein the digital signature is transmitted within a supplemental enhancement information message of the video data stream. 50. Checks on the authenticity of the video data stream decrypting the digital signature to obtain a check value; 50. A decoder as described in embodiment 48 or 49, comprising checking whether the hash value matches the check value. 51. Applying a predetermined portion of a video data stream, or data derived therefrom, to a hash function to obtain a hash value, reconstructing the video with respect to a predetermined portion to obtain a reconstructed portion of the video; 51. A decoder according to any one of embodiments 48 to 50, comprising: subjecting the reconstructed portion to a hash function.

[0176] 52. configured to decode a digital signature from a supplemental enhancement information message of a video data stream; A decoder according to any one of embodiments 48 to 51. 53. Checks on the authenticity of the video data stream A decoder as described in any of embodiments 48 to 52, comprising locating a predetermined portion within a video data stream by determining, through the use of one or more SEI messages interspersed within the video data stream, that the predetermined portion is a section of the video data stream that spans or extends between one or more SEI messages. 54. Configured to decrypt a digital signature from one of one or more SEI messages of a video data stream; A decoder as described in embodiment 53.

[0177] 55. Checks on the authenticity of the video data stream A decoder as described in any of embodiments 48 to 52, comprising locating a predetermined portion within a video data stream by using prefix SEI messages and suffix SEI messages interspersed within the video data stream to determine that the predetermined portion is a section of the video data stream that spans or is located between the prefix SEI messages and the suffix SEI messages. 56. The check on the authenticity of the video data stream includes locating a predetermined portion 13 in the video data stream by using prefix SEI messages 25 and suffix SEI messages 27 interspersed within the video data stream, determining that the predetermined portion is located between the prefix SEI message and the suffix SEI message; A decoder according to any one of embodiments 48 to 52. 57. The decoder of embodiment 55 or 56 configured to decode a digital signature from a suffix SEI message.

[0178] 58. Configured to locate a predetermined portion within a video data stream by using a first SEI message and a second SEI message interspersed within the video data stream to determine the predetermined portion to be a section of the video data stream that spans or is located between the first SEI message and the second SEI message, or a section of the video data stream that spans between a point in the data stream located downstream of the first SEI message and the second SEI message; A decoder according to embodiment 54 or 55.

[0179] 59. A decoder as described in embodiment 54 or 55, configured to locate a predetermined portion 13 within a video data stream by using a first SEI message 25 and a second SEI message 27 interspersed within the video data stream to determine that the predetermined portion is located between the first SEI message and the second SEI message, or between a point in the data stream located downstream of the first SEI message and the second SEI message.

[0180] 60. A decoder as described in embodiment 58 or 59, wherein the point in the data stream located downstream of the second SEI message is determined based on the length of the section or as being located at the end of the video coding layer portion having the access unit of the video data stream in which the second SEI message is contained. 61. A decoder according to any one of embodiments 58 to 60, configured to decrypt the digital signature from the second SEI message.

[0181] 62. A method for deriving a summary SEI message from a video data stream, the summary SEI message indicating one or more substreams of the video data stream, the method being capable of checking the reliability of the video data stream based on one or more portions within each individual substream; A check on the reliability of the video data stream is performed for a given substream of the subset, locating one or more portions within the video data stream by using one or more first SEI messages and second SEI messages interspersed within the video data stream to determine that the predetermined portion is a section of the video data stream formed by concatenating a subsection of the video data stream that follows each of the one or more first SEI messages and extends to a video coding layer end of the access unit that contains the respective first SEI message and a subsection that precedes the second SEI message and extends to a video coding layer start of the access unit that contains the second SEI message or that follows the second SEI message and extends to a video coding layer end of the access unit that contains the second SEI message; A decoder as described in any of embodiments 48 to 55, comprising performing a check on the video data stream regarding reliability for a subset of one or more substreams of the one or more substreams.

[0182] 63. A method for deriving a summary SEI message from a video data stream that indicates one or more substreams of the video data stream, the summary SEI message being capable of checking the reliability of the video data stream based on one or more portions within each individual substream; A check on the reliability of the video data stream is performed for a given substream of the subset, locating a portion of the given substream of the video data stream by using one or more first SEI messages interspersed within the video data stream to determine that the portion of the given substream is a section of the video data stream formed by concatenating subsections of the video data stream that follow each of the one or more first SEI messages and extend up to a video coding layer end of the access unit in which the respective first SEI message is contained; A decoder as described in any of embodiments 48 to 55, comprising performing a check on the video data stream regarding reliability for a subset of one or more substreams of the one or more substreams.

[0183] 64. A method for deriving a summary SEI message from a video data stream that indicates one or more substreams of the video data stream, the summary SEI message being capable of checking the reliability of the video data stream based on one or more portions within each individual substream; The check on the reliability of the video data stream includes, for a picture unit of the video data stream, checking whether the video data stream includes a sub-stream selection SEI message for the picture unit; if the video data stream does not include a sub-stream selection SEI message for the picture unit, assigning video coded layer payload packets of the picture unit to a first sub-stream of the one or more sub-streams; If the video data stream includes a substream selection SEI message for the picture unit, by assigning video coded layer payload packets of the picture unit to one or more substreams, the substreams indicated by the substream selection SEI message; determining a respective portion of the video data stream for one or more substreams; A decoder as described in any of embodiments 48 to 55, comprising performing a check on the video data stream regarding reliability for a subset of one or more substreams of the one or more substreams.

[0184] 65. The method of claim 1, wherein the check for reliability of the video data stream includes checking the video data stream for reliability with respect to a subset of the one or more substreams; A decoder as described in any of embodiments 62 to 64, further comprising applying the determined portions for one or more substreams of a subset of one or more substreams to a hash function to derive respective hash values.

[0185] 66. A decoder described in any of embodiments 62 to 65, further configured to determine the portion of each substream of a subset of one or more substreams by using a first SEI message 25 and a second SEI message 27 interspersed within the video data stream to determine that the portion is located between the first SEI message and the second SEI message, or between a point in the data stream located downstream of the first SEI message and the second SEI message. 67. A decoder as described in any of embodiments 62 to 66, further configured to determine that each portion of a substream of a subset of one or more substreams terminates at or before one end of the encoded video sequence.

[0186] 68. One or more substreams have a defined order therein, and the apparatus is configured to determine that a given portion is part of a given substream of a subset of the one or more substreams; Checks on the authenticity of the video data stream whether the hash value and a further hash value obtained by applying a hash function to the previous portion of the predetermined portion, or further data derived from it, match the digital signature; or by checking whether a combined hash value derived by hashing the predetermined portion and a further hash value obtained by applying a hash function to a previous portion of the video data stream, or further data derived therefrom, matches the digital signature; sequentially performing a check of the video data stream for authenticity for each portion of the video data stream derived for one or more substreams, 67. A decoder as described in any one of embodiments 63 to 66, comprising the previous part being before the given part in a defined sequence order between the parts.

[0187] 69. Checks on the authenticity of the video data stream and whether the hash value and a further hash value obtained by applying a hash function to a previous portion of the video data stream, or further data derived therefrom, match the digital signature; or by checking whether a combined hash value derived by hashing the predetermined portion and a further hash value obtained by applying a hash function to a previous portion of the video data stream, or further data derived therefrom, matches the digital signature; sequentially performing a check of the video data stream for authenticity with respect to a plurality of portions of the video data stream; A decoder according to any one of embodiments 48 to 67.

[0188] 70. Checks on the authenticity of the video data stream combining the hash value with a further hash value to obtain a combined hash value and checking whether the combined hash value matches the digital signature; or combining the predetermined portion and a previous portion of the video data stream, or further data derived therefrom, by applying a hash function to the resulting further hash value to obtain a combined hash value, and checking whether the combined hash value matches the digital signature. 70. A decoder according to embodiment 68 or 69. 71. The decoder of embodiment 70, wherein the combination is a concatenation. 72. Checks on the authenticity of the video data stream checking whether the identifier in the hash value matches the digital signature to further determine whether the video data stream is authentic. A decoder according to any one of embodiments 68 to 71.

[0189] 73. Two different digital signatures are transmitted within the video data stream for a given portion; Checks on the authenticity of the video data stream If the video data stream contains a previous part for a given part, whether the hash value and a further hash value obtained by applying a hash function to an earlier portion of the video data stream, or further data derived therefrom, matches the first of two different digital signatures; or checking whether a combined hash value derived by hashing the predetermined portion and a further hash value obtained by applying a hash function to a previous portion of the video data stream, or further data derived therefrom, matches a first of the two different digital signatures; If the video data stream does not contain any previous parts for a given part, By checking whether the hash value matches the second of two different digital signatures to determine whether the video data stream can be trusted. sequentially performing a check of the video data stream for authenticity with respect to a plurality of portions of the video data stream; A decoder according to any one of embodiments 48 to 72.

[0190] 74. Checks on the authenticity of the video data stream If the video data stream contains a previous part with respect to the given part, checking whether the hash value and a further hash value obtained by applying a hash function to a previous portion of the video data stream or further data derived therefrom match the digital signature, or whether a still further hash value, which is equal to a further hash value obtained by applying a hash function to a previous portion of the video data stream or further data derived therefrom, transmitted in the video data stream for the given portion, matches the digital signature; and checking whether a combined hash value derived by hashing the predetermined portion on the one hand and a further hash value obtained by applying a hash function to an earlier portion of the video data stream or further data derived therefrom on the other hand matches a first of the two different digital signatures, or whether a combined hash value derived by hashing the hash value and a still further hash value equal to a further hash value obtained by applying a hash function to an earlier portion of the video data stream or further data derived therefrom, which is transmitted in the video data stream for the predetermined portion, matches the digital signature; If the video data stream does not contain any previous parts for a given part, By checking if the hash value matches the digital signature to determine if the video data stream can be trusted. sequentially performing a check of the video data stream for authenticity with respect to a plurality of portions of the video data stream; A decoder according to any one of embodiments 48 to 72.

[0191] 75. Checks on the authenticity of the video data stream If the video data stream does not contain any previous parts for a given part, A decoder as described in embodiment 74, comprising determining whether the video data stream is trustworthy by checking whether the hash value matches the digital signature by checking whether the hash value and a further hash value transmitted within the video data stream for a given portion match the digital signature.

[0192] 76. The predetermined value is equal to the check value obtained by decrypting the digital signature or a predetermined portion of the check value related to the predetermined value; or the digital signature is matched by a predetermined value if the predetermined value is equal to a check value in a further hash field arrived at by a further hash function applied to the predetermined value or to a concatenation of values ​​including the predetermined value; A decoder according to any one of embodiments 48 to 75. 77. The check on the authenticity of the video data stream includes the use of an asymmetric decryption method using a public key; A decoder according to any one of embodiments 48 to 76.

[0193] 78. The decoder of embodiment 77 configured to derive an asymmetric decryption scheme using first information derived from the data stream. 79. A decoder as described in embodiment 78, wherein the first information includes a decryption scheme identifier or a first pointer to a first location from which an asymmetric decryption scheme can be determined, or an identifier of an entity that encoded the video into the video data stream. 80. A decoder according to any one of embodiments 48 to 79, configured to derive a public key using second information derived from the data stream.

[0194] 81. A decoder as described in embodiment 80, wherein the second information includes a second pointer to a second location from which the public key can be obtained, or an identifier of the entity that encoded the video into the video data stream. 82. An apparatus configured to derive a public key by deriving from a video data stream a first syntax element and a second syntax element indicating a pointer to a location from which the public key can be derived, comprising: if the first syntax element has a first state, inferring that the location identifies exactly one public key, deriving exactly one public key from the location; A decoder as described in any of embodiments 77 to 81, configured to infer that, if the first syntax element has a second state, the position indicates a list of keys and to derive from the video data stream a third syntax element indicating a pointer to an entry in the list of keys.

[0195] 83. A decoder according to any one of embodiments 48-82, configured to derive a hash function using third information derived from the data stream. 84. A decoder as described in embodiment 83, wherein the third information includes a hash function identifier or a third pointer to a third location from which the hash function can be determined, or an identifier of the entity that encoded the video into the video data stream. 85. A decoder according to any one of embodiments 48 to 84, wherein the hash value depends on all bits of a predetermined portion of the video data stream. 86. A decoder according to any one of embodiments 48 to 85, wherein the hash value depends on all bits of a given portion of the video data stream within the entropy-coded domain.

[0196] 87. A decoder described in any of embodiments 48 to 86, wherein a predetermined portion of the video data stream spans more than one access unit of the video data stream such that the hash value depends on bits of more than one access unit. 88. Checks on the authenticity of the video data stream checking whether the hash function is correct by checking whether the parameterization or identifier of the hash function matches the digital signature; A decoder according to any one of embodiments 48 to 87. 89. A decoder described in any of embodiments 48 to 88, wherein the predetermined portion consists of one or more video coding layer portions of a video data stream in which motion vectors and intra prediction modes for predictive blocks and transform coefficients for residual blocks are coded. 90. Providing a hash value for checking the authenticity of a video data stream combined with a media stream, together with a further hash value obtained by subjecting a portion of the media stream accompanying the video data stream, or further data derived therefrom, to a hash function or a different hash function; A decoder according to any one of embodiments 48 to 89.

[0197] 91. A decoder may include a first syntax element indicating the total number of non-zero transform coefficients in a transform block representing a residual block, and a trailing ones number indicating the number of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order. one or more second syntax elements that indicate the signs of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; and one or more third syntax elements indicating values ​​of the non-zero transform coefficients, excluding the number of non-zero transform coefficients having an absolute value of one when traversing the coefficients along the scan order; and a fourth syntax element indicating the total number of zero-valued transform coefficient levels in the transform block following the first encountered non-zero transform coefficient in scan order; one or more fifth syntax elements that indicate the position of the non-zero transform coefficients along the scan order by indicating the number of consecutive zero-valued transform coefficients in the scan order between consecutively encountered non-zero transform coefficients; or decoding a significance flag indicating whether a non-zero transform coefficient is located at a current position in a forward scan traversing the transform coefficients of the transform block, and if so and if the current position is not the last in the forward scan, decoding a last significance flag indicating whether the non-zero transform coefficient located at the current position is the last non-zero transform coefficient in the forward scan, thereby decoding a significance map indicating the positions of the non-zero transform coefficients in the transform block representing the residual block; sequentially decoding the values ​​of the non-zero transform coefficients in a reverse scan order by reversing the forward scan order, thereby By using context-adaptive binary arithmetic decoding, By decoding the prediction residual data of the residual block from the video data stream, Block-based predictive decoding and transform-based residual decoding configured to decode video from a video data stream; A decoder according to any one of embodiments 48 to 90.

[0198] 92. Decode coordinates of a location within the transform block representing prediction residual data at which a last non-zero transform coefficient is encountered when traversing the transform coefficients of the transform block along a predetermined scan order; sequentially decoding values ​​of ranked transform coefficients included between the last non-zero transform coefficient and the first scanned transform coefficient along a predetermined scan order; By using context-adaptive binary arithmetic decoding, by selecting a predetermined scan order from among a diagonal scan order, a horizontal scan order, and a vertical scan order according to an intra prediction mode of the intra predicted block using a mapping that maps each of the 33 intra prediction modes to a corresponding diagonal scan order, a horizontal scan order, and a vertical scan order. By decoding the prediction residual data of the intra-predicted block from the video data stream, configured to decode video from a video data stream by block-based predictive decoding and transform-based residual decoding; A decoder according to any one of embodiments 48 to 90.

[0199] 93. By using context-adaptive binary arithmetic decoding of quantization indices of transform coefficients of a transform block representing a residual block and successive inverse quantization of quantization indices in which the value of a current transform coefficient depends on the parity of the quantization index of the previous quantization index. By decoding the prediction residual data of the residual block from the video data stream, A decoder according to any one of embodiments 48 to 90, configured for decoding video from a video data stream by block-based predictive decoding and transform-based residual decoding.

[0200] 94. A device 15 for rendering a video data stream 14 in which video that can be checked for authenticity is encoded, the device comprising: applying a predetermined portion 13 of the video data stream, or data derived therefrom, to a hash function 31 to obtain a hash value 33; calculating a digital signature 43 based on the hash value 33 and digitally signing the hash value 33; configured to insert 77 a digital signature 43 into the video data stream 14, thereby making it possible to determine whether the video data stream is authentic by checking whether the hash value 33 matches the digital signature 43; a first syntax element indicating a total number of non-zero transform coefficients in a transform block representing a residual block, and a trailing ones number indicating the number of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; one or more second syntax elements that indicate the signs of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; and one or more third syntax elements indicating values ​​of the non-zero transform coefficients, excluding the number of non-zero transform coefficients having an absolute value of one when traversing the coefficients along the scan order; and a fourth syntax element indicating the total number of zero-valued transform coefficient levels in the transform block following the first encountered non-zero transform coefficient in scan order; and one or more fifth syntax elements indicating the position of the non-zero transform coefficients along the scan order by indicating the number of consecutive zero-valued transform coefficients in the scan order between consecutively encountered non-zero transform coefficients. By encoding the prediction residual data of the residual block into the video data stream, Block-based predictive coding and transform-based residual coding A device that encodes video into a video data stream by encoding the video into a video data stream. 95. The apparatus of embodiment 94, configured to insert a digital signature into a supplemental enhancement information message of a video data stream. 96. Form a check value based on the hash value; configured to calculate a digital signature based on the hash value by encrypting the check value to obtain the digital signature; 96. A device as described in embodiment 94 or 95.

[0201] 97. Applying a predetermined portion of a video data stream, or data derived therefrom, to a hash function to obtain a hash value, reconstructing the video with respect to a predetermined portion to obtain a reconstructed portion of the video; An apparatus described in any of embodiments 94 to 96, comprising: subjecting the reconstructed portion to a hash function. 98. A device encodes video into a video data stream; an encoder configured to encode a digital signature into a video data stream; An apparatus described in any one of embodiments 94 to 97.

[0202] 99. The method is configured to encode a digital signature into a supplemental enhancement information message of a video data stream. The device described in embodiment 98. 100. By use of one or more SEI messages interspersed within the video data stream, locating a predetermined portion within the video data stream by determining the predetermined portion to be a section of the video data stream that spans or extends between one or more SEI messages; 100. A device as described in embodiment 98 or 99. 101. A method for encoding a digital signature into one of one or more SEI messages of a video data stream; An apparatus as described in embodiment 100.

[0203] 102. Using prefix and suffix SEI messages interspersed within the video data stream, locating a predetermined portion within the video data stream by determining the predetermined portion to be a section of the video data stream that spans or is located between the prefix and suffix SEI messages; 100. A device as described in embodiment 98 or 99.

[0204] 103. Using prefix SEI messages 25 and suffix SEI messages 27 interspersed within the video data stream, determining that the predetermined portion is located between the prefix SEI message and the suffix SEI message, thereby locating the predetermined portion within the video data stream; 100. A device as described in embodiment 98 or 99. 104. The apparatus of embodiment 102 or 103 configured to encode a digital signature into a suffix SEI message.

[0205] 105. Using a first SEI message and a second SEI message interspersed within the video data stream, locating the predetermined portion within the video data stream by determining the predetermined portion to be a section of the video data stream that spans or is located between the first SEI message and the second SEI message, or a section of the video data stream that spans between the first SEI message and a point within the data stream that is located downstream of the second SEI message; 100. A device as described in embodiment 98 or 99.

[0206] 106. Using a first SEI message 25 and a second SEI message 27 interspersed within the video data stream, locating a predetermined portion within the video data stream by determining that the predetermined portion is located between the first SEI message and the second SEI message, or between the first SEI message and a point within the data stream located downstream of the second SEI message; 100. An apparatus as described in embodiment 98 or 99. 107. An apparatus as described in embodiment 106, which determines a point in the data stream located downstream of the second SEI message based on the length of the section or as being located at the end of a video coding layer portion having an access unit of the video data stream in which the second SEI message is contained. 108. The apparatus of embodiment 106 or 107 configured for encoding a digital signature into the second SEI message.

[0207] 109. Inserting into the video data stream a summary SEI message indicating one or more substreams of the video data stream, for each of which the video data stream can be checked for reliability based on one or more portions within an individual substream; For a given substream of the subset, locating a portion of a given substream by using one or more first and second SEI messages interspersed within the video data stream to determine that the portion of the given substream is a section of the video data stream formed by concatenating a subsection of the video data stream that follows each of the one or more first SEI messages and extends to a video coding layer end of the access unit that contains the respective first SEI message and a subsection that precedes the second SEI message and extends to a video coding layer start of the access unit that contains the second SEI message or that follows the second SEI message and extends to a video coding layer end of the access unit that contains the second SEI message; inserting the digital signature into the second SEI message; 100. A device as described in embodiment 98 or 99.

[0208] 110. Inserting into the video data stream a summary SEI message indicating one or more substreams of the video data stream, for each of which the video data stream can be checked for reliability based on one or more portions within an individual substream; For a given substream of the subset, locating the portion of the given substream by use of one or more first SEI messages interspersed within the video data stream, by determining the portion of the given substream to be a section of the video data stream formed by concatenating subsections of the video data stream that follow each of the one or more first SEI messages and extend up to the video coding layer end of the access unit in which the respective first SEI message is contained; 100. An apparatus as described in embodiment 98 or 99.

[0209] 111. Checks on the authenticity of the video data stream are and further computing and digitally signing a digital signature based on the hash value and a further hash value obtained by subjecting a previous portion of the video data stream, or further data derived therefrom, to a hash function; or An apparatus as described in any of embodiments 94 to 110, wherein the method is performed sequentially on multiple portions of a video data stream by calculating a digital signature based on a combined hash value obtained by hashing a predetermined portion and a further hash value obtained by applying a hash function to a previous portion of the video data stream or further data derived from it, and digitally signing with the combined hash value.

[0210] 112. Combining the hash value with a further hash value to obtain a combined hash value, calculating a digital signature, and digitally signing the combined hash value; or configured to combine the predetermined value with a further hash value obtained by applying a hash function to a previous portion of the video data stream, or further data derived therefrom, to obtain a combined hash value, and to calculate a digital signature and digitally sign the combined hash value. An apparatus as described in embodiment 111. 113. The device of embodiment 112, wherein the combination is a linkage. 114. The apparatus of any of embodiments 111-113, configured to calculate a digital signature based on an identifier of the hash function and further digitally sign therewith.

[0211] 115. A further hash value obtained by applying a hash function to the hash value and to a previous portion of the video data stream, or further data derived therefrom; or by computing a first of two different digital signatures based on a combined hash value derived by hashing the predetermined portion and the further hash value, computing a second of the same digital signatures based on the hash values, and digitally signing the combination of the hash value, the further hash value, and the first of the digital signatures; configured to insert two different digital signatures into the video data stream for predetermined portions; This allows checking the video data stream for authenticity. If the video data stream contains a previous part with respect to the given part, checking whether the hash value and the further hash value match a first of two different digital signatures, or whether a combined hash value obtained by applying a hash function to the predetermined portion and a further hash value obtained by applying a hash function to a previous portion of the video data stream, or further data derived therefrom, matches a first of two different digital signatures; If the video data stream does not contain any previous parts for a given part, An apparatus as described in any of embodiments 94 to 114, wherein determining whether a video data stream is trustworthy is made possible by checking whether a hash value matches the second of two different digital signatures.

[0212] 116. configured to calculate a digital signature based on the hash value and a further hash value obtained by applying a hash function to a previous portion of the video data stream, or further data derived therefrom, or a combined hash value derived by hashing the predetermined portion and the further hash value, digitally signing the combination of the hash value and the further hash value, and inserting the digital signature into the video data stream for the predetermined portion, together with a yet further hash value equal to the further hash value; This allows checking the video data stream for authenticity. If the video data stream contains a previous part with respect to the given part, checking whether the hash value and the further hash value match the digital signature or whether the hash value and a still further hash value transmitted in the video data stream for the given portion match the digital signature and the still further hash value is equal to a still further hash value obtained by applying a hash function to a previous portion of the video data stream or further data derived therefrom; checking whether a combined hash value derived by hashing the predetermined portion on the one hand and the further hash value on the other hand matches the first of the two different digital signatures, or whether a combined hash value obtained by applying a hash function to the hash value and a further hash value transmitted in the video data stream for the predetermined portion matches the digital signature and the further hash value is equal to a further hash value obtained by applying the hash value to a previous portion of the video data stream or further data derived therefrom, If the video data stream does not contain any previous parts for a given part, This is done by checking whether the hash value matches the digital signature to determine whether the video data stream is authentic. An apparatus described in any one of embodiments 94 to 114.

[0213] 117. If the video data stream does not contain any previous parts for a given part, determining whether the video data stream is authentic by checking whether the hash value and any further hash values ​​transmitted within the video data stream for a given portion match the digital signature; An apparatus as described in embodiment 116.

[0214] 118. Forming a check value based on the hash value so that the hash value matches a predetermined portion of the check value, and encrypting the check value to obtain a digital signature; or forming a check value based on the hash value by further hashing the predetermined value or a concatenation of values ​​including the predetermined value, and encrypting the check value to obtain a digital signature; An apparatus described in any of embodiments 94 to 117, configured to calculate a digital signature based on a hash value.

[0215] 119. The apparatus of any of embodiments 94-118, configured to calculate a digital signature based on a hash value by using an asymmetric encryption scheme using a private key or a public key and a private key. 120. The apparatus of embodiment 119 configured for inserting first information from which an asymmetric encryption scheme can be derived into a data stream. 121. The device of embodiment 120, wherein the first information includes an encryption scheme identifier or a first pointer to a first location from which the asymmetric encryption scheme can be determined, or an identifier of the device. 122. An apparatus as described in any one of embodiments 94 to 121, configured to insert second information from which a public key can be derived into a video data stream. 123. The device of embodiment 122, wherein the second information includes a second pointer to a second location from which the public key can be obtained or an identifier of the device.

[0216] 124. An apparatus described in any of embodiments 119 to 123, configured to insert a first syntax element and a second syntax element into a video data stream, wherein the second syntax element indicates a pointer to a location from which a public key can be derived, the first syntax element having a first state and a second state, the first state indicating that the location identifies exactly one public key and the second state indicating that the location indicates a list of keys, and when the apparatus sets the first syntax element to the second state, configured to insert into the video data stream a third syntax element indicating a pointer to an entry in the list of keys.

[0217] 125. The apparatus of any one of embodiments 94-124 configured to insert third information from which a hash function can be derived into the data stream. 126. The device of embodiment 125, wherein the third information includes a hash function identifier or a third pointer to a third location from which the hash function can be determined, or an identifier of the device. 127. The apparatus of any one of embodiments 94-126, wherein the hash value depends on all bits of a predetermined portion of the video data stream. 128. An apparatus as described in any of embodiments 94-127, wherein the hash value depends on all bits of a predetermined portion of the video data stream within the entropy-coded domain.

[0218] 129. An apparatus described in any of embodiments 94 to 128, wherein a predetermined portion of the video data stream spans more than one access unit of the data stream such that the hash value depends on bits of more than one access unit. 130. Further calculate a digital signature based on the parameterization of the hash function or the identifier; An apparatus described in any of embodiments 94 to 129, thereby digitally signing. 131. An apparatus described in any of embodiments 94 to 130, wherein the predetermined portion consists of one or more video coding layer portions of a video data stream in which motion vectors and intra prediction modes for predictive blocks and transform coefficients for residual blocks are coded.

[0219] 132. A first syntax element indicating the total number of non-zero transform coefficients in a transform block representing a residual block, and a trailing ones number indicating the number of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; one or more second syntax elements that indicate the signs of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; and one or more third syntax elements indicating values ​​of the non-zero transform coefficients, excluding the number of non-zero transform coefficients having an absolute value of one when traversing the coefficients along the scan order; and a fourth syntax element indicating the total number of zero-valued transform coefficient levels in the transform block following the first encountered non-zero transform coefficient in scan order; one or more fifth syntax elements that indicate the position of the non-zero transform coefficients along the scan order by indicating the number of consecutive zero-valued transform coefficients in the scan order between consecutively encountered non-zero transform coefficients; or encoding a significance map indicating the locations of non-zero transform coefficients in a transform block representing a residual block by encoding a significance flag indicating whether a non-zero transform coefficient is located at a current position in a forward scan traversing the transform coefficients of the transform block, and if so and if the current position is not the last in the forward scan, encoding a last significance flag indicating whether the non-zero transform coefficient located at the current position is the last non-zero transform coefficient in the forward scan; sequentially encoding the values ​​of the non-zero transform coefficients in a reverse scan order by reversing the forward scan order; By using context-adaptive binary arithmetic coding, By encoding the prediction residual data of the residual block into the video data stream, Block-based predictive coding and transform-based residual coding An apparatus described in any of embodiments 94 to 131, which is an encoder configured to encode video into a video data stream.

[0220] 133. Encoding coordinates of a location within the transform block representing prediction residual data at which a last non-zero transform coefficient is encountered when traversing the transform coefficients of the transform block along a predetermined scan order; sequentially encoding values ​​of ranked transform coefficients included between the last non-zero transform coefficient and the first scanned transform coefficient along a predetermined scan order; selecting a predetermined scan order from among a diagonal scan order, a horizontal scan order, and a vertical scan order according to an intra prediction mode of the intra predicted block, using a mapping that maps each of the 33 intra prediction modes to a corresponding diagonal scan order, a horizontal scan order, and a vertical scan order; By using context-adaptive binary arithmetic coding, By encoding the prediction residual data of intra-predicted blocks into the video data stream, block-based prediction coding and transform-based residual coding An apparatus described in any of embodiments 94 to 132, which is an encoder configured to encode video into a video data stream.

[0221] 134. By using context-adaptive binary arithmetic coding of quantization indices of transform coefficients of a transform block representing a residual block and sequential quantization of the transform coefficients such that a quantizer quantizing a current transform coefficient obtains a quantization index that depends on the parity of the quantization index of the previous quantization index; By encoding the prediction residual data of the residual block into the video data stream, An apparatus described in any of embodiments 94 to 131, which is an encoder configured to encode video into a video data stream by block-based predictive coding and transform-based residual coding.

[0222] 135. A method (160) for checking the authenticity of a video data stream (14) in which video is encoded, comprising: The method comprises: applying a hash function 31 to a predetermined portion of the video data stream, or data derived therefrom, to obtain a hash value 33 (131); and deriving a digital signature 43 from the video data stream (161); and checking whether the hash value 33 matches the digital signature 43 to determine (141) whether the video data stream is authentic; a first syntax element indicating a total number of non-zero transform coefficients in a transform block representing a residual block, and a trailing ones number indicating the number of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; one or more second syntax elements that indicate the signs of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; and one or more third syntax elements indicating values ​​of the non-zero transform coefficients, excluding the number of non-zero transform coefficients having an absolute value of one when traversing the coefficients along the scan order; and a fourth syntax element indicating the total number of zero-valued transform coefficient levels in the transform block following the first encountered non-zero transform coefficient in scan order; and one or more fifth syntax elements indicating the position of the non-zero transform coefficients along the scan order by indicating the number of consecutive zero-valued transform coefficients in the scan order between consecutively encountered non-zero transform coefficients. By encoding the prediction residual data of the residual block into the video data stream, Block-based predictive coding and transform-based residual coding A method for encoding video into a video data stream by encoding the video into a video data stream.

[0223] 136. A method (200) for decoding video from a video data stream (14), the method comprising: Decrypting (163) the digital signature 43 from the video data stream; applying a hash function 31 to a predetermined portion 13 of the video data stream, or data 62 derived therefrom, to obtain a hash value 33 (131); By checking if the hash value matches the digital signature to determine if the video data stream is trustworthy 141 and subjecting the digital signature to a check on the authenticity of the video data stream; The method is a first syntax element indicating a total number of non-zero transform coefficients in a transform block representing a residual block, and a trailing ones number indicating the number of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; one or more second syntax elements that indicate the signs of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; and one or more third syntax elements indicating values ​​of the non-zero transform coefficients, excluding the number of non-zero transform coefficients having an absolute value of one when traversing the coefficients along the scan order; and a fourth syntax element indicating the total number of zero-valued transform coefficient levels in the transform block following the first encountered non-zero transform coefficient in scan order; and one or more fifth syntax elements indicating the position of the non-zero transform coefficients along the scan order by indicating the number of consecutive zero-valued transform coefficients in the scan order between consecutively encountered non-zero transform coefficients. By decoding the prediction residual data of the residual block from the video data stream, A method comprising decoding video from a video data stream by block-based predictive decoding and transform-based residual decoding.

[0224] 137. A method 15 for rendering a video data stream 14 in which video that can be checked for authenticity is encoded, comprising: applying a hash function 31 to a predetermined portion 13 of the video data stream, or data derived therefrom, to obtain a hash value 33 (131); Calculating a digital signature 43 based on the hash value 33 and digitally signing 171 the hash value 33; Inserting a digital signature 43 into the video data stream 14, thereby making it possible to determine whether the video data stream is authentic by checking whether the hash value 33 matches the digital signature 43 (177); a first syntax element indicating a total number of non-zero transform coefficients in a transform block representing a residual block, and a trailing ones number indicating the number of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; one or more second syntax elements that indicate the signs of non-zero transform coefficients that have an absolute value of one when traversing the coefficients along the scan order; and one or more third syntax elements indicating values ​​of the non-zero transform coefficients, excluding the number of non-zero transform coefficients having an absolute value of one when traversing the coefficients along the scan order; and a fourth syntax element indicating the total number of zero-valued transform coefficient levels in the transform block following the first encountered non-zero transform coefficient in scan order; and one or more fifth syntax elements indicating the position of the non-zero transform coefficients along the scan order by indicating the number of consecutive zero-valued transform coefficients in the scan order between consecutively encountered non-zero transform coefficients. By encoding the prediction residual data of the residual block into the video data stream, Block-based predictive coding and transform-based residual coding A method for encoding video into a video data stream by encoding the video into a video data stream. 138. A video data stream generated by the method of embodiment 137.

[0225] Alternative Implementations While some aspects are described as features in the context of an apparatus, it will be apparent that such description may also be considered a description of corresponding features of a method. Although some aspects are described as features in the context of an apparatus, it will be apparent that such description may also be considered a description of corresponding features in terms of the functionality of the apparatus. In particular, block diagrams illustrating apparatuses may also be considered illustrations of individual methods including the steps described by the blocks in the block diagram. Some or all of the method steps may be performed by (or using) a hardware apparatus, such as, for example, a microprocessor, a programmable computer, or an electronic circuit, and in some embodiments, one or more of the most important method steps may be performed by such an apparatus.

[0226] The coded image signal of the present invention can be stored on a digital storage medium or can be transmitted over a transmission medium such as a wireless transmission medium or a wired transmission medium such as the Internet. In other words, a further embodiment provides a video bitstream product comprising a video bitstream according to any of the embodiments described herein, e.g., a digital storage medium having stored thereon a video bitstream.

[0227] Depending on specific implementation requirements, embodiments of the present invention can be implemented in hardware or software, or at least partly in hardware, or at least partly in software. Implementation can be performed using a digital storage medium, such as a floppy disk, DVD, Blu-ray, CD, ROM, PROM, EPROM, EEPROM, or flash memory, on which electronically readable control signals are stored, which cooperate (or can cooperate) with a programmable computer system to perform the respective methods. Thus, the digital storage medium may be computer-readable.

[0228] Some embodiments according to the present invention include a data carrier having electronically readable control signals that can cooperate with a programmable computer system to perform one of the methods described herein.

[0229] Generally, embodiments of the present invention can be implemented as a computer program product having program code that operates to perform one of the methods when the computer program product is run on a computer. The program code can, for example, be stored on a machine-readable carrier. Other embodiments comprise the computer program for performing one of the methods described herein, stored on a machine readable carrier.

[0230] In other words, therefore, an embodiment of the inventive methods is a computer program having a program code for performing one of the methods described herein, when the computer program runs on a computer. A further embodiment of the inventive method is therefore a data carrier (or digital storage medium, or computer readable medium) having recorded thereon a computer program for performing one of the methods described herein. The data carrier, digital storage medium, or recording medium is typically tangible and / or non-transitory.

[0231] A further embodiment of the inventive method is, therefore, a data stream or a sequence of signals representing the computer program for performing one of the methods described herein, The data stream or the sequence of signals can for example be arranged to be transferred via a data communication connection, for example via the Internet. A further embodiment comprises a processing means, for example a computer, or a programmable logic device, configured to or adapted to perform one of the methods described herein. A further embodiment comprises a computer having installed thereon the computer program for performing one of the methods described herein.

[0232] Further embodiments according to the invention include an apparatus or system configured to transfer (e.g., electronically or optically) a computer program for performing one of the methods described herein to a receiver. The receiver may be, for example, a computer, a mobile device, a memory device, etc. The apparatus or system may, for example, include a file server for transferring the computer program to the receiver.

[0233] In some embodiments, a programmable logic device (e.g., a field programmable gate array) may be used to perform some or all of the functionality of the methods described herein. In some embodiments, a field programmable gate array may cooperate with a microprocessor to perform one of the methods described herein. In general, the methods are preferably performed by any hardware apparatus. The apparatus described herein may be implemented using a hardware apparatus, or using a computer, or using a combination of a hardware apparatus and a computer. The methods described herein may be performed using a hardware apparatus, or using a computer, or using a combination of a hardware apparatus and a computer.

[0234] In the foregoing Detailed Description, it will be appreciated that various features are grouped together in examples for the purpose of streamlining the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed examples require more features than are expressly recited in each claim. Rather, as the following claims reflect, subject matter may lie in fewer than all features of a single disclosed example. Accordingly, the following claims are incorporated into this Detailed Description, with each claim standing on its own as a separate example. While each claim may stand on its own as a separate example, a dependent claim may refer to a specific combination with one or more other claims in the claim, and it should be noted that other examples may also include a combination of a dependent claim with the subject matter of other dependent claims, or a combination of each feature with other dependent or independent claims. Such combinations are suggested herein unless it is expressly stated that a specific combination is not intended. Furthermore, it is intended to include features of any other independent claim, even if that claim is not directly dependent on that independent claim.

[0235] The above-described embodiments are merely illustrative of the principles of the present disclosure. It is understood that modifications and variations of the arrangements and details described herein will be apparent to those skilled in the art. It is therefore intended to be limited only by the scope of the appended claims and not by the specific details presented as illustrations and description of the embodiments herein.< / cabac>

Claims

1. An apparatus (16) for checking a video data stream (14) in which video is encoded for authenticity, said apparatus comprising: applying a predetermined portion (13) of the video data stream, or data derived therefrom, to a hash function (31) to obtain a hash value (33); deriving a digital signature (43) from said video data stream; configured to check whether the hash value (33) matches the digital signature (43) to determine (41) whether the video data stream is authentic; encoding a significance map indicating the locations of non-zero transform coefficients in a transform block representing the residual block by encoding a significance flag indicating whether a non-zero transform coefficient is located at a current position in a forward scan traversing the transform coefficients of the transform block, and if so and if the current position is not the last in the forward scan, encoding a last significance flag indicating whether the non-zero transform coefficient located at the current position is the last non-zero transform coefficient in the forward scan; and sequentially encoding the values ​​of the non-zero transform coefficients in a reverse scan order by reversing the forward scan order, thereby By using context-adaptive binary arithmetic coding, encoding the prediction residual data of the residual block into the video data stream; encoding said video into said video data stream by block-based predictive coding and transform-based residual coding; An apparatus for encoding the video into the video data stream.

2. The apparatus of claim 1 , wherein the digital signature is transmitted within a supplemental enhancement information message of the video data stream.

3. checking (41) whether the hash value matches the digital signature to determine whether the video data stream is authentic; decrypting (45) the digital signature to obtain a check value (47); 3. The device of claim 1, configured to check (49) whether the hash value (33) matches the check value (47).

4. subjecting the predetermined portion (22) of the video data stream, or data derived therefrom, to the hash function to obtain the hash value; reconstructing the video with respect to the predetermined portion to obtain a reconstructed portion of the video; An apparatus according to any preceding claim, configured to subject the reconstructed portion to the hash function.

5. The device, decoding the video from the video data stream; The apparatus of any of claims 1 to 4, being a decoder (20) configured for decrypting said digital signature from said video data stream.

6. configured to decrypt the digital signature from a supplemental enhancement information message of the video data stream.

6. The apparatus of claim 5.

7. configured to locate said predetermined portion within said video data stream by using one or more SEI messages (21, 25, 27) interspersed within the data stream to determine said predetermined portion to be a section of said video data stream that spans between or extends from said one or more SEI messages.

7. Apparatus according to claim 5 or 6.

8. configured to decode the digital signature from one of the one or more SEI messages of the video data stream.

8. The apparatus of claim 7.

9. locating the predetermined portion (13) within the video data stream by using prefix SEI messages (25) and suffix SEI messages (27) interspersed within the video data stream to determine the predetermined portion to be a section of the video data stream that spans or is located between the prefix SEI message and the suffix SEI message; 7. Apparatus according to claim 5 or 6.

10. locating said predetermined portion 13 within said video data stream by using prefix SEI messages (25) and suffix SEI messages (27) interspersed within said video data stream, by determining said predetermined portion to be located between said prefix SEI message and said suffix SEI message; 7. An apparatus according to claim 5 or 6.

11. 11. The apparatus of claim 9 or 10, configured for decrypting the digital signature from the suffix SEI message.

12. 7. The apparatus of claim 5, configured to locate the predetermined portion (13) within the video data stream by using a first SEI message (25) and a second SEI message (27) interspersed within the video data stream to determine the predetermined portion to be a section of the video data stream that spans or is located between the first SEI message and the second SEI message, or a section of the video data stream that spans between the first SEI message and a point in the data stream that is located downstream of the second SEI message.

13. 7. The apparatus of claim 5, configured to locate the predetermined portion (13) within the video data stream by using a first SEI message (25) and a second SEI message (27) interspersed within the video data stream to determine that the predetermined portion is located between the first SEI message and the second SEI message, or between the first SEI message and a point in the data stream located downstream of the second SEI message.

14. determining the point in the data stream located downstream of the second SEI message based on a length of the section or as located at the end of a video coding layer portion of the video data stream having an access unit in which the second SEI message resides; 14. The apparatus of claim 12 or 13, configured for

15. An apparatus according to any of claims 12 to 14, configured for decrypting the digital signature from the second SEI message.

16. deriving from the video data stream a summary SEI message indicating one or more substreams of the video data stream for which it is possible to check the video data stream for reliability based on one or more portions within the individual substreams; For a given substream of the subset, and determining, through the use of one or more first and second SEI messages interspersed within the video data stream, that the portion of the given substream is a section of the video data stream formed by concatenating a subsection of the video data stream that follows each of the one or more first SEI messages and extends to a video coding layer end of an access unit in which the respective first SEI message is contained, and a subsection that precedes the second SEI message and extends to a video coding layer start of the access unit in which the second SEI message is contained, or that follows the second SEI message and extends to a video coding layer end of the access unit in which the second SEI message is contained.

7. Apparatus according to claim 5 or 6.

17. deriving from the video data stream a summary SEI message indicating one or more substreams of the video data stream for which it is possible to check the video data stream for reliability based on one or more portions within the individual substreams; For a given substream of the subset, locating the portion of the given substream of the video data stream by using one or more first SEI messages interspersed within the video data stream to determine the portion of the given substream to be a section of the video data stream formed by concatenating subsections of the video data stream that follow each of the one or more first SEI messages and extend up to a video coding layer end of an access unit in which the respective first SEI message is contained; 7. Apparatus according to claim 5 or 6, configured for performing a check of the video data stream with respect to reliability for a subset of one or more of the one or more sub-streams.

18. deriving from the video data stream a summary SEI message indicating one or more substreams of the video data stream for which it is possible to check the video data stream for reliability based on one or more portions within the individual substreams; For a picture unit of the video data stream, checking whether the video data stream includes a sub-stream selection SEI message for the picture unit; if the video data stream does not include a sub-stream selection SEI message for the picture unit, assigning video coded layer payload packets of the picture unit to a first sub-stream of the one or more sub-streams; if the video data stream includes a substream selection SEI message for the picture unit, by assigning video coded layer payload packets of the picture unit to a substream of the one or more substreams indicated by the substream selection SEI message; configured to perform a check of the video data stream with respect to a subset of one or more substreams of the one or more substreams with respect to authenticity by determining a respective portion of the video data stream for the one or more substreams.

7. Apparatus according to claim 5 or 6.

19. checking the video data stream for reliability with respect to the subset of one or more sub-streams; 19. The apparatus of claim 16, configured to perform by subjecting the determined portion for the one or more sub-streams of the subset of one or more sub-streams to the hash function to derive a respective hash value.

20. 20. The apparatus of claim 16, further configured for determining the respective portions of the sub-streams of the subset of one or more sub-streams by using first and second SEI messages (25) interspersed within a video data stream to determine that the portions are located between the first and second SEI messages or between the first and second SEI messages and a point in the data stream located downstream of the second SEI message.

21. 21. The apparatus of claim 16, further configured for determining that the respective portions of the sub-streams of the subset of one or more sub-streams terminate at or before one end of the encoded video sequence.

22. the one or more substreams have an order defined therein, and the apparatus determines that the predetermined portion is part of a predetermined substream of the subset of one or more substreams; whether the hash value and a further hash value obtained by subjecting a portion preceding the predetermined portion, or further data derived therefrom, to the hash function match the digital signature; or by checking whether a combined hash value derived by hashing the predetermined portion and a further hash value obtained by applying the hash function to a previous portion of the video data stream, or further data derived therefrom, matches the digital signature; configured to sequentially perform checking the video data stream for reliability for each portion of the video data stream derived for the one or more sub-streams, the previous portion being before the given portion in the defined sequence order between the portions; 22. Apparatus according to any one of claims 17 to 21.

23. whether the hash value and a further hash value obtained by subjecting an earlier portion of the video data stream, or further data derived therefrom, to the hash function match the digital signature; or and checking whether a combined hash value derived by hashing the predetermined portion and a further hash value obtained by applying the hash function to a previous portion of the video data stream, or further data derived therefrom, matches the digital signature. configured to sequentially perform checking the video data stream for authenticity for a plurality of portions of the video data stream; 22. Apparatus according to any one of claims 1 to 21.

24. combining the hash value with the further hash value to obtain a combined hash value, and checking whether the combined hash value matches the digital signature; or is configured to apply the predetermined portion and a previous portion of the video data stream, or further data derived therefrom, to the hash function, combine the resulting further hash value to obtain a combined hash value, and check whether the combined hash value matches the digital signature.

24. Apparatus according to claim 22 or 23.

25. 25. The device of claim 24, wherein the combination is a linkage.

26. 26. The apparatus of claim 22, 23, 24 or 25, configured to further check whether the hash function parameters or identifier match the digital signature to determine whether the video data stream can be trusted.

27. Two different digital signatures are transmitted within the video data stream for the predetermined portion, and the device: if the video data stream includes a previous portion relative to the given portion, whether the hash value and a further hash value obtained by subjecting an earlier portion of the video data stream, or further data derived therefrom, to the hash function match a first of the two different digital signatures; or checking whether a combined hash value derived by hashing the predetermined portion and a further hash value obtained by applying the hash function to a previous portion of the video data stream, or further data derived therefrom, matches the first of the two different digital signatures; If the video data stream does not include a previous portion for the given portion, by checking whether the hash value matches a second of the two different digital signatures to determine whether the video data stream is authentic; configured to sequentially perform checking the video data stream for authenticity for a plurality of portions of the video data stream; 27. Apparatus according to any one of claims 1 to 26.

28. The device, if the video data stream includes a previous portion relative to the given portion, checking whether the hash value and a further hash value obtained by applying the hash function to an earlier portion of the video data stream or further data derived therefrom match the digital signature, or whether the hash value and a still further hash value obtained by applying the hash function to an earlier portion of the video data stream or further data derived therefrom, which is transmitted in the video data stream for the predetermined portion, match the digital signature and the still further hash value is equal to a still further hash value obtained by applying the hash function to an earlier portion of the video data stream or further data derived therefrom; checking whether a combined hash value derived by hashing the predetermined portion on the one hand and a further hash value obtained by applying the hash function to an earlier portion of the video data stream or further data derived therefrom on the other hand matches the first of the two different digital signatures, or whether a combined hash value obtained by applying the hash function to said hash value and a further hash value transmitted in the video data stream for the predetermined portion matches the digital signature and said further hash value is equal to a further hash value obtained by applying the hash function to an earlier portion of the video data stream or further data derived therefrom, If the video data stream does not include a previous portion for the given portion, by checking whether the hash value matches the digital signature to determine whether the video data stream is authentic; Apparatus according to any preceding claim, configured for sequentially performing checking of the video data stream for authenticity for a plurality of parts of the video data stream.

29. The device, If the video data stream does not include a previous portion for the given portion, 29. The apparatus of claim 28, configured to check whether the hash value matches the digital signature to determine whether the video data stream can be trusted by checking whether the hash value and the yet further hash value transmitted in the video data stream for the predetermined portion match the digital signature.

30. a predetermined value is equal to a check value obtained by decrypting the digital signature or a predetermined portion of the check value that relates to the predetermined value; or if the predetermined value is equal to the check value in a further hash field arrived at by a further hash function applied to the predetermined value or to a concatenation of values ​​including the predetermined value, the digital signature is matched by the predetermined value; 30. Apparatus according to any one of claims 1 to 29.

31. Apparatus according to any preceding claim, arranged to perform said check by use of an asymmetric decryption scheme using a public key.

32. 32. The apparatus of claim 31 configured to derive the asymmetric decryption scheme using first information derived from the data stream.

33. 33. The apparatus of claim 32, wherein the first information comprises a decryption scheme identifier or a first pointer to a first location from which the asymmetric decryption scheme can be determined, or an identifier of an entity that encoded the video into the video data stream.

34. Apparatus according to any of claims 31 to 33, configured to derive the public key using second information derived from the data stream.

35. 35. The apparatus of claim 34, wherein the second information comprises a second pointer to a second location where the public key can be obtained or an identifier of the entity that encoded the video into the video data stream.

36. configured to derive the public key by deriving a first syntax element and a second syntax element from the video data stream, the second syntax element indicating a pointer to a location from which the public key can be derived, the apparatus comprising: if the first syntax element has a first state, inferring that the location identifies exactly one public key and deriving the exactly one public key from the location; if the first syntax element has the second state, infer that the location indicates a list of keys, derive from the video data stream a third syntax element indicating a pointer to an entry in the list of keys, and derive the public key from the entry in the list of keys pointed to by the pointer.

36. Apparatus according to any one of claims 31 to 35, configured for

37. Apparatus according to any preceding claim, configured to derive the hash function using third information derived from the data stream.

38. 38. The apparatus of claim 37, wherein the third information comprises a hash function identifier or a third pointer to a third location from which the hash function can be determined, or an identifier of the entity that encoded the video into the video data stream.

39. Apparatus according to any preceding claim, wherein the hash value depends on all bits of the predetermined portion of the video data stream.

40. Apparatus according to any preceding claim, wherein the hash value depends on all bits of the predetermined portion of the video data stream in an entropy coded domain.

41. 41. An apparatus according to any preceding claim, wherein the predetermined portion of the video data stream spans more than one access unit of the video data stream such that the hash value depends on bits of the more than one access unit.

42. by checking whether the parameterization or identifier of the hash function matches the digital signature; Apparatus according to any of the preceding claims, configured for further checking authenticity of said video data stream by checking whether said hash function is correct.

43. 43. An apparatus according to any preceding claim, wherein the predetermined portion comprises one or more video coding layer portions of the video data stream in which motion vectors and intra prediction modes for prediction blocks and transform coefficients for residual blocks are coded.

44. 44. An apparatus as described in any one of claims 1 to 43, providing a hash value for subjecting to an authenticity check of the video data stream combined with the media stream, together with a further hash value obtained by subjecting a portion of a media stream accompanying the video data stream, or further data derived therefrom, to the hash function or a different hash function.

45. A decoder (20) for decoding video from a video data stream (14), said decoder comprising: Decrypting (63) the digital signature (43) from the video data stream; applying a predetermined portion (13) of the video data stream, or data derived therefrom (62), to a hash function (31) to obtain a hash value (33); checking whether the hash value matches the digital signature to determine (41) whether the video data stream is authentic; configured to subject the digital signature to a check regarding the authenticity of the video data stream; the decoder decodes a significance flag indicating whether a non-zero transform coefficient is located at a current position in a forward scan traversing transform coefficients of the transform block, and if so and if the current position is not the last in the forward scan, a last significance flag indicating whether the non-zero transform coefficient located at the current position is the last non-zero transform coefficient in the forward scan, thereby decoding a significance map indicating the positions of non-zero transform coefficients in a transform block representing the residual block; and sequentially decoding the values ​​of the non-zero transform coefficients in a reverse scan order by reversing the forward scan order, thereby By using context-adaptive binary arithmetic decoding, by decoding the prediction residual data of the residual block from the video data stream; A decoder configured to decode the video from the video data stream by block-based predictive decoding and transform-based residual decoding.

46. 46. ​​The decoder of claim 45, wherein the digital signature is transmitted within a supplemental enhancement information message of the video data stream.

47. The check on the authenticity of the video data stream comprises: decrypting the digital signature to obtain a check value; and checking whether the hash value matches the check value.

48. subjecting the predetermined portion of the video data stream, or data derived therefrom, to a hash function to obtain the hash value; reconstructing the video with respect to the predetermined portion to obtain a reconstructed portion of the video; and subjecting said reconstructed portion to said hash function.

49. configured to decrypt the digital signature from a supplemental enhancement information message of the video data stream. A decoder according to any one of claims 45 to 48.

50. The check on the authenticity of the video data stream comprises:

50. A decoder as claimed in any one of claims 45 to 49, comprising locating said predetermined portion within said video data stream by use of one or more SEI messages interspersed within the video data stream, determining said predetermined portion to be a section of said video data stream that spans or extends between said one or more SEI messages.

51. configured to decode the digital signature from one of the one or more SEI messages of the video data stream.

51. A decoder according to claim 50.

52. The check on the authenticity of the video data stream comprises:

50. A decoder as claimed in any one of claims 45 to 49, comprising locating said predetermined portion within said video data stream by using prefix and suffix SEI messages interspersed within the video data stream to determine said predetermined portion to be a section of said video data stream that spans or is located between said prefix and suffix SEI messages.

53. the check on the authenticity of the video data stream comprises locating the predetermined portion (13) in the video data stream by using prefix SEI messages (25) and suffix SEI messages (27) interspersed in the video data stream, by determining that the predetermined portion is located between the prefix SEI message and the suffix SEI message, A decoder according to any one of claims 45 to 49.

54. 54. A decoder according to claim 52 or 53, configured for decrypting the digital signature from the suffix SEI message.

55. using a first SEI message and a second SEI message interspersed within the video data stream, defining the predetermined portion as a section of the video data stream spanning or located between the first SEI message and the second SEI message; 53. A decoder as claimed in claim 51 or 52, configured to locate the predetermined portion within the video data stream by determining that the predetermined portion is a section of the video data stream spanning between the first SEI message and a point in the data stream located downstream of the second SEI message.

56. 53. A decoder as claimed in claim 51 or 52, configured to locate the predetermined portion (13) within the video data stream by using a first SEI message (25) and a second SEI message (27) interspersed within the video data stream to determine that the predetermined portion is located between the first SEI message and the second SEI message, or between the first SEI message and a point in the data stream located downstream of the second SEI message.

57. 57. A decoder as claimed in claim 55 or 56, wherein the point in the data stream located downstream of the second SEI message is determined based on the length of the section or as being located at the end of a video coding layer portion of the video data stream comprising an access unit containing the second SEI message.

58. A decoder according to any of claims 55 to 57, configured for decrypting the digital signature from the second SEI message.

59. configured to derive from said video data stream a summary SEI message indicating one or more substreams of said video data stream for which it is possible to check said video data stream for reliability based on one or more portions within said individual substreams; The check on the authenticity of the video data stream comprises, for a given substream of the subset: locating the one or more portions within the video data stream by using one or more first and second SEI messages interspersed within the video data stream to determine that the predetermined portion is a section of the video data stream formed by concatenating a subsection of the video data stream that follows each of the one or more first SEI messages and extends to a video coding layer end of an access unit in which the respective first SEI message is contained, and a subsection that precedes the second SEI message and extends to a video coding layer start of the access unit in which the second SEI message is contained, or that follows the second SEI message and extends to a video coding layer end of the access unit in which the second SEI message is contained; A decoder according to any of claims 45 to 52, comprising performing a check of the video data stream with respect to reliability for a subset of one or more of the one or more sub-streams.

60. configured to derive from said video data stream a summary SEI message indicating one or more substreams of said video data stream for which it is possible to check said video data stream for reliability based on one or more portions within said individual substreams; The check on the authenticity of the video data stream comprises, for a given substream of the subset: locating the portion of the given substream of the video data stream by using one or more first SEI messages interspersed within the video data stream to determine the portion of the given substream to be a section of the video data stream formed by concatenating subsections of the video data stream that follow each of the one or more first SEI messages and extend up to a video coding layer end of an access unit in which the respective first SEI message is contained; A decoder according to any of claims 45 to 52, comprising performing a check of the video data stream with respect to reliability for a subset of one or more of the one or more sub-streams.

61. configured to derive from said video data stream a summary SEI message indicating one or more substreams of said video data stream for which it is possible to check said video data stream for reliability based on one or more portions within said individual substreams; The check on the authenticity of the video data stream comprises: For a picture unit of the video data stream, checking whether the video data stream includes a sub-stream selection SEI message for the picture unit; if the video data stream does not include a sub-stream selection SEI message for the picture unit, assigning video coded layer payload packets of the picture unit to a first sub-stream of the one or more sub-streams; if the video data stream includes a substream selection SEI message for the picture unit, by assigning video coded layer payload packets of the picture unit to a substream of the one or more substreams indicated by the substream selection SEI message; determining respective portions of the video data stream for the one or more sub-streams; performing a check of the video data stream for reliability with respect to a subset of one or more sub-streams of the one or more sub-streams. A decoder according to any one of claims 45 to 52.

62. said checking for authenticity of said video data stream includes checking for authenticity of said video data stream with respect to said subset of one or more sub-streams; 62. A decoder according to any of claims 59 to 61, further comprising subjecting the determined portion for the one or more sub-streams of the subset of one or more sub-streams to the hash function to derive a respective hash value.

63. 63. A decoder according to any of claims 59 to 62, further configured to determine the respective portions of the sub-streams of the subset of one or more sub-streams by use of first and second SEI messages (25) and (27) interspersed within the video data stream, and to determine that the portions are located between the first and second SEI messages or between the first and second SEI messages and a point in the data stream located downstream of the second SEI message.

64. 64. A decoder according to any of claims 59 to 63, further configured for determining that the respective portions of the sub-streams of the subset of one or more sub-streams terminate at or before one end of the encoded video sequence.

65. the one or more sub-streams have a defined order therein, and the decoder is configured to determine that the predetermined portion is part of a predetermined sub-stream of the subset of one or more sub-streams; The check on the authenticity of the video data stream comprises: whether the hash value and a further hash value obtained by subjecting a portion preceding the predetermined portion, or further data derived therefrom, to the hash function match the digital signature; or by checking whether a combined hash value derived by hashing the predetermined portion and a further hash value obtained by applying the hash function to a previous portion of the video data stream, or further data derived therefrom, matches the digital signature; sequentially performing a check of the video data stream for authenticity for each portion of the video data stream derived for the one or more sub-streams, A decoder according to any of claims 60 to 63, wherein said previous portion precedes said given portion in the sequence order defined between said portions.

66. The check on the authenticity of the video data stream comprises: whether the hash value and a further hash value obtained by subjecting an earlier portion of the video data stream, or further data derived therefrom, to the hash function match the digital signature; or by further checking whether a combined hash value derived by hashing the predetermined portion and a further hash value obtained by applying the hash function to a previous portion of the video data stream, or further data derived therefrom, matches the digital signature; sequentially performing a check of the video data stream for authenticity for a plurality of portions of the video data stream; A decoder according to any one of claims 45 to 64.

67. The check on the authenticity of the video data stream comprises: combining the hash value with the further hash value to obtain a combined hash value and checking whether the combined hash value matches the digital signature; or applying the predetermined portion and a previous portion of the video data stream, or further data derived therefrom, to the hash function, and combining the resulting further hash value to obtain a combined hash value, and checking whether the combined hash value matches the digital signature.

67. A decoder according to claim 65 or 66.

68. 68. The decoder of claim 67, wherein the combination is a concatenation.

69. The check on the authenticity of the video data stream comprises: checking whether an identifier of the hash value matches the digital signature to further determine whether the video data stream is authentic. A decoder according to any one of claims 65 to 68.

70. two different digital signatures are transmitted within the video data stream for the predetermined portion; The check on the authenticity of the video data stream comprises: if the video data stream includes a previous portion relative to the given portion, whether the hash value and a further hash value obtained by subjecting an earlier portion of the video data stream, or further data derived therefrom, to the hash function match a first of the two different digital signatures; or checking whether a combined hash value derived by hashing the predetermined portion and a further hash value obtained by applying the hash function to a previous portion of the video data stream, or further data derived therefrom, matches the first of the two different digital signatures; If the video data stream does not include a previous portion for the given portion, by checking whether the hash value matches a second of the two different digital signatures to determine whether the video data stream is authentic; sequentially performing a check of the video data stream for authenticity for a plurality of portions of the video data stream; A decoder according to any one of claims 45 to 69.

71. The check on the authenticity of the video data stream comprises: If the video data stream includes a previous portion with respect to the given portion, checking whether the hash value and a further hash value obtained by applying the hash function to a previous portion of the video data stream, or further data derived therefrom, match the digital signature, or whether the hash value and the yet further hash value transmitted in the video data stream for the given portion match the digital signature and the yet further hash value is equal to a further hash value obtained by applying the hash function to a previous portion of the video data stream, or further data derived therefrom; and checking whether a combined hash value derived by hashing the predetermined portion on the one hand and a further hash value obtained by applying the hash function to an earlier portion of the video data stream or further data derived therefrom on the other hand matches the first of the two different digital signatures, or whether said hash value and said yet further hash value transmitted in the video data stream for the predetermined portion match said digital signature and said yet further hash value is equal to a further hash value obtained by applying the hash function to an earlier portion of the video data stream or further data derived therefrom, If the video data stream does not include a previous portion with respect to the given portion, Checking whether the hash value matches the digital signature; determining whether the video data stream is reliable; A decoder as claimed in any one of claims 45 to 69, comprising sequentially performing checking the video data stream for authenticity for a plurality of parts of the video data stream.

72. The check on the authenticity of the video data stream comprises: If the video data stream does not include a previous portion for the given portion, 72. The decoder of claim 71, comprising determining whether the video data stream can be trusted by checking whether the hash value matches the digital signature and checking whether the hash value and the yet further hash value transmitted within the video data stream for the predetermined portion match the digital signature.

73. a predetermined value is equal to a check value obtained by decrypting the digital signature or a predetermined portion of the check value that relates to the predetermined value; or if the predetermined value is equal to the check value in a further hash field reached by a further hash function applied to the predetermined value or to a concatenation of values ​​including the predetermined value, the digital signature is matched by the predetermined value; A decoder according to any one of claims 45 to 72.

74. said check on the authenticity of said video data stream comprises the use of an asymmetric decryption scheme using a public key; A decoder according to any one of claims 45 to 73.

75. 75. A decoder according to claim 74 configured to derive the asymmetric decryption scheme using first information derived from the data stream.

76. 76. The decoder of claim 75, wherein the first information comprises a decryption scheme identifier or a first pointer to a first location from which the asymmetric decryption scheme can be determined, or an identifier of the entity that encoded the video into the video data stream.

77. A decoder according to any of claims 45 to 76, configured to derive the public key using second information derived from the data stream.

78. 78. The decoder of claim 77, wherein the second information comprises a second pointer to a second location where the public key can be obtained, or an identifier of the entity that encoded the video into the video data stream.

79. configured to derive the public key by deriving a first syntax element and a second syntax element from the video data stream, the second syntax element indicating a pointer to a location from which the public key can be derived, and the decoder: if the first syntax element has a first state, inferring that the location identifies exactly one public key and deriving the exactly one public key from the location; A decoder as claimed in any one of claims 74 to 78, configured to infer that the location indicates a list of keys if the first syntax element has the second state, and to derive from the video data stream a third syntax element indicating a pointer to an entry in the list of keys.

80. A decoder as claimed in any one of claims 45 to 79, configured to derive the hash function using third information derived from the data stream.

81. 81. The decoder of claim 80, wherein the third information comprises a hash function identifier or a third pointer to a third location from which the hash function can be determined, or an identifier of the entity that encoded the video into the video data stream.

82. A decoder according to any one of claims 45 to 81, wherein the hash value depends on all bits of the predetermined portion of the video data stream.

83. A decoder according to any of claims 45 to 82, wherein the hash value depends on all bits of the predetermined portion of the video data stream in an entropy coded domain.

84. A decoder as claimed in any one of claims 45 to 83, wherein the predetermined portion of the video data stream spans more than one access unit of the video data stream such that the hash value depends on bits of the more than one access unit.

85. The check on the authenticity of the video data stream comprises: checking whether the hash function is correct by checking whether the parameterization or identifier of the hash function matches the digital signature. A decoder according to any one of claims 45 to 84.

86. A decoder as claimed in any one of claims 45 to 85, wherein the predetermined portion consists of one or more video coding layer portions of the video data stream in which motion vectors and intra prediction modes for prediction blocks and transform coefficients for residual blocks are coded.

87. providing a further hash value obtained by subjecting a portion of a media stream accompanying the video data stream, or further data derived therefrom, to the hash function or a different hash function, together with the further hash value, for subjecting the video data stream combined with the media stream to an authenticity check; A decoder according to any one of claims 45 to 86.

88. An apparatus (15) for rendering a video data stream (14) in which a video that can be checked for authenticity is encoded, said apparatus comprising: applying a predetermined portion (13) of the video data stream, or data derived therefrom, to a hash function (31) to obtain a hash value (33); calculating a digital signature (43) based on said hash value (33) and digitally signing said hash value (33); configured to insert (77) the digital signature (43) into the video data stream (14), thereby making it possible to determine whether the video data stream is authentic by checking whether the hash value (33) matches the digital signature (43); encoding a significance map indicating the locations of non-zero transform coefficients in a transform block representing the residual block by encoding a significance flag indicating whether a non-zero transform coefficient is located at a current position in a forward scan traversing transform coefficients of the transform block, and if so and if the current position is not the last in the forward scan, encoding a last significance flag indicating whether the non-zero transform coefficient located at the current position is the last non-zero transform coefficient in the forward scan; and sequentially encoding the values ​​of the non-zero transform coefficients in a reverse scan order by reversing the forward scan order, thereby By using context-adaptive binary arithmetic coding, encoding the prediction residual data of the residual block into the video data stream; encoding said video into said video data stream by block-based predictive coding and transform-based residual coding; An apparatus for encoding the video into the video data stream.

89. 90. The apparatus of claim 88, configured for inserting the digital signature into a supplemental enhancement information message of the video data stream.

90. forming a check value based on the hash value; by encrypting the check value to obtain the digital signature; 90. Apparatus according to claim 88 or 89, configured to calculate the digital signature based on the hash value.

91. subjecting the predetermined portion of the video data stream, or data derived therefrom, to the hash function to obtain the hash value; reconstructing the video with respect to the predetermined portion to obtain a reconstructed portion of the video; and subjecting said reconstructed portion to said hash function.

92. The device, encoding said video into said video data stream; Apparatus according to any of claims 88 to 91, being an encoder configured for encoding said digital signature into said video data stream.

93. configured to encode the digital signature into a supplemental enhancement information message of the video data stream.

93. The apparatus of claim 92.

94. locating the predetermined portion within the video data stream by using one or more SEI messages interspersed within the video data stream to determine the predetermined portion to be a section of the video data stream that spans or extends between the one or more SEI messages; 94. Apparatus according to claim 92 or 93.

95. configured to encode the digital signature into one of the one or more SEI messages of the video data stream.

95. The apparatus of claim 94.

96. locating the predetermined portion within the video data stream by using prefix and suffix SEI messages interspersed within the video data stream to determine the predetermined portion to be a section of the video data stream that spans or is located between the prefix and suffix SEI messages; 94. Apparatus according to claim 92 or 93.

97. using prefix SEI messages (25) and suffix SEI messages (27) interspersed within the video data stream, determining that the predetermined portion is located between the prefix SEI message and the suffix SEI message, thereby locating the predetermined portion within the video data stream; 94. Apparatus according to claim 92 or 93.

98. 98. An apparatus according to claim 96 or 97, configured to encode the digital signature into the suffix SEI message.

99. locating the predetermined portion within the video data stream by using a first SEI message and a second SEI message interspersed within the video data stream to determine the predetermined portion to be a section of the video data stream that spans or is located between the first SEI message and the second SEI message, or a section of the video data stream that spans between the first SEI message and a point in the data stream that is located downstream of the second SEI message; 94. Apparatus according to claim 92 or 93.

100. using a first SEI message (25) and a second SEI message (27) interspersed within the video data stream to determine that the predetermined portion is located between the first SEI message and the second SEI message, or between the first SEI message and a point in the data stream located downstream of the second SEI message, thereby locating the predetermined portion within the video data stream; 94. Apparatus according to claim 92 or 93.

101. 101. The apparatus of claim 100, wherein the point in the data stream located downstream of the second SEI message is determined based on a length of the section or as located at an end of a video coding layer portion having an access unit of the video data stream that contains the second SEI message.

102. 102. The apparatus of claim 100 or 101, configured to encode the digital signature into the second SEI message.

103. inserting into the video data stream a summary SEI message indicating one or more substreams of the video data stream for which it is possible to check the video data stream for reliability based on one or more portions within the individual substream; For a given substream of the subset, locating the portion of the given substream by using one or more first and second SEI messages interspersed within the video data stream to determine that the portion of the given substream is a section of the video data stream formed by concatenating a subsection of the video data stream that follows each of the one or more first SEI messages and extends to a video coding layer end of an access unit in which the respective first SEI message is contained, and a subsection that precedes the second SEI message and extends to a video coding layer start of the access unit in which the second SEI message is contained, or that follows the second SEI message and extends to a video coding layer end of the access unit in which the second SEI message is contained; inserting the digital signature into the second SEI message; 94. Apparatus according to claim 92 or 93.

104. inserting into the video data stream a summary SEI message indicating one or more substreams of the video data stream for which it is possible to check the video data stream for reliability based on one or more portions within the individual substream; For a given substream of the subset, locating the portion of the given substream by use of one or more first SEI messages interspersed within the video data stream by determining the portion of the given substream to be a section of the video data stream formed by concatenating subsections of the video data stream that follow each of the one or more first SEI messages up to a video coding layer end of an access unit in which the respective first SEI message is contained; 94. Apparatus according to claim 92 or 93.

105. The check on the authenticity of the video data stream comprises: further by calculating the digital signature based on the hash value and a further hash value obtained by applying the hash function to a previous portion of the video data stream, or further data derived therefrom, and digitally signing using the digital signature, or by calculating the digital signature based on a combined hash value obtained by hashing the predetermined portion and a further hash value obtained by applying the hash function to a previous portion of the video data stream, or further data derived therefrom, and digitally signing using the digital signature; Apparatus according to any of claims 88 to 104 adapted to be performed sequentially on a plurality of portions of the video data stream.

106. combining the hash value with the further hash value to obtain a combined hash value, calculating the digital signature, and digitally signing the combined hash value; or configured to combine the predetermined value with the further hash value obtained by subjecting a previous portion of the video data stream, or further data derived therefrom, to the hash function to obtain a combined hash value, and to calculate the digital signature and digitally sign the combined hash value.

106. The apparatus of claim 105.

107. 107. The device of claim 106, wherein the combination is a linkage.

108. An apparatus according to any of claims 105 to 107, configured to calculate the digital signature based on an identifier of the hash function, and further to digitally sign with the digital signature.

109. a further hash value obtained by subjecting said hash value and a previous portion of said video data stream, or further data derived therefrom, to said hash function; or configured to insert two different digital signatures into the video data stream for the predetermined portion by calculating a first of two different digital signatures based on a combined hash value derived by hashing the predetermined portion and the further hash value, calculating a second of the same digital signatures based on said hash value, and digitally signing the combination of said hash value, said further hash value, and first of the digital signatures, thereby digitally signing said hash value; Thereby, checking the video data stream for authenticity comprises: If the video data stream includes a previous portion with respect to the given portion, whether the hash value and the further hash value match a first of the two different digital signatures; or checking whether a combined hash value obtained by applying the predetermined portion and a further hash value obtained by applying the hash function to an earlier portion of the video data stream, or further data derived therefrom, matches the first of the two different digital signatures; If the video data stream does not include a previous portion with respect to the given portion, 109. An apparatus according to any of claims 88 to 108, wherein said apparatus is enabled by checking whether said hash value matches said second of said two different digital signatures to determine whether said video data stream can be trusted.

110. is configured to calculate the digital signature based on the hash value and a further hash value obtained by applying the hash function to a previous portion of the video data stream, or further data derived therefrom, or a combined hash value derived by hashing the predetermined portion and the further hash value, digitally signing the combination of the hash value and the further hash value, and inserting the digital signature into the video data stream for the predetermined portion, together with a yet further hash value equal to the further hash value; Thereby, checking the video data stream for authenticity comprises: If the video data stream includes a previous portion with respect to the given portion, checking whether the hash value and the further hash value match the digital signature, or whether the hash value and the yet further hash value transmitted in the video data stream for the given portion match the digital signature and the yet further hash value is equal to a further hash value obtained by applying the hash function to a previous portion of the video data stream or further data derived therefrom; checking whether a combined hash value derived by hashing the predetermined portion on the one hand and the further hash value on the other hand matches the first of the two different digital signatures, or whether a combined hash value obtained by applying a hash function to said hash value and said yet further hash value transmitted in the video data stream for said predetermined portion matches said digital signature and said yet further hash value is equal to a further hash value obtained by applying said hash value to a previous portion of the video data stream or further data derived therefrom, If the video data stream does not include a previous portion with respect to the given portion, Checking whether the hash value matches the digital signature; by determining whether the video data stream is reliable; 109. Apparatus according to any one of claims 88 to 108.

111. If the video data stream does not include a previous portion for the given portion, determining whether the video data stream can be trusted by checking whether the hash value and the still further hash value transmitted within the video data stream for the predetermined portion match the digital signature; 111. The apparatus of claim 110.

112. forming a check value based on the hash value such that the hash value matches a predetermined portion of the check value, and encrypting the check value to obtain the digital signature; or forming a check value based on the hash value by further hashing the predetermined value or a concatenation of values ​​including the predetermined value, and encrypting the check value to obtain the digital signature; An apparatus according to any of claims 88 to 111, configured to calculate the digital signature based on the hash value.

113. An apparatus according to any of claims 88 to 112, configured to calculate the digital signature based on the hash value by use of an asymmetric cryptography scheme using a private key or a public and private key.

114. 114. The apparatus of claim 113 configured to insert first information into the data stream from which the asymmetric encryption scheme can be derived.

115. 115. The device of claim 114, wherein the first information comprises an encryption scheme identifier or a first pointer to a first location from which the asymmetric encryption scheme can be determined, or an identifier of the device.

116. Apparatus according to any of claims 88 to 115, configured for inserting second information from which the public key can be derived into the video data stream.

117. 117. The device of claim 116, wherein the second information comprises a second pointer to a second location from which the public key can be obtained or an identifier of the device.

118. 118. An apparatus according to any one of claims 113 to 117, configured for inserting a first syntax element and a second syntax element into a video data stream, the second syntax element indicating a pointer to a location from which the public key can be derived, the first syntax element having a first state and a second state, the first state indicating that the location identifies exactly one public key and the second state indicating that the location indicates a list of keys, and configured to insert into the video data stream a third syntax element indicating a pointer to an entry in the list of keys when the apparatus sets the first syntax element to the second state.

119. Apparatus according to any of claims 88 to 118, configured to insert third information into the data stream from which the hash function can be derived.

120. 120. The device of claim 119, wherein the third information comprises a hash function identifier or a third pointer to a third location from which the hash function can be determined, or an identifier of the device.

121. Apparatus according to any of claims 88 to 120, wherein the hash value depends on all bits of the predetermined portion of the video data stream.

122. Apparatus according to any of claims 88 to 121, wherein the hash value depends on all bits of the predetermined portion of the video data stream in an entropy coded domain.

123. An apparatus as claimed in any one of claims 88 to 122, wherein the predetermined portion of the video data stream spans more than one access unit of the video data stream such that the hash value depends on bits of the more than one access unit.

124. further calculating the digital signature based on a parameterization or an identifier of the hash function; An apparatus according to any one of claims 88 to 123, whereby digitally signing.

125. 125. An apparatus according to any one of claims 88 to 124, wherein the predetermined portion consists of one or more video coding layer portions of the video data stream that are encoded into motion vectors and intra prediction modes for prediction blocks and transform coefficients for residual blocks.

126. A method (160) for checking a video data stream (14) in which video is encoded for authenticity, said method comprising: subjecting (131) a predetermined portion of said video data stream, or data derived therefrom, to a hash function (31) to obtain a hash value (33); deriving (161) a digital signature (43) from said video data stream; and checking (141) whether the hash value (33) matches the digital signature (43) to determine whether the video data stream is authentic; encoding a significance map indicating the locations of non-zero transform coefficients in a transform block representing the residual block by encoding a significance flag indicating whether a non-zero transform coefficient is located at a current position in a forward scan traversing the transform coefficients of the transform block, and if so and if the current position is not the last in the forward scan, encoding a last significance flag indicating whether the non-zero transform coefficient located at the current position is the last non-zero transform coefficient in the forward scan; and sequentially encoding the values ​​of the non-zero transform coefficients in a reverse scan order by reversing the forward scan order, thereby By using context-adaptive binary arithmetic coding, encoding the prediction residual data of the residual block into the video data stream; encoding said video into said video data stream by block-based predictive coding and transform-based residual coding; encoding said video into said video data stream.

127. A method (200) for decoding video from a video data stream (14), the method comprising: Decrypting (163) the digital signature (43) from the video data stream; applying a hash function (31) to a predetermined portion (13) of the video data stream, or data derived therefrom (62), to obtain (131) a hash value (33); by checking whether the hash value matches the digital signature to determine (141) whether the video data stream is authentic; and subjecting the digital signature to a check on authenticity of the video data stream, said method comprising: decoding a significance flag indicating whether a non-zero transform coefficient is located at a current position in a forward scan traversing the transform coefficients of the transform block, and if so and if the current position is not the last in the forward scan, decoding a last significance flag indicating whether the non-zero transform coefficient located at the current position is the last non-zero transform coefficient in the forward scan, thereby decoding a significance map indicating the positions of non-zero transform coefficients in a transform block representing the residual block; and sequentially decoding the values ​​of the non-zero transform coefficients in a reverse scan order by reversing the forward scan order, thereby By using context-adaptive binary arithmetic decoding, by decoding the prediction residual data of the residual block from the video data stream; A method comprising decoding the video from the video data stream by block-based predictive decoding and transform-based residual decoding.

128. A method (15) for rendering a video data stream (14) in which video that can be checked for authenticity is encoded, said method comprising: subjecting (131) a predetermined portion (13) of said video data stream, or data derived therefrom, to a hash function (31) to obtain a hash value (33); calculating a digital signature (43) based on said hash value (33) and digitally signing (171) said hash value (33); and inserting (177) said digital signature (43) into said video data stream (14), thereby making it possible to determine whether said video data stream can be trusted by checking whether said hash value (33) matches said digital signature (43); encoding a significance map indicating the locations of non-zero transform coefficients in a transform block representing the residual block by encoding a significance flag indicating whether a non-zero transform coefficient is located at a current position in a forward scan traversing the transform coefficients of the transform block, and if so and if the current position is not the last in the forward scan, encoding a last significance flag indicating whether the non-zero transform coefficient located at the current position is the last non-zero transform coefficient in the forward scan; and sequentially encoding the values ​​of the non-zero transform coefficients in a reverse scan order by reversing the forward scan order, thereby By using context-adaptive binary arithmetic coding, by encoding the prediction residual data of the residual block into the video data stream by block-based predictive coding and transform-based residual coding; by encoding said video into said video data stream; encoding said video into said video data stream.

129. 129. A video data stream produced by the method of claim 128.

Images