A video data protection method, device, computer equipment and storage medium

Abstract

The application relates to a video data protection method and device, computer equipment and a storage medium. The method comprises the following steps: after receiving a playing request of a target video from a client, creating a playing session, and determining a data distribution window according to a session state; obtaining media index information of the target video, and selecting a window data unit in the data distribution window; generating data access identification and key access identification for the window data unit and a media key, and establishing an authorization relationship; generating a media sub-index based on the window data unit and the access identification, and sending the media sub-index to the client; after receiving an access request, verifying based on the authorization relationship, and providing the corresponding window data unit and / or the media key after verification. According to the application, the video data and decryption information that can be obtained by the client can be dynamically restricted in the video on demand process, the risk that the request entry is excessively exposed and is requested by a batch of simulating players is reduced, and the download protection capability for the video data is improved.

Description

Technical Field

[0001] This application relates to the fields of streaming video security and digital rights protection technology, and in particular to a video data protection method, apparatus, computer equipment, and storage medium. Background Technology

[0002] In web-based video-on-demand scenarios, video resources are typically transmitted in segments. For example, a playback index records the acquisition paths of multiple video segments, and the client continuously requests the corresponding segments based on this playback index to complete playback. Because the web-based playback environment is relatively open, network requests, index content, and request parameters during playback are relatively easy to observe or intercept. For instance, users can directly view the video segment request addresses through the network panel of their browser's developer tools, copy them, and then download them in batches using download tools. Alternatively, after obtaining the playback index, they can infer the addresses of subsequent segments based on the exposed segment addresses or regular path structures. Furthermore, they can intercept requests carrying authentication parameters using packet sniffing tools and replay or forge requests in batches within the validity period of the authentication parameters. Moreover, if the playback index itself lacks effective protection, even if access control is set for individual video segments, attackers may still obtain a complete or near-complete sequence of video segments through the leaked index content, thereby bypassing the normal player process to obtain video data.

[0003] While existing technologies have proposed methods such as URL authentication, access tokens, request timeliness control, index file protection, and video content encryption to raise the barrier to entry for video resources, these methods often tend to protect individual requests, individual files, or single access stages in practical applications. There is a lack of linkage constraints between the entry point for obtaining video segments and the entry point for obtaining decryption information, which are matched with the actual playback process. Specifically, once the client obtains a relatively complete playback index, segment request entry point, and corresponding key request entry point during a legitimate on-demand process, it may still simulate player behavior, bypass the normal playback rhythm, and request video segments and their decryption information in batches, thereby recovering playable video content. Summary of the Invention

[0004] Therefore, it is necessary to provide a video data protection method, device, computer equipment, and storage medium that can dynamically constrain the video data and its decryption information available to the client during video-on-demand, so as to at least solve the technical problem in the related art that the video data request entry and the corresponding decryption information request entry are easily overexposed during playback, and thus can be requested in batches by the simulated player.

[0005] Firstly, a video data protection method is provided, applied on a server side, the method comprising: In response to receiving a playback request from a client for a target video, a playback session is created, and a data distribution window is determined based on the session state of the playback session to at least characterize the range of video data currently allowed to be provided to the client. Obtain the media index information of the target video, and select the window data unit in the data distribution window from the video data units indicated by the media index information; Determine the data access identifier corresponding to the window data unit and the key access identifier for the media key used to decrypt the window data unit, and establish the authorization relationship between the data access identifier, the key access identifier, the playback session, the data distribution window, the window data unit, and the media key; A media sub-index is generated based on the window data unit, the data access identifier, and the key access identifier, and the media sub-index is sent to the client so that the client can initiate an access request to the server carrying the data access identifier and / or the key access identifier based on the media sub-index. In response to receiving the access request, the access request is verified based on the authorization relationship. If the verification is successful, the client is provided with the window data unit corresponding to the access request and / or the media key used to decrypt the window data unit, and the session state of the playback session is updated.

[0006] Secondly, a video data protection method is provided, applied to a client, the method comprising: Upon receiving a video-on-demand request, the target video is determined, a corresponding playback request is generated, and sent to the server. Receive and parse the media sub-index returned by the server in response to the playback request to obtain the data access identifier corresponding to the video data unit in the current window, and the key access identifier for the media key used to decrypt the video data unit; Initiate an access request carrying the data access identifier to the server to obtain the video data unit; Initiate an access request carrying the key access identifier to the server to obtain the media key; The corresponding video data unit is decrypted based on the media key to obtain the video data of the current window and then played.

[0007] Thirdly, a video data protection device is provided for use on a server, the device comprising: The session window determination module is used to create a playback session in response to receiving a playback request sent by a client for a target video, and to determine a data distribution window based on the session state of the playback session to at least characterize the range of video data that is currently allowed to be provided to the client. The window unit selection module is used to obtain the media index information of the target video and select the window data unit located in the data distribution window from the video data units indicated by the media index information; The authorization relationship establishment module is used to determine the data access identifier corresponding to the window data unit and the key access identifier used to decrypt the media key of the window data unit, and to establish the authorization relationship between the data access identifier, the key access identifier and the playback session, the data distribution window, the window data unit and the media key; The sub-index sending module is used to generate a media sub-index based on the window data unit, the data access identifier, and the key access identifier, and send the media sub-index to the client, so that the client can initiate an access request to the server carrying the data access identifier and / or the key access identifier based on the media sub-index; The access request processing module is configured to, in response to receiving the access request, verify the access request based on the authorization relationship; if the verification is successful, provide the client with the window data unit corresponding to the access request and / or the media key for decrypting the window data unit, and update the session state of the playback session.

[0008] Fourthly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the above-described video data protection methods.

[0009] Fifthly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the video data protection methods described above.

[0010] The aforementioned video data protection methods, devices, computer equipment, and storage media do not expose the complete video segment sequence and key request entry point to the client all at once at the beginning of playback. Instead, they release the media access content required within the current playback range in stages according to the progress of the playback session. The video data acquisition entry point and the corresponding decryption information acquisition entry point are incorporated into the same session control system for correlation verification. Thus, even if the client observes or intercepts part of the index content, segment request information, or key request information through developer tools, packet capture tools, etc. during web playback, the content it can use is limited to the current session and the current playback range. It is difficult to directly infer, replay, or construct the complete video segment requests and key requests in batches based on this. At the same time, the server can continuously update the playback session state as access requests are processed, so that the range of subsequently accessible video data changes dynamically with the normal playback process. This ensures normal continuous playback for the client while avoiding excessive exposure of the complete media data sequence and corresponding decryption information request entry point, improving the linkage access control capability of video data and media keys, and reducing the possibility that the legitimate playback process can be exploited by batch download tools to recover the complete playable video content. Attached Figure Description

[0011] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a diagram illustrating the application environment of a video data protection method in one embodiment; Figure 2 This is a schematic diagram of a video data protection method applied to the server in one embodiment; Figure 3 This is a schematic diagram of a video data protection method applied to a client in one embodiment; Figure 4 This is a diagram illustrating the application environment of the video data protection method in another embodiment; Figure 5 This is a structural block diagram of a video data protection device applied to a server in one embodiment; Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0014] This application provides a video data protection method that can be applied to, for example... Figure 1 In the application environment shown, client 101 communicates with server 102 via a network. In response to a user's video-on-demand operation for a target video, client 101 sends a playback request to server 102. Upon receiving the playback request, server 102 creates a corresponding playback session for client 101 and determines the data distribution window currently allowed to provide video data to client 101 based on the session state. Server 102 selects video data units within the data distribution window based on the media index information of the target video and configures data access identifiers and key access identifiers for the selected video data units and their corresponding media keys, establishing authorization relationships between each access identifier and the playback session, data distribution window, video data units, and media keys. Subsequently, server 102 generates media based on the video data units and their access identifiers within the current window. The client 101 parses the media sub-index and requests the corresponding video data unit and media key from the server 102 based on the data access identifier and key access identifier contained therein. The server 102 verifies the access request sent by the client 101 based on the pre-established authorization relationship. After successful verification, the server 102 provides the corresponding video data unit and / or media key to the client 101 and updates the session state of the playback session according to the provision of the corresponding resources, so as to dynamically adjust the range of video data allowed to be provided to the client 101 as the video playback process progresses. The client 101 uses the obtained media key to decrypt and play the corresponding video data unit, thereby meeting the normal video-on-demand requirements while reducing the exposure of the complete video data sequence and its decryption information access point on the client side. The client 101 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server 102 can be implemented as a standalone server or as a server cluster consisting of multiple servers. The network between client 101 and server 102 may include, but is not limited to, the Internet, wide area network, local area network, mobile communication network or any combination thereof.

[0015] In one embodiment, such as Figure 2 As shown, a video data protection method is provided, which is applied to... Figure 1 Taking server 102 as an example, the explanation includes the following steps: Step 201: In response to receiving a playback request from the client for the target video, a playback session is created, and a data distribution window is determined based on the session state of the playback session to at least characterize the range of video data that is currently allowed to be provided to the client. Step 202: Obtain the media index information of the target video, and select the window data unit in the data distribution window from the video data units indicated by the media index information; Step 203: Determine the data access identifier corresponding to the window data unit and the key access identifier used to decrypt the media key of the window data unit, and establish the authorization relationship between the data access identifier, the key access identifier and the playback session, the data distribution window, the window data unit and the media key. Step 204: Generate a media sub-index based on the window data unit, data access identifier, and key access identifier, and send the media sub-index to the client so that the client can initiate an access request carrying the data access identifier and / or key access identifier to the server based on the media sub-index; Step 205: In response to receiving an access request, the access request is verified based on the authorization relationship. If the verification is successful, the client is provided with the window data unit corresponding to the access request and / or the media key used to decrypt the window data unit, and the session state of the playback session is updated.

