Code stream signature and authentication method

Abstract

The embodiment of the invention provides a signature and authentication method of a code stream, the code stream comprises a group of data units and an authentication identifier of each data unit in the group of data units, and the signature method comprises the following steps: firstly, obtaining authentication data; wherein the authentication data comprises signature data, an authentication identifier of each data unit in one group of data units and abstract data of each data unit in one group of data units, and the signature data is obtained by performing signature according to the abstract data of each data unit in one group of data units; then, the authentication data is added to the code stream. Therefore, each data unit can be independently authenticated at the authentication end, so that other data units can be authenticated under the condition that part of data units are lost (frame loss). Besides, the authentication identifier is used for identifying the data unit, so that the one-to-one correspondence between the data unit and the authentication data is ensured, and the problem that the data unit and the authentication data are not matched due to long signature time is avoided.

Description

[0001] This application is a divisional application. The application number of the original application is 202311614838.5, the original application date is November 28, 2023, and the entire content of the original application is incorporated herein by reference. Technical Field

[0002] The embodiments of this application relate to the field of media, and in particular to a method for signing and authenticating a bitstream. Background Art

[0003] In many audio and video encoding and decoding scenarios (such as surveillance, live broadcast, video-on-demand, etc.), there are certain requirements for the authenticity and integrity of audio and video content; therefore, in order to ensure the security of audio and video content during transmission and prevent the audio and video content from being tampered with during transmission, it is necessary to sign the audio and video content.

[0004] However, the current technology for tree-shaped signing of audio and video content has some defects: for example, if a single Network Abstract Layer (NAL) unit is incorrect, or the order of NAL units changes during transmission, it will cause multiple NAL units participating in authentication to fail. Another example is that each NAL unit or NAL unit sequence cannot be authenticated independently. Another example is that if there are multiple NAL unit sequences that need to be decoded independently, or support frame extraction scenarios, or the base layer and enhancement layer NAL unit sequences in GB / T 25724-2017, multiple independent authentication sequences are required, which will make the authentication very complex and difficult to implement using existing technologies. Another example is that the encoding rate is relatively fast while the signing time is relatively long, which will cause the position of the authentication data in the bitstream to be uncertain; or in the case where the authentication data of the previous frame NAL unit sequence is lost, it is impossible to match the authentication data with the corresponding NAL unit sequence to be authenticated; and so on. Summary of the Invention

[0005] In view of this, this application provides a method for signing and authenticating a bitstream.

[0006] In a first aspect, the embodiments of this application provide a method for signing a bitstream. The bitstream includes a group of data units and an authentication identifier for each data unit in the group of data units. The method includes: First, obtain authentication data; where the authentication data includes: signature data, an authentication identifier for each data unit in the group of data units, and digest data for each data unit in the group of data units, and the signature data is obtained by signing the digest data for each data unit in the group of data units; then, add the authentication data to the bitstream.

[0007] Among them, the authentication identifier of each data unit can be used to uniquely identify a data unit; the authentication identifiers of multiple data units in a group of data units can be used to determine the authentication data used for authenticating a group of data units.

[0008] That is to say, in this application, a digest is independently generated for each data unit, and the digest data of each data unit is transmitted to the authentication end; in this way, the authentication end can independently authenticate each data unit; therefore, even if some data units are lost (frames are dropped), other data units can still be authenticated. In addition, since the data units are identified using authentication identifiers, the one-to-one correspondence between the data units and the authentication data is ensured, avoiding the problem of mismatch between the data units and the authentication data caused by a long signature time.

[0009] For the temporal scalable video coding (SVC) of the Surveillance Video and Audio Coding (SVAC) standard for public security video surveillance, each data unit uses temporal_id to identify its temporal layer. During decoding, some temporal layers or data units may not participate in decoding; in this application, since a digest is independently generated for each data unit, during authentication, for the data units participating in authentication, the corresponding digest data can be found in the authentication data, and the data units not participating in authentication do not affect the authentication of other data units.

[0010] For the spatial SVC coding of the SVAC standard, each data unit uses layer_id to identify its spatial layer. During decoding, some spatial layers or data units may not participate in decoding; in this application, since a digest is independently generated for each data unit, during authentication, for the data units participating in authentication, the corresponding digest data can be found in the authentication data, and the data units not participating in authentication do not affect the authentication of other data units.

[0011] For the video quality SVC coding of the SVAC standard, during decoding, some quality layers or data units may not participate in decoding. In this application, since a digest is independently generated for each data unit, during authentication, for the data units participating in authentication, the corresponding digest data can be found in the authentication data, and the data units not participating in authentication do not affect the authentication of other data units.

[0012] In addition, for SVC coding, only the authentication data of a group of data units needs to be transmitted to support the authentication of sub-bitstreams extracted from the bitstream.

[0013] That is to say, the present application can also effectively solve the problem that the current SVAC coding, time-domain SVC coding, spatial-domain SVC coding, and video quality SVC coding require independent authentication.

[0014] Data unit

[0015] The basic syntax structure of the coded bitstream can be a NAL unit or an access unit.

[0016] NAL unit

[0017] A syntax structure that contains a type indication of the subsequent data and the number of bytes included (located in the NAL header), and the data appears in the form of a Raw Byte Sequence Payload (RBSP), which may also include scattered anti-counterfeiting bytes when necessary.

[0018] Access unit

[0019] A group of NAL units that are correlated with each other according to specified rules and are consecutive in decoding order.

[0020] It should be noted that, from another dimension, the data unit can also include a coded image.

[0021] Coded picture

[0022] The coded representation of a frame of image.

[0023] It should be noted that the present application does not group the data units, but for the convenience of description, the term "a group of data units" is used to describe.

[0024] Exemplarily, a group of data units can include n data units, and these n data units are all data units that need to be authenticated, where n is a positive integer. Correspondingly, the authentication data can include n authentication identifiers and n digest data, and the n authentication identifiers correspond to the n data units one by one, and the n digest data correspond to the n data units one by one. Exemplarily, "a group of data units" can also be described as "n data units".

[0025] Exemplarily, the authentication identifier can also be referred to as an authentication serial number (such as it can be represented by authentication_id).

[0026] Exemplarily, the multiple digest data of a group of data units can form a digest data list; that is to say, the authentication data can include a digest data list.

[0027] Exemplarily, the authentication data can be Auth.

[0028] Exemplarily, the signature data may be signature.

[0029] Exemplarily, the digest data may also be referred to as authentication digest data.

[0030] Exemplarily, the bitstream may be an audio compression bitstream (or referred to as an audio compression bit stream) or a video compression bitstream (or referred to as a video compression bit stream), and the present application does not limit this. The present application takes signing and authenticating a video compression bitstream as an example for illustration.

[0031] Bitstream

[0032] The binary data stream formed by encoding image / audio frames.

[0033] According to the first aspect, the method further includes: calculating, according to a digest algorithm, each data unit in a set of data units to obtain the digest data of each data unit in the set of data units. In this way, the digest data of each data unit can be quickly determined.

[0034] For example, calculating the data unit 1 in a set of data units according to the digest algorithm to obtain the digest data of the data unit 1; calculating the data unit 2 in a set of data units according to the digest algorithm to obtain the digest data of the data unit 2;... and so on.

[0035] Exemplarily, each data unit in a set of data units may be calculated by a hash algorithm (Hash) according to the digest algorithm to obtain the digest data of each data unit in the set of data units.

[0036] It should be understood that the present application does not limit the type of the digest algorithm.

[0037] Exemplarily, the digest data may also be referred to as authentication digest data (such as authentication_hash).

[0038] According to the first aspect, or any one of the above implementation manners of the first aspect, the method further includes: concatenating the digest data of each data unit in a set of data units to determine the digest data of the concatenated digest data; signing the digest data of the concatenated digest data with a private key to obtain signature data. In this way, the signature data can be quickly determined.

[0039] Exemplarily, the connection can be splicing. For example, the digest data of n data units are respectively: H1, H2, H3, H4, H5, ..., Hn; then the concatenated digest data is H1+H2+H3+H4+H5+...+Hn. Perform a hash calculation on the concatenated digest data H1+H2+H3+H4+H5+...+Hn to obtain the digest data Hg of the concatenated digest data.

[0040] It should be understood that the top-level digest data can also be generated, and the private key is used to sign the top-level digest data to obtain the signature data. The present application does not limit the manner of signing according to the digest data of the data units.

[0041] Exemplarily, the private key can be Private Key.

[0042] According to the first aspect, or any one of the implementation manners of the above first aspect, the method further includes: generating authentication data according to the signature data, the authentication identifier of each data unit in a group of data units, and the digest data of each data unit in a group of data units.

[0043] According to the first aspect, or any one of the implementation manners of the above first aspect, adding the authentication data to the bitstream includes: encoding the authentication data and adding the encoded authentication data to the bitstream. In this way, the bitrate overhead can be reduced.

[0044] Exemplarily, the authentication data can be encoded using Base64; then, the encoded authentication data is packed into the NAL unit of the authentication data of the bitstream.

[0045] According to the first aspect, or any one of the implementation manners of the above first aspect, each data unit in a group of data units includes one or more Network Abstraction Layer (NAL) units.

[0046] Exemplarily, when a data unit is a single NAL unit, a group of data units can include multiple NAL units, and the authentication identifier of each NAL unit is different. When a data unit is multiple NAL units, a group of data units includes multiple access units, the authentication identifier of each access unit is different, and the authentication identifiers of the multiple NAL units included in each access unit are the same.

[0047] According to the first aspect, or any one of the implementation manners of the above first aspect, the multiple NAL units in a group of data units are associated with each other according to a specified rule, and the decoding order of the multiple NAL units in a group of data units is consecutive. That is to say, one data unit is one access unit

[0048] According to the first aspect, or any one of the implementation manners of the above first aspect, each data unit in a group of data units includes an encoded image.

[0049] According to the first aspect, or any implementation manner of the above first aspect, each NAL unit includes an authentication identifier of the data unit to which it belongs. In this way, it is convenient for the authentication end to know the one-to-one correspondence between the NAL unit and the authentication identifier.

[0050] Specifically, it may be that the NAL header of each NAL unit includes an authentication identifier of the data unit to which it belongs.

[0051] Exemplarily, compared with the prior art, the NAL unit of the present application newly adds an authentication identifier authentication_id.

[0052] According to the first aspect, or any implementation manner of the above first aspect, the authentication identifier of each data unit in a group of data units in the bitstream is located before the group of data units. In this way, the authentication end can receive the authentication identifier of each data unit in a group of data units before receiving the group of data units, and then ensure that the authentication end marks each data unit in the received group of data units according to the authentication identifier of each data unit in the group of data units, determines the authentication identifier of each data unit, and ensures the correspondence between the data unit and the authentication data.

[0053] According to the first aspect, or any implementation manner of the above first aspect, the bitstream further includes a security parameter set, and the security parameter set includes an authentication identifier of each data unit in a group of data units.

[0054] Exemplarily, the security parameter set is located before the group of data units.

[0055] Exemplarily, compared with the prior art, the security parameter set of the present application newly adds: authentication_id (which can also be referred to as the authentication identifier).

[0056] In a possible manner, the security parameter set in the bitstream is represented in the form of RBSP. Therefore, the bitstream further includes a security parameter set, and the security parameter set includes an authentication identifier of each data unit in a group of data units, which can be written as the bitstream further includes a security parameter set RBSP, and the security parameter set RBSP includes an authentication identifier of each data unit in a group of data units.

[0057] According to the first aspect, or any implementation manner of the above first aspect, the bitstream further includes extended information, and the extended information includes an authentication identifier of each data unit in a group of data units.

[0058] Exemplarily, the extended information is located before the group of data units.

[0059] Exemplarily, the CEI extension information of the present application newly adds: authentication_id (which can also be referred to as the authentication identifier).

[0060] Optionally, hash_type (hash type, indicating the algorithm used for authentication), signature_type (digital signature type, indicating the algorithm for digitally signing the digest data of the image (or data unit)), and authentication_flag (indicating whether the video data (or data unit) after this extended data is authenticated) can also be newly added to the CEI extension information of the present application.

[0061] According to the first aspect, or any one of the above implementation manners of the first aspect, the bitstream further includes a first identifier, and the first identifier indicates the authentication mode adopted by a group of data units.

[0062] For example, the first identifier can be authenticate_mode.

[0063] If authenticate_mode is 0, it indicates the authentication method of independently generating digest data for each data unit;

[0064] If authenticate_mode is 1, it indicates the tree-type digest data authentication method.

[0065] According to the first aspect, or any one of the above implementation manners of the first aspect, the bitstream further includes a security parameter set, and the security parameter set includes the first identifier.

[0066] Exemplarily, compared with the prior art, the security parameter set of the present application newly adds: authenticate_mode (which can be referred to as the first identifier).

[0067] According to the first aspect, or any one of the above implementation manners of the first aspect, the bitstream further includes an NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein, the second identifier indicates the temporal level, and the value of the second identifier is 0.

