Patent Description:
A digital signature provides a layer of validation and security to a digital message, such as a video sequence comprising encoded image frames, that is transmitted through a non-secure channel from a transmitter to a receiver. The transmitter may generate the digital signature by encrypting, using a private encryption key of a private-public encryption key pair, one or more cryptographic hash values of the video sequence. The cryptographic hash values may be frame-wise cryptographic hash values, wherein each cryptographic hash value may be a hash value of a respective encoded image frame's image data, or a hash value of that encoded image frame's image data in combination with optional further information. Usually both the generated digital signature and the frame-wise cryptographic hash values used to generate the digital signature are provided to the video sequence by the transmitter before transmitting the video sequence to the receiver.

To validate that a received video sequence is an authentic video sequence from an alleged transmitter and that the received video sequence has not been manipulated, a receiver needs to verify both the digital signature and the received encoded image frames.

To verify a received digital signature, the receiver of the video sequence decrypts the received digital signature using a public key of the transmitter's private-public encryption key pair and compares the decrypted received digital signature with the received one or more cryptographic hash values. If the decrypted received digital signature is equal to, e.g., matches, the received cryptographic hash values, the received digital signature is verified. Thereby, it is verified that the video sequence received by the receiver was digitally signed by the alleged transmitter.

In addition to the verification of the digital signature, the receiver needs to verify that the video sequence received is the same as the video sequence transmitted by the transmitter. One way of verifying a sequence of received encoded image frames is for the receiver to generate cryptographic hash values of the encoded image frames in the received video sequence in the same way as the transmitter generated the cryptographic hash values. Thus, there is an agreement between the transmitter and the receiver on how to generate cryptographic hash values. Once the receiver has generated the cryptographic hash values, the receiver compares its generated cryptographic hash values with the received cryptographic hash values, and if they are the same, e.g., match each other, the received video sequence has been verified as the same as the transmitted video sequence.

However, by adding the digital signature and especially, by adding the cryptographic hash values to the video sequence, the bitrate required for transmitting the video sequence increases. As available bitrate may be a limiting factor when transmitting video sequences over the communication channel there is a need to reduce the bitrate required for transmitting the digital signature and the cryptographic hash values without sacrificing or deteriorating the ability for a receiver to validate the video sequence.

In view of the above, it is thus an objective of the present invention to mitigate drawbacks with the prior art and to enable validation of a video sequence with a reduction in the required bitrate for transmitting the video sequence and additional data needed for the validation as compared to the prior art. A further objective is to reduce the size of the additional data thereby decreasing the required bitrate for transmission. A yet further objective is to provide the video sequence with the additional data as a data structure and a digital signature which data structure and a digital signature enable the video sequence to be validated and at the same time require reduced amount of available bitrate resources for transmission. A still further objective is to propose a transmitter and computer program with these capabilities. A further objective is to perform validation of the video sequence provided with the data structure and the digital signature. A yet further objective is to propose a receiver and computer program with these capabilities.

At least some of these objectives are achieved by the invention as defined by the independent claims. The dependent claims relate to advantageous embodiments.

According to a first aspect of this disclosure, there is provided a method performed by a transmitter for enabling validation of a video sequence by providing the video sequence with a data structure and a digital signature, wherein the video sequence comprises encoded image frames.

The method comprises performing lossless compression of each encoded image frame of the video sequence to obtain a respective losslessly compressed (LC) encoded image frame.

Further, the method comprises, among the obtained LC encoded image frames, identifying one or more small LC encoded image frames each having a data size that is smaller than a predefined number of bytes.

Furthermore, the method comprises generating a data structure comprising the identified one or more small LC encoded image frames, and individual hashes of either: all encoded image frames lacking a respective small LC encoded image frame; or all other obtained LC encoded image frames being different from the one or more small LC encoded image frames. The individual hashes are obtained by individually hashing each one of the all encoded image frames lacking a respective small LC encoded image frame, or by individually hashing each one of the all other obtained LC encoded image frame, respectively.

Yet further the method comprises generating a digital signature for the video sequence; and providing the data structure and the digital signature to the video sequence. Thereby enabling a receiver to validate the video sequence.

By performing lossless compression and by including the identified small LC encoded image frames in the data structure instead of respective hashes, the size of the data structure can be reduced without compromising with the data structure's usefulness when validating the video sequence.

In this disclosure the term "data structure" should be understood as any structure, element, or unit configured to be provided to the video sequence and configured to comprise information as a text sequence of text, as a binary sequence, i.e., a bitstream, as a sequence of bytes, i.e., a byte stream, or as a combination thereof, just to give some examples. The data structure is sometimes referred to as a document. The data structure is configured to comprise one or more small LC encoded image frames and one or more individual hashes. The data structure may also comprise metadata, i.e., data that may relate to information comprised in the data structure. Thus, the metadata may relate to the one or more small LC encoded image frames and/or to the one or more individual hashes. As will be described below, sometimes the data structure comprises information about the location and optionally also the size of one or more small LC encoded image frames. Hence, the location and the size are two examples of metadata that can be comprised in the data structure. Another example of metadata is the type of the small LC encoded image frame. As will be described below, the small LC encoded image frame may be of a first type or of a second type, and consequently this information may be comprised in the data structure as metadata.

As used herein "a digital signature" is meant a digital code which is provided to the transmitted video sequence to verify the transmitter's identity. The digital code is generated and authenticated by private/public key encryption. In more detail, the transmitter generates the digital code using a private key of an encryption key pair of the transmitter and a receiver authenticates the digital code using a public key of the transmitter's encryption key pair.