[0016] In the aforementioned video data protection method, the server does not expose the complete video segment sequence and the complete key request entry to the client all at once at the beginning of playback. Instead, it releases the media access content required within the current playback range in stages according to the progress of the playback session. The video data acquisition entry and the corresponding decryption information acquisition entry are incorporated into the same session control system for correlation verification. Thus, even if the client observes or intercepts part of the index content, segment request information, or key request information through developer tools, packet capture tools, etc., during web playback, the content it can use is limited to the current session and the current playback range. It is difficult to directly infer, replay, or construct the complete video segment requests and key requests in batches based on this. At the same time, the server can continuously update the playback session state as access requests are processed, so that the range of subsequently accessible video data changes dynamically with the normal playback process. This ensures normal continuous playback for the client while avoiding excessive exposure of the complete media data sequence and the corresponding decryption information request entry, improving the linkage access control capability of video data and media keys, and reducing the possibility that the legitimate playback process can be exploited by batch download tools to recover the complete playable video content.

[0017] In one embodiment, in response to receiving a playback request from a client for a target video, a playback session is created, and a data distribution window is determined based on the session state of the playback session to at least characterize the range of video data currently allowed to be provided to the client, including: Parse the playback request to obtain the video identifier of the target video and determine whether the playback request carries start parameters; The playback request may include one or more of the following: video identifier, client identifier, user authentication information, playback resolution information, playback protocol type, and start-up parameters. The video identifier uniquely or relatively uniquely indicates the target video; for example, it may be a video number, content number, resource number, media asset identifier in a media asset system, or an identifier derived from the above information. The start-up parameters characterize the position at which the client expects to begin playback, and may include one or more of the following: playback time point, playback progress percentage, video data unit sequence number, resume playback identifier, or historical playback progress identifier. A playback session is created based on the video identifier, and a session identifier is generated for the playback session; The session identifier is used to distinguish different playback processes and can be generated by one or more of the following: random number, timestamp, video identifier, client identifier, and server signature information. For example, it can be a UUID, snowflake algorithm identifier, random token, or a string generated based on a hash algorithm. If the playback request includes a start-up parameter, the requested playback position is determined based on the start-up parameter, and the requested playback position is set as the current distribution position of the playback session; if the playback request does not include a start-up parameter, the starting playback position of the target video is set as the current distribution position of the playback session. Write the video identifier, session identifier, and current distribution position into the session state of the playback session; The session status of the playback session may include one or more of the following: video identifier, session identifier, current distribution location, current data distribution window, window access status, session creation time, last access time, and session validity period. Using the current distribution position as the starting position of the window, extend the window along the playback direction of the target video for a preset playback duration or a preset number of video data units to determine the ending position of the window; The current distribution position can be the time position on the target video playback timeline, or the video data unit sequence number or index position corresponding to that time position; the preset playback duration can be set according to the video playback protocol, segment duration, network quality, and anti-theft strategy, for example, it can be set to 10 to 120 seconds, preferably 20 to 60 seconds; the preset number of video data units can be set according to the average playback duration of a single video data unit, for example, it can be set to 2 to 20 video data units, preferably 3 to 8 video data units; the above values ​​are only examples, and in actual applications, they can be dynamically adjusted by the server according to video clarity, bitrate, client network status, or business security level; A data distribution window is generated based on the start and end positions of the window, and then the data distribution window is bound to the playback session. The data distribution window is used to limit the range of video data that the server is currently allowed to provide to the client. It may include one or more of the following: window identifier, window start position, window end position, set of video data units within the window, and window validity period.

[0018] Preferably, the requested playback position can be obtained in the following ways: if the start parameter is a playback time point, then that playback time point is determined as the requested playback position; if the start parameter is a playback progress ratio, then the requested playback position is calculated based on the total playback duration of the target video and the playback progress ratio; if the start parameter is a video data unit number, then the requested playback position is determined based on the playback time interval corresponding to that video data unit in the media index information; if the start parameter is a breakpoint resume identifier or a historical playback progress identifier, then the client or user's corresponding historical playback record is queried based on the identifier, and the queried historical playback position is determined as the requested playback position. If the position indicated by the start parameter is earlier than the target video's start playback position, then the target video's start playback position can be determined as the requested playback position; if the position indicated by the start parameter is later than the target video's end playback position, then a playback end prompt, a start parameter error prompt, or a preset position before the target video's end position can be returned as the requested playback position.

[0019] Specifically, the end position of the window can be obtained in the following ways: When a preset playback duration is used to determine the data distribution window, the current distribution position is added to the preset playback duration to obtain the candidate window end position. If the candidate window end position does not exceed the end playback position of the target video, then the candidate window end position is used as the window end position; if the candidate window end position exceeds the end playback position of the target video, then the end playback position of the target video is used as the window end position. When a preset number of video data units are used to determine the data distribution window, a preset number of video data units can be selected starting from the video data unit corresponding to or adjacent to the current distribution position, along the playback direction of the target video, and the window end position is determined based on the playback end position of the last selected video data unit. If the current distribution position has reached or exceeded the end playback position of the target video, a data distribution window containing video data units can be omitted, or an empty window can be generated to indicate the end of playback.

[0020] Preferably, binding the data distribution window to the playback session means establishing a correspondence between the data distribution window and the playback session in the session storage, authorization record table, caching system or memory object on the server side, so that subsequent access requests for video data units and media keys within the data distribution window can be traced back to the corresponding playback session.

[0021] Specifically, this implementation identifies the target video and start-up parameters during the playback request phase, and establishes a playback session state containing session identifier, video identifier, and current distribution position. This allows the server to clearly identify which video, which session, and from which playback position the video content distribution begins for this playback request. Based on this, a data distribution window is generated starting from the current distribution position, ensuring that the media content initially obtained by the client matches the actual playback requirements without exposing the complete segment sequence of the target video to the client. This approach, on the one hand, is compatible with different playback scenarios such as playback from the video's starting position, playback from a specified position, or resumed playback, avoiding playback loss or repetition due to inaccurate window start points. On the other hand, it limits the video data that the client can obtain at the current stage to a preset playback duration or a preset number of video data units, thus providing a basis for subsequent dynamic distribution, authorization verification, and window updates based on the playback session state, reducing the possibility of the client obtaining the complete video access entry at the start of playback.

[0022] In one embodiment, obtaining media index information of the target video and selecting a window data unit located in the data distribution window from the video data units indicated by the media index information includes: Based on the video identifier of the target video, obtain the media index information of the target video; The media index information describes the organization and access methods of each video data unit in the target video. For example, it can be an M3U8 index file in the HLS protocol, an MPD file in the DASH protocol, or a media index file customized by the server. The media index information may include one or more of the following: index attribute information, multiple index entries, playback duration of the video data unit, storage address of the video data unit, video data unit sequence number, encryption method, key indication information, and initialization segment information. Preferably, the server can obtain media index information from an object storage system, file storage system, database, caching system, or media asset management system based on the video identifier; if the media index information corresponding to the video identifier is not obtained, the server can return a prompt to the client that the video does not exist, the index is missing, or the video is temporarily unplayable; if the media index information is obtained but parsing fails, the server can return an index error prompt or retrieve the media index information from an alternative storage location. The media index information is parsed to obtain multiple index entries, each of which corresponds to a stored video data unit; Among them, video data units can refer to video segments, media segments, slice files, chunk files, or other video data components that can be requested and played by the client in sequence; Based on the order of multiple index entries in the media index information and the playback duration recorded in each index entry, the playback time range of each video data unit in the target video is determined. The playback time interval of each video data unit is compared with the data distribution window; If the start time of the playback time interval of any video data unit is earlier than the end position of the data distribution window, and the end time of the playback time interval is later than the start position of the data distribution window, then the video data unit is determined as a window data unit.

[0023] Specifically, the playback time interval of each video data unit can be obtained as follows: Following the order of multiple index entries in the media index information, the playback start time of the video data unit corresponding to the first index entry is determined as the starting playback position of the target video. For the i-th index entry, the sum of the playback durations recorded by all index entries preceding the i-th index entry is determined as the playback start time of the i-th video data unit, and the sum of this playback start time and the playback duration recorded by the i-th index entry is determined as the playback end time of the i-th video data unit. Thus, the playback time interval of each video data unit on the target video playback timeline can be obtained. If the media index information has already explicitly recorded the start time, end time, or timestamp mapping relationship of the video data unit, the playback time interval can also be directly determined based on this explicit record.

[0024] Specifically, the data distribution window can be represented by a left-closed, right-open time interval, meaning the window's starting position belongs to the data distribution window, while its ending position does not. In this case, if the start time of the playback time interval of a video data unit is earlier than the end time of the data distribution window, and the end time of the playback time interval is later than the start time of the data distribution window, then the video data unit overlaps with the data distribution window and is therefore identified as a window data unit. If the end time of the playback time interval of a video data unit is not later than the start time of the data distribution window, or the start time of the playback time interval is not earlier than the end time of the data distribution window, then the video data unit is not within the current data distribution window and may not be identified as a window data unit.

[0025] Specifically, if no window data unit is selected according to the above method, it can be determined whether the target video has finished playing based on the current distribution position; if the target video has finished playing, playback end information or empty media sub-index is returned to the client; if the target video has not finished playing but no window data unit is selected, the current distribution position can be recalibrated based on the media index information, or an error message can be generated by returning a window.

[0026] Specifically, this implementation determines the actual playback time interval of each video data unit in the target video by parsing the arrangement order and playback duration of each index entry in the media index information. This playback time interval is then compared with the data distribution window to accurately filter out video data units that have a time overlap with the current playback window. This method does not simply extract video segments according to a fixed number or fixed file sequence number, but rather judges based on the actual position of the video data unit on the playback timeline. Therefore, it can adapt to different segment durations, different index arrangement methods, and situations where the window boundary falls in the middle of a segment. As a result, it can avoid providing too many video data units outside the current window to the client, reducing the exposure range of index content and data access entry points, and also avoid omitting necessary video data units that intersect with the window boundary, ensuring that the client can continuously and completely play the corresponding video content within the current window.