[0068] Since in the temporal SVC coding scenario of the SVAC standard, the temporal base layer (i.e., the data unit with the second identifier being 0) needs to be parsed, in order to ensure that during the authentication process, the authentication data can be obtained regardless of whether the temporal enhancement layer is parsed; the value of the second identifier in the NAL unit of the authentication data can be set to 0.

[0069] In one possible way, the authentication data in the bitstream is represented in the form of RBSP. Therefore, the bitstream further includes the NAL unit of the authentication data. The NAL unit of the authentication data includes a second identifier, which can be written as the bitstream further includes the authentication unit of the authentication data RBSP, and the NAL unit of the authentication data RBSP includes a second identifier.

[0070] Exemplarily, the second identifier may be temporal_id.

[0071] Exemplarily, compared with the prior art, the authentication data newly adds authentication_id (authentication identifier) and authentication_hash (digest data).

[0072] According to the first aspect, or any implementation manner of the above first aspect, the bitstream further includes the NAL unit of the authentication data. The NAL unit of the authentication data includes a third identifier; wherein, the third identifier indicates the spatial layer or the quality coding layer, and the value of the third identifier is 0.

[0073] Since in the spatial SVC coding or quality SVC coding scenario of the SVAC standard, the spatial base layer / quality coding base layer (i.e., the data unit with the third identifier being 0) needs to be parsed. Therefore, in order to ensure that during the authentication process, whether or not the spatial enhancement layer / quality coding enhancement layer is parsed, the authentication data can be obtained; the value of the third identifier in the NAL unit of the authentication data can be set to 0.

[0074] Exemplarily, the third identifier may be layer_id.

[0075] It should be noted that the authentication data in the first aspect and any implementation manner of the first aspect may further include the public key corresponding to the private key. Exemplarily, the public key is Public Key, and the public key can be used to verify the signature data. It should be understood that the public key corresponding to the above private key can also be transmitted in other ways, such as being built into the authentication end, being transmitted to the authentication end in the authentication certificate, etc., and the present application does not limit this.

[0076] It should be noted that the first aspect and any implementation manner of the first aspect may be executed by the encoder in the signature end, or by the signature module in the signature end, or by the encoder and the authentication module in the signature end in cooperation. The present application does not limit this.

[0077] Second aspect, an embodiment of the present application provides a bitstream, which includes: a set of data units, authentication data, and an authentication identifier for each data unit in the set of data units; wherein, the authentication data includes: signature data, an authentication identifier for each data unit in the set of data units, and digest data for each data unit in the set of data units, and the signature data is obtained by signing the digest data for each data unit in the set of data units.

[0078] According to the second aspect, the authentication identifier for each data unit in the set of data units is located before the set of data units.

[0079] According to the second aspect, or any implementation manner of the above second aspect, the bitstream further includes a safety parameter set, and the safety parameter set includes an authentication identifier for each data unit in the set of data units.

[0080] According to the second aspect, or any implementation manner of the above second aspect, the bitstream further includes extended information, and the extended information includes an authentication identifier for each data unit in the set of data units.

[0081] According to the second aspect, or any implementation manner of the above second aspect, each data unit in the set of data units includes one or more network abstraction layer (NAL) units.

[0082] According to the second aspect, or any implementation manner of the above second aspect, multiple NAL units in the set of data units are associated with each other according to a specified rule, and the decoding order of multiple NAL units in the set of data units is continuous. That is to say, one data unit is one access unit.

[0083] According to the second aspect, or any implementation manner of the above second aspect, each data unit in the set of data units includes an encoded image.

[0084] According to the second aspect, or any implementation manner of the above second aspect, each NAL unit includes an authentication identifier of the data unit to which it belongs.

[0085] According to the second aspect, or any implementation manner of the above second aspect, the bitstream further includes a first identifier, and the first identifier indicates the authentication mode adopted by the set of data units.

[0086] According to the second aspect, or any implementation manner of the above second aspect, the bitstream further includes a safety parameter set, and the safety parameter set includes the first identifier.

[0087] According to the second aspect, or any implementation manner of the above second aspect, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein, the second identifier indicates a time domain level, and the value of the second identifier is 0.

[0088] According to a second aspect, or any implementation manner of the above second aspect, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a third identifier; wherein, the third identifier indicates a spatial layer or a quality coding layer, and the value of the third identifier is 0.

[0089] According to a second aspect, or any implementation manner of the above second aspect, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data further includes a fourth identifier, and the fourth identifier is used to determine the quantity of digest data included in the authentication data.

[0090] Exemplarily, the fourth identifier may be authentication_hash_number_minus1; it is also a new syntax element of the NAL unit of the authentication data of the present application.

[0091] The second aspect and any implementation manner of the second aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the second aspect and any implementation manner of the second aspect, reference may be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, which will not be elaborated here.

[0092] In a third aspect, an embodiment of the present application provides a method for authenticating a bitstream, and the method includes: First, obtain a first authentication identifier of each data unit in a group of data units from the bitstream; then, determine a first digest data of each data unit in the group of data units; after that, obtain authentication data from the bitstream, and the authentication data includes: signature data, a second authentication identifier of each data unit in the group of data units, and a second digest data of each data unit in the group of data units, and the signature data is obtained by signing the second digest data of each data unit in the group of data units; subsequently, when the verification of the signature data is successful, store the authentication data in an authentication data list; then, from the authentication data list, search for authentication data that matches multiple first authentication identifiers of the group of data units; wherein, the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of the group of data units; verify the multiple first digest data in the group of data units according to the multiple second digest data in the matching authentication data.

[0093] It should be noted that the second authentication identifier and the first authentication identifier are used to distinguish the authentication identifier in the authentication data and the authentication identifier in other positions in the bitstream. The first digest data and the second digest data are used to distinguish the digest data calculated by the authentication end and the digest data in the authentication data.

[0094] According to a third aspect, determining first digest data for each data unit in a set of data units includes: calculating each data unit in the set of data units according to a digest algorithm to obtain first digest data for each data unit in the set of data units.

[0095] In a possible way, when hash_type is parsed from the security parameter set RBSP of the bitstream, each data unit in the set of data units can be calculated according to the authentication algorithm (i.e., the digest algorithm) indicated by hash_type to obtain first digest data for each data unit in the set of data units.

[0096] For example, each data unit in the set of data units can be hashed according to the digest algorithm indicated by hash_type in the security parameter set RBSP to obtain digest data for each data unit in the set of data units.

[0097] In a possible way, when hash_type is not parsed from the security parameter set RBSP of the bitstream, each data unit in the set of data units can be calculated according to a pre-agreed digest algorithm to obtain digest data for each data unit in the set of data units.

[0098] According to the third aspect, or any implementation manner of the above third aspect, the method further includes: obtaining a public key; concatenating second digest data of each data unit in the set of data units, and determining digest data of the concatenated second digest data; verifying signature data according to the public key, the digest data of the concatenated second digest data, and a signature algorithm.

[0099] Exemplarily, when the authentication data generated at the signature end further includes the public key corresponding to the private key used for signature, the public key can also be parsed from the authentication data RBSP.

[0100] In a possible way, when signature_type is parsed from the security parameter set RBSP of the bitstream, the signature algorithm can be determined according to the signature algorithm indicated by signature_type.

[0101] In a possible way, when camera_idc obtained from the security parameter set RBSP of the bitstream is available, the signature algorithm can be found from the authentication certificate indicated by camera_idc.

[0102] In a possible way, the public key can be parsed from the authentication data RBSP of the bitstream.

[0103] In a possible way, the public key pre-built in the authentication end 220 can be obtained.

[0104] In a possible way, the signature algorithm can be determined according to a pre-agreed signature algorithm.

[0105] According to the third aspect, or any one of the implementation manners of the above third aspect, the method further includes: obtaining a first identifier from the bitstream, where the first identifier indicates an authentication mode adopted by a group of data units; when the value of the first identifier is a first preset value, performing the step of determining first digest data of each data unit in the group of data units.

[0106] According to the third aspect, or any one of the implementation manners of the above third aspect, the method further includes: obtaining a fourth identifier from the bitstream, and determining a value n according to the fourth identifier; where a group of data units includes n data units, and n is a positive integer; obtaining second digest data of each of the n data units from the bitstream.

[0107] According to the third aspect, or any one of the implementation manners of the above third aspect, each data unit in a group of data units includes one or more Network Abstraction Layer (NAL) units.

[0108] According to the third aspect, or any one of the implementation manners of the above third aspect, multiple NAL units in a group of data units are associated with each other according to a specified rule, and the decoding order of multiple NAL units in a group of data units is consecutive.

[0109] According to the third aspect, or any one of the implementation manners of the above third aspect, each data unit in a group of data units includes an encoded image.

[0110] According to the third aspect, or any one of the implementation manners of the above third aspect, verifying multiple first digest data in a group of data units according to multiple second digest data in the matched authentication data includes: for a first data unit in a group of data units: if a second digest data identical to the first digest data of the first data unit is found in the multiple second digest data in the matched authentication data, it is determined that the authentication of the first data unit is successful; otherwise, it is determined that the authentication of the first data unit fails.

[0111] It should be noted that the third aspect and any one of the implementation manners of the third aspect may be executed by a decoder in the authentication end, or by an authentication module in the authentication end, or by the decoder and the authentication module in the authentication end in cooperation. This application does not limit this.

[0112] The third aspect and any one of the implementation manners of the third aspect respectively correspond to the first aspect and any one of the implementation manners of the first aspect. For the technical effects corresponding to the third aspect and any one of the implementation manners of the third aspect, reference may be made to the technical effects corresponding to the first aspect and any one of the implementation manners of the first aspect above, and details are not described here again.

[0113] Fourthly, an embodiment of the present application provides a signature device for a bitstream. The bitstream includes: a set of data units and an authentication identifier for each data unit in the set of data units. The signature device for the bitstream includes:

[0114] A first authentication data acquisition module, configured to acquire authentication data. The authentication data includes: signature data, an authentication identifier for each data unit in the set of data units, and digest data for each data unit in the set of data units. The signature data is obtained by signing the digest data for each data unit in the set of data units;

[0115] An addition module, configured to add the authentication data to the bitstream.

[0116] Exemplarily, the above signature device for the bitstream can be used to execute the signature method in the first aspect or any possible implementation manner of the first aspect.

[0117] The fourth aspect and any implementation manner of the fourth aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the fourth aspect and any implementation manner of the fourth aspect, reference can be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, which will not be elaborated here.

[0118] Fifthly, an embodiment of the present application provides an authentication device for a bitstream. The authentication device for the bitstream includes:

[0119] An authentication identifier acquisition module, configured to acquire a first authentication identifier for each data unit in a set of data units from the bitstream;

[0120] A digest data determination module, configured to determine first digest data for each data unit in the set of data units;

[0121] A second authentication data acquisition module, configured to acquire authentication data from the bitstream. The authentication data includes: signature data, a second authentication identifier for each data unit in the set of data units, and second digest data for each data unit in the set of data units. The signature data is obtained by signing the second digest data for each data unit in the set of data units;

[0122] An authentication data storage module, configured to store the authentication data in an authentication data list when the verification of the signature data is successful;

[0123] An authentication data search module, configured to search for authentication data that matches multiple first authentication identifiers of a set of data units from the authentication data list. The matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of the set of data units;

[0124] A verification module, configured to verify multiple first digest data in a set of data units according to multiple second digest data in the matched authentication data.

[0125] Exemplarily, the above authentication device for the code stream can be used to execute the authentication method in the third aspect or any possible implementation manner of the third aspect.

[0126] The fifth aspect and any implementation manner of the fifth aspect respectively correspond to the third aspect and any implementation manner of the third aspect. For the technical effects corresponding to the fifth aspect and any implementation manner of the fifth aspect, reference can be made to the technical effects corresponding to the third aspect and any implementation manner of the third aspect above, which will not be elaborated here.

[0127] In a sixth aspect, an embodiment of the present application provides an electronic device, including: a memory and a processor, the memory is coupled to the processor; the memory stores program instructions, and when the program instructions are executed by the processor, the electronic device is caused to execute the signature method for the code stream in the first aspect or any possible implementation manner of the first aspect.

[0128] The sixth aspect and any implementation manner of the sixth aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the sixth aspect and any implementation manner of the sixth aspect, reference can be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, which will not be elaborated here.

[0129] In a seventh aspect, an embodiment of the present application provides an electronic device, including: a memory and a processor, the memory is coupled to the processor; the memory stores program instructions, and when the program instructions are executed by the processor, the electronic device is caused to execute the authentication method for the code stream in the third aspect or any possible implementation manner of the third aspect.

[0130] The seventh aspect and any implementation manner of the seventh aspect respectively correspond to the third aspect and any implementation manner of the third aspect. For the technical effects corresponding to the seventh aspect and any implementation manner of the seventh aspect, reference can be made to the technical effects corresponding to the third aspect and any implementation manner of the third aspect above, which will not be elaborated here.

[0131] In an eighth aspect, an embodiment of the present application provides a chip, including one or more interface circuits and one or more processors; the one or more processors receive or send data through the one or more interface circuits, and when the one or more processors execute computer instructions, the steps of the signature method for the code stream in the first aspect or any possible implementation manner of the first aspect are executed.

