A vehicle-mounted monitoring video file processing method and device

Abstract

The application discloses a kind of vehicle-mounted monitoring video file processing method, device, the method comprises: obtaining the encrypted vehicle-mounted monitoring video file to be encrypted;Obtain the encrypted video frame to be encrypted in the encrypted vehicle-mounted monitoring video file to be encrypted;According to the preset encryption logic, the encrypted video frame is encrypted frame by frame, and encrypted video frame is obtained, wherein at least two encrypted video frames to be encrypted are encrypted using different encryption algorithms;According to the encryption algorithm number used by each encrypted video frame, generate encryption mark frame;The encryption mark frame is inserted after the corresponding encrypted video frame, and the encrypted video file is obtained;According to the encrypted video file, the file fingerprint of the encrypted video file is obtained;The file fingerprint is uploaded to the authentication server;The encrypted video file is stored.The vehicle-mounted monitoring video file processing method of the application makes the encryption algorithm complex without increasing the decryption burden, and greatly improves the cracking difficulty compared with the current encryption method.

Description

Technical Field

[0001] This application relates to the field of data encryption technology, specifically to a method for processing vehicle-mounted surveillance video files, a device for processing vehicle-mounted surveillance video files, and a method for authenticating and playing vehicle-mounted surveillance video files. Background Technology

[0002] With the development of automotive intelligence, more and more cameras are being installed in vehicles. Traditional in-vehicle video surveillance systems typically store raw video directly on media without any security measures. These videos are easily stolen or tampered with, posing numerous security risks to users. Currently, some in-vehicle monitoring and recording systems encrypt local files, requiring passwords, fingerprints, or other verification methods when retrieving and copying videos; however, this method offers no protection against secondary dissemination of copied videos and is powerless when privacy and security issues arise.

[0003] Patent document CN103824343A discloses a vehicle-mounted video surveillance device with fingerprint encryption recognition. This device's storage unit is connected to a fingerprint encryption unit. To retrieve digital signals, the user's fingerprint information must first be entered. The fingerprint encryption unit also supports biometric detection. Other documents provide other encryption methods, such as passwords, facial recognition, and other biometric methods. These methods all involve setting access permissions for the storage device. Once access is granted, all videos are exposed, just like in an unencrypted environment, and secondary distribution is unrestricted.

[0004] Patent document CN111050213A discloses a video playback method, apparatus, electronic device, and storage medium. This system plays videos via a dedicated player. Each video carries an encryption flag, which is stored for each video. Before playback, the encryption flag is detected; the flag is located in the URI (Uniform Name System). A matching key is loaded based on the flag, and then decryption and playback are performed. This method encrypts each video and decrypts it during playback, achieving simultaneous decryption and playback, thus providing good security. However, it also has some drawbacks, such as a single encryption method, indiscriminate encryption of all videos, and a short time to crack the encryption algorithm. This means that any single decryption player can play all encrypted videos; if the encryption / decryption algorithm is leaked, the encryption measures for all encrypted videos become ineffective.

[0005] In summary, current vehicle monitoring systems generally suffer from unencrypted recorded data or only restrict data copying permissions. Even with authorized playback, current encryption methods lack effective solutions for algorithm cracking and handling after algorithm leaks. This severely limits the ability to prevent video copying, making copied videos easily redistributable. Furthermore, with the widespread use of vehicle cameras, current encryption methods are inconvenient to use, as not all video components require encryption. There are no solutions for conveniently controlling encryption and ensuring compatibility between encrypted and unencrypted playback. Therefore, it is necessary to propose a new video encryption and playback method to address these issues. Summary of the Invention

[0006] The purpose of this invention is to provide a method for processing vehicle-mounted surveillance video files, a device for processing vehicle-mounted surveillance video files, and a method for authenticating and playing vehicle-mounted surveillance video files, so as to solve at least one of the above-mentioned technical problems.

[0007] This invention provides the following solution:

[0008] According to one aspect of the present invention, a method for processing vehicle-mounted surveillance video files is provided, comprising:

[0009] Obtain the in-vehicle monitoring video file to be encrypted;

