Video processing method, terminal device and storage medium

Abstract

This invention discloses a video processing method, a terminal device, and a storage medium. The video processing method includes: receiving a video file, a playlist file, and a key file via a first application on a first terminal device; the video file includes one or more video segments; the playlist file includes a playlist of the video segments; the key file includes a first key; the first key is used to decrypt the video file; storing the key file in a first storage space; the first storage space allows access by the first application but prohibits access by a second application; the second application is different from the first application; writing key information into the playlist file according to the storage address of the key file in the first storage space; the key information is used to read the key file; when decrypting the video file, reading the first key from the first storage space based on the first application and the key information; and using the first key to decrypt the video file.

Description

Technical Field

[0001] This invention relates to the field of video technology, and in particular to a video processing method, terminal device, and storage medium. Background Technology

[0002] Typically, video files have a larger total data volume compared to text, audio, or image files. With the development of network technology, terminal devices can conveniently download and watch video files online. To facilitate network transmission, video files can be divided into multiple video segments, which are then combined to form a complete video file. In some cases, the multiple video segments are used to create a playlist, allowing the terminal device to play each segment in an orderly manner. Summary of the Invention

[0003] In view of the above, embodiments of the present invention provide a video processing method, a terminal device, and a storage medium.

[0004] The technical solution of this invention is implemented as follows:

[0005] The first aspect of this disclosure provides a video processing method, executed by a first terminal device, comprising:

[0006] The first APP (Application) of the first terminal device receives a video file, a playlist file, and a key file; the video file includes one or more video segments; the playlist file includes a playlist and the key file; the key file includes a first key; the first key is used to decrypt the video file;

[0007] The key file is stored in a first storage space; the first storage space allows access from the first APP but prohibits access from the second APP; the second APP is different from the first APP.

[0008] Based on the storage address of the key file in the first storage space, key information is written into the list file; the key information is used to read the key file.

[0009] When decrypting the video file, the first key is read from the first storage space based on the first APP and the key information;

[0010] The video file is decrypted using the first key.

[0011] Based on the above scheme, the method further includes:

[0012] The key file is stored in the target folder of the first storage space; the target file is accessible to the first terminal device but inaccessible to the second terminal device; the second terminal device is different from the first terminal device.

[0013] Based on the above scheme, the target folder is named with the device identifier of the first terminal device, and the device identifier is used to verify whether the user has the right to access the target folder.

[0014] Based on the above scheme, the method further includes:

[0015] The key file and / or the list file storing the key information are encrypted using a second key.

[0016] Based on the above scheme, the method further includes:

[0017] The second key is stored in a second storage space; the second storage space is different from the first storage space.

[0018] Based on the above scheme, the step of reading the first key from the first storage space based on the first APP and the key information when decrypting the video file includes:

[0019] When decrypting the video file, the second key is used to decrypt the list file;

[0020] After decrypting the list file, the key information is read;

[0021] Based on the key information, the first key is read from the key file in the first storage space.

[0022] Based on the above scheme, the method includes:

[0023] When video playback stops, encrypt the list file and / or the key file.

[0024] A second aspect of this disclosure provides a terminal device, the terminal device comprising:

[0025] The receiving module is configured to receive a video file, a playlist file, and a key file based on a first application (APP) of the first terminal device; the video file includes one or more video segments; the playlist file includes a playlist and the key file; the key file includes a first key; the first key is used to decrypt the video file.

[0026] A storage module is used to store the key file in a first storage space; the first storage space allows the first APP to access it but prohibits the second APP from accessing it; the second APP is different from the first APP;

[0027] The writing module is used to write key information into the list file according to the storage address of the key file in the first storage space; the key information is used to read the key file.

[0028] The reading module is used to read the first key from the first storage space based on the first APP and the key information when decrypting the video file;

[0029] A decryption module is used to decrypt the video file using the first key.

[0030] A third aspect of this disclosure provides a terminal device, including:

[0031] Memory, at least for storing computer-executable instructions;

[0032] A processor, connected to the memory, is configured to implement the video processing method described in any of the technical solutions of the first aspect through the execution of computer-executable instructions.

[0033] A fourth aspect of this disclosure provides a computer storage medium storing computer-readable instructions, which, when executed, can perform the method described in any of the technical solutions of the first aspect.

[0034] The fifth aspect of this disclosure provides a computer-readable instruction that, when executed, can perform the method described in any of the technical solutions of the first aspect described above. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating a video processing method provided in some embodiments of the present invention;