[0132] The eighth aspect and any implementation manner of the eighth aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the eighth aspect and any implementation manner of the eighth aspect, reference may be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, which will not be elaborated here.

[0133] In a ninth aspect, an embodiment of the present application provides a chip, including one or more interface circuits and one or more processors; the one or more processors receive or send data through the one or more interface circuits, and when the one or more processors execute computer instructions, the steps of the code stream authentication method in the third aspect or any possible implementation manner of the third aspect are executed.

[0134] The ninth aspect and any implementation manner of the ninth aspect respectively correspond to the third aspect and any implementation manner of the third aspect. For the technical effects corresponding to the ninth aspect and any implementation manner of the ninth aspect, reference may be made to the technical effects corresponding to the third aspect and any implementation manner of the third aspect above, which will not be elaborated here.

[0135] In a tenth aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program, and when the computer program runs on a computer or a processor, the computer or the processor executes the code stream signature method in the first aspect or any possible implementation manner of the first aspect.

[0136] The tenth aspect and any implementation manner of the tenth aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the tenth aspect and any implementation manner of the tenth aspect, reference may be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, which will not be elaborated here.

[0137] In an eleventh aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program, and when the computer program runs on a computer or a processor, the computer or the processor executes the code stream authentication method in the third aspect or any possible implementation manner of the third aspect.

[0138] The eleventh aspect and any implementation manner of the eleventh aspect respectively correspond to the third aspect and any implementation manner of the third aspect. For the technical effects corresponding to the eleventh aspect and any implementation manner of the eleventh aspect, reference may be made to the technical effects corresponding to the third aspect and any implementation manner of the third aspect above, which will not be elaborated here.

[0139] In a twelfth aspect, an embodiment of the present application provides a computer program product, which includes computer instructions. When the computer instructions are executed by a computer or a processor, the computer or the processor is caused to execute the signature method of the bitstream in the first aspect or any possible implementation manner of the first aspect.

[0140] The twelfth aspect and any implementation manner of the twelfth aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the twelfth aspect and any implementation manner of the twelfth aspect, reference may be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, and details are not described herein again.

[0141] In a thirteenth aspect, an embodiment of the present application provides a computer program product, which includes computer instructions. When the computer instructions are executed by a computer or a processor, the computer or the processor is caused to execute the authentication method of the bitstream in the third aspect or any possible implementation manner of the third aspect.

[0142] The thirteenth aspect and any implementation manner of the thirteenth aspect respectively correspond to the third aspect and any implementation manner of the third aspect. For the technical effects corresponding to the thirteenth aspect and any implementation manner of the thirteenth aspect, reference may be made to the technical effects corresponding to the third aspect and any implementation manner of the third aspect above, and details are not described herein again.

[0143] In a fourteenth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores the bitstream in the second aspect or any possible implementation manner of the second aspect.

[0144] The fourteenth aspect and any implementation manner of the fourteenth aspect respectively correspond to the second aspect and any implementation manner of the second aspect. For the technical effects corresponding to the fourteenth aspect and any implementation manner of the fourteenth aspect, reference may be made to the technical effects corresponding to the second aspect and any implementation manner of the second aspect above, and details are not described herein again.

[0145] In a fifteenth aspect, an embodiment of the present application provides a device for storing a bitstream. The device includes: a receiver and at least one storage medium. The receiver is configured to receive the bitstream in the second aspect or any possible implementation manner of the second aspect; and the at least one storage medium is configured to store the bitstream.

[0146] The fifteenth aspect and any implementation manner of the fifteenth aspect respectively correspond to the second aspect and any implementation manner of the second aspect. For the technical effects corresponding to the fifteenth aspect and any implementation manner of the fifteenth aspect, reference may be made to the technical effects corresponding to the second aspect and any implementation manner of the second aspect above, and details are not described herein again.

[0147] In a sixteenth aspect, an embodiment of the present application provides a device for transmitting a bitstream. The device includes: a transmitter and at least one storage medium. The at least one storage medium is configured to store the bitstream in the second aspect or any possible implementation manner of the second aspect; the transmitter is configured to obtain the bitstream from the storage medium and send the bitstream to the terminal device through a transmission medium.

[0148] The sixteenth aspect and any implementation manner of the sixteenth aspect respectively correspond to the second aspect and any implementation manner of the second aspect. For the technical effects corresponding to the sixteenth aspect and any implementation manner of the sixteenth aspect, reference may be made to the technical effects corresponding to the second aspect and any implementation manner of the second aspect above, which will not be elaborated here.

[0149] In a seventeenth aspect, an embodiment of the present application provides a system for distributing a bitstream. The system includes: at least one storage medium configured to store the bitstream in at least one of the second aspect or any possible implementation manner of the second aspect, and a streaming media device configured to obtain a target bitstream from the at least one storage medium and send the target bitstream to the terminal device, where the streaming media device includes a content server or a content distribution server.

[0150] The seventeenth aspect and any implementation manner of the seventeenth aspect respectively correspond to the second aspect and any implementation manner of the second aspect. For the technical effects corresponding to the seventeenth aspect and any implementation manner of the seventeenth aspect, reference may be made to the technical effects corresponding to the second aspect and any implementation manner of the second aspect above, which will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0151] Figure 1 It is a schematic diagram of an exemplary application scenario;

[0152] Figure 2 It is a schematic diagram of an exemplary authentication and signature system 200;

[0153] Figure 3 It is a schematic diagram of an exemplary signature process 300;

[0154] Figure 4 It is a schematic diagram of an exemplary authentication process 400;

[0155] Figure 5A It is a schematic diagram of an exemplary signature process 500;

[0156] Figure 5B It is a schematic diagram of an exemplary signature process;

[0157] Figure 6A It is a schematic diagram of an exemplary authentication process;

[0158] Figure 6B Schematic diagram of the authentication process 600 shown by way of example;

[0159] Figure 7 Schematic diagram of the signature process 700 shown by way of example;

[0160] Figure 8A Schematic diagram of the authentication process shown by way of example;

[0161] Figure 8B Schematic diagram of the authentication process 600 shown by way of example;

[0162] Figure 9 Schematic diagram of the signature process 900 shown by way of example;

[0163] Figure 10A Schematic diagram of the authentication process shown by way of example;

[0164] Figure 10B Schematic diagram of the authentication process 1000 shown by way of example;

[0165] Figure 11 Schematic diagram of the signature device for the code stream shown by way of example;

[0166] Figure 12 Schematic diagram of the authentication device for the code stream shown by way of example;

[0167] Figure 13 Schematic diagram of the structure of the device shown by way of example. Detailed implementation manners

[0168] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are some, but not all, of the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without making creative efforts shall fall within the protection scope of the present application.

[0169] The term "and / or" in this article is merely a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. These three situations.

[0170] The terms "first" and "second" etc. in the description and claims of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order of the objects. For example, the first target object and the second target object etc. are used to distinguish different target objects, rather than to describe a specific order of the target objects.

[0171] In the embodiments of the present application, words such as "exemplarily" or "for example" are used to represent examples, illustrations, or explanations. Any embodiment or design solution described as "exemplarily" or "for example" in the embodiments of the present application should not be construed as being more preferred or more advantageous than other embodiments or design solutions. Rather, the use of words such as "exemplarily" or "for example" is intended to present relevant concepts in a specific manner.

[0172] In the description of the embodiments of the present application, unless otherwise specified, the meaning of "a plurality of" refers to two or more. For example, a plurality of processing units refers to two or more processing units; a plurality of systems refers to two or more systems.

[0173] Exemplarily, the signature and authentication method for the bitstream involved in the present application can be applied to sign and authenticate any one of an audio compression bitstream (or referred to as an audio compression bitstream) or a video compression bitstream (or referred to as a video compression bitstream). The present application does not limit this. The present application takes the signature and authentication of a video compression bitstream as an example for illustration.

[0174] bitstream

[0175] The binary data stream formed by encoding image / audio frames.

[0176] Figure 1 It is a schematic diagram of an exemplary application scenario. Figure 1 It shows a monitoring scenario, a live broadcast scenario, and an on-demand scenario.

[0177] Refer to Figure 1 , exemplarily, in the monitoring scenario, the camera 11 can sign the monitoring video bitstream to obtain the signed monitoring video bitstream 101. Then, the signed monitoring video bitstream 101 is sent to the laptop 13 through the network 12. After that, the laptop 13 can authenticate the signed monitoring video bitstream 101 to obtain the authentication result 105 and display it, and play the monitoring video 104.

[0178] Refer to Figure 1 , exemplarily, in the live broadcast scenario, the mobile phone 14 can sign the live broadcast video bitstream to obtain the signed live broadcast video bitstream 102. Then, the signed live broadcast video bitstream 102 is sent to the mobile phone 15 through the network 12. After that, the mobile phone 15 can authenticate the signed live broadcast video bitstream 102 to obtain the authentication result 107 and display it, and play the live broadcast video 106.

[0179] Refer to Figure 1, Exemplarily, in an on-demand scenario, the personal computer 16 can sign the on-demand video stream to obtain the signed on-demand video stream 103. Then, the signed on-demand video stream 103 is sent to the mobile phone 17 via the network 12. After that, the mobile phone 17 can authenticate the signed on-demand video stream 103 to obtain the authentication result 109 and display it, and play the on-demand video 108.

[0180] It should be understood that the present application can also be used in other scenarios of audio and video encoding and decoding, such as digital content trust scenarios, etc., and the present application does not limit this.

[0181] Figure 2 Schematic diagram of the authentication and signature system 200 shown exemplarily. In Figure 2 the above Figure 1 the authentication and signature process is described.

[0182] Referring to Figure 2 , exemplarily, the authentication and signature system 200 can include a signature end 210 and an authentication end 220.

[0183] For example, the signature end 210 can be the camera 11, the mobile phone 14, and the personal computer 16 in the above Figure 1 , and the authentication end 220 can be the laptop computer 13, the mobile phone 15, and the mobile phone 17 in the above Figure 1 .

[0184] It should be understood that the same terminal device can be used as both the signature end 210 and the authentication end 220, and the present application does not limit this.

[0185] Continuing to refer to Figure 2 , exemplarily, after the signature end 210 obtains the video data 201, it can perform video encoding 21 on the video data 201 to obtain the stream 202; and perform video signature 22 on the stream 202 to obtain the signed stream 203.

[0186] For example, the video data 201 can be the surveillance video collected by the camera 11, the live video recorded by the mobile phone 14, or the on-demand video produced by the personal computer 16 in the above Figure 1 .

[0187] For example, the signed stream 203 can be the signed surveillance video stream 101, the signed live video stream 102, or the signed on-demand video stream 103 in the above Figure 1 .

[0188] It should be noted that the two operations of video encoding 21 and video signature 22 can be executed in parallel.

[0189] It should be noted that, in one possible way, the signing end 210 may include an encoder, and the encoder performs video encoding 21 and video signing 22. In one possible way, the signing end 210 may include an encoder and a signing module, where the encoder performs video encoding 21 and the signing module performs video signing 22. In one possible way, the signing end 210 may include a signing module, and the signing module performs video encoding 21 and video signing 22.

[0190] After that, the signing end 210 may send the signed bitstream 203 to the authentication end 220.

[0191] Continuing to refer to Figure 2 , exemplarily, after the authentication end 220 receives the signed bitstream 203, it may perform video authentication 23 on the signed bitstream 203 to obtain an authentication result 205; and it may perform video decoding 24 on the bitstream 202 in the signed bitstream 203 to obtain decoded video data 204.

[0192] For example, the decoded video data 204 may be the surveillance video 104, the live video 106, or the on-demand video 108 mentioned above Figure 1 .

[0193] For example, the authentication result 205 may be the authentication result 105, the authentication result 107, or the authentication result 109 mentioned above Figure 1 .

[0194] It should be noted that the two operations of video authentication 23 and video decoding 24 may be performed in parallel.

[0195] It should be noted that, in one possible way, the authentication end 220 may include a decoder, and the decoder performs video decoding 24 and video authentication 23. In one possible way, the authentication end 220 may include a decoder and an authentication module, where the decoder performs video decoding 24 and the authentication module performs video authentication 23. In one possible way, the authentication end 220 may include an authentication module, and the authentication module performs video decoding 24 and video authentication 23.

[0196] It should be noted that when the signing end 210 performs lossless encoding, the video data is the same as the decoded video data; when the signing end 210 performs lossy encoding, there are differences between the video data and the decoded video data.

[0197] It should be noted that the encoder, decoder, and authentication module may be implemented in software or in hardware, and this application does not make any restrictions on this.

[0198] Figure 3Schematic diagram of the exemplary signature process 300. Among them, the process 300 can be implemented by the signature end 210.

[0199] S301, obtain authentication data; among them, the authentication data includes: signature data, the authentication identifier of each data unit in a group of data units, and the digest data of each data unit in a group of data units. The signature data is obtained by signing the digest data of each data unit in a group of data units.