By the expression "performing lossless compression of each encoded image frame" when used herein is meant compressing each encoded image frame, without loss of image information, into a compressed encoded image frame. The compressed encoded image frame may have a data size that is equal to or smaller than the encoded image frame. Sometimes, the compressed encoded image frame has a data size that is larger than the encoded image frame, in such case the encoded image frame may be used as the compressed encoded image frame. In other cases, the lossless compression may result in a compressed encoded image frame comprising a reference to another encoded image frame. The another encoded image frame may be a previous encoded image frame in the video sequence or a stored encoded image frame. Importantly, no image information is lost when performing the lossless compression. As no image information is lost in the lossless compression, the original encoded image frame can be perfectly reconstructed from the compressed encoded image with no loss in image quality. The action of reconstructing the original encoded image frame from the compressed encoded image frame may be referred to as decompressing the compressed encoded image frame into the originally encoded image frame. The compressed encoded image frame is in this disclosure referred to as a losslessly compressed (LC) encoded image frame.

Some examples of lossless compression algorithms are Huffman coding, arithmetic encoding, codebook-based encoding and run-length encoding. A device performing the lossless compression as described above is herein referred to as a lossless compressing module configured to perform lossless compression of encoded image frames.

In this disclosure "a losslessly compressed (LC) encoded image frame" is meant an image frame resulting from lossless compression of an encoded image frame.

By the expression "individually hashing an encoded image frame" is meant applying a hash function (or one-way function) to each individual encoded image frame to obtain an individual hash. The hash function may be a cryptographic hash function that provides a safety level considered adequate in view of the sensitivity of the video sequence to be signed and/or in view of the value at stake if the video sequence is manipulated by an unauthorized party. Three examples of hash functions are Secure Hash Algorithm <NUM>-bit (SHA-<NUM>), Secure Hash Algorithm3 <NUM>-bit (SHA3-<NUM>) and Rivest-Shamir-Adleman <NUM>-bit (RSA-<NUM>). The hash function shall be predefined (e.g., it shall be reproducible) so that the individual hashes can be regenerated when the digital signature and/or data structure is to be verified by the receiver.

As used herein "an individual hash" is meant an individual cryptographic hash value obtained by applying a hash function to an individual encoded image frame or an individual LC encoded image frame.

According to a second aspect of this disclosure, there is provided a method performed by a receiver for validating a video sequence provided with a data structure and a digital signature, wherein the video sequence comprises encoded image frames.

The method comprises receiving, from a transmitter, the video sequence comprising encoded image frames and being provided with the data structure and the digital signature.

Further, the method comprises verifying the received digital signature using the received data structure; and verifying the received encoded image frames as being equal to the transmitted encoded image frames using the received data structure. Whereby the received video sequence is validated as being equal to the transmitted video sequence when the received digital signature and the received encoded image frames are verified.

According to a third aspect of this disclosure, there is provided a transmitter for enabling validation of a video sequence by providing the video sequence with a data structure and a digital signature, wherein the transmitter comprises processing circuitry configured to cause the transmitter to perform any of the actions of the method of the first aspect.

According to a fourth aspect of this disclosure, there is provided a receiver for validating a video sequence provided with a data structure and a digital signature, wherein the receiver comprises processing circuitry configured to cause the receiver to perform any of the actions of the method of the second aspect.

According to a fifth aspect of this disclosure, there is provided a non-transitory computer-readable medium having stored thereon computer code instructions adapted to carry out the method of the first aspect when executed by a device having processing capability.

According to a sixth aspect of this disclosure, there is provided a non-transitory computer-readable medium having stored thereon computer code instructions adapted to carry out the method of the second aspect when executed by a device having processing capability.

The second, third, fourth, fifth, and sixth aspects may generally have the same features and advantages as the first aspect.

The present disclosure further relates to a computer program containing instructions for causing a computer to carry out any one of the above methods. The computer program may be stored or distributed on a data carrier. As used herein, a "data carrier" may be a transitory data carrier, such as modulated electromagnetic or optical waves, or a non-transitory data carrier. Non-transitory data carriers include volatile and non-volatile memories, such as permanent and non-permanent storage media of magnetic, optical or solid-state type. Still within the scope of "data carrier", such memories may be fixedly mounted or portable.

The above, as well as additional objects, features and advantages of the present invention, will be better understood through the following illustrative and non-limiting detailed description of embodiments of the present invention, with reference to the appended drawings, where the same reference numerals will be used for similar elements, wherein:.

The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, on which certain embodiments of the invention are shown. These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of the invention to those skilled in the art.

To overcome or mitigate constrains in bitrate availability when transmitting a video sequence over a communications network and especially when transmitting the video sequence with additional data enabling validation of the video sequence, the present invention relates to the reduction in size of the additional data while not deteriorating the reliability of the validation. In this disclosure, the additional data is a data structure and a digital signature. Especially, the present invention relates to the reduction in size of the data structure by reducing the size of the data structure's content while keeping the validation reliable.

Before going into details on how to enable validation of the video sequence provided with the data structure and the digital signature, and on how to validate the video sequence, the components of a system wherein the present invention can be realised will be described.

With reference to <FIG>, embodiments of a system <NUM> for enabling validation of a video sequence and for validating the video sequence will be described. The system <NUM> comprises a transmitter <NUM> configured to enable validation of the video sequence. The transmitter <NUM> may comprise or may be connected to one or more cameras <NUM>. Alternatively, the transmitter <NUM> may be comprised in a camera <NUM>. The transmitter <NUM> and the one or more cameras <NUM> may be referred to as a camera system. The camera system may be comprised in one single unit, i.e., one unit comprising the transmitter <NUM> and one or more cameras <NUM>, or in several separate units. The camera <NUM> may be a monitoring camera, sometimes also referred to as surveillance camera. Further, the camera <NUM> may be a fixed camera such as a stationary camera, or a movable camera such as a pan, tilt and zoom (PTZ) camera. The camera <NUM> may be a visible light camera, a thermal camera, or a camera comprising both a visible light camera and a thermal camera. It should be noted that the camera <NUM> may include several components relating to e.g., image capturing such as a capturing module, and image processing such as an encoding module, which are common in conventional camera systems and whose purpose and operations are well known to those having ordinary skill in the art. Such components have been omitted from the illustration and description of <FIG> for clarity reasons.