[0010] Obtain the video frame to be encrypted from the vehicle monitoring video file to be encrypted;

[0011] The video frames to be encrypted are encrypted frame by frame according to the preset encryption logic to obtain encrypted video frames, wherein at least two video frames to be encrypted are encrypted using different encryption algorithms.

[0012] An encryption flag frame is generated based on the encryption algorithm number used for each encrypted video frame.

[0013] The encryption flag frame is inserted after the corresponding encryption video frame to obtain an encrypted video file;

[0014] Obtain the file fingerprint of the encrypted video file based on the encrypted video file;

[0015] Upload the file fingerprint to the authentication server;

[0016] The encrypted video file is stored.

[0017] Optionally, obtaining the vehicle monitoring video file to be encrypted includes:

[0018] Obtain vehicle monitoring video files containing sensitive information that need to be encrypted, or vehicle monitoring video files generated according to user requirements that need to be encrypted.

[0019] Optionally, the step of encrypting the video frames to be encrypted frame by frame according to a preset encryption logic to obtain encrypted video frames, wherein at least two video frames to be encrypted are encrypted using different encryption algorithms, includes:

[0020] According to the preset encryption logic, different encryption algorithms are used to encrypt the video frame to be encrypted frame by frame to obtain the encrypted video frame.

[0021] Replace the video frame to be encrypted in the vehicle monitoring video file with the encrypted video frame.

[0022] Optionally, the encrypted flag frame further includes encrypted tag information of the encrypted video frame;

[0023] The step of generating an encryption flag frame based on the encryption algorithm number used for each encrypted video frame includes:

[0024] An encryption flag frame is generated based on the encryption algorithm number and encryption tag information used in the encrypted video frame, and the encryption flag frame is inserted after the encrypted video frame to obtain an encrypted video file.

[0025] Optionally, obtaining the file fingerprint based on the encrypted video file includes:

[0026] The file fingerprint of the encrypted video file is obtained by performing an MD5 hash function on the encrypted video file.

[0027] Optionally, uploading the file fingerprint to the authentication server includes:

[0028] After logging into the authentication server with their user account, the user uploads the file fingerprint to the authentication server.

[0029] The file fingerprint is bound to the logged-in user account.

[0030] Optionally, the authentication server is used to record the binding relationship between the file fingerprint and the user account and to issue a decryption key to the client when the client player requests authentication;

[0031] The decryption key is a verification code calculated based on user account information, file fingerprint information, user device information, and file storage location information on the playback terminal.

[0032] This invention provides an in-vehicle monitoring video file processing device, comprising:

[0033] A module for acquiring vehicle-mounted monitoring video files to be encrypted, wherein the module is used to acquire vehicle-mounted monitoring video files to be encrypted;

[0034] A video frame acquisition module for encrypting video frames is used to acquire the video frames to be encrypted in the vehicle monitoring video file to be encrypted.

[0035] An encryption module is used to encrypt the video frame to be encrypted frame by frame according to a preset encryption logic to obtain an encrypted video frame, wherein at least two video frames to be encrypted are encrypted using different encryption algorithms.

[0036] An encryption flag frame generation module is used to generate an encryption flag frame by assigning the encryption algorithm number used by each encrypted video frame.

[0037] An encrypted video file acquisition module is used to store the encryption flag frame after the corresponding encrypted video frame to obtain an encrypted video file;

[0038] The file fingerprint acquisition module is used to acquire the file fingerprint of the encrypted video file based on the encrypted video file.

[0039] The file fingerprint upload module is used to upload the file fingerprint to the authentication server;

[0040] An encrypted video file storage module is used to store the encrypted video file.

[0041] This invention also provides a method for authenticating and playing vehicle-mounted monitoring video files, which, when used on a server, includes:

[0042] Obtain video file playback information sent by the client, wherein the video file playback information includes the client device information, video file fingerprint information, and video file storage location information;

[0043] Based on the video file playback information and the client's logged-in user account, playback permissions are verified. If the verification is successful, then...

[0044] Calculate the decryption key based on the video file playback information and the client login user account;

[0045] The decryption key is sent to the client.

[0046] Optionally, when used on a client side, it includes:

[0047] Obtain the decryption key for the video file sent by the server;

[0048] Obtain a local temporary key;

[0049] Verify the local temporary key with the decryption key. If they match, then...

[0050] Decrypt the video file and play the video file.

[0051] Optionally, the client and the server have the same key calculation logic;

[0052] The step of verifying the local temporary key with the decryption key includes:

[0053] The client calculates a local temporary key based on local video file playback information;

[0054] The local temporary key is verified against the decryption key issued by the server. If they match, then...

[0055] Decrypt the video file and play the video file;

[0056] If the local temporary key does not match the decryption key issued by the server, then

[0057] Play the video file.

[0058] Compared with the prior art, the present invention has the following advantages:

[0059] This invention encrypts sensitive information in vehicle-mounted monitoring video files, and each frame of audio and video can be encrypted using a different encryption algorithm. This increases the complexity of the encryption algorithm without increasing the decryption burden, significantly raising the difficulty of cracking compared to currently used encryption methods, thus gaining more protection time in the encryption / decryption battle. This invention can encrypt according to user needs or automatically identify and encrypt sensitive information in video files, making the encryption operation more flexible. In its authentication and playback section, each video is bound to a specific user, and the decryption key is verified each time it is played. The key has an expiration date, providing highly effective control against secondary dissemination of the video. Furthermore, the player can still be used like a general player even without the decryption key or if the decryption key verification fails, only without the decryption function. Attached Figure Description

[0060] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0061] Figure 1 This is a flowchart illustrating a method for processing vehicle-mounted monitoring video files according to an embodiment of the present invention;

[0062] Figure 2 This is a flowchart illustrating a vehicle-mounted monitoring video file processing method according to another embodiment of the present invention;

[0063] Figure 3 This is a schematic diagram comparing encrypted and unencrypted frames in a vehicle monitoring video file processing method according to another embodiment of the present invention.

[0064] Figure 4 This is a flowchart illustrating a method for authenticating and playing vehicle-mounted monitoring video files according to an embodiment of the present invention.

[0065] Figure 5 This is a schematic diagram of the decryption process of an in-vehicle monitoring video file authentication and playback method according to an embodiment of the present invention;

[0066] Figure 6 This is a schematic diagram of the structure of an in-vehicle monitoring video file processing device according to an embodiment of the present invention;

[0067] Figure 7 This is a structural diagram of an electronic device that can implement the present invention. Detailed Implementation

[0068] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0069] Figure 1 This is a flowchart illustrating a method for processing vehicle-mounted monitoring video files according to an embodiment of the present invention;

[0070] like Figure 1 As shown, a method for processing vehicle-mounted surveillance video files includes:

[0071] Step 1: Obtain the in-vehicle monitoring video file to be encrypted;

[0072] Step 2: Obtain the video frames to be encrypted from the vehicle monitoring video file to be encrypted;

[0073] Step 3: Encrypt the video frames to be encrypted frame by frame according to the preset encryption logic to obtain encrypted video frames, wherein at least two video frames to be encrypted are encrypted using different encryption algorithms;

[0074] Step 4: Generate an encryption flag frame based on the encryption algorithm number used for each encrypted video frame;

[0075] Step 5: Insert the encryption flag frame after the corresponding encrypted video frame to obtain the encrypted video file;

[0076] Step 6: Obtain the file fingerprint of the encrypted video file based on the encrypted video file;

[0077] Step 7: Upload the file fingerprint to the authentication server;

[0078] Step 8: Store the encrypted video file.

[0079] This invention encrypts sensitive information in vehicle-mounted monitoring video files, and each frame of audio and video can be encrypted using a different encryption algorithm. This increases the complexity of the encryption algorithm without increasing the decryption burden, significantly increasing the difficulty of cracking compared to currently used encryption methods. This allows for more protection time in the encryption and decryption battle. This invention can encrypt according to user needs or automatically identify and encrypt sensitive information in video files, making the encryption operation more flexible.

[0080] In this embodiment, obtaining the vehicle monitoring video file to be encrypted includes:

[0081] Obtain vehicle monitoring video files containing sensitive information that need to be encrypted, or vehicle monitoring video files generated according to user requirements that need to be encrypted.