[0200] Exemplarily, when authentication needs to be supported, the number n of data units to be authenticated can be determined, and the authentication identifier of each of the n data units can be generated; then, the authentication identifier of each data unit in a group of data units is added to the bitstream. Among them, n is a positive integer.

[0201] data unit

[0202] The basic syntax structure of the coded bitstream can be a NAL unit or an access unit.

[0203] NAL unit

[0204] A syntax structure that contains the type indication of the subsequent data and the number of bytes included (located in the NAL header), and the data appears in the form of a Raw Byte Sequence Payload (RBSP), and may also include scattered anti-counterfeiting bytes when necessary.

[0205] access unit

[0206] A group of NAL units that are associated with each other according to specified rules and are consecutive in decoding order.

[0207] It should be noted that from another dimension, the data unit can also include a coded image.

[0208] coded picture

[0209] The coded representation of a frame of image.

[0210] Refer to Figure 3 , exemplarily, the n data units to be authenticated in the bitstream are respectively: data unit 1, data unit 2,..., data unit n. These n data units to be authenticated can be called a group of data units. The group of data units involved subsequently all refer to the data units to be authenticated.

[0211] It should be noted that the present application does not group the data units, but for the convenience of description, the term "a group of data units" is used to describe.

[0212] Reference Figure 3 , exemplarily, the authentication identifiers in the bitstream are respectively: authentication identifier 1, authentication identifier 2,..., authentication identifier n.

[0213] It should be noted that the n authentication identifiers correspond one-to-one with the n data units. For example, authentication identifier 1 corresponds to data unit 1, authentication identifier 2 corresponds to data unit 2,..., authentication identifier n corresponds to data unit n. One authentication identifier can be used to identify one data unit, and the n authentication identifiers can indicate the authentication data used by the group of data units.

[0214] Reference Figure 3 , exemplarily, a digest data can be independently calculated for each data unit in a group of data units, and the digest data (which can also be called authentication digest data) of each data unit in the group of data units can be obtained. The n digest data can include: digest data 1, digest data 2,..., digest data n; where the n digest data correspond one-to-one with the n data units; for example, digest data 1 corresponds to data unit 1, digest data 2 corresponds to data unit 2,..., digest data n corresponds to data unit n.

[0215] Exemplarily, a signature data (signature) can be obtained by signing according to the digest data of each data unit in a group of data units.

[0216] Exemplarily, authentication data (Auth) can be generated according to the signature data, the authentication identifier of each data unit in a group of data units, and the digest data of each data unit in a group of data units. In this way, the authentication data can be {authentication serial number 1, authentication serial number 2,..., authentication serial number n, digest data 1, digest data 2,..., digest data n, signature}.

[0217] Optionally, the digest data of each data unit in a group of data units in the authentication data can form a digest data list {digest data 1, digest data 2,..., digest data n}.

[0218] S302, Add the authentication data to the bitstream.

[0219] Exemplarily, after the authentication data is obtained, the authentication data can be added to the bitstream to obtain a signed bitstream, that is, the signed bitstream 203 in the above Figure 2 .

[0220] It should be noted that S301 to S302 can be executed by the encoder in the signature terminal 210, or by the signature module in the signature terminal 210, or by the encoder and the authentication module in the signature terminal 210 in cooperation (the encoder executes S302 and the authentication module executes S301), and the present application does not limit this.

[0221] Figure 4 It is a schematic diagram of the exemplary authentication process 400. Among them, the process 400 can be implemented by the authentication terminal 220, and the process 400 corresponds to the process 300.

[0222] S401, obtain the first authentication identifier of each data unit in a group of data units from the bitstream.

[0223] Refer to Figure 4 , exemplarily, the bitstream may include data units, authentication identifiers, and authentication data. Among them, in order to distinguish the authentication identifier located in the authentication data from the authentication identifier located in other positions in the bitstream, the authentication identifier located in other positions in the bitstream can be called the first authentication identifier, and the authentication identifier located in the authentication data can be called the second authentication identifier.

[0224] Exemplarily, the bitstream can be parsed to read the first authentication identifier of the data unit to be authenticated from the bitstream. Among them, the first authentication identifier may include: authentication identifier 11, authentication identifier 12,..., authentication identifier 1n. In this way, n data units can be determined as the data units to be authenticated, and these n data units are respectively: data unit 1, data unit 2,..., data unit n.

[0225] Exemplarily, the n first authentication identifiers correspond to the n data units one by one, that is: data unit 1 corresponds to authentication identifier 11, data unit 2 corresponds to authentication identifier 12,..., data unit n corresponds to authentication identifier 1n.

[0226] S402, determine the first digest data of each data unit in a group of data units.

[0227] Exemplarily, n data units to be authenticated (that is, a group of data units to be authenticated) can be read from the bitstream. Then, a digest data is independently calculated for each data unit in this group of data units, and the digest data of each data unit in this group of data units can be obtained. In order to distinguish the digest data calculated in S402 from the digest data included in the authentication data, the digest data calculated in S402 can be called the first digest data, and the digest data included in the authentication data can be called the second digest data.

[0228] Refer to Figure 4, Exemplarily, the n first summary data are respectively: summary data 11, summary data 12,..., summary data 1n.

[0229] Exemplarily, the n first summary data and the n data units are in one-to-one correspondence. For example, summary data 11 corresponds to data unit 1, summary data 12 corresponds to data unit 2,..., summary data 1n corresponds to data unit n.

[0230] S403, Obtain authentication data from the bitstream. The authentication data includes: signature data, the second authentication identifier of each data unit in a group of data units, and the second summary data of each data unit in a group of data units. The signature data is obtained by signing the second summary data of each data unit in a group of data units.

[0231] Exemplarily, the bitstream can be parsed to read the authentication data from the bitstream. Among them, the authentication data includes: signature data, n second summary data (including summary data 21, summary data 22,..., summary data 2n) and n second authentication identifiers (including authentication identifier 21, authentication identifier 22,..., authentication identifier 2n).

[0232] Exemplarily, the n second summary data can form a summary data list {summary data 21, summary data 22,..., summary data 2n}.

[0233] Exemplarily, the n second summary data and the n data units are in one-to-one correspondence. For example, summary data 21 corresponds to data unit 1, summary data 22 corresponds to data unit 2,..., summary data 2n corresponds to data unit n.

[0234] Exemplarily, the n second authentication identifiers and the n data units are in one-to-one correspondence. For example, authentication identifier 21 corresponds to data unit 1, authentication identifier 22 corresponds to data unit 2,..., authentication identifier 2n corresponds to data unit n.

[0235] S404, When the signature data is successfully verified, store the authentication data in the authentication data list.

[0236] Exemplarily, the signature data can be verified. When the signature data is successfully verified, store the authentication data in the authentication data list.

[0237] Among them, the authentication data list can include multiple authentication data (including one or more previously obtained authentication data and the currently obtained authentication data). Each authentication data can include: signature data, the second authentication identifier of each data unit in a group of data units, and the second summary data of each data unit in a group of data units. The signature data is obtained by signing the second summary data of each data unit in a group of data units.

[0238] S405. Search for authentication data in the authentication data list that matches multiple first authentication identifiers of a set of data units; wherein the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of the set of data units.

[0239] Next, the multiple first authentication identifiers obtained from the bitstream can be compared with the multiple second authentication identifiers included in each authentication data in the authentication data list; when authentication data containing multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers obtained from the bitstream is found, the authentication data containing these multiple second authentication identifiers can be determined as the authentication data that matches the multiple first authentication identifiers of the set of data units obtained from the bitstream.

[0240] S406. Verify multiple first digest data of a set of data units according to multiple second digest data in the matching authentication data.

[0241] Exemplarily, after the matching authentication data is found in the authentication data list, multiple second digest data (or a digest data list) can be read from the matching authentication data; then, multiple first digest data of a set of data units are verified according to the multiple second digest data in the matching authentication data.

[0242] Specifically, for the first data unit in a set of data units obtained from the bitstream (the first data unit can be any data unit in the set of data units obtained from the bitstream), it can be checked whether there is a second digest data in the multiple second digest data of the matching authentication data that is the same as the first digest data of the first data unit; when a second digest data that is the same as the first digest data of the first data unit is found in the multiple second digest data of the matching authentication data, it is determined that the authentication of the first data unit is successful, that is, the authentication result can be authentication successful. Otherwise, it is determined that the authentication of the first data unit fails, that is, the authentication result can be authentication failed.

[0243] For example, in the implementation process, a digest data list {digest data 21, digest data 22,..., digest data 2n} can be made into a Map data structure, such as Map[digest data 21]=1, Map[digest data 22]=1,..., Map[digest data 2n]=1, to achieve fast search.

[0244] It should be noted that S401 to S406 can be executed by the decoder in the authentication end 220, or by the authentication module in the authentication end 220, or jointly executed by the decoder and the authentication module in the authentication end 220 (the decoder executes S401 and S403, and the authentication module executes S402, S404 to S406). This application does not limit this.

[0245] For the temporal SVC coding of the public security video surveillance digital video and audio coding (Surveillance Video and Audio Coding, SVAC) standard, each data unit uses temporal_id to identify its temporal level. During decoding, some temporal levels or data units may not participate in decoding; in this application, since each data unit independently generates digest data, during authentication, for the data units participating in authentication, the corresponding digest data can be searched in the authentication data, and the data units not participating in authentication do not affect the authentication of other data units.

[0246] For the spatial SVC coding of the SVAC standard, each data unit uses layer_id to identify its spatial level. During decoding, some spatial levels or data units may not participate in decoding; in this application, since each data unit independently generates digest data, during authentication, for the data units participating in authentication, the corresponding digest data can be searched in the authentication data, and the data units not participating in authentication do not affect the authentication of other data units.

[0247] For the video quality SVC coding of the SVAC standard, during decoding, some quality levels or data units may not participate in decoding. In this application, since each data unit independently generates digest data, during authentication, for the data units participating in authentication, the corresponding digest data can be searched in the authentication data, and the data units not participating in authentication do not affect the authentication of other data units.

[0248] In addition, for SVC coding, only the authentication data of a group of data units needs to be transmitted to support the authentication of the sub-bitstreams extracted from the bitstream.

[0249] In summary, this application can effectively solve the problem that the current SVAC coding temporal SVC coding, spatial SVC coding, and video quality SVC coding require independent authentication.

[0250] Secondly, since each data unit is authenticated independently, even if some data units are lost (dropped frames), other data units can still be authenticated. In addition, by using the authentication identifier to label the data units, the one-to-one correspondence between the data units and the authentication data is ensured, avoiding the problem of mismatch between the data units and the authentication data caused by a long signature time.

[0251] Exemplarily, the authentication identifier of each data unit in a group of data units in the bitstream can be located before the group of data units. In this way, the authentication end 220 can receive the authentication identifier of each data unit in a group of data units before receiving the group of data units, and then ensure that the authentication end 220 marks each data unit in the received group of data units according to the authentication identifier of each data unit in the group of data units, determines the authentication identifier of each data unit, and ensures the correspondence between the data unit and the authentication data.

[0252] Figure 5A It is a schematic diagram of the exemplary signature process 500. Among them, the process 500 can be implemented by the signature end 210. The process 500 is a process in which the SVAC signature end uses the secure parameter set RBSP to carry the authentication identifier to implement data unit signature.

[0253] S501, generate a secure parameter set RBSP.

[0254] Exemplarily, when video image authentication needs to be supported, a secure parameter set RBSP (such as Figure 5A the SEC_RBSP in it) can be generated. Among them, the definition of the secure parameter set RBSP in the NAL unit of the secure parameter set can be as shown in Table 1:

[0255] Table 1 Definition of secure parameter set RBSP

[0256]

[0257]

[0258] Authentication mode authentication_mode

[0259] A 2-bit unsigned integer. It indicates the authentication mode used for authentication, which can be as shown in Table 2:

[0260] Table 2 Explanation of authentication mode

[0261] Value of authentication_mode Description 0 Each data unit independently performs digest data authentication 1 Tree-shaped digest data authentication 2～3 Reserved

[0262] If authenticate_mode is 0, first concatenate the digest data of the image data (which can also be a data unit), perform a digest operation on the concatenated digest data, and then perform a digital signature on the digest data.

[0263] Authentication serial number authentication_id

[0264] Binary variable. The authentication serial number is used to identify the authentication data set it uses. A new authentication_id indicates the start of a new authentication sequence (i.e., a new set of data units).

[0265] Hash type hash_type

[0266] A 2-bit unsigned integer. It indicates the algorithm used for authentication (i.e., the algorithm for determining the digest data of the data unit). The specific correspondence is shown in Table 3 as follows:

[0267] Table 3 Correspondence between hash type and specific algorithm

[0268] Value of hash_type Authentication algorithm Digest data length (bytes) 0 SM3 32 1～3 Reserved Reserved

[0269] Digital signature type signature_type

[0270] A 2-bit unsigned integer. It indicates the algorithm for digitally signing the digest data of the data unit, as shown in Table 4 below:

[0271] Table 4 Correspondence between digital signature type and specific encryption algorithm

[0272] Value of signature_type Signature algorithm 0 SM2 1～3 Reserved