[0027] In one embodiment, the data access identifier of the window data unit and the key access identifier of the media key associated with the window data unit are determined, and the authorization relationship between the data access identifier, the key access identifier, the playback session, the data distribution window, the window data unit, and the media key is established, including: For each window data unit, determine the index entry corresponding to the window data unit in the media index information, and extract the original data address of the window data unit from the index entry; The original data address refers to the address of the original record in the media index information used to access the window data unit. For example, it can be a storage path, object storage address, CDN address, file system path or other resource location information. The original resource name of the window data unit is determined based on the original data address, and the original resource name is subjected to preset obfuscation processing to obtain the obfuscated resource name; The original resource name can be a file name, object name, path terminator name, or name that indicates the storage resource of the video data unit in the original data address; the preset obfuscation process is used to make it difficult for the client to directly deduce the original data address or original resource name from the data access identifier, which can include hash processing, salted hash processing, encoding conversion, string rearrangement, mapping table replacement, truncation processing, or a combination of the above methods; the obfuscated resource name is not required to be able to be restored by the client, and it can only serve as the external display name for the server to identify or route access requests; A data access token is generated based on the session identifier of the playback session, the window identifier of the data distribution window, the unit identifier of the window data unit, and the preset first expiration time. Among them, the window identifier is used to distinguish different data distribution windows in the same playback session, and can be generated based on one or more of the session identifier, window start position, window end position, window generation time, and random number; the unit identifier of the window data unit is used to distinguish different video data units, and can be the sequence number, segment number, object number, hash value corresponding to the original resource name, or internal identifier generated by the server for the video data unit in the media index information. Preferably, the data access token can be obtained by signing the session identifier, window identifier, unit identifier, first expiration time, and server key. For example, it can be generated using the HMAC algorithm, digital signature algorithm, JWT token structure, or a server-customized token structure. The first expiration time can be set according to the playback duration of the data distribution window, the network jitter tolerance time, and the security level. For example, it can be set to 30 to 180 seconds after the current time, or it can be set to the sum of the playback duration of the data distribution window and the preset buffer duration. The preset buffer duration can be 5 to 60 seconds to tolerate client request delays and network transmission delays. Generate a one-time random number for the window data unit and record that the one-time random number is valid; One-time random numbers are used to restrict the repeated use of the same data access identifier. They can be random strings, random integers, UUIDs, or random bit sequences with a preset number of bits, such as 128-bit or 256-bit random numbers. The server can record the status of one-time random numbers in a caching system, database, or session state. A valid one-time random number indicates that the data access identifier has not been successfully used. An invalid one-time random number indicates that the data access identifier has been successfully used or has expired and should not be used again to obtain the corresponding window data unit. Based on a preset data access identifier format, the obfuscated resource name, data access token, and one-time random number are combined to generate a data access identifier; The preset data access identifier format can be a path format, query parameter format, token encapsulation format, or a combination thereof. For example, the data access identifier can include three parts: an obfuscated resource name, a data access token, and a one-time random number, enabling the client to use this data access identifier as a data request entry point in the media sub-index, but not to directly obtain the original data address; Based on the media index information, determine the key indication information that is valid for the window data unit, and extract the original key address and key description information from the key indication information; The key indication information refers to the information in the media index information used to indicate the encryption method and key acquisition method of the video data unit. It may include one or more of the following: encryption algorithm, key address, key number, initialization vector, key scope, and key description information. For example, in the HLS scenario, the key indication information may include fields describing the encryption method, the key's Uniform Resource Identifier, and the initialization vector; in the DASH scenario, the key indication information may include content protection description information, key identifier, and encryption scheme description information; the key description information may include the encryption algorithm, key identifier, initialization vector, key version, key scope, or non-sensitive description fields that the player needs to retain when decrypting. The media key associated with the window data unit is obtained based on the original key address, and a key access token is generated based on the session identifier of the playback session, the data distribution window, the unit identifier of the window data unit, and the preset second expiration time. Preferably, the media key can be obtained by the server from a key management system, object storage system, database, or encryption service based on the original key address; the second expiration time can be set according to the security level of the media key, the validity period of the data distribution window, and the client's decryption needs, for example, it can be set to 30 to 300 seconds after the current time; the second expiration time can be the same as or different from the first expiration time; in one implementation, the second expiration time can be slightly longer than the first expiration time so that the client can still request the corresponding media key within a short time after successfully obtaining the video data unit; in another implementation, the second expiration time can be shorter than the first expiration time to improve the security of key access; Based on the preset key access identifier format, the key access token is encapsulated to generate a key access identifier; The preset key access identifier format can be a key request path, a key request token, or an encapsulated key access string, which at least enables the server to identify the corresponding key access token and authorization record when it receives a key request. Establish a first authorization record with the data access identifier as the query identifier. The first authorization record shall include at least the playback session, the data distribution window, the window data unit, the original data address, and a one-time random number. Establish a second authorization record with the key access identifier as the query identifier. The second authorization record includes at least the playback session, data distribution window, window data unit, and media key. The first authorization record and the second authorization record can be stored in the server's database, caching system, in-memory data structure, or distributed session storage; the first authorization record may also include one or more of the following: data access token digest, first expiration time, client identifier, access count, access status, and risk flag; the second authorization record may also include one or more of the following: key access token digest, second expiration time, key identifier, key description information, client identifier, and access status. By associating the first and second authorization records corresponding to the same window data unit, the authorization relationship can be obtained; Preferably, associating the first authorization record and the second authorization record corresponding to the same window data unit can be achieved by writing the same session identifier, window identifier and unit identifier into the two types of authorization records, or by writing each other's record identifiers into the authorization records.

[0028] Specifically, valid key indication information for a window data unit can be determined as follows: If the media index information explicitly records key indication information at the corresponding index entry for that window data unit, then that key indication information is determined to be valid for that window data unit; if the index entry does not explicitly record key indication information, then the most recently occurring key indication information that has not yet been replaced by new key indication information can be searched backwards along the arrangement direction of the index entries in the media index information, and that key indication information is determined to be valid for that window data unit. If no valid key indication information is found, then it can be determined that the window data unit is not encrypted, or a key configuration error message can be returned. For unencrypted video data units, a key access identifier may not be generated, or an empty key identifier may be generated to indicate that a media key is not required.

[0029] Specifically, in this implementation, by converting the original data address of the window data unit into a data access identifier and the original key address of the media key into a key access identifier, the client can avoid directly knowing the real resource path of the video data and key in the server or storage system, thereby reducing the possibility of attackers speculating on subsequent fragment addresses or key addresses based on the original address patterns. At the same time, the data access identifier and key access identifier are not simply address replacements, but are associated with the playback session, data distribution window, window data unit, expiration time, and corresponding authorization records, so that the intercepted access identifier can only be used in a specific authorization context. Furthermore, by setting a one-time random number for the data access identifier and associating the data authorization record corresponding to the same window data unit with the key authorization record, video data requests and key requests can be subject to consistent session constraints and content constraints, reducing the risk that attackers may recover the complete video content locally after separately obtaining video fragments and media keys in batches.

[0030] In one specific embodiment, the obfuscated resource name in the data access identifier can be generated through a deterministic mapping method. Specifically, the server can generate the obfuscated resource name based on the original resource name of the window data unit, the video data unit sequence number, the playback time position, or a server-preset mapping rule. For example, the original resource name with a fixed length or continuous numbering pattern can be converted into a short resource name, summary resource name, or encoded resource name that does not directly reflect the original naming pattern. Correspondingly, in scenarios where the client needs to restore the obfuscated resource name, the playback logic component in the client can convert the obfuscated resource name into a resource name or request resource name that the server can recognize based on the deterministic rule corresponding to the server, and encapsulate the converted resource name together with access credentials such as the data access token and a one-time random number into an access request. It should be understood that this deterministic mapping method is only one lower-level implementation of the obfuscated resource name; in other embodiments, the obfuscated resource name may not be restored by the client, but may be directly parsed or routed to the corresponding original data address by the server based on the authorization record.

[0031] In one specific embodiment, the data access identifier can employ a non-intuitive path structure to hide the actual storage path of the video data unit. For example, the data access identifier can be represented as a proxy path pointing to the server or a proxy server, carrying obfuscated resource names, data access tokens, timestamps, one-time random numbers, or window identifiers, instead of directly carrying the object storage path, video resolution directory, real filename, or bucket identifier. Upon receiving an access request based on this data access identifier, the server can parse the corresponding playback session, data distribution window, and window data unit according to the authorization relationship, and then determine the actual original data address. This reduces the possibility of attackers inferring the storage pattern of the complete video data unit based on the path structure in the media sub-index.

[0032] In one specific embodiment, the data access token can be a short-term access token. Specifically, the server can generate a signature based on one or more of the following: request path, session identifier, window identifier, unit identifier of window data unit, timestamp, expiration time, and server key, and write the signature and timestamp into the data access token. After receiving the access request, the server can verify whether the signature is correct and determine whether the timestamp or expiration time carried in the access request is within the allowed time window. If the signature verification fails or the current time has exceeded the allowed time window, the access request verification is deemed unsuccessful, and the corresponding window data unit is refused. The allowed time window can be set according to playback buffering requirements and security levels, for example, it can be set to 30 seconds, 60 seconds, 120 seconds, or other short-term durations.