[0036] Figure 2 This is a flowchart illustrating a video processing method provided in some embodiments of the present invention;

[0037] Figure 3 This is a flowchart illustrating a video processing method provided in some embodiments of the present invention;

[0038] Figure 4 This is a schematic diagram of the structure of a terminal device provided in some embodiments of the present invention;

[0039] Figure 5 A schematic diagram of the hardware structure of a terminal device provided in an embodiment of the present invention. Detailed Implementation

[0040] In some scenarios, if the video file is a confidential encrypted video file, the terminal device will download the video file from the server along with a password or key. This key can be used to decrypt the encrypted video file. After decryption, the video file can be played normally. However, if both the password and the video file are provided to the terminal device, the confidential video may be misused or its encryption may be removed due to improper user operation or unauthorized access to the terminal device, leading to video leakage and playback risks. Therefore, this application provides a video processing method to improve video security. Specifically, as follows... Figure 1 As shown, the method may include:

[0041] S1101: The first APP (first application APP) of the first terminal device receives a video file, a playlist file, and a key file; the video file includes one or more video segments; the playlist file includes a playlist; the key file includes a first key; the first key is used to decrypt the video file.

[0042] S1102: Store the key file in a first storage space; the first storage space allows the first APP to access it but prohibits the second APP (second application APP) from accessing it; the second APP is different from the first APP;

[0043] S1103: Write key information into the list file according to the storage address of the key file in the first storage space; the key information is used to read the key file;

[0044] S1104: When decrypting the video file, the first key is read from the first storage space based on the first APP and the key information;

[0045] S1105: Decrypt the video file using the first key.

[0046] In some embodiments, the playback duration of video segments within a video file may be equal or unequal. In other embodiments, a video segment may include one or more Group of Pictures (GOPs). A video segment may include all frames from one or more scenes.

[0047] In some embodiments, the video file can be any video file that supports video segmentation. In some embodiments, the list file can be a plain text file. The list file can be used to obtain and / or determine the playback order of multiple video segments in a video file, etc. For example, the video file can include, but is not limited to, an m3u8 video file. An m3u8 video file can be a streaming media file based on the Hypertext Transfer Protocol (HTTP). If the video file is an m3u8 video file, then the list file can be an m3u8 file. In some embodiments, the playlist contained in the m3u8 file can be a media playlist or a master playlist. But regardless of the type of playlist, the text in the m3u8 file uses UTF-8 encoding.

[0048] When an m3u8 file is used as a media playlist, its internal information records a series of media clips. By playing these clips sequentially, the multimedia resources can be displayed in their entirety.

[0049] In this embodiment of the disclosure, the video file can be used for live streaming, on-demand viewing, or video file download.

[0050] For on-demand streaming, the client simply needs to download the aforementioned video clips in sequence and play them one by one. For live streaming, however, the client needs to periodically request the m3u8 file again to check for any new video clips that need to be downloaded and played.

[0051] When an m3u8 file is used as the master playlist, it internally provides multiple variant streams of the same media resource. This m3u8 file may include information about one or more alternate streams of the video file. These alternate streams specify various media playlists with different bitrates and formats, and can also simultaneously provide different versions of the resource content, such as audio files in different languages, video files shot from different angles, etc. Customers can select the appropriate bitrate resource based on different network conditions, and ideally, choose suitable resource content based on user preferences.

[0052] For example, m3u8 files are encoded in UTF-8 and cannot use Byte Order Mark (BOM) byte order. An m3u8 file can include one or more Uniform Resource Locators (URIs). Typically, one line of text in an m3u8 file can be used to write a URI. An m3u8 file may also include one or more tags. For example, these tags may include, but are not limited to:

[0053] Attribute Lists: The values ​​of certain tags are lists of attributes. Tags can have one or more attribute value pairs. For example, there are five types of tags: Basic Tags, Media Segment Tags, Media Playlist Tags, Master Playlist Tags, and Playlist Tags. Basic Tags: Can be applied to both MediaPlaylists and Master Playlists. Specific tags are as follows:

[0054] For example, the type tag (EXTM3U): indicates that the file is an m3u8 file. This tag must be placed on the first line of every M3U file. The version tag (EXT-X-VERSION) indicates the HLS protocol version number; this tag is related to streaming compatibility. This tag has global scope, enabling the entire m3u8 file; only one definition of this tag can appear in each m3u8 file. If the m3u8 file does not contain this tag, it defaults to the first version of the protocol. Media Segment Tags: Each video segment (also called a video slice) is preceded by a series of media segment tags describing it. Some segment tags are only valid for subsequent slice resources; some segment tags are valid for all subsequent slices until another segment described by this tag is encountered. Media segment tags cannot appear in the Master Playlist. The tag (EXTINF): indicates the duration (in seconds) of the media segment specified by the Uniform Resource Identifier. This tag must be specified before the media segment corresponding to each Uniform Resource Identifier. The tag (EXT-X-DISCONTINUITY): indicates that there is a break between the previous and next slice. In some embodiments, the list file may also include a timestamp sequence. Of course, the above are merely examples of list files. In summary, based on the list file, the first terminal device can obtain each video segment and play each video segment as needed, thereby achieving orderly video playback.

[0055] In this embodiment, the first terminal device receives a key file in addition to the video file. The key file stores a first key. This first key can decrypt the video file. Exemplarily, the first key can be a symmetric encryption key or an asymmetric encryption key.

[0056] In some embodiments, the key file may include one or more first keys. For example, a video file may have one first key, and all video segments of that video file can be decrypted using this one first key. Alternatively, a video file may have multiple first keys; for instance, different video segments may have different first keys. Or, multiple video segments (e.g., related video segments) may share a single first key. For example, this relatedness of video segments may be reflected in content association or having the same Uniform Resource Identifier (URL). In specific implementations, content association may be reflected in multiple video segments needing to be played consecutively, or multiple video files depicting the same scene or adjacent scenes in the videos.

[0057] In this embodiment, after receiving the key file, the first terminal device stores the key file in a specific first storage space. This first storage space is configured with space characteristics, allowing only the corresponding first app to access it. In some embodiments, the first storage space may also be a sandbox space for the first app. The second app can be any app installed on the first terminal device or a remote online app. Other apps besides the first app are not allowed to access the first storage space. Thus, the key file is no longer stored in a storage space accessible to the second app along with the video file and / or list file, achieving separate storage of the video file and list file from the key file. This at least improves the security of the key file and reduces the risk of hackers or unauthorized devices stealing the key file through other apps on the first terminal device or remote online apps, thereby preventing them from decrypting the video file based on the first key stored in the key file and ultimately enhancing the security of the video file.

[0058] In some embodiments, since the key file is not stored in the same storage space as the list file and video file, after the first terminal device stores the key file in the first storage space, it writes the key information to the list file according to the storage address of the key file in the first storage space. This key information can be used by the first APP to read the key file. For example, the key information may include information such as the storage address and storage path of the key file in the first storage space.

[0059] In some embodiments, the first app may be an app capable of playing videos or an app capable of receiving video files. If the first app is an app capable of playing videos, it needs to decrypt the video file first when it detects a playback command. If the first app is an app that downloads video files, it determines to decrypt the video file upon receiving a playback request from the video playback app, and sends the decrypted video segments one by one to the video playback app for playback. To further enhance the security of the video file, the first app only sends one or a small number of video segments to the video playback app at a time, rather than all video segments, to avoid video leakage caused by the video playback app receiving all decrypted video segments at once. In some embodiments, the video segment is set with segment attributes, which can prevent modification of the video segment attributes by any app or any app other than the first app, permanent storage of the video segment, or queryable storage. When it is necessary to decrypt the video file, the first app reads the first key from a location in the first storage space according to the key information, and then uses the first key to decrypt.

[0060] In some embodiments, to further enhance the security of the key file, the key file is written to a target folder in the first storage space. In some embodiments, the target folder has the characteristic of requiring access verification. In other embodiments, the target folder may be a hidden folder visible only to the first terminal device. In some embodiments, the target folder is configured with verification information, requiring authentication to access it. Authentication allows only the first terminal device to access the folder and prohibits access from second terminal devices. For example, the authentication information may be the device identifier of the first terminal device. The device identifier may be any information that uniquely identifies the first terminal device. Exemplarily, the device identifier may include, but is not limited to, the physical identifier of the first terminal device. In some embodiments, the physical identifier may include, but is not limited to, the International Mobile Equipment Identity (IMEI) and / or the device's serial number. In some embodiments, the verification information may also be other physical identifiers of the first terminal device, such as the Media Access Control Address (MAC) address of the first terminal device.