[0273] Authentication enable flag authentication_flag

[0274] A 1-bit unsigned integer. It indicates whether a set of data units supports authentication, as shown in Table 5:

[0275] Table 5 Explanation of authentication enable flag

[0276] Value of authentication_flag Description 0 Does not support authentication 1 Supports authentication

[0277] camera_idc is a 19-byte string used to represent the certificate identifier of the camera from which the video stream's corresponding image is sourced.

[0278] It should be noted that compared with the prior art, the security parameter set of this application newly adds: authenticate_mode (which can be called the first identifier) and authentication_id (which can also be called the authentication identifier).

[0279] Refer to Figure 5A, Exemplarily, the SEC_RBSP may include n authentication identifiers: P1, P2, P3, P4, ..., Pn. Among them, P1 is the authentication identifier of data unit 1, P2 is the authentication identifier of data unit 2, P3 is the authentication identifier of data unit 3, P4 is the authentication identifier of data unit 4, ..., Pn is the authentication identifier of data unit n.

[0280] Exemplarily, when authenticate_mode is 0, it can be determined to use the signature method of the bitstream involved in this application for signature, and reference can be made to S502 to S504 as follows; when authenticate_mode is 1, it can be determined to use the signature method in the prior art for signature, that is, calculate the tree-shaped digest data and sign the top-level digest data. Furthermore, when using the signature method of this application, the authenticate_mode in the security parameter set RBSP can be set to 0 during the process of generating the security parameter set RBSP.

[0281] Exemplarily, during the process of generating the security parameter set RBSP, the authentication_flag in the security parameter set RBSP can be set to 1, so that it can indicate that a group of data units located after the security parameter set RBSP supports authentication.

[0282] Exemplarily, when the data unit is a NAL unit, a group of data units may include multiple NAL units, and the authentication identifiers of each NAL unit are different. When the data unit is multiple NAL units, a group of data units includes multiple access units, the authentication identifiers of each access unit are different, and the authentication identifiers of multiple NAL units included in each access unit are the same.

[0283] It should be noted that hash_type, signature_type, and camera_idc in the security parameter set RBSP are optional.

[0284] S502, Calculate each data unit in a group of data units according to the digest algorithm to obtain the digest data of each data unit in the group of data units.

[0285] Exemplarily, the number of data units to be authenticated can be determined according to the number of authentication_id in the security parameter set RBSP; that is, the number of data units included in a group of data units.

[0286] In one possible way, when the security parameter set RBSP includes hash_type, the digest algorithm can be the authentication algorithm indicated by hash_type in the security parameter set RBSP. In this case, for each data unit in a set of data units, the digest data of each data unit in the set of data units can be calculated according to the authentication algorithm indicated by hash_type in the security parameter set RBSP. For example, for each data unit in a set of data units, the hash calculation can be performed according to the digest algorithm indicated by hash_type in the security parameter set RBSP to obtain the digest data of each data unit in the set of data units.

[0287] In one possible way, the signature end 210 and the authentication end 220 can pre-agree on the digest algorithm; in this way, for each data unit in a set of data units, the digest data of each data unit in the set of data units can be calculated according to the pre-agreed digest algorithm. In this case, the security parameter set RBSP may not include hash_type.

[0288] It should be understood that this application does not limit the way for the signature end 210 and the authentication end 220 to synchronize the digest algorithm.

[0289] Refer again to Figure 5A , exemplarily, perform the hash calculation on data unit 1 to obtain the digest data H1; perform the hash calculation on data unit 2 to obtain the digest data H2; perform the hash calculation on data unit 3 to obtain the digest data H3; perform the hash calculation on data unit 4 to obtain the digest data H4;...; perform the hash calculation on data unit n to obtain the digest data Hn.

[0290] S503, connect the digest data of each data unit in a set of data units, and determine the digest data of the connected digest data of each data unit in the set of data units.

[0291] Exemplarily, the digest data of each data unit in a set of data units can be spliced to obtain the connected digest data as H1 + H2 + H3 + H4 + H5 +... + Hn.

[0292] Then, the connected digest data can be calculated to obtain the digest data of the connected digest data. For example, perform the hash calculation on H1 + H2 + H3 + H4 + H5 +... + Hn to obtain the digest data Hg of the connected digest data (as Figure 5A shown).

[0293] S504, use the private key to sign the digest data of the connected digest data to obtain the signature data.

[0294] In one possible way, when the security parameter set RBSP includes signature_type, the signature data can be obtained by signing the digest data of the concatenated digest data according to the signature algorithm and private key indicated by signature_type in the security parameter set RBSP.

[0295] In one possible way, the signature end 210 and the authentication end 220 can pre-agree on a signature algorithm; in this way, the signature data can be obtained by signing the digest data of the concatenated digest data according to the pre-agreed signature algorithm and private key. In this case, the security parameter set RBSP may not include signature_type.

[0296] It should be understood that this application does not limit the way for the signature end 210 and the authentication end 220 to synchronize the signature algorithm.

[0297] It should be understood that the top-level digest data can also be generated, and the signature data can be obtained by signing the top-level digest data with the private key. This application does not limit the way of signing according to the digest data of the data unit.

[0298] Exemplarily, authentication data is generated according to the digest data of each data unit in a group of data units, the authentication identifier of each data unit in the group of data units, and the signature data.

[0299] For example, the authentication data may include {P1, P2, P3, P4, P5,..., Pn, H1, H2, H3, H4, H5,..., Hn, signature}.

[0300] S505, encode the authentication data and add the encoded authentication data to the bitstream.

[0301] Exemplarily, the authentication data can be encoded using Base64; then, the encoded authentication data is packed into the NAL unit of the authentication data. Among them, the definition of the authentication data RBSP in the NAL unit of the authentication data can be as shown in Table 6 below:

[0302] Table 6 Definition of authentication data RBSP

[0303]

[0304]

[0305] Authentication sequence number authentication_id

[0306] Binary variable. The authentication sequence number of the authentication data set.

[0307] The number of authentication digest data, authentication_hash_number_minus1

[0308] 8-bit unsigned integer. Adding 1 represents the length of the signature data in bytes, and the value should be in the range of 0 to 255.

[0309] Authentication digest data, authentication_hash

[0310] Binary data, with the length being the digest data length corresponding to the hash type in the correspondence table between the hash types and specific algorithms in the security parameter set, in bytes.

[0311] The length of the signature data, authentication_data_length_minus1

[0312] 8-bit unsigned integer. Adding 1 represents the length of the signature data in bytes, and the value should be in the range of 0 to 255.

[0313] The number of bytes of the signature data, authentication_data[i]

[0314] 8-bit unsigned integer. The i-th byte of a signature data. The signature data should be Base64 encoded. See rfc3548 for the Base64 encoding method.

[0315] Exemplarily, the authentication identifier included in the authentication data, that is, authentication_id (authentication sequence number) in Table 6.

[0316] Exemplarily, the digest data included in the authentication data, that is, authentication_hash (authentication digest data) in Table 6.

[0317] Exemplarily, authentication_hash_number_minus1 in the authentication data RBSP can be referred to as the fourth identifier.

[0318] It should be noted that, compared with the authentication data RBSP in the prior art, the NAL unit of the authentication data in this application includes authentication_id, authentication_hash, and authentication_hash_number_minus1.

[0319] In addition, in the scenario of temporal SVC coding of the SVAC standard, each data unit includes a second identifier (temporal_id) for identifying the temporal layer to which the data unit belongs; correspondingly, the authentication data RBSP may also include the second identifier (temporal_id). Since in the scenario of temporal SVC coding of the SVAC standard, the temporal base layer (i.e., the data unit with the second identifier being 0) needs to be parsed, in order to ensure that the authentication data can be obtained regardless of whether the temporal enhancement layer is parsed during the authentication process; the value of the second identifier in the NAL unit of the authentication data can be set to 0

[0320] In the scenario of spatial SVC coding or quality SVC coding of the SVAC standard, each data unit includes a third identifier (layer_id) for identifying the spatial layer or quality coding layer to which the data unit belongs; correspondingly, the authentication data RBSP may also include the third identifier (layer_id). Since in the scenario of spatial SVC coding or quality SVC coding of the SVAC standard, the spatial base layer / quality coding base layer (i.e., the data unit with the third identifier being 0) needs to be parsed, in order to ensure that the authentication data can be obtained regardless of whether the spatial enhancement layer / quality coding enhancement layer is parsed during the authentication process; the value of the third identifier in the NAL unit of the authentication data can be set to 0.

[0321] Figure 5B It is a schematic diagram of the signature process shown exemplarily. Figure 5B Two groups of data units in the bitstream and the authentication data corresponding to the two groups of data units are shown.

[0322] Refer to Figure 5B , exemplarily, Sec represents the NAL unit of the security parameter set RESP, P1 to Pn respectively correspond to a data unit, and Auth represents the authentication data. Private Key is the private key, sign is the signature, and Publice Key is the public key.

[0323] Refer to Figure 5B , in one possible way, the public key can be added to the authentication data.

[0324] It should be understood that the public key corresponding to the above private key can also be transmitted in other ways, such as being built into the authentication end, transmitted to the authentication end in the authentication certificate, etc., and this application does not limit this.

[0325] It should be noted that the authentication data corresponding to the current group of data units may be connected after the current group of data units, such as Figure 5BAs shown by the first set of data units and the authentication data of the first set of data units. The authentication data corresponding to the current set of data units is not necessarily connected after the current set of data units, and may also be connected after the first few data units of the next set of data units (as Figure 5B shown by the second set of data units and the authentication data of the second set of data units in), which is caused by the difference between the rate of the encoded data units and the rate of generating the authentication data. However, since the present application uses the authentication identifier to identify the data units, the one-to-one correspondence between the data units and the authentication data is ensured, thereby avoiding the problem of mismatch between the data units and the authentication data due to the long signature time.

[0326] Figure 6A It is a schematic diagram of the authentication process shown exemplarily.

[0327] Figure 6B It is a schematic diagram of the authentication process 600 shown exemplarily. The process 600 is a process in which the SVAC authentication end realizes the authentication of data units when the authentication identifier is carried in the security parameter set RBSP. The process 600 corresponds to the process 500.

[0328] S601, obtain the first authentication identifier of each data unit in a set of data units from the security parameter set RBSP of the bitstream.

[0329] Exemplarily, after the authentication end 220 receives the security parameter set RBSP of the bitstream, when it parses that the authentication_flag is 1 from the security parameter set RBSP of the bitstream, it determines that the subsequent set of data units supports authentication. At this time, the syntax elements in the security parameter set RBSP can be parsed continuously according to the order of each syntax element in Table 1.

[0330] Exemplarily, parse the hash_mode in the security parameter set RBSP; when it is parsed that the hash_mode is 0, S602 can be executed.

[0331] Exemplarily, parse the authentication_id in the security parameter set RBSP, and the first authentication identifier of each data unit in a set of data units can be obtained.

[0332] Exemplarily, parse the hash_type in the security parameter set RBSP; according to the value of the parsed hash_type, determine the digest algorithm.

[0333] Exemplarily, parse the signature_type in the security parameter set RBSP; according to the value of the parsed signature_type, determine the signature algorithm.

[0334] Exemplarily, parse the camera_idc in the safety parameter set RBSP; according to the value of the parsed camera_idc, determine the certificate identifier of the camera from which the video stream's corresponding image is sourced.

[0335] Refer to Figure 6A , exemplarily, the n first authentication identifiers are respectively: P1, P2, P3, P4,..., Pn.

[0336] S602, calculate each data unit in a group of data units according to the digest algorithm to obtain the first digest data of each data unit in the group of data units.

[0337] Exemplarily, when the authentication end 220 receives each data unit of a subsequent group of data units, it can record the corresponding authentication identifier for each NAL unit of each data unit; and calculate each data unit in the group of data units to obtain the first digest data of each data unit in the group of data units.

[0338] In a possible way, when hash_type is parsed from the safety parameter set RBSP of the video stream, the authentication algorithm (i.e., the digest algorithm) indicated by hash_type can be used to calculate each data unit in a group of data units to obtain the first digest data of each data unit in the group of data units.

[0339] For example, the digest algorithm indicated by hash_type in the safety parameter set RBSP can be used to perform a hash calculation on each data unit in a group of data units to obtain the digest data of each data unit in the group of data units.

[0340] In a possible way, when hash_type is not parsed from the safety parameter set RBSP of the video stream, each data unit in a group of data units can be calculated according to a pre-agreed digest algorithm to obtain the digest data of each data unit in the group of data units.

[0341] Refer to Figure 6A , exemplarily, the n first digest data are respectively: H1’, H2’, H3’, H4’, H5’,..., Hn’.

[0342] S603, obtain the authentication data from the video stream, where the authentication data includes: signature data, the second authentication identifier of each data unit in a group of data units, and the second digest data of each data unit in a group of data units, and the signature data is obtained by signing according to the second digest data of each data unit in the group of data units.

[0343] Exemplarily, the authentication data RBSP in the video stream can be parsed to obtain the authentication data.