[0033] In one embodiment, generating a media sub-index based on a window data unit, a data access identifier, and a key access identifier includes: Extract basic description information for describing index attributes from media index information, and adapt the description fields related to the video data unit range in the basic description information according to the data distribution window to obtain target description information; The basic description information describes the overall attributes of the media index, which may include one or more of the following: protocol version, index type, target segment duration, media sequence number, playback start position, total playback duration, bitrate information, resolution information, initial segment information, time base information, and content type information. The description fields related to the range of video data units refer to the fields that need to be adjusted because the media sub-index only contains a portion of the video data units, such as media sequence number, start number, number of segments, window playback duration, start time, end time, and whether the index has ended. Based on the arrangement order of each window data unit in the media index information, determine the index entry corresponding to each window data unit and generate a set of index entries to be output. The set of index entries to be output refers to the set of index entries that are filtered according to the data distribution window and are prepared to be written into the media sub-index. The order of each index entry in the set of index entries to be output is consistent with its order in the original media index information, so as to ensure that when the client requests video data units according to the media sub-index, it can still decode and play them in the correct playback order. Based on the authorization relationship, determine the data access identifier and key access identifier corresponding to each window data unit; For each index entry to be output in the set of index entries to be output, replace the original data address recorded in the index entry to be output with the data access identifier of the corresponding window data unit to obtain the target index entry; For each window data unit, determine the key indication information that is valid for the window data unit, replace the original key address in the key indication information with the key access identifier corresponding to the window data unit, and retain the key description information in the key indication information to obtain the target key indication information corresponding to the window data unit. The target key indication information is used to enable the client to determine the decryption method and key request entry corresponding to the window data unit. If multiple consecutive window data units use the same media key, the target key indication information can be written once before the first target index entry applicable to that media key. If different window data units use different media keys, the corresponding target key indication information can be written before the corresponding target index entry. If a key indication information in the original media index information is located before the data distribution window, but it is still valid for the first window data unit in the current window, then when generating the media sub-index, this key indication information can be converted into target key indication information and written before the first target index entry in the current window to ensure that the client can correctly obtain the media key corresponding to the window data unit. If the window data unit is not encrypted, the target key indication information can be omitted, or a description indicating that no key is required can be written. According to the index format of the media index information, the target description information is written into the corresponding index-level description position in the index content. According to the arrangement order of each window data unit in the media index information, the relative positional relationship between each target key indication information and the target index entry it acts on is maintained. Each target key indication information and each target index entry are written into the index content to generate a media sub-index. Maintaining the relative position of each target key indication information and the target index entry it applies to means that when generating a media sub-index, the target key indication information is placed before the target index entry to which it applies or at the position required by the media index format, so as to avoid the client mistakenly applying a media key to an incompatible video data unit. If the media index format also requires the initialization of segments, mapping information or time reference information, the corresponding information can be retained in the media sub-index, or the original address in it can be replaced with a controlled access identifier.

[0034] It's worth noting that if the set of index entries to be output is empty, an empty media sub-index can be generated to indicate that there are currently no video data units to distribute, or a message indicating that playback has ended, the window is empty, or a re-request should be sent to the client. If the format of the media index information is not supported by the server, a message indicating that the index format is not supported can be returned.

[0035] Preferably, adapting the basic description information may include at least one of the following processes: adjusting the media sequence number or starting number to the sequence number corresponding to the first window data unit within the current data distribution window; adjusting the playback duration field in the index to the playback duration corresponding to the data distribution window or the cumulative playback duration of the window data unit; adjusting the target segment duration to the value corresponding to the maximum playback duration in the window data unit, or retaining the target segment duration in the original media index information; deleting the end marker indicating the end of the complete video from the media sub-index, or retaining the end marker only when the current data distribution window has covered the end position of the target video.

[0036] Specifically, the target index entry can be obtained by copying the necessary playback description fields from the index entry to be output, excluding the original data address, such as playback duration, sequence number, byte range, timestamp, initial segment reference, and segment type; replacing the fields recording the original data address with the corresponding data access identifier; and deleting, setting to null, or replacing fields that do not affect playback but may expose the complete resource structure with server-generated controlled fields. Thus, the target index entry still retains the information needed by the client to play the current window's video data, but no longer carries the original video data access path.

[0037] Specifically, this implementation adapts the descriptive information in the media index based on the data distribution window, and only writes the video data units within the current window and their corresponding data access identifiers and key access identifiers into the media sub-index. This can limit the range of media resources visible to the client while preserving the index structure required by a normal player. Since the original data address and original key address in the media sub-index are replaced with access identifiers constrained by authorized relationships, even if the client obtains the media sub-index, it is difficult to directly know the real resource address or the complete video segment sequence. At the same time, by maintaining the relative positional relationship between the target key indication information and the target index entry it acts on, it can be ensured that the client can still correctly identify the decryption information corresponding to each video data unit when parsing the media sub-index, avoiding playback abnormalities caused by index pruning or address replacement. Thus, this implementation can balance the playability of the media sub-index with the controllability of the resource exposure range.

[0038] In one specific embodiment, the media sub-index can be encrypted as a whole before being sent to the client. Specifically, after generating the media sub-index, the server can use a symmetric encryption algorithm to encrypt the index content of the media sub-index, obtaining encrypted index data, and then send the encrypted index data to the client. After receiving the encrypted index data, the client can decrypt the encrypted index data using the session key corresponding to the playback session, the client-preset key, the negotiated key, or the index decryption key dynamically obtained from the server, to obtain the media sub-index, and complete the parsing of the media sub-index in the client's memory. Preferably, the client can directly hand over the decrypted media sub-index to the playback component for use, without writing the complete decrypted index content into the page document object model or global variables. Thus, even if the media sub-index request process is observed, the attacker can only obtain the encrypted index data, making it difficult to directly obtain the arrangement relationship of video data units, data access identifiers, and key access identifiers within the current window.

[0039] In one embodiment, the access request is verified based on the authorization relationship. If the verification is successful, the client is provided with the window data unit corresponding to the access request and / or the media key used to decrypt the window data unit, and the session state of the playback session is updated, including: Parse the access request and determine the access identifier carried in the access request. The access identifier includes one or more of the following: data access identifier and key access identifier. The access request can be a video data request, key request, or merging request initiated by the client based on the media sub-index; the access request can carry one or more of the following: data access identifier, key access identifier, session identifier, client identifier, user authentication information, request timestamp, and request signature; if the access request does not carry either the data access identifier or the key access identifier, the server can reject the access request and return an access identifier missing prompt. If the access identifier includes a data access identifier, then the data access identifier is used as the query identifier to retrieve the corresponding first authorization record from the authorization relationship; Based on the first authorization record and the data access token in the data access identifier, data access authorization verification is performed on the access request. The data access authorization verification includes access credential validity verification and authorization context consistency verification. The access credential validity verification is performed at least based on the status information of the data access token, the first expiration time, and the one-time random number. The authorization context consistency verification is performed at least based on the session identifier, the window identifier, and the unit identifier of the window data unit. If the data access authorization verification passes, the one-time random number in the first authorization record is updated from valid to invalid using an atomic operation, and the corresponding window data unit is provided to the client based on the original data address in the first authorization record; An atomic operation is an operation that updates a one-time random number from a valid state to an invalid state, and this operation cannot be successfully executed repeatedly by concurrent requests. For example, the server can implement this atomic operation through database condition updates, comparison and exchange operations in the cache system, distributed locks, or transaction mechanisms. If the atomic operation is successful, it means that the data access identifier has been used effectively for the first time. The server can read the corresponding window data unit from the storage system based on the original data address in the first authorization record and return the window data unit to the client. If the atomic operation fails, it means that the one-time random number has expired or has been used by other requests. The server can reject the current access request to reduce the possibility of successful replay of the request. If the data access authorization verification fails, the server may not provide the window data unit to the client and may return prompts such as access expired, authorization failed, duplicate request, session mismatch or resource inaccessible; at the same time, the server may also record the reason for failure, the number of failures and the source of the request, and mark the playback session as abnormal when the number of failures reaches a preset threshold; the preset threshold can be set according to the business security policy, for example, it can be set to 3 times, 5 times or 10 times; If the access identifier includes a key access identifier, then the key access identifier is used as the query identifier to retrieve the corresponding second authorization record from the authorization relationship; Based on the second authorization record and the key access token in the key access identifier, a key access authorization verification is performed on the access request. The key access authorization verification includes access credential validity verification and authorization context consistency verification. The access credential validity verification is performed at least based on the key access token and the second expiration time, and the authorization context consistency verification is performed at least based on the session identifier, window identifier, unit identifier of the window data unit, and media key. If the key access authorization verification fails, the server may not provide the media key to the client and will return prompts such as key access expired, authorization failed, or key inaccessible. If the key access authorization verification passes, the media key in the second authorization record is provided to the client; or, the media key in the second authorization record is encrypted to obtain encrypted key data, and the media key is provided to the client in the form of encrypted key data. The process of encrypting the media key to obtain encrypted key data can include encrypting the media key using the session key corresponding to the playback session, the client's public key, the transport layer key, the key encapsulation method provided by the digital rights management system, or a server-preset encryption key. After receiving the encrypted key data, the client can obtain the media key according to the corresponding decryption method, or hand the encrypted key data over to the player or a secure decryption module for processing. If there is no need to encrypt the media key again, the media key can also be provided to the client directly through a secure transmission channel. Based on the provided window data unit and / or media key, update the access state associated with the corresponding window data unit in the playback session, and update the session state of the playback session based on the updated access state. The access status is used to record the access progress of the window data unit and the media key, and may include one or more of the following: data unit provided status, key provided status, data unit provided time, key provided time, access failure status, repeated access status, and abnormal access status. The process of updating the playback session state based on the updated access status can include: advancing the current distribution position to the position after the provided video data unit when a video data unit meeting preset conditions has been provided within the current data distribution window; generating the next data distribution window when all video data units within the current data distribution window have been accessed or the playback progress has reached the window advancement threshold; and updating the playback session to an abnormal or invalid state when an access anomaly or session expiration is detected. The window advancement threshold can be set according to business needs, for example, it can be set to 50%, 70%, or 90% of the current window's playback duration, or it can be set to the number of video data units within the current window that have been successfully requested.