[0061] In other embodiments, the verification information may also be the highest security level verification information set by the operating system of the first device. Thus, after verification is completed based on the verification information and passes, the target folder allows the application to read the key file; otherwise, a read error will occur or the read operation will not be responded to. Therefore, by writing the key file to the target folder in this way, the protection of the key file is further enhanced.

[0062] In some embodiments, the target folder is named after the device identifier of the first terminal device, and the device identifier is used to verify whether the user has the right to access the target folder.

[0063] In this embodiment, the target folder is named after the device identifier of the first terminal device and is accessible only to the first terminal device, not other terminal devices. Exemplarily, this method achieves the binding between the folder and the terminal device. In this case, even if an unauthorized device directly copies the entire first app from the first terminal device, because the target folder is named after the first terminal device or accessed only by the first terminal device through folder attribute settings, the second terminal device that has the copied first app written into it cannot read the key file from the target folder. This again prevents the leakage of video files caused by hackers or unauthorized devices copying the entire first app from the first terminal device, thus eliminating the possibility of leaking confidential video files.

[0064] In some embodiments, the method further includes:

[0065] The key file and / or the list file storing the key information are encrypted using a second key.

[0066] In some embodiments, a second key is used to encrypt the key file.

[0067] In some embodiments, a second key is used to encrypt a list file containing key information. For example, at least the second key is used to encrypt the list file, reducing the leakage of key information in the list file and reducing the likelihood of obtaining information such as the storage address and path of the stored key file based on the key information in the list file.

[0068] In some embodiments, a second key is used to encrypt a key file and a list file containing key information, respectively.

[0069] In some embodiments, to enhance the security of the key file, different decryption algorithms are used when encrypting the key file and the list file using the second key. Thus, even if an unauthorized device or hacker obtains the second key and successfully decrypts the list file, they cannot decrypt the key file using the same decryption algorithm with the same second key.

[0070] In some embodiments, when encrypting the list file and key file using a second key, the list file is encrypted using a first algorithm and the key file is encrypted using a second algorithm. The first and second algorithms are different. For example, encrypting the list file based on the first algorithm allows the contents of the list file to be directly converted into ciphertext based on the second key. However, encrypting the list file using the second algorithm involves generating a third key based on the second key, and then encrypting the contents of the key file using the third key to obtain the encrypted ciphertext. When encrypting the key file using the second key, the second key is essentially an intermediate key for encrypting the key file. Of course, this is merely an example of encrypting the list file and key file using a second key, and the actual implementation is not limited to this example.

[0071] To further enhance the security of the first key in the key file, after the key file is downloaded to the local machine of the first terminal device, the operating system or the first application of the first terminal device will again use the second key to encrypt the list file containing the key information stored in the first storage space. In some embodiments, the second key can be generated by the first terminal device itself. For example, the operating system or the first application of the first terminal device generates the second key based on a specified key derivation algorithm. In some embodiments, the derivation algorithm of the second key can be specified by the server providing the video file. The server can also provide some parameters for generating the second key. Of course, the parameters required for generating the second key can also be determined by the first terminal device itself, for example, the first terminal device can use its own key derivation algorithm. Different encrypted video files can have different second keys. In some embodiments, the second key can be a system-level key, so that even if the first application is completely copied, the system-level key will not be known to the first application, and hackers or unauthorized devices will find it more difficult to obtain the first key due to the lack of the second key.

[0072] In some embodiments, the method further includes:

[0073] The second key is stored in a second storage space; the second storage space is different from the first storage space.

[0074] In some embodiments, the second storage space is not the storage space under the directory where the first app is located. Therefore, even if the first app is copied, it cannot be copied to the second key.

[0075] In some embodiments, the second storage space may be a storage space that the first app cannot directly access. For example, when the first app needs to obtain the second key, it requests the operating system of the first terminal device to read the second key from the second storage space and pass it to the first app based on the key acquisition password.

[0076] For example, the second storage space may be the system storage space provided by the first terminal, or a storage space that can only be accessed by the operating system of the first terminal device.

[0077] Thus, by storing the second key in the second storage space, the security of the first key can be further enhanced by improving the security of the second key.

[0078] like Figure 2 As shown, the video processing method provided in this embodiment may include a video decryption method, specifically including:

[0079] S2101: When decrypting video files, use the second key to decrypt the list file;

[0080] S2102: After decrypting the list file, read the key information;

[0081] S2103: Read the first key from the key file in the first storage space according to the key information;