[0344] Exemplarily, the authentication_id in the authentication data RBSP is parsed to obtain the second authentication identifier for each data unit in a set of data units.

[0345] Exemplarily, the authentication_hash_number_minus1 (which can also be referred to as the fourth identifier) in the authentication data RBSP is parsed to obtain the number of second digest data included in the authentication data.

[0346] Exemplarily, the authentication_hash in the authentication data RBSP is parsed according to the authentication_hash_number_minus1 to obtain the second digest data for each data unit in a set of data units; wherein, the number of the second digest data is the same as the value calculated according to the authentication_hash_number_minus1.

[0347] Exemplarily, when the authentication data generated in the signature end 210 further includes the public key corresponding to the private key for signature, the public key can also be parsed from the authentication data RBSP.

[0348] Exemplarily, the authentication data may include {P1, P2, P3, P4, P5,..., Pn, H1, H2, H3, H4, H5,..., Hn, signature}

[0349] S604, verify the signature data according to the public key, the first digest data for each data unit in a set of data units, and the signature algorithm.

[0350] Exemplarily, the first digest data for each data unit in a set of data units can be concatenated; then, the digest data Hg' of the concatenated first digest data is determined. After that, the verification result of the signature data can be obtained by processing the public key, Hg', and the signature data using the signature verification algorithm corresponding to the signature algorithm.

[0351] In a possible way, when the signature_type is parsed from the code stream security parameter set RBSP, the signature algorithm can be determined according to the signature algorithm indicated by the signature_type.

[0352] In a possible way, the signature algorithm can be determined according to a pre-agreed signature algorithm.

[0353] In a possible way, when the camera_idc is obtained from the security parameter set RBSP of the code stream, the public key can be found from the authentication certificate indicated by the camera_idc.

[0354] In one possible way, the public key can be parsed from the authentication data RBSP of the bitstream.

[0355] In one possible way, the public key pre-built in the authentication end 220 can be obtained.

[0356] S605: When the signature data is successfully verified, store the authentication data in the authentication data list.

[0357] S606: Search for the authentication data in the authentication data list that matches multiple first authentication identifiers of a group of data units; wherein, the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of the group of data units.

[0358] S607: Verify multiple first digest data of a group of data units according to multiple second digest data in the matching authentication data.

[0359] Exemplarily, S605 to S607 can refer to the descriptions of S404 to S406 above and will not be elaborated here.

[0360] Exemplarily, in S607, multiple second digest data in the matching authentication data can be {H1, H2, H3, H4, H5,..., Hn}, and multiple first digest data of a group of data units can be {H1’, H2’, H3’, H4’, H5’,..., Hn’}; search for each first digest data in {H1’, H2’, H3’, H4’, H5’,..., Hn’} from {H1, H2, H3, H4, H5,..., Hn}. For example, when the second digest data equal to H1’ is found from {H1, H2, H3, H4, H5,..., Hn}, it can be determined that the authentication of data unit 1 is successful; when the second digest data equal to H2’ is found from {H1, H2, H3, H4, H5,..., Hn}, it can be determined that the authentication of data unit 2 is successful, and so on, which will not be elaborated here. If the second digest data equal to H1’ is not found from {H1, H2, H3, H4, H5,..., Hn}, it can be determined that the authentication of data unit 1 fails; if the second digest data equal to H2’ is not found from {H1, H2, H3, H4, H5,..., Hn}, it can be determined that the authentication of data unit 2 fails; and so on.

[0361] Figure 7 It is a schematic diagram of the exemplary signature process 700. Among them, the process 700 can be implemented by the signature end 210. The process 700 is a process in which the signature end realizes the signature of data units by carrying authentication identifiers through extended information.

[0362] Exemplarily, in H.264 video coding, CEI extension information is included in the SEI information with NAL unit type 6, and in H.265 video coding, CEI extension information is included in the SEI information with NAL unit type 39. The CEI data of the AVS series of standards is carried in the extension_data after the sequence_header. This application extends the CEI syntax to support the authentication of NAL units; among them, when the new CEI syntax that supports authentication appears, it indicates the start of a new authentication.

[0363] S701, generate extension information.

[0364] Exemplarily, when video image authentication is required, CEI extension information (or CEI data) can be generated, as shown in Table 7:

[0365] Table 7 CEI data syntax format

[0366]

[0367]

[0368] authentication_flag: Indicates whether the video data (or data unit) after this extended data is authenticated;

[0369] authentication_id: Authentication sequence number, used to identify the authentication data set it uses. A new authentication_id indicates the start of a new authentication sequence.

[0370] hash_type: Hash type, indicating the algorithm used for authentication. The specific correspondence is shown in Table 8 below:

[0371] Table 8 Correspondence between hash type and specific algorithm

[0372] Value of hash_type Authentication algorithm Digest data length (bytes) 0 SM3 32 1～3 Reserved Reserved

[0373] signature_type: Digital signature type, indicating the algorithm for digitally signing the digest data of the image (or data unit), as shown in Table 9 below:

[0374] Table 9 Correspondence between digital signature type and specific encryption algorithm

[0375] Value of signature_type Signature algorithm 0 SM2 1～3 Reserved

[0376] It should be noted that, compared with the prior art, the CEI extension information of the present application newly adds: authentication_id (which can also be referred to as the authentication identifier), hash_type, signature_type, and authentication_flag.

[0377] Exemplarily, in the process of generating the CEI diffusion information, the authentication_flag in the CEI extension information can be set to 1, so as to indicate that a group of data units located after the CEI extension information supports authentication.

[0378] Exemplarily, when the data unit is a NAL unit, a group of data units can include multiple NAL units, and the authentication identifiers of each NAL unit are different. When the data unit is multiple NAL units, a group of data units includes multiple access units, the authentication identifiers of each access unit are different, and the authentication identifiers of multiple NAL units included in each access unit are the same.

[0379] It should be noted that hash_type and signature_type in the extension information are optional.

[0380] S702, calculate each data unit in a group of data units according to the digest algorithm to obtain the digest data of each data unit in the group of data units.

[0381] Exemplarily, the number of data units to be authenticated can be determined according to the number of authentication_id in the CEI extension information; that is, the number of data units included in a group of data units.

[0382] Exemplarily, S702 can refer to the description of S502 above and will not be elaborated here.

[0383] Among them, the difference between S702 and S502 is that in one possible way of S702, the digest algorithm can be the authentication algorithm indicated by hash_type in the CEI extension information.

[0384] S703, concatenate the digest data of each data unit in a group of data units to determine the digest data of the concatenated digest data of each data unit in the group of data units.

[0385] S704, sign the digest data of the concatenated digest data of each data unit in a group of data units by using the private key to obtain the signature data.

[0386] Exemplarily, S703 - S704 can refer to the description of S503 - S504 above and will not be elaborated here.

[0387] Among them, the difference between S704 and S504 is that in one possible way of S704, the signature algorithm can be the signature algorithm indicated by signature_type in the CEI extension information.

[0388] S705: Encode the authentication data and add the encoded authentication data to the bitstream.

[0389] Exemplarily, S702 to S705 can refer to the descriptions of the above S502 to S505, and will not be elaborated here.

[0390] Exemplarily, the definition of the authentication data RBSP in process 700 can be as shown in Table 10 below:

[0391] Table 10 Definition of Authentication Data RBSP

[0392]

[0393] Authentication sequence number authentication_id

[0394] Binary variable. The authentication sequence number of the authentication data set.

[0395] Number of authentication digest data authentication_hash_number_minus1

[0396] 8-bit unsigned integer. Adding 1 represents the length of the signature data in bytes, and the value should be 0 to 255.

[0397] Authentication digest data authentication_hash

[0398] Binary data, with a length equal to the length of the digest data corresponding to the hash type in the correspondence table between the hash type and the specific algorithm in the security parameter set, in bytes.

[0399] Length of signature data authentication_data_length_minus1

[0400] 8-bit unsigned integer. Adding 1 represents the length of the signature data in bytes, and the value should be 0 to 255.

[0401] Number of bytes of signature data authentication_data[i]

[0402] The i-th byte of the signature data.

[0403] It should be noted that the authentication data RBSP generated in process 700 is newly added.

[0404] Signature certificate chain length, certificate_chain_length_minus1

[0405] The length of the certificate chain used to verify the signature, plus 1 represents the length of the signature data, in bytes, and the value should be 0 to 65535. When it is 1, it means there is no certificate chain.

[0406] Signature certificate chain, certificate_chain_data[i]

[0407] The i-th byte of the signature certificate chain.

[0408] It should be noted that certificate_chain_data and certificate_chain_length_minus1 are optional.

[0409] In addition, in the scenario of temporal SVC coding in the SVAC standard, each data unit includes a second identifier (temporal_id) for identifying the temporal level where the data unit is located; correspondingly, the authentication data RBSP can also include a second identifier (temporal_id). Since in the scenario of temporal SVC coding in the SVAC standard, the temporal base layer (i.e., the data unit with the second identifier being 0) needs to be parsed, in order to ensure that in the authentication process, whether or not the temporal enhancement layer is parsed, the authentication data can be obtained; the value of the second identifier in the NAL unit of the authentication data can be set to 0.

[0410] In the scenario of spatial SVC coding or quality SVC coding in the SVAC standard, each data unit includes a third identifier (layer_id) for identifying the spatial level or quality coding level where the data unit is located; correspondingly, the authentication data RBSP can also include a third identifier (layer_id). Since in the scenario of spatial SVC coding or quality SVC coding in the SVAC standard, the spatial base layer / quality coding base layer (i.e., the data unit with the third identifier being 0) needs to be parsed, in order to ensure that in the authentication process, whether or not the spatial enhancement layer / quality coding enhancement layer is parsed, the authentication data can be obtained; the value of the third identifier in the NAL unit of the authentication data can be set to 0.

[0411] In process 700, the public key can also be added to the authentication data (the public key can be in the signature certificate chain certificate_chain_data). It should be understood that the public key corresponding to the above private key can also be transmitted in other ways, such as being built into the authentication end, transmitted to the authentication end in a certificate, etc., and this application does not limit this.

[0412] Figure 8A Schematic diagram of the authentication process shown for exemplary purposes.

[0413] Figure 8B A schematic diagram of the authentication process 600 shown exemplarily. The process 800 is a process for the authentication end to implement data unit authentication when the extended information carries an authentication identifier. The process 800 corresponds to the process 700.

[0414] S801. Obtain the first authentication identifier of each data unit in a group of data units from the extended information of the bitstream.

[0415] Exemplarily, after the authentication end receives the CEI extended information of the bitstream, when the authentication_flag in the CEI extended information of the bitstream is 1, it is determined that the subsequent group of data units supports authentication. At this time, the syntax elements in the CEI extended information can be continuously parsed in the order of each syntax element in Table 7.

[0416] Exemplarily, by parsing the authentication_id in the CEI extended information, the first authentication identifier of each data unit in a group of data units can be obtained.

[0417] Exemplarily, parse the hash_type in the CEI extended information; according to the value of the parsed hash_type, determine the digest algorithm.

[0418] Exemplarily, parse the signature_type in the CEI extended information; according to the value of the parsed signature_type, determine the signature algorithm.

[0419] Refer to Figure 8A , exemplarily, the n first authentication identifiers are respectively: P1, P2, P3, P4,..., Pn.

[0420] S802. Calculate each data unit in a group of data units according to the digest algorithm to obtain the first digest data of each data unit in the group of data units.

[0421] Exemplarily, S802 can refer to the description of S602 above and will not be elaborated here.

[0422] Among them, the difference between S802 and S602 is that in a possible way of S802, the digest algorithm can be determined according to the hash_type parsed from the CEI extended information of the bitstream.

[0423] S803. Obtain authentication data from the bitstream. The authentication data includes: signature data, the second authentication identifier of each data unit in a group of data units, and the second digest data of each data unit in a group of data units. The signature data is obtained by signing the second digest data of each data unit in a group of data units.

[0424] Exemplarily, S803 can refer to the description of S603 above and will not be elaborated here.

[0425] S804, verify the signature data according to the public key, the first digest data of each data unit in a set of data units, and the signature algorithm.

[0426] Exemplarily, S804 can refer to the description of S604 above and will not be elaborated here.

[0427] Among them, the difference between S804 and S604 is that in one possible way of S804, the signature algorithm can be determined according to the signature_type parsed from the CEI extension information of the bitstream. And, since the camera_idc is not included in the CEI extension information of the bitstream; furthermore, S804 does not include the method of determining the public key according to the camera_idc.

[0428] S805, when the verification of the signature data is successful, store the authentication data in the authentication data list.

[0429] S806, search for the authentication data in the authentication data list that matches multiple first authentication identifiers of a set of data units; among them, the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of the set of data units.

[0430] S807, verify the multiple first digest data of a set of data units according to the multiple second digest data in the matching authentication data.

[0431] Exemplarily, S805 to S807 can refer to the descriptions of S605 to S607 above and will not be elaborated here.

[0432] Figure 9 It is a schematic diagram of the exemplary signature process 900 shown. Among them, the process 900 can be implemented by the signature end 210. The process 900 is a process in which the SVAC signature end realizes the signature of data units by carrying authentication identifiers through the NAL header.