[0040] Preferably, if the access request carries both a data access identifier and a key access identifier, the server can perform data access authorization verification and key access authorization verification separately; if both verifications pass, the server can provide the corresponding window data unit and media key to the client simultaneously or sequentially; if one verification fails, the server can provide only the verified resources or reject the entire access request according to the security policy.

[0041] Specifically, the validity verification of access credentials in data access authorization verification may include: verifying whether the format of the data access token is correct; verifying whether the signature of the data access token matches the signature rules used when the server generates it; verifying whether the current time is earlier than the first expiration time; verifying whether a one-time random number exists and is in a valid state; if any of the above is not satisfied, the data access authorization verification is determined to fail.

[0042] Specifically, the authorization context consistency verification in data access authorization verification may include: verifying whether the data access token, the first authorization record, and the session identifier in the access request are consistent; verifying whether the window identifier corresponds to the data distribution window bound under the current playback session; verifying whether the unit identifier corresponds to the window data unit in the first authorization record; and further verifying whether the client identifier, user authentication information, or request source information are consistent with the information recorded in the playback session; if the context information is inconsistent, the data access authorization verification is determined to fail.

[0043] Specifically, the access credential validity verification in key access authorization verification may include: verifying whether the format and signature of the key access token are correct, and verifying whether the current time is earlier than the second expiration time. The authorization context consistency verification in key access authorization verification may include: verifying whether the key access token, the second authorization record, and the session identifier in the access request are consistent; verifying whether the window identifier corresponds to the data distribution window under the current playback session; verifying whether the unit identifier corresponds to the window data unit in the second authorization record; and verifying whether the media key in the second authorization record is the valid media key corresponding to the window data unit.

[0044] Specifically, in this implementation, after receiving an access request, the server performs authorization verification on both the data access identifier and the key access identifier. This ensures that the acquisition of video data and media keys are controlled by the server, rather than relying solely on the index information already held by the client. For data access requests, verification is performed by combining the access token, expiration time, one-time random number status, and authorization context such as session identifier, window identifier, and unit identifier. This determines whether the request is still valid, belongs to the current authorized window, and has been reused. After successful verification, the one-time random number is invalidated using an atomic operation, reducing the possibility of repeated replays of the same data access identifier after packet capture. For key access requests, verification of the key access token and its authorization context, and further returning the media key in the form of encrypted key data, reduces the risk of direct abuse after the key request entry is intercepted. In addition, the playback session status is updated based on the provided window data unit and / or media key, allowing the server to continue adjusting the range of subsequently distributable video according to the actual access progress, thus forming a dynamic access control mechanism that progresses with the playback process.

[0045] In one specific embodiment, the window data unit can be a video data unit that has undergone segmented encryption. Specifically, during the storage or transcoding process of the target video, a symmetric encryption algorithm can be used to encrypt each video data unit separately, and the corresponding key indication information is recorded in the media index information. For example, when the target video uses the HLS playback protocol, the AES-128-CBC algorithm can be used to encrypt each video data unit in segments, and the encryption method, key acquisition address, key identifier, or initialization vector is recorded through the key indication information in the media index information. When the server generates the media sub-index, it replaces the original key address with the key access identifier and retains the key description information required for client decryption, enabling the client to decrypt and play the corresponding window data unit after obtaining the media key.

[0046] In one specific embodiment, the media key can be provided to the client in the form of encrypted key data. Specifically, the server can obtain the media key associated with the window data unit from a key management system, storage service, or encryption service, and encrypt the media key using the session key corresponding to the playback session, the client's public key, the transport layer key, or a server-preset key to obtain encrypted key data. After receiving the encrypted key data, the client can process the encrypted key data using its playback logic component, security decryption module, or player kernel to obtain the media key used to decrypt the window data unit. This avoids the media key being directly exposed in plaintext during network transmission or in the client's page logic.

[0047] For example, in a client environment where the non-native playback kernel can intercept key requests, the playback logic component in the client can decrypt the encrypted key data after the key request is returned and provide the decrypted media key to the player kernel. In a client environment where the native playback kernel cannot easily intercept key requests, the playback logic component in the client can request the corresponding encrypted key data from the server in advance, decrypt it to obtain the media key, and then write the media key or its encapsulated data into the target key indication information in the media sub-index in a data format supported by the player kernel. The above processing is only an exemplary method for client-side adaptation to different playback environments and does not limit the specific method of providing the media key in this application.

[0048] In one specific embodiment, different window data units can correspond to the same media key or different media keys. When multiple consecutive window data units correspond to the same media key, the server can generate the same or associated key access identifiers for these multiple window data units and apply the corresponding target key indication information to these multiple window data units in the media sub-index. When each window data unit corresponds to a different media key, the server can generate corresponding key access identifiers for each window data unit and write target key indication information for each window data unit in the media sub-index. Thus, even if a certain media key is obtained, the range of window data units that can be used can be limited to a small range.

[0049] In one specific embodiment, the server can dynamically refresh the media sub-index based on the playback process. Specifically, when the client reaches a preset progress in playing video data within the current data distribution window, or when the remaining playable time within the current data distribution window is lower than a preset buffer threshold, the client can request subsequent media sub-indexes from the server. The server can also proactively generate the media sub-index corresponding to the next data distribution window based on the session state of the playback session. For the next data distribution window, the server redetermines the window data unit, regenerates the data access identifier and key access identifier, and re-establishes or updates the authorization relationship. This avoids the access identifiers generated early in the long video playback process from affecting normal playback due to their short validity period, while still ensuring that each access identifier remains valid for a short time and within a limited scope.

[0050] In another embodiment, the server may provide window data units to the client not through the request address pointed to by the data access identifier, but through a persistent connection or on-demand push method. Specifically, after the client establishes a persistent connection with the server, the server pushes the corresponding window data unit or its controlled access entry to the client on demand, based on the session state of the playback session and the current data distribution window. This method can further reduce the exposure of visible request addresses in the media sub-index, but requires the server to assume the corresponding connection management and push control capabilities. This embodiment can serve as an alternative implementation to the method of pulling window data units based on access requests.

[0051] It is worth noting that when a client requests window data units and media keys within the current data distribution window based on media sub-indexes, although the data distribution window restricts the range of video data currently visible to the client, in extreme cases where attackers use packet sniffing tools or automated download programs, they may still launch bursty, concurrent access requests to multiple window data units and multiple media keys within the current data distribution window before the data access identifier and key access identifier expire. While these access requests may still fall within the current data distribution window, their request rhythm, order, or look-ahead range are inconsistent with the normal playback process. If verification is based solely on whether the access identifier belongs to the current data distribution window, it may be difficult to distinguish between normal buffering requests and batch capture requests in a timely manner.

[0052] Therefore, in a preferred embodiment, the access request is verified based on the authorization relationship. If the verification is successful, the client is provided with the window data unit corresponding to the access request and / or the media key used to decrypt the window data unit, and the session state of the playback session is updated. The method also includes: Retrieve the current playback progress information, provided video data unit information, provided media key information, and window access constraints corresponding to the current data distribution window recorded in the playback session; The current playback progress information is used to characterize the client's playback progress on the target video playback timeline. It can be determined based on the playback progress reported by the client, the playback time interval of the provided window data units, the order of access requests, the most recently successfully provided window data unit, or a combination of the above information. The provided video data unit information is used to record the window data units that the server has provided to the client, and the provided media key information is used to record the media key or encryption key data that the server has provided to the client. The window access constraint is used to limit the range and pace of data that the client is allowed to request in advance during the current playback phase. It may include one or more of the following: allowed advance playback duration, allowed number of advance video data units, allowed number of video data units to be requested per unit time, allowed number of media keys to be requested per unit time, maximum number of concurrent requests, and allowed out-of-order request range. For example, the allowed advance playback duration can be set to 5 to 30 seconds, the allowed number of advance video data units can be set to 2 to 6, and the maximum number of concurrent requests can be set to 2 to 8. The above parameters can be dynamically adjusted according to the video bitrate, network status, player buffering strategy, and business security level. Based on the current playback progress information and window access constraints, determine the set of candidate window data units that the client is allowed to request at the current moment; In response to an access request carrying a data access identifier, the requested window data unit is determined based on the data access identifier, and it is determined whether the requested window data unit belongs to the candidate window data unit set. If the requested window data unit belongs to the candidate window data unit set, then continue to perform data access authorization verification on the access request based on the authorization relationship; If the requested window data unit does not belong to the candidate window data unit set, it is determined that the access request does not meet the playback progress consistency requirement, and the corresponding window data unit is refused to be provided to the client, or the playback session is marked as a risk session. In response to an access request carrying a key access identifier, the window data unit corresponding to the requested media key is determined based on the key access identifier, and it is determined whether the window data unit corresponding to the media key matches a window data unit that has been provided, is being provided, or is allowed to be provided in advance. If the window data unit corresponding to the media key meets the matching condition, then continue to perform key access authorization verification on the access request based on the authorization relationship; If the window data unit corresponding to the media key does not meet the matching conditions, the media key will be refused to be provided to the client, or the media key will be delayed in being provided to the client. Update the access risk status of the playback session based on one or more of the following: number of access requests per unit time, number of concurrent requests, request order, request interval, and number of request failures. If the access risk status meets the preset abnormal conditions, the subsequent data distribution window will be narrowed, the validity period of the data access identifier and / or key access identifier will be shortened, the generation of subsequent media sub-indexes will be suspended, or the playback session will be invalidated.