[0082] It is understood that this embodiment can control the monitoring and recording device to encrypt only sensitive information, or to encrypt the parts that the user wants to encrypt based on the user's active operation.

[0083] In this embodiment, the video frames to be encrypted are encrypted frame by frame according to a preset encryption logic to obtain encrypted video frames. At least two video frames to be encrypted are encrypted using different encryption algorithms, including:

[0084] Based on the preset encryption logic, different encryption algorithms are used to encrypt the video frames to be encrypted frame by frame to obtain encrypted video frames.

[0085] Replace the unencrypted video frame in the vehicle monitoring video file with an encrypted video frame.

[0086] Specifically, such as Figure 2 As shown, in this embodiment, the camera is responsible for video acquisition. The acquired video is a raw image with a large data volume, which needs to be encoded and compressed before transmission and storage. Due to the large amount of raw video data, the encoder and camera are typically deployed using transmission protocols capable of transmitting large amounts of data, such as LVDS protocol for data transmission between the camera and encoding device. Currently, network transmission protocols based on NDI protocol can also complete the transmission of large amounts of raw video data.

[0087] In this embodiment, the encoder performs video data compression encoding, generating a continuous GOP (Group of Pictures) after encoding multiple images. The decoder, during playback, reads this continuous GOP, decodes it, and then renders and displays it. A GOP is a group of consecutive frames, consisting of one I-frame and several B / P frames, and is the basic unit accessed by the video image encoder and decoder. The I-frame is called a keyframe and is entirely internally encoded. The P-frame is a forward prediction frame, whose encoding references frames preceding it within the same GOP. The B-frame is a bidirectional interpolation frame, whose encoding considers both the encoded frames preceding and following the source image sequence, taking into account temporal redundancy. The difference between encrypted and unencrypted frames is that a GOP differs by an encryption flag frame. The SEI frame immediately follows the I-frame of the current GOP; in this embodiment, the SEI frame is the encryption flag frame. In this embodiment, the GOP structure for encrypted and unencrypted videos is as follows: Figure 3 As shown.

[0088] Specifically, the encryption device completes the encryption of the encoded audio and video. This device can control whether encryption is started or stopped at any time, and can also control the use of different encryption algorithms. It is understood that, in another embodiment, the encryption process of the video frames to be encrypted in the same video file can use different encryption algorithms, or all video frames to be encrypted can be encrypted using the same encryption algorithm. The same encryption algorithm can be applied to different video files to be encrypted without reducing the overall system's cracking difficulty. When encryption is started, an SEI frame is inserted after each I-frame of video data. The encryption algorithm number and encryption tag information of the current I-frame are stored in the SEI frame. The encryption tag information indicates whether the I-frame is encrypted. The specific encryption algorithm is not stored in the SEI frame; only the algorithm number is saved. The encryption device can implement multiple encryption algorithms, and the encryption algorithms can be remotely upgraded. The upgrade scheme does not need to be backward compatible; that is, a completely new encryption algorithm can be used after the upgrade, and the algorithm number cannot be the same as a previously used number. In this embodiment, audio can also be encrypted synchronously with video, and its encryption flag and algorithm number, along with the timestamp, are stored in the SEI frame following the corresponding timestamp I-frame of the video.

[0089] In one embodiment, the encoding and encryption devices are deployed together. Upon completion of encoding each frame of data, a determination is made immediately whether encryption is required, thus improving overall encoding efficiency. During encoding, the current frame's attributes are detected. In this embodiment, only I-frames are encrypted, and SEI frame data with encryption algorithm numbers and encryption tag information is inserted after the I-frame. Since the encoding of P-frames and B-frames within a GOP is based on I-frames, if the I-frame is not decrypted correctly, the P-frames and B-frames within this GOP cannot be decoded correctly either. This is equivalent to P-frames and B-frames sharing the encryption identifier of the I-frame. Alternatively, P-frames and B-frames can also be encrypted independently, with the encryption flag frame using the information from the corresponding encryption flag frame of the I-frame within the same GOP.