[0433] Exemplarily, when video image authentication needs to be supported, a security parameter set RBSP is generated; the definition of the security parameter set RBSP can be as shown in Table 11 below:

[0434] Table 11 Definition of the security parameter set RBSP

[0435]

[0436]

[0437] Among them, the descriptions of the syntax elements in Table 11 can refer to the descriptions of the syntax elements in Table 6 above, and will not be elaborated here.

[0438] It should be noted that compared with the prior art, the present application newly adds in the security parameter set: authentication_mode (which can be called the first identifier).

[0439] Exemplarily, the authentication_flag in the security parameter set RBSP can also be set to 1, so that it can indicate that a group of data units located after the security parameter set RBSP supports authentication.

[0440] It should be noted that hash_type, signature_type, and camera_idc in the security parameter set RBSP are optional.

[0441] S901, generate a NAL unit.

[0442] Exemplarily, the NAL unit syntax table can be as shown in Table 12:

[0443] Table 12 NAL unit syntax table

[0444]

[0445] Authentication sequence number authentication_id

[0446] Binary variable. The authentication_idc value of '1' represents the authentication sequence number, which is used to identify the authentication data set it uses.

[0447] Authentication enable flag authentication_idc

[0448] Binary variable. Indicates whether the NAL unit is authenticated. The value of '0' indicates that the NAL unit is not authenticated, and the value of '1' indicates that the NAL unit is authenticated by the authentication method specified in the security parameter set.

[0449] Temporal layer identifier temporal_id

[0450] 3-bit unsigned integer. Indicates the temporal layer where the NAL unit is located.

[0451] It should be noted that compared with the prior art, in the NAL units included in the data units of the present application, a new authentication_id (which can also be called the authentication identifier) is added.

[0452] Exemplarily, during the process of generating the NAL unit, the value of authentication_idc can be set to 1; in this way, it can be indicated that the NAL unit needs to be authenticated.

[0453] S902, calculate each data unit in a group of data units according to the digest algorithm to obtain the digest data of each data unit in the group of data units.

[0454] Exemplarily, the number of data units to be authenticated can be determined according to the authentication_id obtained from the NAL unit; that is, the number of data units included in a group of data units.

[0455] For example, if the authentication_id is obtained from 100 NAL units and these 100 authentication_ids are all different, it can be determined that each data unit includes one NAL unit, and a group of data units includes 100 data units.

[0456] For another example, if the authentication_id is obtained from 100 NAL units and every 10 of these 100 authentication_ids are the same, it can be determined that each data unit includes 10 NAL units, and a group of data units includes 10 data units.

[0457] S903, concatenate the digest data of each data unit in a group of data units to determine the digest data of the concatenated digest data of each data unit in the group of data units.

[0458] S904, sign the digest data of the concatenated digest data of each data unit in a group of data units with a private key to obtain signature data.

[0459] S905, encode the authentication data and add the encoded authentication data to the bitstream.

[0460] Exemplarily, S902 to S905 can refer to the descriptions of the above S502 to S505 and will not be elaborated here.

[0461] Among them, the definition of the authentication data RBSP can refer to Table 6 above and will not be elaborated here.

[0462] In addition, in the scenario of temporal SVC coding of the SVAC standard, each data unit includes a second identifier (temporal_id) for identifying the temporal layer in which the data unit is located; correspondingly, the authentication data RBSP may also include the second identifier (temporal_id). Since in the scenario of temporal SVC coding of the SVAC standard, the temporal base layer (i.e., the data unit with the second identifier being 0) needs to be parsed, in order to ensure that the authentication data can be obtained regardless of whether the temporal enhancement layer is parsed during the authentication process; the value of the second identifier in the NAL unit of the authentication data can be set to 0.

[0463] In the scenario of spatial SVC coding or quality SVC coding of the SVAC standard, each data unit includes a third identifier (layer_id) for identifying the spatial layer or quality coding layer in which the data unit is located; correspondingly, the authentication data RBSP may also include the third identifier (layer_id). Since in the scenario of spatial SVC coding or quality SVC coding of the SVAC standard, the spatial base layer / quality coding base layer (i.e., the data unit with the third identifier being 0) needs to be parsed, in order to ensure that the authentication data can be obtained regardless of whether the spatial enhancement layer / quality coding enhancement layer is parsed during the authentication process; the value of the third identifier in the NAL unit of the authentication data can be set to 0.

[0464] In process 900, the public key can also be added to the authentication data. It should be understood that the public key corresponding to the above private key can also be transmitted in other ways, such as being built into the authentication end and transmitted to the authentication end in a certificate, etc., and this application does not limit this.

[0465] Figure 10A It is a schematic diagram of the authentication process shown exemplarily.

[0466] Figure 10B It is a schematic diagram of the exemplary authentication process 1000. Among them, process 1000 can be implemented by the authentication end 220. Process 1000 is a process for the SVAC authentication end to authenticate data units when carrying an authentication identifier in the NAL header.

[0467] Exemplarily, after the authentication end 220 receives the security parameter set RBSP of the bitstream, when the authentication_flag in the security parameter set RBSP of the bitstream is 1, it is determined that the subsequent group of data units supports authentication. At this time, the syntax elements in the security parameter set RBSP can be continuously parsed in the order of each syntax element in Table 1.

[0468] Exemplarily, parse the hash_mode in the security parameter set RBSP; when it is parsed that the hash_mode is 0, S602 can be executed.

[0469] Exemplarily, parse hash_type in the RBSP of the security parameter set; determine the digest algorithm according to the value of hash_type obtained by parsing.

[0470] Exemplarily, parse signature_type in the RBSP of the security parameter set; determine the signature algorithm according to the value of signature_type obtained by parsing.

[0471] Exemplarily, parse camera_idc in the RBSP of the security parameter set; determine the authentication certificate identifier of the camera from which the video stream corresponding image is sourced according to the value of camera_idc obtained by parsing.

[0472] S1001, obtain the first authentication identifier of the NAL unit from the NAL units of the video stream.

[0473] Exemplarily, when the authentication end 220 receives the NAL unit, parse authentication_idc parsed from the NAL unit; when authentication_idc is 1, continue to parse the NAL unit to obtain the first authentication identifier in the NAL unit.

[0474] S1002, calculate each data unit in a group of data units according to the digest algorithm to obtain the first digest data of each data unit in the group of data units.

[0475] Exemplarily, S1002 can refer to the description of S602 above and will not be elaborated here.

[0476] Exemplarily, the present application does not limit the execution order of S1001 and S1002.

[0477] S1003, obtain authentication data from the video stream, where the authentication data includes: signature data, the second authentication identifier of each data unit in a group of data units, and the second digest data of each data unit in the group of data units, and the signature data is obtained by signing the second digest data of each data unit in the group of data units.

[0478] S1004, verify the signature data according to the public key, the first digest data of each data unit in a group of data units, and the signature algorithm.

[0479] S1005, when the verification of the signature data is successful, store the authentication data in the authentication data list.

[0480] S1006, search for the authentication data in the authentication data list that matches the multiple first authentication identifiers of a group of data units; where the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of the group of data units.

[0481] S1007. Verify multiple first digest data of a set of data units based on multiple second digest data in the matched authentication data.

[0482] Exemplarily, S1003 - S807 can refer to the descriptions of S603 - S607 above and will not be elaborated here.

[0483] It should be understood that in one possible way, both the security parameter set and the NAL units included in the data units include an authentication identifier. In one possible way, both the diffusion information and the NAL units included in the data units include an authentication identifier. In one possible way, both the security parameter set and the extended information include an authentication identifier.

[0484] Figure 11 Schematic diagram of the signature device for the bitstream shown by way of example. The schematic diagram of the signature device for the bitstream can be used to execute the method of the foregoing embodiments. Therefore, the beneficial effects it can achieve can refer to the beneficial effects in the corresponding method provided above and will not be elaborated here.

[0485] Among them, the bitstream includes: a set of data units and the authentication identifier of each data unit in the set of data units.

[0486] Refer to Figure 11 , the signature device 1100 of the bitstream may include:

[0487] The first authentication data acquisition module 1101 is used to acquire authentication data; among them, the authentication data includes: signature data, the authentication identifier of each data unit in a set of data units, and the digest data of each data unit in a set of data units. The signature data is obtained by signing the digest data of each data unit in a set of data units.

[0488] The addition module 1102 is used to add the authentication data to the bitstream.

[0489] Exemplarily, the signature device 1100 of the bitstream further includes:

[0490] The digest data calculation module is used to calculate each data unit in a set of data units according to the digest algorithm to obtain the digest data of each data unit in a set of data units.

[0491] Exemplarily, the digest data calculation module is further used to concatenate the digest data of each data unit in a set of data units and determine the digest data of the concatenated digest data.

[0492] The signature device 1100 of the bitstream further includes:

[0493] A signature module, which is used to sign the digest data of the concatenated digest data by using a private key to obtain signature data.

[0494] Exemplarily, the signature device 1100 of the bitstream further includes:

[0495] An authentication data generation module, which is used to generate authentication data according to the signature data, the authentication identifier of each data unit in a group of data units, and the digest data of each data unit in a group of data units.

[0496] Exemplarily, the adding module 1102 is specifically used to encode the authentication data and add the encoded authentication data to the bitstream.

[0497] Exemplarily, each data unit in a group of data units includes one or more network abstraction layer NAL units.

[0498] Exemplarily, multiple NAL units in a group of data units are correlated with each other according to a specified rule, and the decoding order of multiple NAL units in a group of data units is continuous. That is to say, one data unit is one access unit

[0499] Exemplarily, each data unit in a group of data units includes an encoded image.

[0500] Exemplarily, each NAL unit includes the authentication identifier of the data unit to which it belongs.

[0501] Exemplarily, the authentication identifier of each data unit in a group of data units in the bitstream is located before the group of data units.

[0502] Exemplarily, the bitstream further includes a security parameter set, and the security parameter set includes the authentication identifier of each data unit in a group of data units.

[0503] Exemplarily, the bitstream further includes extended information, and the extended information includes the authentication identifier of each data unit in a group of data units.

[0504] Exemplarily, the bitstream further includes a first identifier, and the first identifier indicates the authentication mode adopted by a group of data units.

[0505] Exemplarily, the bitstream further includes a security parameter set, and the security parameter set includes the first identifier.

[0506] Exemplarily, the bitstream further includes an NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein, the second identifier indicates the time domain level, and the value of the second identifier is 0.

[0507] Exemplarily, the bitstream further includes NAL units of authentication data, and the NAL units of authentication data include a third identifier; wherein, the third identifier indicates a spatial layer or a quality coding layer, and the value of the third identifier is 0.

[0508] Figure 12 FIG. is a schematic diagram of an authentication device for an exemplary bitstream. The schematic diagram of the authentication device for the bitstream can be used to execute the method of the foregoing embodiments. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be elaborated here.

[0509] Referring to Figure 12 , the authentication device 1200 of the bitstream includes:

[0510] An authentication identifier acquisition module 1201, configured to acquire a first authentication identifier of each data unit in a set of data units from the bitstream;

[0511] A digest data determination module 1202, configured to determine first digest data of each data unit in a set of data units;

[0512] A second authentication data acquisition module 1203, configured to acquire authentication data from the bitstream, where the authentication data includes: signature data, a second authentication identifier of each data unit in a set of data units, and second digest data of each data unit in a set of data units, and the signature data is obtained by signing the second digest data of each data unit in a set of data units;

[0513] An authentication data storage module 1204, configured to store the authentication data in an authentication data list when the verification of the signature data is successful;

[0514] An authentication data search module 1205, configured to search for authentication data matching multiple first authentication identifiers of a set of data units from the authentication data list; wherein, the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of the set of data units;

[0515] A verification module 1206, configured to verify multiple first digest data of a set of data units according to multiple second digest data in the matching authentication data.

[0516] Exemplarily, the digest data determination module 1202 is specifically configured to calculate each data unit in a set of data units according to a digest algorithm to obtain first digest data of each data unit in the set of data units.

[0517] Exemplarily, the authentication device 1200 of the bitstream further includes:

[0518] A public key acquisition module, configured to acquire a public key;

[0519] The summary data determination module 1202 is further configured to connect the second summary data of each data unit in a group of data units, and determine the summary data of the connected second summary data;

[0520] The verification module 1206 is further configured to verify the signature data according to the public key, the summary data of the connected second summary data, and the signature algorithm.

[0521] Exemplarily, the bitstream authentication device 1200 further includes:

[0522] An identification acquisition module, configured to acquire a first identification from the bitstream, where the first identification indicates an authentication mode adopted by a group of data units;

[0523] When the value of the first identification is a first preset value, the summary data determination module is configured to determine the first summary data of each data unit in a group of data units.

[0524] Exemplarily, the identification acquisition module is further configured to acquire a fourth identification from the bitstream, and determine a value n according to the fourth identification; where a group of data units includes n data units, and n is a positive integer;

[0525] Exemplarily, the bitstream authentication device 1200 further includes:

[0526] A summary data acquisition module, configured to acquire the second summary data of each of the n data units from the bitstream.

[0527] Exemplarily, each data unit in a group of data units includes one or more network abstraction layer (NAL) units.

[0528] Exemplarily, multiple NAL units in a group of data units are correlated with each other according to a specified rule, and the decoding order of multiple NAL units in a group of data units is continuous. That is, one data unit is one access unit

[0529] Exemplarily, each data unit in a group of data units includes an encoded image.

[0530] Exemplarily, the verification module 1206 is specifically configured to, for a first data unit in a group of data units: if, among multiple second summary data in the matching authentication data, a second summary data identical to the first summary data of the first data unit is found, it is determined that the authentication of the first data unit is successful; otherwise, it is determined that the authentication of the first data unit fails.

[0531] In one example, Figure 13 FIG. shows a schematic block diagram of a device 1300 according to an embodiment of the present application. The device 1300 may include: a processor 1301 and a transceiver / transceiver pin 1302. Optionally, it further includes a memory 1303.

[0532] Each component of the device 1300 is coupled together via a bus 1304, which, in addition to a data bus, includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, all kinds of buses are referred to as bus 1304 in the figure.

[0533] Optionally, the memory 1303 can be used to store the instructions in the foregoing method embodiments. The processor 1301 can be used to execute the instructions in the memory 1303, control the receiving pin to receive signals, and control the transmitting pin to transmit signals.

[0534] The device 1300 can be the electronic device or the chip of the electronic device in the foregoing method embodiments.

[0535] Among them, all relevant contents of the steps involved in the foregoing method embodiments can be cited in the function descriptions of the corresponding functional modules, and will not be elaborated here.

[0536] An embodiment of the present application further provides a chip, including one or more interface circuits and one or more processors; the one or more processors receive or send data through the one or more interface circuits, and when the one or more processors execute computer instructions, the relevant method steps described above are executed to implement the steps of the method in the foregoing embodiments. Among them, the interface circuit is the transceiver / transceiving pin 1302.

[0537] This embodiment further provides a computer-readable storage medium, in which computer instructions are stored. When the computer instructions run on an electronic device, the electronic device is enabled to execute the relevant method steps to implement the method in the foregoing embodiments.

[0538] This embodiment further provides a computer program product, which includes computer instructions. When the computer instructions are executed by a computer or a processor, the computer is enabled to execute the relevant steps to implement the method in the foregoing embodiments.

[0539] In addition, an embodiment of the present application further provides a device, which can specifically be a chip, a component or a module. The device may include a processor and a memory connected to each other; among them, the memory is used to store computer execution instructions. When the device runs, the processor can execute the computer execution instructions stored in the memory to enable the chip to execute the methods in the foregoing method embodiments.

[0540] Among them, the electronic device, the computer-readable storage medium, the computer program product or the chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be elaborated here.

[0541] Through the description of the above embodiments, those skilled in the art can understand that for the convenience and conciseness of description, only the division of the above functional modules is used as an example. In actual applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

[0542] In several embodiments provided in the present application, it should be understood that the disclosed device and method can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in electrical, mechanical or other forms.

[0543] The units described as separate components may or may not be physically separated. The components displayed as units may be one physical unit or multiple physical units, that is, they can be located in one place or distributed to multiple different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0544] In addition, in each embodiment of the present application, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0545] Any content of each embodiment of the present application, as well as any content of the same embodiment, can be freely combined. Any combination of the above content is within the scope of the present application.

[0546] When an integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions for causing a device (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods of the various embodiments of the present application. The aforementioned storage medium includes: USB flash drives, mobile hard disks, read-only memories (ROM), random access memories (RAM), magnetic disks, or optical discs, etc., all kinds of media that can store program codes.

[0547] The steps of the methods or algorithms described in combination with the disclosed content of the embodiments of the present application can be implemented in a hardware manner or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in a random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, compact disc read-only memories (CD-ROMs), or any other form of storage medium well-known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0548] Those skilled in the art should be able to realize that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented by hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. The computer-readable medium includes computer-readable storage media and communication media, where the communication media includes any medium facilitating the transmission of a computer program from one place to another. The storage medium can be any available medium accessible by a general-purpose or special-purpose computer.

[0549] The embodiments of the present application have been described above in conjunction with the accompanying drawings. However, the present application is not limited to the above specific embodiments. The above specific embodiments are merely illustrative rather than restrictive. Under the inspiration of the present application, those of ordinary skill in the art can also make many forms without departing from the purpose of the present application and the scope protected by the claims, and all of them fall within the protection scope of the present application.

Claims

1. A method for signing a bitstream, characterized in that, the bitstream includes: a set of data units and an authentication identifier for each data unit in the set of data units, and the method includes: obtaining authentication data; wherein, the authentication data includes: signature data, an authentication identifier for each data unit in the set of data units, and digest data for each data unit in the set of data units, and the signature data is obtained by signing the digest data for each data unit in the set of data units; adding the authentication data to the bitstream.

2. The method according to claim 1, characterized in that, the method further includes: calculating, according to a digest algorithm, each data unit in the set of data units to obtain the digest data for each data unit in the set of data units.

3. The method according to claim 2, characterized in that, the digest algorithm is the digest algorithm indicated by the hash type hash_type, and the hash_type is parsed from the security parameter set RBSP of the bitstream.

4. The method according to any one of claims 1 to 3, characterized in that, the method further includes: concatenating the digest data for each data unit in the set of data units, and determining the digest data of the concatenated digest data.

5. The method according to claim 4, characterized in that, the method further includes: signing the digest data of the concatenated digest data to obtain the signature data.

6. The method according to any one of claims 1 to 5, characterized in that, the method further includes: generating the authentication data according to the signature data, the authentication identifier for each data unit in the set of data units, and the digest data for each data unit in the set of data units.

7. The method according to any one of claims 1 to 6, characterized in that, the authentication data includes a digest data list, and the digest data list is composed of the digest data for each data unit in the set of data units.

8. The method according to any one of claims 1 to 7, characterized in that, each data unit in the set of data units includes one or more network abstraction layer NAL units.

9. The method according to claim 8, characterized in that, the NAL unit includes an authentication enable flag authentication_idc, and the authentication_idc is used to indicate whether the NAL unit supports authentication.

10. The method according to claim 8 or 9, characterized in that, each NAL unit includes the authentication identifier of the data unit to which it belongs.

11. The method according to any one of claims 1 to 10, characterized in that, the bitstream further includes a first identifier, and the first identifier indicates the authentication mode adopted by the set of data units.

12. The method according to claim 11, characterized in that, the bitstream further includes a security parameter set, and the security parameter set includes the first identifier.

13. The method according to any one of claims 1 to 12, characterized in that, The bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein, the second identifier is a temporal_id for indicating a temporal level, and the value of the temporal_id is 0.

14. The method according to any one of claims 1 to 13, characterized in that the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a third identifier; wherein, the third identifier is a layer_id for indicating a spatial level, and the value of the layer_id is 0.

15. A bitstream, characterized in that the bitstream includes: a set of data units, authentication data, and an authentication identifier for each data unit in the set of data units; wherein, the authentication data includes: signature data, an authentication identifier for each data unit in the set of data units, and digest data for each data unit in the set of data units, and the signature data is obtained by signing the digest data for each data unit in the set of data units.

16. The bitstream according to claim 15, characterized in that the authentication data includes a list of digest data, and the list of digest data is composed of the digest data for each data unit in the set of data units.

17. The bitstream according to claim 15 or 16, characterized in that each data unit in the set of data units includes one or more Network Abstraction Layer (NAL) units.

18. The bitstream according to claim 17, characterized in that the NAL unit includes an authentication enable flag authentication_idc, and the authentication_idc is used to indicate whether the NAL unit supports authentication.

19. The bitstream according to claim 17 or 18, characterized in that each NAL unit includes an authentication identifier of the data unit to which it belongs.

20. The bitstream according to any one of claims 15 to 19, characterized in that the bitstream further includes a first identifier, and the first identifier indicates the authentication mode adopted by the set of data units.

21. The bitstream according to claim 20, characterized in that the bitstream further includes a set of security parameters, and the set of security parameters includes the first identifier.

22. The bitstream according to any one of claims 15 to 21, characterized in that the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein, the second identifier is a temporal_id for indicating a temporal level, and the value of the temporal_id is 0.

23. The bitstream according to any one of claims 15 to 22, characterized in that the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a third identifier; wherein, the third identifier is a layer_id for indicating a spatial level, and the value of the layer_id is 0.

24. The bitstream according to any one of claims 15 to 22, characterized in that The authentication data further includes a fourth identifier, and the fourth identifier is used to determine the number of digest data included in the authentication data.

25. A method for authenticating a bitstream, characterized in that, the method includes: obtaining a first authentication identifier for each data unit in a set of data units from the bitstream; determining first digest data for each data unit in the set of data units; the first digest data corresponds to the first authentication identifier; obtaining authentication data from the bitstream, the authentication data includes: signature data, a second authentication identifier for each data unit in the set of data units, and second digest data for each data unit in the set of data units, and the signature data is obtained by signing according to the second digest data for each data unit in the set of data units; determining that the signature data verification is successful; in response to the multiple first authentication identifiers of the set of data units being respectively the same as the multiple second authentication identifiers in the authentication data, verifying the multiple first digest data of the set of data units according to the multiple second digest data in the authentication data.

26. The method according to claim 25, characterized in that, the determining the first digest data for each data unit in the set of data units includes: calculating each data unit in the set of data units according to a digest algorithm to obtain the first digest data for each data unit in the set of data units.

27. The method according to claim 26, characterized in that, the digest algorithm is the digest algorithm indicated by the hash type hash_type, and the hash_type is parsed from the security parameter set RBSP of the bitstream.

28. The method according to any one of claims 25 to 27, characterized in that, the method further includes: concatenating the second digest data for each data unit in the set of data units, and determining the digest data of the concatenated second digest data.

29. The method according to claim 28, characterized in that, the method further includes: verifying the signature data according to the digest data of the concatenated second digest data.

30. The method according to any one of claims 25 to 28, characterized in that, the authentication data includes a digest data list, and the digest data list is composed of the second digest data for each data unit in the set of data units.

31. The method according to any one of claims 25 to 30, characterized in that, the method further includes: obtaining a first identifier from the bitstream, and the first identifier indicates the authentication mode adopted by the set of data units; when the value of the first identifier is a first preset value, performing the step of determining the first digest data for each data unit in the set of data units.

32. The method according to claim 31, characterized in that, the bitstream further includes a security parameter set, and the security parameter set includes the first identifier.

33. The method according to any one of claims 25 to 32, characterized in that, the method further includes: Obtain a fourth identifier from the bitstream, and determine a value n according to the fourth identifier; wherein, the set of data units includes n data units, and n is a positive integer; Obtain the second digest data of each data unit among the n data units from the bitstream.

34. The method according to any one of claims 25 to 33, characterized in that each data unit in the set of data units includes one or more Network Abstraction Layer (NAL) units.

35. The method according to claim 34, characterized in that the NAL unit includes an authentication enable flag authentication_idc, and the authentication_idc is used to indicate whether the NAL unit supports authentication.

36. The method according to claim 34 or 35, characterized in that each NAL unit includes a second authentication identifier of the data unit to which it belongs.

37. The method according to any one of claims 25 to 36, characterized in that the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein, the second identifier is temporal_id, which is used to indicate the temporal level, and the value of the temporal_id is 0.

38. The method according to any one of claims 25 to 37, characterized in that the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a third identifier; wherein, the third identifier is layer_id, which is used to indicate the spatial level, and the value of the layer_id is 0.

39. The method according to any one of claims 25 to 38, characterized in that verifying the multiple first digest data of the set of data units according to the multiple second digest data in the authentication data includes: For the first data unit in the set of data units; if a second digest data identical to the first digest data of the first data unit is found among the multiple second digest data in the authentication data, it is determined that the authentication of the first data unit is successful; otherwise, it is determined that the authentication of the first data unit fails.

40. A signature device for a bitstream, characterized in that it includes a module for executing the signature method of the bitstream according to any one of claims 1 to 14.

41. An authentication device for a bitstream, characterized in that it includes a module for executing the authentication method of the bitstream according to any one of claims 25 to 39.

42. An electronic device, characterized in that it includes: a memory and a processor, the memory is coupled to the processor; The memory stores program instructions, and when the program instructions are executed by the processor, the electronic device executes the signature method of the bitstream according to any one of claims 1 to 14, or executes the authentication method of the bitstream according to any one of claims 25 to 39.

43. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when running on a computer or a processor, causes the computer or the processor to execute the method according to any one of claims 1 to 14, or to execute the method according to any one of claims 25 to 39.

44. A computer program product, characterized in that the computer program product includes computer instructions, which, when executed by a computer or a processor, cause the steps of the method according to any one of claims 1 to 14 to be executed, or cause the steps of the method according to any one of claims 25 to 39 to be executed.

45. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a bitstream according to any one of claims 15 to 24.

Images