[0053] Specifically, the candidate window data unit set can be obtained in the following ways: determine the current playback position based on the current playback progress information; extend the allowed forward playback duration along the playback direction of the target video based on the current playback position to obtain the allowed requested playback time range; compare the playback time interval of each window data unit in the current data distribution window with the allowed requested playback time range; if the playback time interval of any window data unit overlaps with the allowed requested playback time range, then the window data unit is determined as a candidate window data unit; or, the server can also start from the window data unit corresponding to or adjacent to the current playback position and select a preset number of window data units along the playback direction of the target video to obtain the candidate window data unit set.

[0054] Specifically, for a data access request, the server can first determine the requested window data unit based on the data access identifier, and then determine whether the window data unit belongs to the candidate window data unit set. If it belongs to the candidate window data unit set, it means that the request matches the current playback progress and normal buffering range, and the server can continue to perform checks such as data access token, first expiration time, one-time random number state, and authorization context consistency. If it does not belong to the candidate window data unit set, for example, if the client continuously requests multiple window data units at the end of the current data distribution window before the current playback progress is close to the end of the window, it can be determined that the access request is inconsistent with the normal playback progress, and the corresponding window data unit will be refused.

[0055] Specifically, for a key access request, the server can determine the window data unit corresponding to the media key based on the key access identifier, and determine whether the window data unit has already been provided, is being provided, or is in the set of candidate window data units allowed for lookahead provision. If the window data unit corresponding to the media key meets the above conditions, the server continues to perform checks such as key access token, second expiration time, and authorization context consistency. If the window data unit corresponding to the media key has not yet entered the allowed lookahead range, or if the client requests multiple media keys consecutively without requesting the corresponding window data unit, the server can refuse to provide the media key, or only provide the media key after the data access authorization check of the corresponding window data unit passes.

[0056] Specifically, preset abnormal conditions may include at least one of the following: within a preset statistical period, the number of data access requests corresponding to the same playback session exceeds a first request threshold; the number of key access requests exceeds a second request threshold; the number of concurrent requests exceeds a first concurrency threshold; the number of request order jumps exceeds a first jump threshold; the number of times a media key is requested without requesting the corresponding window data unit exceeds a first key abnormality threshold; or the number of access authorization verification failures exceeds a first failure threshold. The preset statistical period can be set to 1 second, 3 seconds, 5 seconds, or 10 seconds, and the first failure threshold can be set to 3 times, 5 times, or 10 times. The above thresholds are only examples; in actual applications, they can be set according to the playback protocol, video length, resolution, and business security level.

[0057] Specifically, when the access risk status meets preset abnormal conditions, the server can shorten the playback duration or the number of window data units in the next data distribution window, shorten the remaining validity period of the data access identifier and key access identifier, prohibit concurrent key requests within the same playback session, suspend the generation of subsequent media sub-indexes, or invalidate the playback session. If the access risk status does not meet the preset abnormal conditions, the server can update the session status of the playback session according to the normal process and continue to provide the client with the corresponding window data units and / or media keys within the current data distribution window.

[0058] In this way, the server can not only determine whether an access request belongs to the current data distribution window, but also further determine whether the access request conforms to the current playback progress, buffering range, and normal request rhythm. Therefore, without affecting normal continuous playback and reasonable buffering, the risk of attackers concurrently capturing all window data units and media keys within the current data distribution window during the short validity period of the access identifier can be reduced.

[0059] It's worth noting that in scenarios supporting start parameters, resume playback, and drag-and-drop playback, clients can request different playback positions within the target video based on different start parameters. This mechanism can improve the playback experience for normal users. However, in extreme cases, attackers might attempt to split the target video into multiple windows and then piece them together to form a complete video by repeatedly constructing different start parameters, creating multiple playback sessions in a short period, or requesting multiple data distribution windows that are far apart in parallel. This type of behavior does not necessarily manifest as abnormal access within a single data distribution window, but may instead manifest as an abnormal expansion of the window range across playback sessions and across start positions.

[0060] Therefore, in a preferred embodiment, in response to receiving a playback request from a client for a target video, a playback session is created, and a data distribution window is determined based on the session state of the playback session, further comprising: Parse the playback request to obtain the target video's video identifier, client identifier, user authentication information, and playback start parameters; Based on the video identifier, client identifier, and / or user authentication information, query the historical playback sessions and / or currently valid playback sessions associated with the target video; Based on historical playback sessions and / or currently active playback sessions, determine the set of historical data distribution windows that have been provided to or accessed by clients within a preset statistical period; Based on the historical data distribution window set, calculate the window coverage of the client for the target video within a preset statistical period; The historical data distribution window set refers to one or more data distribution windows that the server has opened for the same client, the same user authentication information, or the same playback certificate within a preset statistical period. The preset statistical period can be set according to the total playback duration of the target video, the validity period of the playback certificate, and the business security level. For example, it can be set to 1 minute, 5 minutes, 10 minutes, 30 minutes, or the validity period of a single playback certificate. The requested playback position is determined based on the start-up parameters, and a candidate data distribution window is generated based on the requested playback position. Determine whether the window coverage after superimposing the candidate data distribution window and the historical data distribution window set meets the preset coverage conditions; Window coverage is used to characterize the proportion of the target video playback range that the server has allowed the client to access within a preset statistical period, relative to the total playback range of the target video. Window coverage can be calculated based on playback duration or the number of video data units. For example, when calculated based on playback duration, window coverage can be the ratio between the combined total duration of the opened playback time intervals and the total playback duration of the target video; when calculated based on the number of video data units, window coverage can be the ratio between the number of different opened video data units and the total number of video data units in the target video. If the coverage of the overlaid window meets the preset coverage conditions, a playback session is created or updated based on the candidate data distribution window; The preset coverage conditions may include at least one of the following: the window coverage within a preset statistical period does not exceed a first coverage threshold; the number of playback sessions created per unit time does not exceed a first session threshold; the number of discontinuous jumps does not exceed a first jump threshold; the interval distribution between multiple data distribution windows satisfies normal drag-and-drop playback behavior; or the number of currently valid playback sessions on the same client does not exceed a first parallel threshold. For example, the first coverage threshold can be set to 20%, 30%, or 50% of the total playback duration of the target video; the first session threshold can be set to 2, 3, or 5 sessions; and the first jump threshold can be set to 3, 5, or 10 jumps. These thresholds are merely examples; in actual applications, they can be set according to the video length, playback permission level, and anti-download security level. If the coverage of the superimposed window does not meet the preset coverage conditions, then the generation of candidate data distribution window based on the start-up parameters will be refused, or the candidate data distribution window will be reduced, or the client will be required to re-authenticate for playback. In response to the determination that multiple currently valid playback sessions exist on the client side, the system determines whether to restrict the creation of new playback sessions or invalidate at least one existing playback session based on the coverage relationship between the data distribution windows corresponding to the multiple currently valid playback sessions.

[0061] Specifically, window coverage can be obtained as follows: map each data distribution window in the historical data distribution window set onto the playback timeline of the target video to obtain multiple historical playback time intervals; merge historical playback time intervals that overlap or are consecutive to obtain one or more open playback time intervals; calculate the total duration of each open playback time interval; and compare this total duration with the total playback duration of the target video to obtain the window coverage. Alternatively, if the number of video data units is used for calculation, the number of different video data units already covered by the historical data distribution window set can be counted, and this number can be compared with the total number of video data units in the target video to obtain the window coverage.

[0062] Specifically, when generating candidate data distribution windows based on the start-up parameters, the server can first determine the requested playback position according to the start-up parameters, and then generate candidate data distribution windows based on the requested playback position and the preset playback duration or preset number of video data units. Subsequently, the server overlays the candidate data distribution windows with the set of historical data distribution windows and recalculates the coverage of the overlaid window. If the coverage of the overlaid window meets the preset coverage conditions, it means that the candidate data distribution window is still within the range of normal playback, resume playback, or reasonable dragging. The server can then create or update a playback session based on the candidate data distribution window and continue to generate media sub-indexes, data access identifiers, and key access identifiers.

[0063] Specifically, if the coverage of the superimposed windows does not meet the preset coverage conditions—for example, if the same client requests multiple data distribution windows that are far apart in the target video within a short period of time using multiple start-up parameters, and the cumulative coverage area significantly exceeds the range required for normal playback or normal dragging—the server can determine that the playback request carries the risk of enumerating the range of video data. In this case, the server can refuse to generate candidate data distribution windows according to the start-up parameters, narrow the window range of the candidate data distribution windows, provide the client with only shorter playback durations or fewer window data units, or require the client to re-authenticate playback.

[0064] In a further embodiment, if the same client identifier, the same user authentication information, or the same playback credential creates multiple currently valid playback sessions for the same target video within a preset statistical period, the server can group these multiple currently valid playback sessions into the same session group and calculate the coverage of the data distribution window corresponding to the session group. If multiple data distribution windows in the session group correspond to multiple non-contiguous playback positions in the target video, and the cumulative window coverage exceeds a preset coverage condition, the server can restrict the creation of new playback sessions, invalidate some existing playback sessions, or retain only the playback session corresponding to the most recent normal playback position.

[0065] For example, in legitimate drag-and-drop playback or resume playback scenarios, the server can allow the client to redetermine the requested playback position within a certain range. If the distance between the requested playback position corresponding to the start-up parameter and the current distribution position in the playback session is less than a preset jump distance, or if the client carries jump trigger information associated with the user's playback operation when initiating the playback request, the server can recognize it as a normal jump and generate a new data distribution window based on the new requested playback position. The preset jump distance can be set to 30 seconds, 60 seconds, 120 seconds, or a preset proportion of the total playback duration of the target video.

[0066] Preferably, when the server generates a new data distribution window based on a new requested playback position, it can invalidate or shorten the remaining validity period of unused data access identifiers and key access identifiers in the original data distribution window. This avoids keeping both old and new data distribution windows accessible for an extended period, reducing the risk of attackers accumulating access to multiple data distribution window contents through frequent dragging or repeated playback.