[0090] In this embodiment, the specific encryption algorithm for each frame of image in the encryption device and the decryption algorithm in the client player have a corresponding relationship. The algorithms are not publicly disclosed in practice. The specific algorithm is required to ensure that no information is lost after data encryption; that is, any data conversion algorithm that can theoretically completely restore the data can be used here. During implementation, multiple different encryption algorithms can be used depending on the specific situation. The encryption algorithm for each frame of data in the encryption device can be updated at any time, and updates do not necessarily require historical compatibility. The client player generally needs to include all decryption algorithms for historical compatibility; otherwise, it may not support the decryption of certain videos. For this situation, this embodiment provides an online algorithm library update solution.

[0091] In this embodiment, the encryption method can be combined with the video detection function to automatically enable encryption for sensitive information and automatically disable encryption for non-sensitive information; alternatively, the encryption function can be activated at any time by the user to actively control the content to be encrypted.

[0092] In this embodiment, obtaining the file fingerprint from the encrypted video file includes:

[0093] The file fingerprint of the encrypted video file is obtained by calculating the MD5 hash function.

[0094] In this embodiment, uploading the file fingerprint to the authentication server includes:

[0095] After logging into the authentication server, the user uploads the file fingerprint to the authentication server.

[0096] The file fingerprint is linked to the logged-in user account.

[0097] In this embodiment, the authentication server is used to record the binding relationship between file fingerprints and user accounts and to issue decryption keys to the client when the client player requests authentication;

[0098] The decryption key is a verification code calculated based on user account information, file fingerprint information, user device information, and file storage location information on the playback terminal.

[0099] Specifically, in this embodiment, the local storage device is used to store encrypted video files; however, this solution can also support cloud storage. When stored locally, the storage device needs to extract the file fingerprint and upload it to the authentication server. The common practice for obtaining a file fingerprint is to perform a hash calculation on the video file to obtain its MD5 hash. Alternatively, a fixed portion of the file can be extracted to calculate the MD5 hash. In this embodiment, the MD5 hash algorithm can be used as one algorithm for calculating the file fingerprint, but other algorithms can also be used. Uploading the file fingerprint requires prior account login; the entire recording function of the local system is under account management. The uploaded content and the logged-in account are bound on the server side; that is, the encrypted file corresponding to the file fingerprint is bound to the user account to which the uploaded file belongs. The user account is verified when the file is decrypted and played. The uploaded file fingerprint and account binding are unique; a file fingerprint already bound to an account cannot be bound to another account, but after the binding relationship is broken, it can be bound to another account.

[0100] In this embodiment, encrypted video files are bound to user accounts via file fingerprints. This binding relationship is unique; that is, one file (fingerprint) belongs to only one user account. Deduplication is checked during file fingerprint uploads, and file fingerprints with existing bindings cannot be uploaded again unless the binding is broken. Users can log in to the authentication server to delete a file (fingerprint), thereby breaking the binding relationship. After the binding relationship is broken, other users can bind files (fingerprints) to their own accounts. Furthermore, files (fingerprints) can also achieve a one-to-many binding relationship with users. This one-to-many relationship is achieved through the video sharing function of bound users, meaning users can share videos under their own names with other users. This method of video dissemination is a user-initiated action, and the distributed videos still have secondary dissemination prevention functions, without increasing the risk of video content leakage. The so-called prevention of secondary dissemination means that even if a video is obtained through unauthorized sharing methods, such as unauthorized downloading or copying, the encrypted portion of the video cannot be played normally without the account bound to the video logging into the client.

[0101] In this embodiment, video files can be stored on a local file storage device; the files themselves are not uploaded to the server, only the file fingerprint is uploaded. However, in some scenarios, due to limitations in the capacity of local file storage devices, files are stored in the cloud. In this case, the solution described in this invention is still effective. The file fingerprint on the authentication server can be uploaded from the monitoring recording device, or the server can extract the fingerprint from the uploaded file using the same fingerprint extraction algorithm. The player can play cloud videos by downloading or streaming them online. When playing online, the client will download the fingerprint data corresponding to the file before downloading the video.

[0102] Figure 4 This is a flowchart illustrating a method for authenticating and playing vehicle-mounted monitoring video files according to an embodiment of the present invention.