As further illustrated in <FIG>, the transmitter <NUM> is configured to communicate over a communications network <NUM> with a receiver <NUM>. The communications network <NUM> may be a wired or wireless communications network over which the transmitter <NUM> transmits video sequences to the receiver <NUM>. The receiver <NUM> may comprise or may be connected to a display device <NUM> configured to display, to an operator, video sequences received by the receiver <NUM>. The transmitter <NUM> and the receiver <NUM> are configured to communicate with a data storage <NUM> either directly or via the communications network <NUM>. The data storage <NUM> may be configured to store data relating to video sequences such as data relating to encoded image frames and/or to LC encoded image frames. For example, the data storage <NUM> may comprise pre-defined encoded image frames 220e. The pre-defined encoded image frames 220e may be stored in the data storage <NUM> as a lookup table wherein each stored pre-defined encoded image frame 220e is identified by an identifier, sometimes referred to as an index or a key. In some embodiments the lookup table is a code book, and the index/key is a codeword. The data storage <NUM> may be a non-volatile memory. Further, the data storage may comprise a common library.

It should be understood that there are many combinations of wireless and wired transmission models that can be used for transmissions between the transmitter <NUM> and the communications network <NUM>, between the communications network <NUM> and the receiver <NUM>, and between the data storage <NUM>, the transmitter <NUM>, the communications network <NUM>, and the receiver <NUM>, and that <FIG> only illustrates one example.

<FIG> schematically illustrates an exemplifying video sequence <NUM> according to embodiments. The video sequence <NUM> comprises a number of encoded image frames <NUM>. An encoded image frame used as a reference for prediction-coding other frames is called a reference frame. Frames encoded without information from other frames are referred to as intra-coded frames, intra-frames, I-frames or key frames. Frames that use prediction from one or more reference frames are referred to as inter-coded frames or inter-frames. A P-frame is an inter-frame that uses prediction from one or more preceding reference frames (or one or more frames for prediction of each region) and a B-frame is an inter-frame that uses prediction from a (possibly weighted) average of two reference frames, one or more preceding frames and/or one or more succeeding frames. A frame is sometimes referred to as a picture.

The encoded image frames <NUM> may be arranged in one or more groups of pictures (GOPs). In <FIG>, the encoded image frames <NUM> are arranged in a plurality of GOPs out of which a first GOP 210a and a second GOP 210b are illustrated. As schematically illustrated in the exemplifying video sequence <NUM>, the first GOP 210a consists of a first I-frame I0, a first P-frame P00, a second P-frame P01, and a third P-frame P02; and the second GOP 210b consists of a first I-frame <NUM>, a first P-frame P10, a second P-frame P11, and a third P-frame P12.

There are a number of conventional video encoding protocols. Some common video encoding protocols that work with the various embodiments of the present invention include: High Efficiency Video Coding (HEVC), also known as H. <NUM> and MPEG-H Part <NUM>; Advanced Video Coding (AVC), also known as H. <NUM> and MPEG-<NUM> Part <NUM>; Versatile Video Coding (VVC), also known as H. <NUM>, MPEG-I Part <NUM> and Future Video Coding (FVC); VP9, VP10 and AOMedia Video <NUM> (AV1), just to give some examples.

A method performed by the transmitter <NUM> for enabling validation of a video sequence <NUM> by providing the video sequence <NUM> with a data structure <NUM> and a digital signature <NUM>, will now be described with reference to the flowchart of <FIG> and with reference to <FIG> schematically illustrating the transmitter <NUM> according to embodiments. Reference will also be made to <FIG> schematically exemplifying a sequence of encoded image frames, a sequence of corresponding LC encoded image frames and two examples of the data structure content according to embodiments.

As previously mentioned, the video sequence <NUM> comprises encoded image frames <NUM>, and the video sequence <NUM> may be composed of at least one group of pictures (GOPs) 210a, 210b. As illustrated in <FIG>, the sequence of encoded image frames may comprise the encoded image frames I0, P00, P01, P02, I1, P10, P11, P12, P13, and I2, wherein the encoded image frames I0, P00, P01, and P02 may be comprised in one GOP, the encoded image frames I1, P10, P11, P12, and P13 may be comprised in another GOP, and the encoded image frame I2 may be comprised in yet another GOP.

The encoded image frames <NUM> of the video sequence <NUM> may have been obtained from the camera <NUM> that captured a number of image frames depicting a scene and that encoded the captured image frames into the encoded image frames <NUM>. The camera <NUM> may provide an obtaining module <NUM> of the transmitter <NUM> with the encoded image frames <NUM>. In cases wherein the camera <NUM> is comprised in the transmitter <NUM> (then referred to as the camera system <NUM>), the camera <NUM> realises the obtaining module of the transmitter <NUM>. In other cases, wherein the camera <NUM> is external of and connected to the transmitter <NUM>, the obtaining module <NUM> of the transmitter <NUM> could be realised by an internal data storage configured to receive encoded image frames <NUM> from the camera <NUM> and to store the received encoded image frames <NUM> in the internal data storage.

In step S502, the transmitter <NUM> performs lossless compression of each encoded image frame <NUM> of the video sequence <NUM> to obtain a respective LC encoded image frame 220LC. This is done to obtain a respective LC encoded image frame having a size that is equal to or less than the size of the encoded image frame <NUM> on which the lossless compression was performed while at the same time obtain the respective LC encoded image frame with the same image quality as the encoded image frame <NUM> on which the lossless compression was performed. As illustrated in <FIG>, the sequence of LC encoded image frames comprises the LC encoded image frames I0LC, P00LC, P01LC, P02LC, I1LC, P10LC, P11LC, P12LC, P13LC, and I2LC.

The lossless compression may be performed based on one or more out of Huffman coding, arithmetic encoding, codebook-based encoding and run-length encoding, just to give some examples. Step S502 may be performed by a lossless compressing module <NUM> comprised in the transmitter <NUM> and being configured to perform lossless compression of encoded image frames.