[0082] S2104: Decrypt the video file using the first key.

[0083] In this embodiment, the first APP no longer directly reads the first key from the key file located in the same folder as the video file to decrypt the video file. Instead, when decrypting the video file, it first uses the second key to decrypt the list file. After the list file is successfully decrypted, key information can be read from a specified location in the list file. The storage address of the key file in the first storage space is determined based on this key information, and the key file is obtained based on this storage address. If the second key is used to encrypt the key file, it needs to be decrypted using the second key before executing S2104. After the key file is successfully decrypted, the first key is read from the key file. If the second key is not used to encrypt the key file, it is not necessary to use the second key to decrypt the key file.

[0084] In some embodiments, since the key file is stored in the target folder, authentication of the key file access user is required before reading the key file. If the authentication is successful, reading the key file is permitted; otherwise, the request to read the key file is rejected. In this case, regardless of whether the key file is encrypted, if the access user is not the first terminal device itself—for example, a terminal device that has successfully intercepted the entire first app—they may not have permission to access the target folder. For example, the target folder may be a folder named after the device identifier of the first terminal device.

[0085] In some embodiments, the method further includes:

[0086] Detect whether the third terminal device has legally obtained the first APP of the first terminal device;

[0087] If a third terminal device legally obtains the first APP of a first terminal device, the third terminal device is allowed to access the target folder.

[0088] For example, when a user replaces their old device with a new one, the new device, acting as a third-party terminal, copies the first app from the old device (the first terminal). In this case, the third-party terminal has legitimate access to the first app from the first terminal, and therefore, it can be granted access to the target folder. This access can be granted by modifying the folder attributes or renaming the target folder.

[0089] In some embodiments, if a third terminal device legally obtains the first app from a first terminal device, the third terminal device will use a valid user account and password, among other authentication information, for authentication. After successful authentication, the third terminal device can be considered to have legally obtained the first app from the first terminal device.

[0090] In some embodiments, the key file may include one or more first keys. If all video segments of a video file share a single first key, the key file may contain only one first key, which is then used to decrypt each video segment one by one. When a key file contains multiple first keys, one first key can be used to decrypt one video segment. In this case, the multiple first keys can be arranged in the key file according to the playback order of the video segments, so that the first terminal device or the first APP can read the first key and decrypt the corresponding video segment as needed. In other embodiments, the key file may store the index of the video segment and the first key accordingly. Thus, when decrypting a video segment, the first key is obtained by retrieving the key file according to the index of the video segment. In some embodiments, some video segments in a video file may also share a single first key. For example, two or three adjacent video segments may share a single first key. In this case, the index of the video segments sharing the same first key is stored in the key file corresponding to the same first key. Alternatively, when there is no index of video segments in the key file, the number of segments sharing the same video segment can be written into the key file. In this way, when the first terminal device or the first APP decrypts video segments in sequence, the number of video segments to be decrypted using a first key is determined based on the number of segments.

[0091] In order to improve the video viewing experience during video decryption or playback, the list file and / or key file can be kept decrypted during the process. In this way, it is not necessary to decrypt the list file and / or key file itself multiple times, reducing the video playback stuttering phenomenon caused by the large delay of video segment decryption.

[0092] In some embodiments, the method further includes:

[0093] After stopping video playback or completing video decryption, encrypt the list file and / or the key file.

[0094] After the video stops playing or the video decryption is complete, the list file and / or key file are encrypted again. This ensures security after the video playback stops or the decryption is complete.

[0095] In some embodiments, the second key is updated when the list file and / or key file are encrypted again. That is, after the initial encryption of the list file and / or key file, the second key is dynamically updated every time the list file and / or key file are encrypted again on the first terminal device. This prevents leakage due to excessive use or prolonged use of a single second key, further enhancing the security of the video file.

[0096] First, because m3u8 files typically contain a key, this information is easily leaked. Furthermore, the decryption process occurs on mobile devices, and due to the inherent insecurity of mobile devices, the encryption algorithm may be vulnerable to being cracked. Additionally, since the video needs to be played offline, the video file resides on the device, posing a risk of it being copied and reused on other devices. This key can be the decryption key for the video file, which is the aforementioned first key.

[0097] The video processing method provided in this disclosure may include:

[0098] Step 1: The server segments and encrypts the video, generates an m3u8 file, generates a key file, and encrypts the key file.