[0103] like Figure 4 As shown, a method for authenticating and playing vehicle-mounted surveillance video files, when used on a server, includes:

[0104] Obtain video file playback information sent by the client, including client device information, video file fingerprint information, and video file storage location information;

[0105] Playback permissions are verified based on the video file playback information and the client's logged-in user account. If the verification is successful, then...

[0106] Calculate the decryption key based on the video file playback information and the client login user account;

[0107] The decryption key is sent to the client.

[0108] In this embodiment, the vehicle-mounted monitoring video file authentication and playback method, when used on a client, includes:

[0109] Obtain the decryption key for the video file sent by the server;

[0110] Obtain a local temporary key;

[0111] Verify the local temporary key with the decryption key. If they match, then...

[0112] Decrypt the video file and play it.

[0113] In this embodiment, the client and the server have the same key calculation logic;

[0114] Verifying the local temporary key with the decryption key includes:

[0115] The client calculates a local temporary key based on the local video file playback information;

[0116] The local temporary key is verified against the decryption key issued by the server. If the verification matches, the video file is decrypted and played.

[0117] If the local temporary key does not match the decryption key issued by the server, then

[0118] Play the video file.

[0119] The vehicle-mounted monitoring video file authentication and playback method of the present invention binds each video to a specific user account, verifies the decryption key each time it is played, and the key has an expiration time. This method has a very effective control capability to prevent the secondary dissemination of videos. Moreover, the player can still be used like a general player if there is no decryption key or the decryption key verification fails, but it will not have the decryption function.

[0120] In this embodiment, the authentication server's functions include recording the affiliation between stored file fingerprints and user accounts, and issuing a decryption key to the client when the client player requests authentication. This key contains a verification code for user account information, file fingerprint information, user device information, and the file storage location information on the playback device; that is, the key is calculated using a specific algorithm based on the above information. This calculation algorithm exists on both the player and server sides, and the key calculation algorithms on both ends are kept synchronized. The server-side algorithm resides in the cloud and is generally not leaked, while the player-side algorithm implementation employs a highly difficult-to-decompile scheme to prevent decompilation and cracking.

[0121] When the client player requests a decryption key, it sends user device information, file fingerprint information, and file storage location information to the authentication server. The server uses the file fingerprint information to check if the file belongs to the user account. If there is no binding relationship, the server refuses to issue the key; if there is a binding relationship, it calculates the key according to a preset algorithm and then sends it to the client player. The validity period of this key can be set when it is issued. After receiving the decryption key, the client player needs to verify its validity. The player generates a local temporary key on the client using the same key generation algorithm and verifies whether the local temporary key matches the decryption key issued by the server. If the keys match, the verification passes, the player's decryption function is activated, and the video file is decrypted and played; if the keys do not match, the verification fails. In this case, the player can still be used, but the decryption function is not activated. When playing the encrypted part of the video, it will exhibit screen tearing and noise, while the unencrypted part of the video can be played normally. The specific decryption and playback process of the video file in this embodiment is as follows: Figure 5 As shown.

[0122] In this embodiment, the binding of the file fingerprint to the user account ensures that only personnel with access to the monitoring device can view the video. The binding relationship between the authentication key and the user device and the file storage location ensures that after the file is disseminated a second or multiple times, playback must be re-authenticated, effectively preventing the unauthorized dissemination of encrypted files.

[0123] In this embodiment, the key acquisition and authentication on the playback end and the audio and video decryption algorithm of the player are all implemented using C and C++ encoding to prevent the encryption algorithm from being cracked after the program is decompiled. Other encoding methods that can prevent decompilation and cracking can replace the method in this embodiment for client implementation.

[0124] It is understandable that, since the decryption algorithm for each frame of data in this embodiment can be different, both the encryption device and the playback device can contain numerous specific encryption algorithms, making it extremely unlikely that all encryption algorithms can be cracked. Because the player kernel is developed using a language that is difficult to decompile, a cracker might bypass key authentication by decompiling the entire client and adding a shell. To counter this method, the authentication key incorporates a verification of the player client itself. When generating the authentication key, the player and server verify the client's own information. Once the client is decompiled, its information changes, and the authentication verification fails.