As mentioned above an aim of the lossless compression is to obtain a respective LC encoded image frame 220LC that has a data size that is equal to or less than the data size of its respective encoded image frame <NUM>. However, lossless compression will not always result in that the respective LC encoded image frame 220LC has an equal or reduced data size as compared to the data size of its respective encoded image frame <NUM>. Therefore, the lossless compressing module <NUM> compares the size of the respective LC encoded image frame 220LC with the size of its respective encoded image frame <NUM>, and if the respective LC encoded image frame 220LC has a larger size, the lossless compressing module <NUM> will output its respective encoded image frame <NUM> as the LC encoded image frame. An alternative way of reducing the size of the LC encoded image frame is to create the LC encoded image frame such that it lacks image information but comprises a reference to, and possibly a difference vis-à-vis, another encoded image frame, such as a stored predefined encoded image frame 220e. This may be the case when the transmitter <NUM> determines that the encoded image frame on which the lossless compression is performed is a skip frame.

By "a skip frame" is meant a type of an inter frame that represent image data by only referring (e.g., by only including references) to image data in other frames without any residual values. When decoding a skip frame, a decoder uses the referenced image data as a representation of the image data represented by the skip frame without making any adjustments (as residual values are lacking).

In step S504, the transmitter <NUM> identifies, among the obtained LC encoded image frames 220LC, one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> each having a data size that is smaller than a predefined number of bytes. The predefined number of bytes may be set in dependence on the hash function used. For example, the predefined number of bytes may be <NUM> bytes (<NUM> bits), <NUM> bytes (<NUM> bits) or <NUM> bytes (<NUM> bits) for SHA-<NUM> hashes, and <NUM> bytes (<NUM> bits) for SHA-<NUM> hashes. An identifying module <NUM> comprised in the transmitter <NUM> and being configured to identify the one or more small LC encoded image frames may perform step S504. The identifying module <NUM> may be comprised in the lossless compressing module <NUM>. Alternatively, the identifying module <NUM> may be comprised in a data structure generating module <NUM> of the transmitter <NUM>. The data structure generating module <NUM> will be described below.

One or more identified small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> may be of a first type of small LC encoded image frames 220LCb-<NUM> wherein each is either equal to the (original) encoded image frame <NUM> having a data size that is smaller than the predefined number of bytes and on which the lossless compression was performed, or equal to the LC encoded image frame 220LC of the (original) encoded image frame <NUM> when the LC encoded image frame 220LC is smaller than the (original) encoded image frame <NUM> and has a data size that is smaller than the predefined number of bytes.

The former may for example be the case when the lossless compression of the encoded image frame <NUM>, having a data size that is smaller than the predefined number of bytes, resulted in the same encoded image frame <NUM> or when the lossless compression of the encoded image frame <NUM> would result in an LC encoded image frame 220LC being larger than the encoded image frame <NUM>. As mentioned above, in this case the lossless compressing module <NUM> performing the lossless compression outputs the original encoded image frame <NUM> as the LC encoded image frame 220LCb-<NUM>.

Thus, in some embodiments, at least one of the identified one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> is a small LC encoded image frame 220LCb-<NUM> of a first type and is equal to its respective encoded image frame <NUM> or equal to the LC encoded image frame 220LC of the encoded image frame <NUM>.

Alternatively, or additionally, one or more identified small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> may be of a second type of small LC encoded image frame 220LCb-<NUM> wherein each is equal to a part of a stored encoded image frame 220e and comprises an identifier of the stored encoded image frame 220e and possibly also a difference.

This may be the case when the encoded image frame <NUM> on which the lossless compression was performed is identical with the stored encoded image frame 220e or is partly identical with the stored encoded image frame 220e. In case the encoded image frame is a skip frame, there is no difference between the stored encoded image frame 220e and the encoded image frame <NUM>, and consequently the small LC encoded image frame <NUM>LCb-<NUM> of the second type only comprises the identifier of the stored encoded image frame 220e and no difference.

However, the encoded image <NUM> frame may be partly identical with the stored encoded image frame 220e and then the small LC encoded image frame 220LCb-<NUM> of the second type may comprise the identifier of the stored encoded image frame 220e and the difference. The difference may relate to a part of an otherwise constant image frame that is updated or changed at certain time points. For example, the difference may relate to a counter, or a clock comprised in the encoded image frame <NUM>, and the difference is the only that make the encoded image frame <NUM> different from the stored encoded image frame 220e. In such case, the difference comprised in the small LC encoded image frame 220LCb-<NUM> of the second type relates to the counter value or the time of the clock.

Therefore, in some embodiments, at least one of the identified one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> is a small LC encoded image frame 220LCb-<NUM> of a second type and comprises an identifier of a stored predefined encoded image frame 220e and a possible difference between the small LC encoded image frame 220LCb-<NUM> of the second type and the stored predefined encoded image frame 220e.

In order to enable validation of the video sequence, a data structure <NUM> is needed. Therefore, in step S506, the transmitter <NUM> generates a data structure <NUM> that comprises the identified one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> and individual hashes. The individual hashes comprised in the data structure <NUM> may be generated in two ways. Firstly, the individually hashes may be individual hashes of all encoded image frames <NUM> lacking a respective small LC encoded image frame 220LCb-<NUM>, 220LCb-<NUM> as shown in a first data structure <NUM>-<NUM> of <FIG>. Secondly, the individual hashes may be individual hashes of all other obtained LC encoded image frames 220LCa being different from the one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> as shown in an alternative second data structure <NUM>-<NUM> of <FIG>. Thus, the individual hashes are individual hashes of either all encoded image frames <NUM> lacking a respective small LC encoded image frame 220LCb-<NUM>, 220LCb-<NUM>, or all other obtained LC encoded image frames 220LCa being different from the one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>. The transmitter <NUM> obtains the individual hashes by individually hashing each one of the all encoded image frames <NUM> lacking a respective small LC encoded image frame 220LCb-<NUM>, 220LCb-<NUM>, or by individually hashing each one of the all other obtained LC encoded image frame 220LCa, respectively. The data structure is, as will be described below, to be used by the receiver <NUM> when validating the video sequence. The transmitter <NUM> comprises a data structure generating module <NUM> configured to generate the data structure and the data structure generating module <NUM> may perform step S506.