[0067] Using the above methods, the server can support start-up, resume-play, and drag-and-drop playback while simultaneously performing overall statistics and coverage constraints on data distribution windows that have been opened by the same client or user within a certain period. This reduces the possibility of attackers repeatedly constructing start-up parameters, creating playback sessions in parallel, or enumerating across windows to extract the complete video data range in batches.

[0068] like Figure 3 As shown, this application also provides a video data protection method applied to a client, the method comprising: Step 301: In response to receiving a video-on-demand operation, the target video is determined, a corresponding playback request is generated and sent to the server; The video-on-demand operation can include actions such as clicking the video playback control, selecting the target video, dragging the playback progress bar, resuming playback, switching resolution, or refreshing the playback page; the client determines the target video, which can include determining one or more of the following: the video identifier selected by the user, the target resolution, the playback protocol type, and the playback start position; the playback request can carry the video identifier, playback start parameters, client identifier, user authentication information, and playback capability information; the playback capability information can include the encoding format, encryption method, resolution, player type, or network status information supported by the client; Step 302: Receive and parse the media sub-index returned by the server in response to the playback request, and obtain the data access identifier corresponding to the video data unit in the current window, as well as the key access identifier of the media key used to decrypt the video data unit. The media sub-index is a portion of the index content generated by the server based on the current data distribution window, which is different from the complete media index of the target video. The data access identifier recorded in the media sub-index is used to request the corresponding video data unit within the current window, and the key access identifier is used to request the media key required to decrypt the video data unit. The client parses the media sub-index, which may include reading the index-level description information, extracting the target index entries in sequence, identifying the target key indication information, establishing the correspondence between the video data unit and the key access identifier, and passing the parsing result to the player for requesting and buffering. Step 303: Initiate an access request carrying a data access identifier to the server to obtain the video data unit; Step 304: Send an access request carrying a key access identifier to the server to obtain the media key; Step 305: Decrypt the corresponding video data unit based on the media key to obtain the video data of the current window and play it.

[0069] Preferably, the client can sequentially send access requests carrying data access identifiers to the server according to the order of the target index entries in the media sub-index to obtain the corresponding video data units. For media keys, the client can send access requests carrying key access identifiers to the server before requesting the first video data unit that requires the media key, after requesting the video data unit, or when the player triggers a key loading event. If multiple video data units share the same media key, the client can reuse the media key within the valid range indicated by the media sub-index. If different video data units correspond to different media keys, the client can request the corresponding media keys separately.

[0070] It is worth noting that if the server returns encrypted key data, the client can process the encrypted key data based on the session key corresponding to the playback session, the client's private key, the transport layer secure channel, or the secure decryption module to obtain the media key that can be used to decrypt the video data unit. If the media sub-index indicates that a certain video data unit does not require a media key, the client can directly decode or play the video data unit. If the client fails to request a video data unit or media key, it can re-initiate the playback request, request a new media sub-index, prompt the user to retry, or stop playback and output an error message, depending on the failure type.

[0071] Specifically, the client decrypts the corresponding video data unit based on the media key. This may include determining the encryption algorithm, initialization vector, and key scope based on the key description information in the media sub-index, and inputting the media key, key description information, and video data unit into the player, decryption module, or media decoding module to obtain playable video data.

[0072] Preferably, when the video data in the current window reaches a preset progress, the client can continue to request subsequent media sub-indexes from the server, or the server can proactively return the media sub-index corresponding to the next data distribution window based on the playback session status. The preset progress can be set according to a buffering strategy, for example, it can be triggered when the current window's playback progress reaches 50%, 70%, or 90%, or it can be triggered when the remaining playable time of the current window is lower than a preset buffer threshold. The preset buffer threshold can be from 2 seconds to 10 seconds.

[0073] Specifically, in this implementation, the client only receives and parses the media sub-index returned by the server, and requests the video data units and media keys within the current window based on the data access identifier and key access identifier therein. This allows the client to decrypt and play the video content in the current window without needing to obtain the complete media index, real segment address, or real key address of the target video. Thus, while ensuring a normal on-demand and continuous playback experience for the client, the exposure of the complete video resource path, complete segment sequence, and complete key request entry point on the client side can be reduced. Even if the client's operating environment is relatively open, attackers can only observe the access information within the current window, which is constrained by the server's authorization relationship. It is difficult to directly recover complete playable video content in batches based solely on client-side information. This, combined with the server-side dynamic window distribution and authorization verification mechanism, improves the effectiveness of video data protection.

[0074] In one specific embodiment, the playback logic component in the client can rewrite the access entry in the media sub-index before initiating an access request. For example, request rewriting may include at least one of the following: replacing the domain name in the access entry with a distribution domain name specified by the server; appending a client identifier, timestamp, request signature, or session-related parameters to the access entry; converting the obfuscated resource name into a request resource name recognizable by the server; or converting the relative path in the media sub-index into an accessible proxy path. The above request rewriting can be completed internally within the client's playback component, remaining transparent to user playback operations. This embodiment pertains to a specific execution method on the client side and does not affect the main process of the server verifying access requests based on authorization relationships.

[0075] It should be understood that, although Figure 2-3 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2-3 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0076] In another embodiment, such as Figure 4 As shown, the server includes a proxy server and a storage service, and the proxy server, storage service, and client communicate with each other. This application provides a video data protection method, including: In response to a user's video-on-demand action for a target video, the client sends a playback request to the proxy server. After receiving a playback request, the proxy server creates a playback session corresponding to this on-demand process and determines the data distribution window based on the session state to limit the range of video data allowed to be provided to the client. Based on the video identifier carried in the playback request, the proxy server retrieves the media index information of the target video from the storage service provider, or retrieves the index parsing result of the media index information corresponding to the video identifier, and determines the window data unit within the data distribution window. For each window data unit, the proxy server generates a corresponding data access identifier and determines the media key and its key access identifier used to decrypt the window data unit, thereby establishing the authorization relationship between the data access identifier, the key access identifier, the playback session, the data distribution window, the window data unit, and the media key. The proxy server generates a media sub-index based on the window data unit, the data access identifier, and the key access identifier, and returns the media sub-index to the client. After parsing the media sub-index, the client initiates an access request based on the data access identifier and / or key access identifier contained therein; The proxy server verifies the access request based on the authorization relationship. If the verification is successful, it obtains the corresponding window data unit and / or media key from the storage service and provides it to the client, or instructs the storage service to provide the corresponding window data unit and / or media key to the client after the verification is successful. The client decrypts and plays the corresponding window data unit based on the obtained media key; The proxy server also updates the session state of the playback session based on the provided window data units and / or media keys, so as to continue adjusting subsequent data distribution windows as playback progresses.

[0077] Therefore, the proxy server centrally undertakes access control functions such as session management, window control, authorization relationship maintenance, and media sub-index generation, while the storage service server is used to store the media index information, video data units, and media keys of the target video. This achieves the linkage protection of video data and decryption information without directly exposing the complete media index, original segment address, and original key address to the client.

[0078] In another embodiment, the server can provide window data units to the client using a redirection method. Specifically, the data access identifier in the media sub-index can point to the access interface of the proxy server. After receiving an access request carrying the data access identifier, the proxy server first verifies the access request based on the authorization relationship. If the verification is successful, it generates a short-term storage access address based on the original data address in the first authorization record and returns a redirection response to the client, enabling the client to obtain the corresponding window data unit from the storage service provider based on the short-term storage access address. In this method, the proxy server can be responsible only for session management, authorization verification, short-term storage access address generation, and redirection response, without directly carrying the transmission traffic of the window data unit; the storage service provider is used to store and return the window data unit. If the access request verification fails, the proxy server does not generate a short-term storage access address and rejects the access request.

[0079] In one specific embodiment, the short-lived storage access address generated by the proxy server can be a pre-signed access address. Specifically, the proxy server can generate a pre-signed access address based on the original data address of the window data unit, the current time, the preset validity period, and the signature key corresponding to the storage service server, and use this pre-signed access address as the target address in the redirection response. The preset validity period can be set according to the security level and network transmission conditions, for example, it can be set to 10 seconds to 120 seconds, preferably 30 seconds to 60 seconds. Therefore, even if an attacker intercepts the redirected storage access address, the address will become invalid in a short time and is difficult to store for a long time or reuse in batches.

[0080] In one embodiment, such as Figure 5 As shown, a video data protection device is provided, applied to server 102, the device comprising: The session window determination module is used to create a playback session in response to receiving a playback request from a client for a target video, and to determine the data distribution window based on the session state of the playback session to at least characterize the range of video data that is currently allowed to be provided to the client. The window unit selection module is used to obtain the media index information of the target video and select the window data unit in the data distribution window from the video data units indicated by the media index information. The authorization relationship establishment module is used to determine the data access identifier corresponding to the window data unit and the key access identifier used to decrypt the media key of the window data unit, and to establish the authorization relationship between the data access identifier, the key access identifier and the playback session, the data distribution window, the window data unit and the media key. The sub-index sending module is used to generate a media sub-index based on the window data unit, data access identifier, and key access identifier, and send the media sub-index to the client so that the client can initiate an access request to the server carrying the data access identifier and / or key access identifier based on the media sub-index. The access request processing module is used to respond to an received access request by verifying the access request based on the authorization relationship. If the verification is successful, it provides the client with the window data unit corresponding to the access request and / or the media key used to decrypt the window data unit, and updates the session state of the playback session.

[0081] In another embodiment, a video data protection device is also provided, applied to client 101, the device comprising: The playback request module is used to respond to a received video-on-demand operation by determining the target video, generating a corresponding playback request, and sending it to the server. The index parsing module is used to receive and parse the media sub-index returned by the server in response to the playback request, to obtain the data access identifier corresponding to the video data unit in the current window, and the key access identifier for the media key used to decrypt the video data unit. The data request module is used to send an access request carrying a data access identifier to the server in order to obtain video data units; The key request module is used to send an access request carrying a key access identifier to the server in order to obtain the media key; The decryption and playback module is used to decrypt the corresponding video data unit based on the media key, obtain the video data of the current window, and play it.