[0099] Step 2: The APP obtains the video key from the server and stores it in the APP's internal storage space (sandbox space, which can only be accessed by the APP and cannot be read by external entities under normal circumstances) in a folder named after the device ID (the purpose is to bind the device so that it cannot be played even if other devices steal it).

[0100] Step 3: The APP downloads the segmented encrypted video file from the server and stores it in the APP's internal storage space; modifies the content of the m3u8 file, points the key location to the storage path of the key in step 2, and then encrypts the m3u8 file.

[0101] Step 4: When the APP plays the video, it first decrypts the m3u8 file, then decrypts the key, and finally the player automatically loads the m3u8 file to play the video.

[0102] Step 5: When playback stops, encrypt the m3u8 file and the key to prevent external theft.

[0103] Video files and key files are stored in the app's internal storage, which is generally inaccessible to other apps and can only be accessed by the app itself, effectively preventing the theft of video and other resources. The key is stored in a folder named after the device identifier (ID) and is bound to the device. If a hacker copies the app and video files to other devices, they cannot be played on those devices. Video files are also bound to the device ID, effectively preventing them from being copied and played on other devices.

[0104] Step 6: Decrypt the m3u8 file and key during playback, and re-encrypt it when playback stops, effectively preventing the key file from being stolen. Decrypting the m3u8 file and key when needed and encrypting them when not in use effectively hides critical data, greatly increasing the difficulty of analysis for hackers.

[0105] like Figure 3 As shown, this disclosure provides a video processing method based on m3u8 files, which may include:

[0106] The server processes the video segments and encrypts them, generating an m3u8 file and the encrypted key.

[0107] The app obtains the key from the server and stores it in a folder named after the device ID;

[0108] Obtain all video segments and m3u8 files and save them.

[0109] Modify the key path in the m3u8 file to point to the path where the key is located in the APP;

[0110] Encrypt the m3u8 file and the key file.

[0111] Determine whether to enter or exit playback mode. If playback mode is entered, play the video; if playback mode is exited, stop video playback.

[0112] If you enter playback mode, the app will automatically play the video after decrypting the m3u8 file and the key file.

[0113] If you exit playback mode, the m3u8 file and the key file will be encrypted.

[0114] like Figure 4 As shown, this disclosure provides a terminal device, which includes:

[0115] The receiving module 4101 is configured to receive a video file, a playlist file, and a key file based on a first application (APP) of the first terminal device; the video file includes one or more video segments; the playlist file includes a playlist and the key file; the key file includes a first key; the first key is used to decrypt the video file;

[0116] Storage module 4102 is used to store the key file in a first storage space; the first storage space allows the first APP to access it but prohibits the second APP from accessing it; the second APP is different from the first APP;

[0117] The writing module 4103 is used to write key information into the list file according to the storage address of the key file in the first storage space; the key information is used to read the key file.

[0118] Reading module 4104 is used to read the first key from the first storage space based on the first APP and the key information when decrypting the video file;

[0119] The decryption module 4105 is used to decrypt the video file using the first key.

[0120] The terminal device may be the aforementioned first terminal device.

[0121] In some embodiments, the receiving module may correspond to the network interface or transceiver antenna of the terminal device.

[0122] In some embodiments, the storage module may correspond to the memory of the terminal device.

[0123] In some embodiments, the write module, read module, and decryption module may correspond to the processor of the terminal device.

[0124] In some embodiments, the storage module is configured to store the key file in a target folder of the first storage space; the target file is accessible to the first terminal device but inaccessible to the second terminal device; the second terminal device is different from the first terminal device.

[0125] In some embodiments, the target folder is named after the device identifier of the first terminal device, and the device identifier is used to verify whether the user has the right to access the target folder.

[0126] In some embodiments, the terminal device further includes:

[0127] An encryption module is used to encrypt the key file and / or the list file storing the key information using a second key.

[0128] This encryption module can also be the processor in the terminal device.

[0129] In some embodiments, the storage module is used to store the second key in a second storage space; the second storage space is different from the first storage space.

[0130] In some embodiments, the decryption module is configured to decrypt the list file using the second key when decrypting the video file; read the key information after decrypting the list file; and read the first key from the key file in the first storage space according to the key information.

[0131] In some embodiments, the encryption module is configured to encrypt the list file and / or the key file when video playback is stopped.