In the example illustrated in <FIG>, the LC encoded image frames P01LC, P02LC, I1LC, P12LC, and I2LC are identified as being small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>, and therefore, both the first data structure <NUM>-<NUM> and the alternative second data structure <NUM>-<NUM> illustrated comprise theses small LC encoded image frames P01LC, P02LC, I1LC, P12LC, and I2LC.

In addition to the small LC encoded image frames, the first data structure <NUM>-<NUM> comprises individual hashes of all encoded image frames <NUM> lacking a respective small LC encoded image frame 220LCb-<NUM>, 220LCb-<NUM>. Thus, in the illustrated example, the (first) data structure also comprises the individual hashes HI0, HP00, HP10, and HP13.

The alternative second data structure <NUM>-<NUM> comprises, in addition to the small LC encoded image frames, individual hashes of the all other obtained LC encoded image frames 220LCa being different from the identified small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>. Thus, the alternative (second) data structure also comprises individual hashes HI0LC, HP00LC, HP10LC, and HP13LC which are the individual hashes of the LC encoded image frames I0LC, P00LC, P10LC, and P13LC.

The data structure <NUM> may be referred to as a document comprising a reduced hash list. The hash list is reduced since it does not only comprise hashes for all the encoded image frames as a complete hash list does, but the reduced hash list comprises instead of the hashes of the small LC encoded image frames, the small LC encoded image frames as they are, i.e. unhashed. This is in contrast to cases wherein the data structure is a document comprising the complete hash list consisting of a respective individual hash for each encoded image frame of the video sequence. Specifically, the present data structure <NUM> comprises the LC encoded image frame for each LC encoded image frame being identified as small and the individual hashes of either all encoded image frames <NUM> lacking a respective small LC encoded image frames or all LC encoded image frame having a size being equal to or larger than the predefined number of bytes. Thus, the reduced hash list only consists of the identified one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>; and the individual hashes of either all encoded image frames <NUM> lacking a respective small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>, or all other obtained LC encoded image frames 220LCa being different from the one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>.

In embodiments, wherein the video sequence is composed of GOPs, the transmitter <NUM> generates one data structure <NUM> and one digital signature <NUM> per one or more GOPs 210a, 210b. Thereby, the transmitted video sequence can be validated by the receiver <NUM> per GOP instead of per the entire video sequence. This is advantageous for the receiver <NUM> since if one or more encoded image frames or GOPs cannot be validated, the receiver can still trust the authenticity of the validated GOPs and the validated GOPs' encoded image frames. That is in contrast with the case when the video sequence has to be validated in its entirety, wherein the receiver cannot trust the authenticity of any of the encoded image frames of the video sequence if the entire video sequence cannot be validated.

Sometimes it is advantageous to provide information about where in the data structure each one of the small LC encoded image frames are located. This may for example, simplify for a receiver <NUM> to find and extract small LC encoded image frames from a received data structure. As will be described below when describing the method performed by the receiver <NUM>, the receiver <NUM> may use the extracted small LC encoded image frames to generate, i.e., reconstruct, their corresponding transmitted encoded image frames and the hashes thereof when verifying the received encoded image frames.

Therefore, some embodiments comprise a step S508, wherein the transmitter <NUM> determines, for each small LC encoded image frame <NUM>LCb-<NUM>, 220LCb-<NUM>, the location of each small LC encoded image frame 220LCb-<NUM>, 220LCb-<NUM> in the data structure <NUM>. In step S508 the transmitter <NUM> may also determine a data size of each small LC encoded image frame 220LCb-<NUM>, 220LCb-<NUM>. Step S508 may be performed by a determining module <NUM> comprised in the transmitter <NUM> and being configured to determine the location of each small LC encoded image frame in the data structure. The determining module <NUM> may be comprised in the lossless compressing module <NUM>. Alternatively, the determining module <NUM> may be comprised in the data structure generating module <NUM> of the transmitter <NUM>. Embodiments may also comprise a step S510 wherein the transmitter <NUM> provides the data structure <NUM> with information specifying the location in the data structure <NUM> and optionally the data size of each small LC encoded image frame 220LCb-<NUM>, 220LCb-<NUM>. The providing of the location specifying information to the data structure <NUM> may be performed by the data structure generating module <NUM>.

In order to enable validation of the video sequence, a digital signature is also needed. Therefore, in action S512, the transmitter <NUM> generates a digital signature <NUM> for the video sequence <NUM>. This step may be performed by a digital signature generating module <NUM> configured to generate digital signatures and being comprised in the transmitter <NUM>.

The transmitter <NUM> may have access to a private-public key pair, and may generate the digital signature by encrypting, with a private key of the private-public key pair, either:.

A private key of the private-public key pair may be stored in a secure storage only accessible by the transmitter <NUM>. The secure storage may be a secure element (SE), e.g., a secure operating system (OS) in a tamper-resistant processor chip or secure component, or a trusted platform module (TPM), e.g. a secure cryptoprocessor or secure chip. A public key of the transmitter's private-public key pair may be stored in a data storage, e.g., the data storage <NUM>, accessible by the receiver <NUM>. Alternatively, the public key of the transmitter's private-public key pair may be transmitted with the video sequence <NUM> to the receiver <NUM>. For example, the public key of the transmitter's private-public key pair may be comprised in or appended to the video sequence <NUM>.

In action S514, the transmitter <NUM> provides the data structure <NUM> and the digital signature <NUM> to the video sequence <NUM>. Thereby enabling a receiver <NUM> to validate the video sequence <NUM>. A providing module <NUM> comprised in the transmitter <NUM> and being configured to provide data structures and digital signatures to video sequences may perform step S514.

The transmitter <NUM>, e.g., by means of the providing module <NUM>, may provide the data structure <NUM> and the digital signature <NUM> in a supplemental information unit (SIU) of the video sequence <NUM>. The supplemental information unit is a unit or message configured to comprise supplemental information about or relating to the video sequence. The supplemental information unit may for example be a Supplemental Enhancement Information (SEI) message in the H. 26x encoding format, or a Metadata Open Bitstream Unit (OBU) in the AV1 encoding format.