[0082] Specific limitations regarding video data protection devices can be found in the limitations of video data protection methods described above, and will not be repeated here. Each module in the aforementioned video data protection device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in a computer device, or stored in software in the memory of a computer device, so that the processor can call and execute the corresponding operations of each module.

[0083] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores video data protection data. The network interface communicates with external clients via a network connection. When the computer program is executed by the processor, it implements a video data protection method.

[0084] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0085] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the video data protection methods described above.

[0086] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the video data protection methods described above. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0087] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0088] The above embodiments merely illustrate several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A video data protection method, applied on a server side, characterized in that, The method includes: In response to receiving a playback request from a client for a target video, a playback session is created, and a data distribution window is determined based on the session state of the playback session to at least characterize the range of video data currently allowed to be provided to the client. Obtain the media index information of the target video, and select the window data unit in the data distribution window from the video data units indicated by the media index information; Determine the data access identifier corresponding to the window data unit and the key access identifier for the media key used to decrypt the window data unit, and establish the authorization relationship between the data access identifier, the key access identifier, the playback session, the data distribution window, the window data unit, and the media key; A media sub-index is generated based on the window data unit, the data access identifier, and the key access identifier, and the media sub-index is sent to the client so that the client can initiate an access request to the server carrying the data access identifier and / or the key access identifier based on the media sub-index. In response to receiving the access request, the access request is verified based on the authorization relationship. If the verification is successful, the client is provided with the window data unit corresponding to the access request and / or the media key used to decrypt the window data unit, and the session state of the playback session is updated.

2. The video data protection method according to claim 1, characterized in that, In response to receiving a playback request from a client for a target video, a playback session is created, and a data distribution window is determined based on the session state of the playback session to at least characterize the range of video data currently allowed to be provided to the client, including: The playback request is parsed to obtain the video identifier of the target video, and it is determined whether the playback request carries start parameters; The playback session is created based on the video identifier, and a session identifier is generated for the playback session; If the playback request carries the start-up parameter, the requested playback position is determined based on the start-up parameter, and the requested playback position is determined as the current distribution position of the playback session; if the playback request does not carry the start-up parameter, the starting playback position of the target video is determined as the current distribution position of the playback session. Write the video identifier, the session identifier, and the current distribution location into the session state of the playback session; Using the current distribution position as the starting position of the window, extend the window along the playback direction of the target video for a preset playback duration or a preset number of video data units to determine the ending position of the window; The data distribution window is generated based on the window's start position and end position, and then bound to the playback session.

3. The video data protection method according to claim 2, characterized in that, The step of obtaining the media index information of the target video and selecting the window data unit located in the data distribution window from the video data units indicated by the media index information includes: Based on the video identifier of the target video, obtain the media index information of the target video; The media index information is parsed to obtain multiple index entries, where each index entry corresponds to a stored video data unit; Based on the order of the multiple index entries in the media index information and the playback duration recorded by each index entry, the playback time interval of each video data unit in the target video is determined; The playback time interval of each video data unit is compared with the data distribution window; If the start time of the playback time interval of any of the video data units is earlier than the end position of the data distribution window, and the end time of the playback time interval is later than the start position of the data distribution window, then the video data unit is determined as a window data unit.

4. The video data protection method according to claim 3, characterized in that, The step of determining the data access identifier of the window data unit and the key access identifier of the media key associated with the window data unit, and establishing the authorization relationship between the data access identifier, the key access identifier, the playback session, the data distribution window, the window data unit, and the media key, includes: For each window data unit, determine the index entry corresponding to the window data unit in the media index information, and extract the original data address of the window data unit from the index entry; The original resource name of the window data unit is determined based on the original data address, and the original resource name is subjected to preset obfuscation processing to obtain an obfuscated resource name; A data access token is generated based on the session identifier of the playback session, the window identifier of the data distribution window, the unit identifier of the window data unit, and a preset first expiration time. Generate a one-time random number for the window data unit and record that the one-time random number is in a valid state; Based on a preset data access identifier format, the obfuscated resource name, the data access token, and the one-time random number are combined to generate a data access identifier; Based on the media index information, determine the key indication information that is valid for the window data unit, and extract the original key address and key description information from the key indication information; The media key associated with the window data unit is obtained based on the original key address, and a key access token is generated based on the session identifier of the playback session, the data distribution window, the unit identifier of the window data unit, and the preset second expiration time. Based on a preset key access identifier format, the key access token is encapsulated to generate the key access identifier; Establish a first authorization record with the data access identifier as the query identifier. The first authorization record includes at least the playback session, the data distribution window, the window data unit, the original data address, and the one-time random number. A second authorization record is established using the key access identifier as the query identifier. The second authorization record includes at least the playback session, the data distribution window, the window data unit, and the media key. The authorization relationship is obtained by associating the first authorization record and the second authorization record corresponding to the same window data unit.

5. A video data protection method according to claim 4, characterized in that, The step of generating a media sub-index based on the window data unit, the data access identifier, and the key access identifier includes: The basic description information for describing index attributes is extracted from the media index information, and the description fields related to the range of video data units in the basic description information are adapted according to the data distribution window to obtain the target description information. Based on the arrangement order of each window data unit in the media index information, the index entry corresponding to each window data unit is determined, and a set of index entries to be output is generated. Based on the authorization relationship, determine the data access identifier and key access identifier corresponding to each window data unit; For each index entry to be output in the set of index entries to be output, replace the original data address recorded in the index entry to be output with the data access identifier of the corresponding window data unit to obtain the target index entry; For each window data unit, determine the key indication information that is valid for the window data unit, replace the original key address in the key indication information with the key access identifier corresponding to the window data unit, and retain the key description information in the key indication information to obtain the target key indication information corresponding to the window data unit; According to the index format of the media index information, the target description information is written into the corresponding index-level description position in the index content, and the relative positional relationship between each target key indication information and the target index entry it acts on is maintained according to the arrangement order of each window data unit in the media index information. Each target key indication information and each target index entry are written into the index content to generate the media sub-index.

6. A video data protection method according to claim 4, characterized in that, The process of verifying the access request based on the authorization relationship, and if the verification is successful, providing the client with the window data unit corresponding to the access request and / or the media key used to decrypt the window data unit, and updating the session state of the playback session, includes: Parse the access request to determine the access identifier carried in the access request. The access identifier includes one or more of the following: data access identifier and key access identifier. In response to the access identifier including the data access identifier, the data access identifier is used as the query identifier to obtain the corresponding first authorization record from the authorization relationship; Based on the first authorization record and the data access token in the data access identifier, a data access authorization verification is performed on the access request. The data access authorization verification includes access credential validity verification and authorization context consistency verification. The access credential validity verification is performed at least based on the status information of the data access token, the first expiration time, and the one-time random number. The authorization context consistency verification is performed at least based on the session identifier, the window identifier, and the unit identifier of the window data unit. If the data access authorization verification passes, the one-time random number in the first authorization record is updated from valid to invalid using an atomic operation, and the corresponding window data unit is provided to the client based on the original data address in the first authorization record; In response to the access identifier including the key access identifier, the key access identifier is used as the query identifier to obtain the corresponding second authorization record from the authorization relationship; Based on the second authorization record and the key access token in the key access identifier, a key access authorization verification is performed on the access request. The key access authorization verification includes access credential validity verification and authorization context consistency verification. The access credential validity verification is performed at least based on the key access token and the second expiration time. The authorization context consistency verification is performed at least based on the session identifier, the window identifier, the unit identifier of the window data unit, and the media key. If the key access authorization verification passes, the media key in the second authorization record is provided to the client; or, the media key in the second authorization record is encrypted to obtain encrypted key data, and the media key is provided to the client in the form of the encrypted key data. Based on the provided results of the window data unit and / or the media key, update the access status associated with the corresponding window data unit in the playback session, and update the session status of the playback session based on the updated access status.

7. A video data protection method, applied to a client, characterized in that, The method includes: Upon receiving a video-on-demand request, the target video is determined, a corresponding playback request is generated, and sent to the server. Receive and parse the media sub-index returned by the server in response to the playback request to obtain the data access identifier corresponding to the video data unit in the current window, and the key access identifier for the media key used to decrypt the video data unit; Initiate an access request carrying the data access identifier to the server to obtain the video data unit; Initiate an access request carrying the key access identifier to the server to obtain the media key; The corresponding video data unit is decrypted based on the media key to obtain the video data of the current window and then played.

8. A video data protection device, applied on a server side, characterized in that, The device includes: The session window determination module is used to create a playback session in response to receiving a playback request sent by a client for a target video, and to determine a data distribution window based on the session state of the playback session to at least characterize the range of video data that is currently allowed to be provided to the client. The window unit selection module is used to obtain the media index information of the target video and select the window data unit located in the data distribution window from the video data units indicated by the media index information; The authorization relationship establishment module is used to determine the data access identifier corresponding to the window data unit and the key access identifier used to decrypt the media key of the window data unit, and to establish the authorization relationship between the data access identifier, the key access identifier and the playback session, the data distribution window, the window data unit and the media key; The sub-index sending module is used to generate a media sub-index based on the window data unit, the data access identifier, and the key access identifier, and send the media sub-index to the client, so that the client can initiate an access request to the server carrying the data access identifier and / or the key access identifier based on the media sub-index; The access request processing module is configured to, in response to receiving the access request, verify the access request based on the authorization relationship; if the verification is successful, provide the client with the window data unit corresponding to the access request and / or the media key for decrypting the window data unit, and update the session state of the playback session.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images