[0125] In this embodiment, the monitoring and recording device and the client player will update the encryption algorithm configuration scheme during the upgrade. At the same time, the key generation and verification method will also be upgraded. After the server is upgraded, it will stop issuing authentication keys to clients that have not been upgraded. This method can easily control the monitoring and recording device to abandon the old encryption and decryption algorithm and use the new algorithm. At the same time, it can prevent videos encrypted with the old encryption algorithm from being copied and played at will.

[0126] Figure 6 This is a schematic diagram of the structure of an in-vehicle monitoring video file processing device according to an embodiment of the present invention;

[0127] like Figure 6 As shown, the present invention also provides an in-vehicle monitoring video file processing device, including an in-vehicle monitoring video file acquisition module to be encrypted, a video frame acquisition module to be encrypted, an encryption module, an encryption flag frame generation module, an encrypted video file acquisition module, a file fingerprint acquisition module, a file fingerprint upload module, and an encrypted video file storage module; wherein,

[0128] A module for acquiring vehicle monitoring video files to be encrypted, wherein the module is used to acquire vehicle monitoring video files to be encrypted;

[0129] A module for acquiring video frames to be encrypted, used to acquire video frames to be encrypted from the vehicle monitoring video file to be encrypted;

[0130] The encryption module is used to encrypt the video frame to be encrypted frame by frame according to a preset encryption logic to obtain an encrypted video frame, wherein at least two video frames to be encrypted are encrypted using different encryption algorithms.

[0131] An encrypted flag frame generation module is used to generate an encrypted flag frame by assigning the encryption algorithm number used by each encrypted video frame.

[0132] An encrypted video file acquisition module is used to store the encryption flag frame after the corresponding encrypted video frame to obtain an encrypted video file;

[0133] The file fingerprint acquisition module is used to acquire the file fingerprint of the encrypted video file based on the encrypted video file.

[0134] The file fingerprint upload module is used to upload the file fingerprint to the authentication server;

[0135] An encrypted video file storage module, used to store the encrypted video file.

[0136] It is worth noting that although this system only discloses basic functional modules such as the module for acquiring vehicle monitoring video files to be encrypted, the module for acquiring video frames to be encrypted, the encryption module, the module for generating encryption flag frames, the module for acquiring encrypted video files, the module for acquiring file fingerprints, the module for uploading file fingerprints, and the module for storing encrypted video files, this does not mean that this device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with existing technology to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. The fact that this embodiment only discloses a few basic functional modules should not be taken as a reason to believe that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules.

[0137] Figure 7 This is a structural diagram of an electronic device that can implement the present invention.

[0138] like Figure 7 As shown, the electronic device includes a processor, a communication interface, a memory, and a communication bus. The processor, the communication interface, and the memory communicate with each other through the communication bus. The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the present invention.

[0139] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the present invention.

[0140] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0141] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0142] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0143] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0144] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0145] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0146] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0147] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0148] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0149] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for processing vehicle-mounted surveillance video files, characterized in that, include: Obtain the in-vehicle monitoring video file to be encrypted; Obtain the video frame to be encrypted from the vehicle monitoring video file to be encrypted; The video frames to be encrypted are encrypted frame by frame according to the preset encryption logic to obtain encrypted video frames, wherein at least two video frames to be encrypted are encrypted using different encryption algorithms. An encryption flag frame is generated based on the encryption algorithm number used for each encrypted video frame. The encryption flag frame is inserted after the corresponding encryption video frame to obtain an encrypted video file; Obtain the file fingerprint of the encrypted video file based on the encrypted video file; Uploading the file fingerprint to the authentication server includes: After logging into the authentication server with their user account, the user uploads the file fingerprint to the authentication server. The file fingerprint is bound to the logged-in user account; The authentication server is used to record the binding relationship between the file fingerprint and the user account, and to issue a decryption key to the client when the client player requests authentication; The decryption key is a verification code calculated based on user account information, file fingerprint information, user device information, and file storage location information on the playback terminal. The encrypted video file is stored.