A receiver <NUM> may validate a received video sequence using a received digital signature and a received data structure as will be described in detail below.

A method performed by the receiver <NUM> for validating a video sequence <NUM>' provided with a data structure <NUM> and a digital signature <NUM>, will now be described with reference to the flowchart of <FIG> and to the embodiment of the receiver <NUM> schematically illustrated in <FIG>. The video sequence <NUM>' comprises encoded image frames <NUM>'.

In step S602 the receiver <NUM> receives, from the transmitter <NUM>, the video sequence <NUM>' comprising encoded image frames <NUM>' and being provided with the data structure <NUM> and the digital signature <NUM>. Preferably, the video sequence <NUM>' received by the receiver <NUM> and the video sequence <NUM> transmitted by the transmitter <NUM> are identical. However, a transmitted video sequence may be manipulated after its transmittal and before its reception, therefore the reference numeral <NUM> is used for the transmitted video sequence and the reference numeral <NUM>' is used for the received video sequence. Step S602 may be performed by a receiving module <NUM> comprised in the receiver <NUM> and being configured to receive video sequences.

The received data structure <NUM> comprises one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>, wherein each small LC encoded image frame 220LCb-<NUM>, 220LCb-<NUM> has a data size that is smaller than a predefined number of bytes and is an LC version of a respective transmitted encoded image frame <NUM> comprised in a video sequence <NUM> transmitted from the transmitter <NUM>. The received data structure <NUM> also comprises individual hashes of either all transmitted encoded image frames <NUM> lacking a respective small LC encoded image frame 220LCb-<NUM>, 220LCb-<NUM>, or all other LC encoded image frames 220LCa being different from the one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>. Each one of the all other LC encoded image frames 220LCa is an LC version of a respective transmitted encoded image frame <NUM> comprised in the transmitted video sequence <NUM>.

As previously mentioned, when describing the method performed by the transmitter <NUM>, the predefined number of bytes may be set in dependence on the hash function used. As the transmitter <NUM> and the receiver <NUM> use the same hash function it is understood that the predefined number of bytes set at the transmitter <NUM> is the same as the predefined number of bytes used at the receiver <NUM>. The predefined number of bytes may be preset in the receiver <NUM> or information about the predefined number of bytes used by the transmitter <NUM> may be transmitted, e.g., together with the video sequence, from the transmitter <NUM> to the receiver <NUM>.

In step S604 the receiver <NUM> verifies the received digital signature <NUM> using the received data structure <NUM>. Step S604 may be performed by a verifying module <NUM> comprised in the receiver <NUM> and being configured to verify digital signatures.

In some embodiments the receiver <NUM> has access to a public key of a private-public key pair of the transmitter <NUM>. In such embodiments, the receiver <NUM> verifies the received digital signature <NUM> by decrypting the received digital signature <NUM> using the public key and by verifying the received digital signature <NUM> when a hash of the received data structure <NUM> matches the received digital signature <NUM> as decrypted. Alternatively, the received digital signature <NUM> is verified when a hash of all individual hashes for all LC encoded image frames as given by the received data structure <NUM> matches the received digital signature <NUM> as decrypted. In yet an alternative, the received digital signature <NUM> is verified when a hash of all individual hashes for all encoded image frames as given by the received data structure <NUM> matches the received digital signature <NUM> as decrypted.

In step S606 the receiver <NUM> verifies the received encoded image frames <NUM>' as being equal to the transmitted encoded image frames <NUM> using the received data structure <NUM>. Step S606 may be performed by the verifying module <NUM> comprised in the receiver <NUM> and being configured to verify encoded image frames. The received video sequence <NUM>' is validated as being equal to the transmitted video sequence <NUM> when the received digital signature <NUM> and the received encoded image frames <NUM>' are verified.

The verification of the received encoded image frames <NUM>' (step S606) will now be described in more detail with reference to some different embodiments. Before going into the details, it could be said that in general the verification is made by comparing hashes of the received encoded image frames with hashes of the encoded image frame as given by the received data structure (as in some first embodiments below), by comparing hashes of LC received encoded image frames with hashes of the LC encoded image frame as given by the received data structure (as in some second embodiments below) or by comparing the received data structure with a generated data structure (as in some third embodiments below).

Further, it should be recalled that the data structure <NUM> transmitted by the transmitter <NUM> and received by the receiver <NUM> comprises, in addition to the one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>, the individual hashes of either: all transmitted encoded image frames <NUM> lacking a respective small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> (as in some first embodiments below), or all other LC encoded image frames 220LCa being different from the one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> (as in some second and third embodiments below).

In some first embodiments, the received data structure <NUM> comprises, in addition to the small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>, individual hashes of all transmitted encoded image frames <NUM> lacking a respective small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>. In such first embodiments, the receiver <NUM> has to generate hashes of the received encoded image frames and has to determine the individual hash(-es) of the respective encoded image frame of the one or more small LC encoded image frames' 220LCb-<NUM>, 220LCb-<NUM> comprised in the received data structure <NUM>. Therefore, the verifying (step S606) of the received encoded image frames <NUM>' as being equal to the transmitted encoded image frames <NUM> using the received data structure <NUM> comprises four sub-steps S606. <NUM> - S606. <NUM>, which are illustrated in <FIG>.

In sub-step S606. <NUM> the receiver <NUM> generates individual hashes of each received encoded image frame <NUM>' comprised in the received video sequence <NUM>'. A hash generating module <NUM> comprised in the receiver <NUM> may perform the generation of the individual hashes.

In sub-step S606. <NUM> the receiver <NUM> performs lossless decompression of each of the one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> comprised in the received data structure <NUM> to obtain a respective encoded image frame. By performing lossless decompression on an LC encoded image frame 220LC, the (original) encoded image frame <NUM> on which the transmitter <NUM> performed the lossless compression to obtain the LC encoded image frame will be obtained. Some examples of lossless decompression algorithms are Huffman decoding, arithmetic decoding, codebook-based decoding, and run-length decoding. A lossless decompressing module <NUM> comprised in the receiver <NUM> may perform the lossless decompression.