[0132] like Figure 5As shown, this disclosure provides a terminal device. The terminal device may include a processor 501 and a memory 502, which can be used to execute the video processing method provided in any of the foregoing embodiments. The processor 501 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Here, the program executed by the processor 501 may be stored in the memory 502 connected to the processor 501 via a communication bus 503. The memory 502 may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache.By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), Sync Link Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM). The memory 502 described in this embodiment of the invention is intended to include, but is not limited to, these and any other suitable types of memory 502. The memory 502 in this embodiment of the invention is used to store various types of data to support the operation of the processor 501. Examples of this data include: any computer programs operated by the processor 501, such as operating systems and applications; contact data; phonebook data; messages; pictures; videos, etc. The operating system contains various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks.

[0133] In some embodiments of the present invention, the memory 502 may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory may be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 502 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0134] The processor 501 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 501 or by instructions in software form. The processor 501 can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 502, and the processor 501 reads the information in memory 502 and, in conjunction with its hardware, completes the steps of the above method. In some embodiments, the embodiments described herein can be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0135] For software implementation, the techniques described herein can be achieved through modules (e.g., procedures, functions, etc.) that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented within the processor or externally.

[0136] Another embodiment of the present invention provides a computer storage medium storing an executable program, which, when executed by a processor 501, can implement the steps of a video processing method applied to the endpoint device. For example, as... Figures 1 to 3 One or more of the methods shown.

[0137] In some embodiments, the computer storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0138] It should be noted that the technical solutions described in the embodiments of the present invention can be combined arbitrarily without conflict.

[0139] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention.

Claims

1. A video processing method, characterized in that, Executed by the first terminal device, including: A first APP on the first terminal device receives a video file, a playlist file, and a key file; the video file includes one or more video segments; the playlist file includes a playlist and the key file; the key file includes a first key; the first key is used to decrypt the video file. The key file is stored in a first storage space; the first storage space allows access from the first APP but prohibits access from the second APP; the second APP is different from the first APP. The key file is stored in a target folder in the first storage space; the target file is accessible to the first terminal device but inaccessible to the second terminal device; the second terminal device is different from the first terminal device; the target folder is named with the device identifier of the first terminal device, and the device identifier is used to verify whether accessing the target folder is authorized; Based on the storage address of the key file in the first storage space, key information is written into the list file; the key information is used to read the key file; the key file and the list file are encrypted by a second key, which is stored in a second storage space; the second storage space is independent of the first storage space and is a storage space that the first APP cannot directly access; When decrypting the video file, the first key is read from the first storage space based on the first APP and the key information; Decrypt the video file using the first key; When video playback stops, update the second key; The list file and the key file are encrypted using the updated second key.

2. The method according to claim 1, characterized in that, When decrypting the video file, reading the first key from the first storage space based on the first APP and the key information includes: When decrypting the video file, the second key is used to decrypt the list file; After decrypting the list file, the key information is read; Based on the key information, the first key is read from the key file in the first storage space.

3. A terminal device, characterized in that, The terminal device is a first terminal device, comprising: A receiving module is used to receive a video file, a playlist file, and a key file based on a first APP on a terminal device; the video file includes one or more video segments; the playlist file includes a playlist and the key file; the key file includes a first key; the first key is used to decrypt the video file. A storage module is used to store the key file in a first storage space; the first storage space allows the first APP to access it but prohibits the second APP from accessing it; the second APP is different from the first APP; The writing module is used to write key information into the list file according to the storage address of the key file in the first storage space; the key information is used to read the key file; the key file is stored in a target folder in the first storage space; the target file is accessible to the first terminal device but inaccessible to the second terminal device; the second terminal device is different from the first terminal device; the target folder is named with the device identifier of the first terminal device, and the device identifier is used to verify whether access to the target folder is authorized; the key file and the list file are encrypted with a second key, which is stored in a second storage space; the second storage space is independent of the first storage space and is a storage space that the first APP cannot directly access; The reading module is used to read the first key from the first storage space based on the first APP and the key information when decrypting the video file; The decryption module is used to decrypt the video file using the first key; An encryption module is used to update the second key when video playback stops; and to encrypt the list file and the key file using the updated second key.

4. A terminal device, characterized in that, include: Memory, at least for storing computer-executable instructions; A processor, connected to the memory, is configured to implement the method of claim 1 or 2 through the execution of computer-executable instructions.

5. A computer storage medium, characterized in that, The computer storage medium stores computer-readable instructions, which, when executed, enable the execution of the method described in claim 1 or 2.

Images