2. The vehicle-mounted monitoring video file processing method as described in claim 1, characterized in that, The process of obtaining the vehicle monitoring video file to be encrypted includes: Obtain vehicle monitoring video files containing sensitive information that need to be encrypted, or vehicle monitoring video files generated according to user requirements that need to be encrypted.

3. The vehicle-mounted monitoring video file processing method as described in claim 2, characterized in that, The step of encrypting the video frames to be encrypted frame by frame according to a preset encryption logic to obtain encrypted video frames, wherein at least two video frames to be encrypted are encrypted using different encryption algorithms, includes: According to the preset encryption logic, different encryption algorithms are used to encrypt the video frame to be encrypted frame by frame to obtain the encrypted video frame. Replace the video frame to be encrypted in the vehicle monitoring video file with the encrypted video frame.

4. The vehicle-mounted monitoring video file processing method as described in claim 3, characterized in that, The encrypted flag frame further includes encrypted tag information of the encrypted video frame; The step of generating an encryption flag frame based on the encryption algorithm number used for each encrypted video frame includes: An encryption flag frame is generated based on the encryption algorithm number and encryption tag information used in the encrypted video frame, and the encryption flag frame is inserted after the encrypted video frame to obtain an encrypted video file.

5. The vehicle-mounted monitoring video file processing method as described in claim 4, characterized in that, The step of obtaining the file fingerprint based on the encrypted video file includes: The file fingerprint of the encrypted video file is obtained by performing an MD5 hash function on the encrypted video file.

6. A vehicle-mounted surveillance video file processing device, characterized in that, include: A module for acquiring vehicle-mounted monitoring video files to be encrypted, wherein the module is used to acquire vehicle-mounted monitoring video files to be encrypted; A video frame acquisition module for encrypting video frames is used to acquire the video frames to be encrypted in the vehicle monitoring video file to be encrypted. An encryption module is used to encrypt the video frame to be encrypted frame by frame according to a preset encryption logic to obtain an encrypted video frame, wherein at least two video frames to be encrypted are encrypted using different encryption algorithms. An encryption flag frame generation module is used to generate an encryption flag frame by assigning the encryption algorithm number used by each encrypted video frame. An encrypted video file acquisition module is used to store the encryption flag frame after the corresponding encrypted video frame to obtain an encrypted video file; The file fingerprint acquisition module is used to acquire the file fingerprint of the encrypted video file based on the encrypted video file. A file fingerprint upload module, wherein the file fingerprint upload module is used to upload the file fingerprint to the authentication server, including: After logging into the authentication server with their user account, the user uploads the file fingerprint to the authentication server. The file fingerprint is bound to the logged-in user account; The authentication server is used to record the binding relationship between the file fingerprint and the user account, and to issue a decryption key to the client when the client player requests authentication; The decryption key is a verification code calculated based on user account information, file fingerprint information, user device information, and file storage location information on the playback terminal. An encrypted video file storage module is used to store the encrypted video file.

7. A method for authenticating and playing vehicle-mounted surveillance video files, characterized in that, The video file is generated using the method described in any one of claims 1-5. When used on a server, the authentication playback includes: Obtain video file playback information sent by the client, wherein the video file playback information includes the client device information, video file fingerprint information, and video file storage location information; Based on the video file playback information and the client's logged-in user account, playback permissions are verified. If the verification is successful, then... Calculate the decryption key based on the video file playback information and the client login user account; The decryption key is sent to the client.

8. The vehicle-mounted monitoring video file authentication and playback method as described in claim 7, characterized in that, When used on a client-side, it includes: Obtain the decryption key for the video file sent by the server; Obtain a local temporary key; Verify the local temporary key with the decryption key. If they match, then... Decrypt the video file and play the video file.

9. The vehicle-mounted monitoring video file authentication and playback method as described in claim 8, characterized in that, The client and server have the same key calculation logic; The step of verifying the local temporary key with the decryption key includes: The client calculates a local temporary key based on local video file playback information; The local temporary key is verified against the decryption key issued by the server. If they match, then... Decrypt the video file and play the video file; If the local temporary key does not match the decryption key issued by the server, then Play the video file.

Images