In sub-step S606. <NUM> the receiver <NUM> generates individual hashes of each obtained respective encoded image frame <NUM>. This may be performed by the hash generating module <NUM>.

In sub-step S606. <NUM> the receiver <NUM> verifies the received encoded image frames <NUM>' as being equal to the transmitted encoded image frames <NUM> when the generated individual hashes of each received encoded image frame <NUM>' comprised in the received video sequence <NUM>' match the generated individual hashes of each obtained respective encoded image frame <NUM>. This may be performed by the verifying module <NUM>.

In some second embodiments, the received data structure <NUM> comprises, in addition to the small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>, individual hashes of all other LC encoded image frames 220LCa being different from the one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>. In such second embodiments, the verifying (step S606) of the received encoded image frames <NUM>' as being equal to the transmitted encoded image frames <NUM> using the received data structure <NUM> comprises four sub-steps S606. <NUM> - S606. <NUM>, which are illustrated in <FIG>.

In sub-step S606. <NUM> the receiver <NUM> performs lossless compression of each received encoded image frame <NUM>' comprised in the received video sequence <NUM>' to obtain respective LC received encoded image frames 220LC'; 220LCa', 220LCb-<NUM>', 220LCb-<NUM>'. Some examples of lossless compression algorithms are Huffman coding, arithmetic encoding, codebook-based encoding, and run-length encoding. A lossless compressing module <NUM> comprised in the receiver <NUM> may perform the lossless compression.

In sub-step S606. <NUM> the receiver <NUM> generates individual hashes of all obtained respective LC received encoded image frames 220LC'; 220LCa', 220LCb-<NUM>', 220LCb-<NUM>'. This may be performed by the hash generating module <NUM>.

In sub-step S606. <NUM> the receiver <NUM> generates individual hashes for all the LC encoded image frames 220LC; 220LCa, 220LCb-<NUM>, 220LCb-<NUM> as given by the received data structure <NUM>. As the individual hashes of the all other LC encoded image frames 220LCa being different from the one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> are comprised in the received data structure <NUM>, the receiver <NUM> can retrieve them directly from the data structure <NUM>. In addition, the receiver <NUM> retrieves the one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> comprised in the received data structure <NUM> and then individually hashes them. The receiver <NUM> will generate the individual hashes differently depending on whether or not the one or more small LC encoded image frame 220LCb-<NUM>, 220LCb-<NUM> is of the first type or the second type. Sub-step S606. <NUM> may be performed by the hash generating module. A detailed description of the generation of the individual hashes will be given after the description of sub-step S606.

In sub-step S606. <NUM> the receiver <NUM> verifies the received encoded image frames <NUM>' as being equal to the transmitted encoded image frames <NUM> when the generated individual hashes for all the LC encoded image frames 220LC; 220LCa, 220LCb-<NUM>, 220LCb-<NUM> as given by the received data structure <NUM> match the generated individual hashes of all obtained respective LC received encoded image frames 220LC'; 220LCa', 220LCb-<NUM>', 220LCb-<NUM>'. This may be performed by the verifying module <NUM>.

How the receiver <NUM> generates individual hashes for all the LC encoded image frames 220LC; 220LCa, 220LCb-<NUM>, 220LCb-<NUM> as given by the received data structure <NUM> (sub-step S606. <NUM> above) will now be described in more detail with reference to two scenarios.

In a first scenario, one or more small LC encoded image frame 220LCb-<NUM> is of the first type and is equal to the encoded image frame <NUM> having a data size that is smaller than the predefined number of bytes or equal to the LC encoded image frame 220LC of the encoded image frame <NUM> when the LC encoded image frame 220LC is smaller than the encoded image frame <NUM> and has a data size that is smaller than the predefined number of bytes. The encoded image frame <NUM> is the original encoded image frame transmitted by the transmitter <NUM>. The small LC encoded image frame 220LCb-<NUM> is equal to the encoded image frame <NUM> when the LC encoded image frame obtained, by the transmitter's lossless compressing module <NUM> when performing lossless compression on the original encoded image frame, had a size that was larger than the original encoded image frame and the lossless compressing module <NUM> outputs the original encoded image frame as the obtained LC encode image frame. Thus, in the first scenario, the one or more of the small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> is a small LC encoded image frame 220LCb-<NUM> of a first type and is equal to its respective transmitted encoded image frame <NUM> or equal to the LC encoded image frame 220LC of the encoded image frame <NUM>. The received data structure <NUM> further comprises information specifying a location, in the data structure <NUM>, and optionally a size, of the small LC encoded image frame 220LCb-<NUM> of the first type. In this first scenario, the generating of individual hashes for all the LC encoded image frames 220LCa, 220LCb-<NUM>, 220LCb-<NUM> as given by the received data structure <NUM> comprises:.

In a second scenario, one or more small LC encoded image frame 220LCb-<NUM> is of the second type. This may be the case when the transmitter <NUM> determines that the respective (original) encoded image frame <NUM> of the small LC encoded image frame 220LCb-<NUM> of the second type is equal to a part of a stored encoded image frame 220e. For example, when the transmitter <NUM>, e.g., by means of the lossless compressing module <NUM>, determines that the respective encoded image frame <NUM> is a skip frame that is identical to a stored encoded image frame 220e, the small LC encoded image frame 220LCb-<NUM> of the second type may be generated to comprise only an identifier of the stored encoded image frame 220e without any other image data. As another example, the transmitter <NUM>, e.g., by means of the lossless compressing module <NUM>, may determines that the respective encoded image frame <NUM> is partly identical to a stored encoded image frame 220e. Then, the small LC encoded image frame 220LCb-<NUM> of the second type may be generated to comprise an identifier of the stored encoded image frame 220e and a difference relative the stored encoded image frame 220e. Thus, one or more of the small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM> is a small LC encoded image frame 220LCb-<NUM> of a second type and comprises an identifier of a stored predefined encoded image frame 220e and a possible difference between the respective transmitted encoded image frame <NUM> and the stored predefined encoded image frame 220e. The received data structure <NUM> further comprises information specifying a location, in the data structure <NUM>, and optionally the data size, of the small LC encoded image frame 220LCb-<NUM> of the second type. In this second scenario, the generating of individual hashes for all the LC encoded image frames 220LCa, 220LCb-<NUM>, 220LCb-<NUM> as given by the received data structure <NUM> comprises:.

In some third embodiments, the received data structure <NUM> comprises individual hashes of all other LC encoded image frames 220LCa being different from the one or more small LC encoded image frames 220LCb-<NUM>, 220LCb-<NUM>. In order to verify the received encoded image frames <NUM>' the receiver <NUM> generates a data structure comprising one or more small LC encoded image frames and individual hashes of all LC encoded image frames being different from the one or more small encoded image frames, and compares it with the received data structure. Therefore, in such third embodiments, the verifying (step S606) of the received encoded image frames <NUM>' as being equal to the transmitted encoded image frames <NUM> using the received data structure <NUM> comprises three sub-steps S606. <NUM> - S606. <NUM>, which are illustrated in <FIG>.

In sub-step S606. <NUM> the receiver <NUM> performs lossless compression of each received encoded image frame <NUM>' comprised in the received video sequence <NUM>' to obtain respective LC received encoded image frames 220LCa', 220LCb-<NUM>', 220LCb-<NUM>'. Some examples of lossless compression algorithms are Huffman coding, arithmetic encoding, codebook-based encoding, and run-length encoding. The lossless compressing module (not shown) comprised in the receiver <NUM> may perform the lossless compression.

In sub-step S606. <NUM> the receiver <NUM> generates a data structure <NUM>' comprising:.

This may be performed by a data structure generating module <NUM> comprised in the receiver <NUM>.

In sub-step S606. <NUM> the receiver <NUM> verifies the received encoded image frames <NUM>' as being equal to the transmitted encoded image frames <NUM> when the generated data structure <NUM>' matches the received data structure <NUM>. This may be performed by the verifying module <NUM>.

Embodiments also relate to a non-transitory computer-readable medium having stored thereon computer code instructions adapted to carry out embodiments of the methods described herein when executed by a device having processing capability.

As described above, the transmitter <NUM> may be configured to implement a method for enabling validation of a video sequence by providing the video sequence with the data structure and the digital signature, and the receiver <NUM> may be configured to implement a method for validating the video sequence by providing the video sequence with the data structure and the digital signature. For this purpose, the transmitter <NUM> and the receiver <NUM>, respectively, may include processing circuitry <NUM>, <NUM>, respectively, which is configured to implement the various method steps described herein.

In a hardware implementation, the processing circuitry <NUM>, <NUM> may be dedicated and specifically designed to implement one or more of the method steps. The circuitry may be in the form of one or more integrated circuits, such as one or more application specific integrated circuits or one or more field-programmable gate arrays.

By way of example, the transmitter <NUM> may hence comprise processing circuitry <NUM> which, when in use:.

By way of example, the receiver <NUM> may comprise processing circuitry <NUM> which, when in use:.

In a software implementation, the circuitry may instead be in the form of a processor, such as a microprocessor, which in association with computer code instructions stored on a (non-transitory) computer-readable medium, such as a non-volatile memory, causes the transmitter <NUM> and the receiver <NUM>, respectively, to carry out the respective method disclosed herein. Examples of non-volatile memory include read-only memory, flash memory, ferroelectric RAM, magnetic computer storage devices, optical discs, and the like. In a software case, each of the method steps described above may thus correspond to a portion of computer code instructions stored on the computer-readable medium, that, when executed by the processor, causes the transmitter <NUM> and the receiver <NUM>, respectively, to carry out the respective method disclosed herein.

It is to be understood that it is also possible to have a combination of a hardware and a software implementation, meaning that some method steps are implemented in hardware and others in software.

Claim 1:
A method performed by a transmitter (<NUM>) for enabling validation of a video sequence (<NUM>) by providing the video sequence (<NUM>) with a data structure (<NUM>) and a digital signature (<NUM>), wherein the video sequence (<NUM>) comprises encoded image frames (<NUM>), and wherein the method comprises:
- performing (S502) lossless compression of each encoded image frame (<NUM>) of the video sequence (<NUM>) to obtain a respective losslessly compressed, LC, encoded image frame (220LC);
- among the obtained LC encoded image frames (220LC) identifying (S504) one or more small LC encoded image frames (220LCb-<NUM>, 220LCb-<NUM>) each having a data size that is smaller than a predefined number of bytes;
- generating (S506) a data structure (<NUM>) comprising:
- the identified one or more small LC encoded image frames (220LCb-<NUM>, 220LCb-<NUM>); and
- individual hashes of either:
all encoded image frames (<NUM>) for which the obtained respective LC encoded image frame (220LCa) is not identified as a respective small LC encoded image frame (220LCb-<NUM>, 220LCb-<NUM>); or
all other obtained respective LC encoded image frames (220LCa) not being identified as one or more small LC encoded image frames (220LCb-<NUM>, 220LCb-<NUM>),
wherein the individual hashes are obtained by individually hashing each one of the all encoded image frames (<NUM>) for which the obtained respective LC encoded image frame (220LCa) is not identified as a respective small LC encoded image frame (220LCb-<NUM>, 220LCb-<NUM>), or by individually hashing each one of the all other obtained respective LC encoded image frame (220LCa) not being identified as a small LC encoded image frame (220LCb-<NUM>, 220LCb-<NUM>), respectively;
- generating (S512) a digital signature (<NUM>) for the video sequence (<NUM>); and
- providing (S514) the data structure (<NUM>) and the digital signature (<NUM>) to the video sequence (<NUM>), thereby enabling a receiver (<NUM>) to validate the video sequence (<NUM>).