Media data processing method and device, electronic equipment and readable medium

Abstract

The invention provides a media data processing method and device, electronic equipment and a readable medium. The method comprises the steps that a video playing request sent by a playing terminal is acquired, the video playing request comprises an equipment fingerprint of the playing terminal, and the equipment fingerprint is generated according to equipment information of the playing terminal; according to the video playing request, a risk query request containing the equipment fingerprint is sent to a risk control server, so that risk state information of the playing terminal is obtained through the risk control server according to the equipment fingerprint, and the risk state information is generated by carrying out risk assessment according to equipment information of the playing terminal; and according to the risk state information sent by the risk control server, if the risk state information satisfies a predetermined risk control strategy, sending the to-be-played video to the playing terminal, so as to play the to-be-played video on the playing terminal. According to the method, the media data leakage can be prevented, and the data confidentiality and the data security of the media content are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and readable medium for processing media data. Background Technology

[0002] With the development of computer technology, edge computing systems have begun to be applied in video playback and live streaming. Copies of media content can be stored on servers located at the network edge. When a terminal device requests to play a video, the edge server provides the media content to the terminal device for playback. However, in such scenarios, preventing media data leakage and media content piracy has become a key research focus.

[0003] In related technologies, media content providers encrypt media content, and only by successfully obtaining the decryption key can viewers decrypt and play the media content, thereby preventing media content from being pirated.

[0004] However, in such schemes, the playback terminal may steal the key by tampering with the playback environment, and then use it to decode the media content sent by the edge server to play the media content. This would expose the media data to unauthorized users, reducing the confidentiality and security of the media content. Summary of the Invention

[0005] In view of the above-mentioned technical problems, this application provides a method, apparatus, electronic device and readable medium for processing media data, so as to prevent media data from being exposed to unauthorized users and improve the data confidentiality and data security of media content.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to one aspect of the embodiments of this application, a method for processing media data is provided, including:

[0008] Obtain a video playback request sent by the playback terminal, wherein the video playback request contains the device fingerprint of the playback terminal, and the device fingerprint is generated based on the device information of the playback terminal;

[0009] Based on the video playback request, a risk query request containing the device fingerprint is sent to the risk control server so that the risk control server can obtain the risk status information of the playback terminal based on the device fingerprint. The risk status information is generated by risk assessment based on the device information of the playback terminal.

[0010] Based on the risk status information sent by the risk control server, if the risk status information meets the predetermined risk control strategy, the video to be played is sent to the playback terminal so that the video to be played can be played on the playback terminal.

[0011] According to one aspect of the embodiments of this application, a media data processing apparatus is provided, comprising:

[0012] The request acquisition module is configured to acquire a video playback request sent by the playback terminal. The video playback request contains the device fingerprint of the playback terminal, which is generated based on the device information of the playback terminal.

[0013] The request sending module is configured to send a risk query request containing the device fingerprint to the risk control server according to the video playback request, so that the risk control server can obtain the risk status information of the playback terminal according to the device fingerprint. The risk status information is generated by risk assessment based on the device information of the playback terminal.

[0014] The video sending module is configured to send a video to be played to the playback terminal based on the risk status information sent by the risk control server, if the risk status information meets the predetermined risk control strategy, so as to play the video to be played on the playback terminal.

[0015] In some embodiments of this application, based on the above technical solutions, the video sending module specifically includes: sending a key request for a video to be played to a video permission server; receiving a decryption key for the video to be played from the video permission server; and sending the video to be played and the decryption key to the playback terminal, so that the playback terminal can decrypt and play the video to be played according to the decryption key.

[0016] In some embodiments of this application, based on the above technical solutions, the video sending module further includes: querying the video to be played from the cache server; if the cache server does not contain the video to be played, obtaining the video to be played from the source server of the video to be played according to the video playback request; and caching the video to be played in the cache server.

[0017] In some embodiments of this application, based on the above technical solutions, the video sending module is further configured to: send a playable video list to the playback terminal, the playable video list containing identification information of at least one playable video; receive a video selection request from the playback terminal, the video selection request containing identification information of the video to be played selected by the playback terminal according to the playable video list; and obtain the video to be played according to the identification information in the video selection request.

[0018] In some embodiments of this application, based on the above technical solutions, the video sending module is further configured to: receive device information sent by the playback terminal, wherein the device information includes the device hash and environment check result of the playback terminal, wherein the device hash is generated by hash calculation based on the hardware and software information of the playback terminal, and the environment check result is generated by checking the system permission status and abnormal application installation status of the playback terminal; calculate and generate the device fingerprint of the playback terminal based on the device hash and the environment check result; perform risk assessment based on the device information to obtain the risk status information of the playback terminal; associate the device fingerprint with the risk status information and store it in the risk control server; and send the device fingerprint to the playback terminal.

[0019] In some embodiments of this application, based on the above technical solutions, the video sending module is specifically configured to: input the device information into the risk assessment model on the risk control server to obtain the risk score output by the risk assessment model; and determine the risk status information of the playback terminal based on the comparison result of the risk score and a preset scoring threshold.

[0020] In some embodiments of this application, based on the above technical solutions, the request sending module is specifically configured to: parse the video playback request and read the device fingerprint; if reading the device fingerprint from the video playback request fails, send a playback rejection notification to the playback terminal; if reading the device fingerprint from the video playback request succeeds, send a risk query request containing the device fingerprint to the risk control server.

[0021] In some embodiments of this application, based on the above technical solutions, the video sending module is further configured to: if the risk status information does not meet the predetermined risk control strategy, then stop processing the video playback request; and send terminal abnormal response information for the video playback request to the playback terminal.

[0022] According to one aspect of the embodiments of this application, a method for processing media data is provided, comprising: sending a video playback request to an edge server according to a video playback instruction, so that the edge server executes the method of any of the above technical solutions, wherein the video playback request includes a device fingerprint of a playback terminal, and the device fingerprint is generated based on the device information of the playback terminal;

[0023] Receive the video to be played from the edge server and play the video to be played.

[0024] According to one aspect of the embodiments of this application, a media data processing apparatus is provided, comprising: a request module configured to send a video playback request to an edge server according to a video playback instruction, so that the edge server executes the method of any of the above technical solutions, wherein the video playback request includes a device fingerprint of a playback terminal, and the device fingerprint is generated based on the device information of the playback terminal;

[0025] The video receiving module is configured to receive and play the video to be played sent by the edge server.

[0026] In some embodiments of this application, based on the above technical solutions, the request sending module is further configured to: obtain device information of the playback terminal through a device fingerprint tool when the playback terminal is initialized; send the device information to the risk control server so that the risk control server generates a device fingerprint of the playback terminal based on the device information; and receive the device fingerprint sent by the risk control server.

[0027] In some embodiments of this application, based on the above technical solutions, the request sending module is specifically configured to: when a video playback instruction is received, perform hash calculation based on the hardware and software information of the playback terminal using a device fingerprint tool to generate a device hash; check the system permission status and abnormal application installation status of the playback terminal using the device fingerprint tool to obtain an environment check result; and package the device hash and the environment check result to generate the device information of the playback terminal.

[0028] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform a media data processing method as described above by executing the executable instructions.

[0029] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the media data processing method as described in the above technical solutions.

[0030] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the media data processing methods provided in the various optional implementations described above.

[0031] According to one aspect of the embodiments of this application, a method for processing a video stream is provided, wherein the video stream is generated by the encoding method in the above technical solutions, or decoded by the decoding method in the above technical solutions.

[0032] According to one aspect of the embodiments of this application, a method for processing video streams is provided, wherein the video stream is stored on a non-volatile computer-readable storage medium, the video stream being generated by the encoding method described above, or decoded by the decoding method described above.

[0033] In the embodiments of this application, the edge server obtains a video playback request sent by the playback terminal. The video playback request contains a device fingerprint generated by the server. Then, based on the video playback request, the edge server sends a risk query request containing the device fingerprint to the risk control server to obtain the risk status information of the playback terminal. The risk status information is generated by risk assessment based on the device information of the playback terminal. After receiving the risk status information fed back by the risk control server, if the risk status information meets the predetermined risk control policy, the edge server sends the video to be played to the playback terminal for playback. In this way, before distributing actual media content to the playback terminal, the edge server verifies whether the device environment of the playback terminal meets the risk control policy, and only provides media content to the playback terminal if the policy is met. This avoids the playback environment from being tampered with, ensures that the playback terminal is a secure playback environment, prevents media data from being exposed to unauthorized users, and thus improves the data confidentiality and security of the media content.

[0034] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0035] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0036] Figure 1 The media data processing method described in this application is applied to the system architecture of a cloud host platform.

[0037] Figure 2 This is a flowchart of a media data processing method according to an embodiment of this application.

[0038] Figure 3 This is a flowchart of a media data processing method according to an embodiment of this application.

[0039] Figure 4 This is a flowchart of a media data processing method according to an embodiment of this application.

[0040] Figure 5 This is a schematic system structure diagram of the video playback system in the embodiments of this application.

[0041] Figure 6 This is a schematic flowchart illustrating how the playback terminal acquires the device fingerprint in an embodiment of this application.

[0042] Figure 7 This is a schematic flowchart of the risk control engine in the embodiments of this application.

[0043] Figure 8 This is a schematic flowchart illustrating the edge node processing procedure in the embodiments of this application.

[0044] Figure 9 This is a schematic diagram illustrating the interactive relationships in the overall video playback process of this application embodiment.

[0045] Figure 10 A block diagram illustrating the composition of a media data processing apparatus in an embodiment of this application is shown schematically.

[0046] Figure 11 A block diagram illustrating the composition of a media data processing apparatus in an embodiment of this application is shown schematically.

[0047] Figure 12 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0048] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0049] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0050] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve the predetermined function, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement at least one module or unit. Furthermore, each module or unit can be part of an overall module or unit that includes the functions of that module or unit.

[0051] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in at least one hardware module or integrated circuit, or in different network and / or processor devices and / or microcontroller devices.

[0052] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0053] It should be understood that the solution of this application can be applied to media playback systems, specifically to media playback systems based on edge servers. In the embodiments of this application, such systems can be, for example, media playback systems built on a Content Delivery Network (CDN), such as live streaming platforms, video playback websites, or internet television video playback systems. The media content played in such systems typically has corresponding copyrights and will only be played to users with the corresponding playback permissions. Therefore, in such systems, user accounts are usually subject to corresponding permission management to ensure that unauthorized accounts or terminals cannot access or watch unauthorized media content, thereby preventing media content piracy. In the solution of this application, a risk control engine and edge computing functions are used to prevent video stream piracy, and playback control is performed at CDN nodes. By combining device fingerprint recognition with the risk control engine and edge computing functions to perform risk analysis on playback terminals, risky playback terminals are identified, such as playback terminals with cracked or rooted operating systems, or playback terminals with suspicious or malicious applications installed, thereby reducing the possibility of video stream piracy.

[0054] In related technologies, media content providers encrypt their content, and viewers can only decrypt and play the content after successfully obtaining the decryption key, thus preventing piracy. However, in such solutions, playback terminals may steal the key by tampering with the playback environment and use it to decode media content sent from edge servers, thereby exposing media data to unauthorized users and reducing the confidentiality and security of the media content.

[0055] Based on this, the technical solution of this application proposes a media data playback scheme. Specifically, please refer to... Figure 1 The media data processing method according to the embodiments of this application applied to the system architecture of a blockchain system can mainly include a playback terminal 110, an edge server 120, and a backend risk control server 130. The playback terminal 110 can include smartphones, tablets, laptops, smart voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. The server 130 can be a server providing various services; it can be an independent physical server, a server cluster composed of multiple physical servers, or a distributed system. It can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The playback terminal 110, edge server 120, and server 130 can be connected via a network. The network can be a communication medium providing various connection types of communication links, such as wired or wireless communication links.

[0056] Depending on the implementation requirements, the system architecture in this application embodiment can have any number of playback terminals, networks, and servers. For example, the edge server 120 and the backend risk control server 130 can be a server group composed of multiple server devices. In addition, the technical solution provided in this application embodiment can be applied to the playback terminal 110, the edge server 120, and the backend risk control server 130, or it can be implemented jointly by the playback terminal 110, the edge server 120, and the backend risk control server 130. This application does not impose any special limitations on this.

[0057] like Figure 1As shown, the media playback system in this application can be deployed on an edge server 120 and a backend risk control server 130. A copy of the media file is cached on the edge server 120, and the media file is also stored on the source server of the media provider. The client on the playback terminal 110 requests media content, such as video, from the edge server 120. Simultaneously, the playback terminal 110 provides its device fingerprint to the edge server 120. The edge server 120 then uses the received device fingerprint to call the backend risk control server 130 to obtain the risk assessment status of the playback terminal 110. Only after determining that the playback terminal 110 meets the risk control requirements based on the risk assessment status will the edge server 120 provide specific media content for playback.

[0058] The implementation details of the technical solutions in the embodiments of this application are described in detail below: Figure 2 A flowchart illustrating a media data processing method according to an embodiment of this application is shown. This media data processing method can be executed by a device with computing processing capabilities, such as an edge server. The media data processing method of this application will be described below from the perspective of an edge server. (Refer to...) Figure 2 As shown, the method for processing this media data includes at least steps S210 to S230, which are described in detail below:

[0059] Step S210: Obtain a video playback request sent by the playback terminal. The video playback request contains the device fingerprint of the playback terminal, which is generated based on the device information of the playback terminal.

[0060] A video playback request is typically generated by the playback terminal when it wants to play a video. This request contains the playback terminal's device fingerprint. The device fingerprint is generated based on the playback terminal's device information; for example, it can be generated by a risk control server, an edge server, or other devices specifically designed for generating device fingerprints. The device fingerprint can be used to identify, monitor, and trace the playback terminal. Specifically, during interactions with video playback websites and applications, the playback terminal generates a device fingerprint by analyzing the unique characteristics of its device information, thereby identifying the playback terminal. The device fingerprint is provided to the playback terminal by the risk control server. The playback terminal adds the device fingerprint to the video playback request when it is generated.

[0061] Step S220: Based on the video playback request, a risk query request containing the device fingerprint is sent to the risk control server so that the risk control server can obtain the risk status information of the playback terminal based on the device fingerprint. The risk status information is generated by risk assessment based on the device information of the playback terminal.

[0062] The edge server parses the device fingerprint of the playback terminal from the video playback request, and then generates a risk query request based on this device fingerprint to call the relevant servers of the risk control server. The risk control server can provide an interface for risk querying, and the edge server performs the query by calling the interface. The risk control server and the edge server are usually two independent servers or cloud servers, but in some embodiments, they can also be deployed on the same server. The risk control server responds to the risk query request and obtains the risk status information of the playback terminal based on the device fingerprint. The risk status information can be generated by the edge server or the risk control server based on the device fingerprint it receives, the device fingerprint previously provided by the playback terminal, and device-related descriptive information. For example, the risk server first assesses and determines the risk status information of the playback terminal based on the relevant device and playback environment information uploaded by the playback terminal and saves it in the risk server. When a request is received from the edge server, the generated risk status information is directly queried based on the device fingerprint or other identification information of the playback terminal and fed back to the edge server.

[0063] Step S230: Based on the risk status information sent by the risk control server, if the risk status information meets the predetermined risk control strategy, send the video to be played to the playback terminal so that the video to be played can be played on the playback terminal.

[0064] The edge server receives risk status information from the risk control server. This risk status information is generated based on a risk assessment of the playback terminal's device information. The risk control server can be configured with corresponding risk control algorithms or trained artificial intelligence models to perform risk assessments based on the sent device fingerprints. The risk status information describes the current risk status of the playback terminal. Specifically, the risk status information can be a risk score or risk level. When the risk of a playback terminal is too high, it indicates that the device may be at risk of video content leakage or that the playback terminal does not have the appropriate permissions to play the video. For example, if a cracked playback application is installed on the playback terminal or the playback terminal's operating system is cracked, the risk level of the playback terminal will increase.

[0065] The predetermined risk control strategy specifies how to determine whether a playback terminal poses a playback risk based on risk status information. This strategy depends on the specific form of the risk status information. For example, if the risk status information is specifically a risk score, with higher scores indicating lower risk, the risk control strategy could require a risk score higher than 50. Then, when the risk status score is above 50, such as 80, the edge server determines that the video can be played on the playback terminal. The edge server then sends a video playback request to the playback terminal, allowing the terminal to play the video upon receipt. This video can be retrieved from locally cached videos or from the source server of the video. The video to be played can be determined based on the video playback request. For example, the video playback request may contain identification information for the video to be played. The edge server uses this identification information, along with information about the locally stored video location, to retrieve the specific file of the video to be played. It is understood that the playback process can vary depending on the specific playback format of the video to be played. For example, if the video to be played is a standalone video, the edge server can provide the video in segments; if the video to be played is live media, the edge server can continuously send the video stream.

[0066] In the embodiments of this application, the edge server obtains a video playback request sent by the playback terminal. The video playback request contains a device fingerprint generated by the server. Then, based on the video playback request, the edge server sends a risk query request containing the device fingerprint to the risk control server to obtain the risk status information of the playback terminal. The risk status information is generated by risk assessment based on the device information of the playback terminal. After receiving the risk status information fed back by the risk control server, if the risk status information meets the predetermined risk control policy, the edge server sends the video to be played to the playback terminal for playback. In this way, before distributing actual media content to the playback terminal, the edge server verifies whether the device environment of the playback terminal meets the risk control policy, and only provides media content to the playback terminal if the policy is met. This avoids the playback environment from being tampered with, ensures that the playback terminal is a secure playback environment, prevents media data from being exposed to unauthorized users, and thus improves the data confidentiality and security of the media content.

[0067] In some embodiments of this application, based on the embodiments described herein, before sending the video to be played to the playback terminal, the edge server also sends a list of playable videos to the playback terminal. This list contains identification information for at least one playable video. Then, it receives a video selection request from the playback terminal. This video selection request contains identification information for the video to be played selected by the playback terminal based on the list of playable videos. Finally, it obtains the video to be played based on the identification information in the video selection request. In this embodiment, the video playback request is triggered before the playback terminal needs to play a video, for example, when a video browsing page is opened. After determining that the playback terminal is safe, the edge server sends a list of playable videos to the playback terminal based on the video playback request. For example, the video playback request may contain page information of a video website, and the edge server uses this page information to determine which videos the playback terminal can currently play, thus determining the list of playable videos. This list of playable videos contains identification information for at least one playable video. The list of playable videos is provided to the playback terminal, which can then select the video to play from this list, thereby generating a video selection request. The edge server receives a video selection request from the playback terminal and retrieves the video to be played based on the video identifier contained in the request. For example, the playback terminal has a live streaming application installed for watching live streams. When a user opens a channel within this live streaming application, the application sends a video playback request to the edge server. After verifying the playback terminal, the edge server sends a list of live streaming rooms currently broadcasting under that channel to the playback terminal. The playback terminal then displays this list of available live streaming rooms to the user on the live streaming application's page. The user selects a live streaming room to watch through the application, and the application retrieves the video stream of that room from the edge server using its room number and plays it within the application. In this way, the edge server provides the list of playable videos only after assessing the risk of the playback terminal. The risk status of the playback terminal is confirmed during the process before officially retrieving the video content. A playback terminal with a risk factor cannot obtain the list of playable videos, making it difficult to trigger the playback of a specific video. This increases the difficulty of intercepting information related to the specific video to be played, thus improving the security of the solution.

[0068] In some embodiments of this application, based on the embodiments of this application, the edge server also receives device information sent by the playback terminal. The device information includes the playback terminal's device hash and environment check results. The device hash is generated by hash calculation based on the playback terminal's hardware and software information. The environment check results are generated by checking the playback terminal's system permission status and abnormal application installation status. Then, based on the device hash and the environment check results, a device fingerprint of the playback terminal is generated. A risk assessment is then performed based on the device information to obtain the playback terminal's risk status information. The device fingerprint is associated with the risk status information and stored in the risk control server. Finally, the device fingerprint is sent to the playback terminal. In this embodiment, the risk control server can be part of the edge server, or it can be included in the video playback system along with the edge server. This system can be managed by the edge server, and the above actions in this embodiment can also be performed by the risk control server. The edge server can receive device information sent by the playback terminal through the risk control server. The device information includes the playback terminal's device hash and environment check results. The device hash is generated based on the playback terminal's hardware and software information, while the environment check results are the results of the playback terminal checking its current environment. Device hashes contain, for example, the numbers or codes of various hardware configurations in the playback terminal, such as information about hardware devices like the processor, graphics card, and memory. Software information includes descriptions of the software installed on the playback terminal, such as the name and version of the installed software, the type and version of the operating system, and which patches are installed. Environment checks primarily examine the security of the playback terminal's software operating environment. Specifically, the checks may include whether the operating system's system permissions have been compromised and whether any abnormal applications (such as suspicious or cracked applications) are installed. The edge server calculates and generates a device fingerprint for the playback terminal based on the device hash and environment check results. Specifically, the calculation can be performed using hash calculations, character concatenation, or mathematical calculations. The generated device fingerprint can be used to uniquely identify the video terminal. The edge server, through a risk control server, performs a risk assessment based on the device information to obtain the playback terminal's risk status information. The risk assessment process can employ a predetermined risk assessment algorithm, such as scoring based on various data points in the device hash and environment check results, or comparing the device fingerprint with a previously determined fingerprint of the playback terminal in a normal state. Specifically, the device hash contains the identification information of each specific component in the playback terminal. Under normal circumstances, this identification information usually does not change. The risk control server can determine the number of components that have changed based on the comparison between the device hash and the historical device hash, which is one of the scoring items in the risk score.For the obtained risk status information, the risk control server associates the device fingerprint with the risk status information and saves it to its local database. The edge server can retrieve this risk status information using the device fingerprint. In some embodiments, the edge server first checks the risk control server for the existence of corresponding risk status information based on the device fingerprint. If it exists, the risk status information can be directly obtained without risk assessment through the risk control server. If it does not exist, risk assessment is then performed through the risk control server to obtain the risk status information. The device fingerprint is sent to the playback terminal for use when requesting video playback. This method allows the risk control server to perform risk assessment based on the device information uploaded by the playback terminal. By actively triggering the risk assessment process with the information uploaded by the playback terminal, the risk server can more specifically assess the status of the playback terminal, thus improving the accuracy of the risk assessment results.

[0069] In some embodiments of this application, based on the embodiments of this application, during the process of risk assessment based on the device information to obtain the risk status information of the playback terminal, the edge server inputs the device information into the risk assessment model on the risk control server to obtain the risk score output by the risk assessment model, and then determines the risk status information of the playback terminal based on the comparison result of the risk score and a preset scoring threshold. In this embodiment, a risk assessment model for risk assessment is deployed on the risk control server. The risk assessment model is pre-trained to assess the risk status of various types of devices. This risk assessment model can specifically be any suitable artificial intelligence model. The edge server determines the risk status information of the playback terminal based on the comparison result of the risk score output by the risk assessment model and a preset scoring threshold. For example, if the preset scoring threshold is 50 points, then all devices with output scores below 50 points are considered risky devices, and those above 50 points are considered risk-free devices. The risk control server continuously receives device information from each playback terminal of the video playback platform. In some embodiments, the risk control server also receives piracy data of the videos played by the playback terminals and marks the risk control results of the device information based on this information. For example, if a video to be played has been played on several playback devices, and piracy occurs, the video platform can use device information related to the video to generate positive and negative samples. These samples can then be used as training data to fine-tune the risk assessment model, thereby improving its evaluation capabilities. For instance, if a pirated video has been played on 100,000 devices, based on the risk scores output by the current risk assessment model for these devices, a portion of these scores can be divided into negative samples according to a predetermined ratio. For example, the lower 20% of scores could be used as negative samples, and the remaining 80% as positive samples. This allows for fine-tuning of the risk assessment model's polarity, improving its accuracy. By using an artificial intelligence model for risk assessment in this way, the risk assessment capabilities of the risk server can be continuously improved and optimized through model training, thus enhancing the accuracy of the risk assessment solution.

[0070] In some embodiments of this application, based on the embodiments in this application, during the process of sending a risk query request containing the device fingerprint to the risk control server according to the video playback request, the edge server first parses the video playback request and reads the device fingerprint. If reading the device fingerprint from the video playback request fails, a playback refusal notification is sent to the playback terminal; if reading the device fingerprint from the video playback request succeeds, a risk query request containing the device fingerprint is sent to the risk control server. In this embodiment, if the edge device cannot read the device fingerprint from the video playback request, it will directly refuse to play the video and send a playback refusal notification to the playback terminal. Specifically, the device fingerprint can be added to the header of the video playback request. When processing the video playback request, the edge server first parses the header and checks whether it contains device fingerprint information. If the header does not contain a device fingerprint, the edge server can directly send a playback refusal notification to the playback terminal without parsing the specific content of the video playback request. In some embodiments, the playback refusal notification triggers the terminal device to send device information to the risk control server to obtain the device fingerprint in order to continue the playback process. For example, after receiving a rejection notification from the edge server, the playback terminal sends its device information to the risk control server. The risk control server then performs a risk assessment on the playback terminal based on this information and generates a new device fingerprint, which is provided to the playback terminal. The playback terminal can then use this new device fingerprint to attempt to play the video again. The edge server will only proceed with the subsequent process if it successfully reads the device fingerprint from the video playback request. This method ensures that the playback terminal undergoes a risk assessment verification process, preventing unassessed playback terminals from executing the playback process and thus improving the security of the solution.

[0071] In some embodiments of this application, based on the embodiments of this application, if the risk status information does not meet the predetermined risk control strategy, the edge server stops processing the video playback request and then sends terminal abnormality response information for the video playback request to the playback terminal. In this embodiment, if the risk status information does not meet the predetermined risk control strategy, such as a risk level that is too high, a risk control score that is insufficient, or the playback terminal being identified as a risky device, it indicates that the playback terminal is at risk. For example, the operating system may be cracked or rooted, or software that may be used for video piracy may be installed on the playback terminal. The edge server will stop processing the video playback request and send terminal abnormality response information for the video playback request to the playback terminal. The playback terminal will not receive any video content provided by the edge server. For example, the edge server can prompt the playback terminal about the reason for being refused playback, such as prompting an application abnormality when pirated software is installed on the playback terminal, prompting a client abnormality when the client used to play the video is cracked software, or prompting an abnormal playback environment when the playback terminal is rooted or cracked. In this way, piracy risks are identified before the playback terminal obtains the media content. Compared to providing encrypted media content to the playback terminal so that the playback terminal cannot decrypt and play it, this method ensures that even if the playback terminal obtains the decoding key through illegal channels, it will still be unable to access the encrypted media content. This further reduces the possibility of the encrypted media content being cracked and improves the data security of the solution.

[0072] In embodiments of this application, a method for... Figure 2 Other detailed embodiments of the technical solution shown in the example are as follows: Figure 3 As shown, a media data processing method according to one embodiment of this application may include the following steps:

[0073] Step S310: Obtain a video playback request sent by the playback terminal. The video playback request contains the device fingerprint of the playback terminal, which is generated based on the device information of the playback terminal.

[0074] Optionally, the implementation details of step S310 are the same as... Figure 2 The steps S210 shown are the same and will not be repeated here.

[0075] Step S320: Based on the video playback request, a risk query request containing the device fingerprint is sent to the risk control server so that the risk control server can obtain the risk status information of the playback terminal based on the device fingerprint. The risk status information is generated by risk assessment based on the device information of the playback terminal.

[0076] Optionally, the implementation details of step S320 are the same as those of... Figure 2The steps S220 shown are the same and will not be repeated here.

[0077] Step S330: Based on the risk status information sent by the risk control server, if the risk status information meets the predetermined risk control strategy, a key request for the video to be played is sent to the video permission server.

[0078] Step S340: Receive the decryption key of the video to be played sent by the video permission server;

[0079] Step S350: Send the video to be played and the decryption key to the playback terminal so that the playback terminal can decrypt and play the video to be played according to the decryption key.

[0080] In this embodiment, after determining that the risk status of the playback terminal meets the requirements, the edge server further needs to perform permission verification of the video to be played. Permission verification is used to determine whether the playback terminal has the permission to play the video, for example, whether the terminal has purchased viewing rights for the video or whether the terminal is in a suitable region for playing the video. Specifically, if the risk status information meets the predetermined risk control strategy, the edge server will send a key request for the video to be played to the video permission server. The video permission server is a server used to verify the permissions of the playback terminal. The key request will contain relevant descriptive information about the playback terminal or information about the currently logged-in account on the playback terminal. This information can be obtained through the video playback request or through the device information uploaded when the playback terminal obtains its device fingerprint. The video permission server will verify whether the playback terminal has permission to play the video based on the key request, and after successful verification, will send the decryption key for the video to be played to the edge server. In this embodiment, the video to be played is itself encrypted, and the playback terminal needs the corresponding decryption key to decrypt it before it can decode and play it. If verification fails, the video access server will refuse to send the decryption key, and the edge server will report to the playback terminal, notifying it that it does not have permission to play the requested video. If verification succeeds, the edge server will send the edge key along with the encrypted video to the playback terminal, which can then decrypt and play the video using the decryption key. For example, some videos on video websites require accounts that meet specific conditions to play. When a playback terminal requests to play such a video, after the edge server passes the risk verification of the playback terminal, it will verify whether the account logged in by the playback terminal meets the specific conditions. If the verification succeeds, the edge server will provide the device with a key to decrypt the video. If verification fails, the playback terminal will not be able to obtain the decryption key, and even if the device passes the risk verification and obtains the video through other means, it will not be able to decrypt and play it. Through this method, the risk status and access status of the playback terminal can be dually verified, thereby further ensuring the legitimate access of the playback terminal to the video to be played. At the same time, since the video to be played is encrypted, it can prevent the interception of the video stream transmission process by the edge server from causing media data leakage, which is beneficial to improving the data security of the solution.

[0081] In the embodiments of this application, the edge server obtains a video playback request sent by the playback terminal. The video playback request contains a device fingerprint generated by the server. Then, based on the video playback request, the edge server sends a risk query request containing the device fingerprint to the risk control server to obtain the risk status information of the playback terminal. The risk status information is generated by risk assessment based on the device information of the playback terminal. After receiving the risk status information fed back by the risk control server, if the risk status information meets the predetermined risk control policy, the edge server sends the video to be played to the playback terminal for playback. In this way, before distributing actual media content to the playback terminal, the edge server verifies whether the device environment of the playback terminal meets the risk control policy, and only provides media content to the playback terminal if the policy is met. This avoids the playback environment from being tampered with, ensures that the playback terminal is a secure playback environment, prevents media data from being exposed to unauthorized users, and thus improves the data confidentiality and security of the media content.

[0082] In some embodiments of this application, based on the embodiments described herein, before sending the video to be played and the decryption key to the playback terminal, the edge server queries the cache server for the video to be played. If the cache server does not contain the video to be played, the edge server retrieves the video to be played from the source server of the video to be played according to the video playback request, and then caches the video to be played in the cache server. In this embodiment, when the edge server has the video to be played locally, it can directly retrieve the video to be played locally and send it to the playback terminal. If the video to be played is not cached locally, it retrieves the media content from the source server of the video to be played and provides it to the playback terminal, and caches the retrieved media content locally on the edge server for use by other playback terminals when requesting the video to be played. Through the above method, the video is saved to the edge server, and when providing the video, it is not necessary to remotely retrieve data, reducing the time required for data transmission and improving the data transmission efficiency of the solution.

[0083] Figure 4 A flowchart illustrating a media data processing method according to an embodiment of this application is shown. This media data processing method can be executed by a device with computing processing capabilities, such as a playback terminal. The media data processing method of this application will be described below from the perspective of the playback terminal. (Refer to...) Figure 2 As shown, the method for processing this media data includes at least steps S410 to S420, which are described in detail below:

[0084] Step S410: According to the video playback instruction, a video playback request is sent to the edge server so that the edge server executes the method as described in any of the above embodiments, wherein the video playback request includes the device fingerprint of the playback terminal, and the device fingerprint is generated based on the device information of the playback terminal.

[0085] Step S420: Receive the video to be played from the edge server and play the video to be played.

[0086] Video playback commands are typically generated based on interactions between the user and the playback terminal. For example, a user requesting a video or opening a video player to retrieve a list of playable videos can trigger a playback command. The playback terminal sends a video playback request to the edge server. The playback terminal's device fingerprint is usually obtained before video playback, such as when the playback terminal starts up or during the startup of the playback application on the playback terminal, by sending a request to the server. The device fingerprint can also be stored in the playback terminal and reused under certain conditions, such as being directly retrieved from the device within a certain timeframe. The edge server then performs a risk assessment of the playback terminal according to the scheme described in this application. The playback terminal adds the device fingerprint to the video playback request. For example, it can be included in the header of the video playback request. The device fingerprint can be obtained when the playback terminal starts up or when the client on the playback terminal starts up. After the risk verification is successful, the edge server sends the video to be played to the playback terminal, which then plays the received video. In this way, before distributing actual media content to the playback terminal, the edge server verifies whether the playback terminal's device environment meets the risk control policy. Only if the policy is met will the edge server provide media content to the playback terminal. This prevents the playback environment from being tampered with and ensures that the playback terminal is a secure playback environment. It also prevents media data from being exposed to unauthorized users, thereby improving the confidentiality and security of media content.

[0087] In some embodiments of this application, based on the embodiments described herein, the playback terminal also obtains its device information via a device fingerprinting tool during initialization, and then sends the device information to a risk control server. This allows the risk control server to generate a device fingerprint for the playback terminal based on the device information, and finally receives the device fingerprint sent by the risk control server. In this embodiment, the device fingerprinting tool is software or code pre-deployed in the playback terminal. The device fingerprinting tool can be embedded in a video player or application and installed on the playback terminal along with it. The initialization process of the playback terminal can be the process of launching a player or application. During application launch, the embedded device fingerprinting tool runs. The application obtains the playback terminal's device information via the device fingerprinting tool and then sends it to the risk control server. The risk control server then provides the playback terminal with a device fingerprint based on the device information for subsequent video playback. The risk control server also performs a risk assessment on the playback terminal based on the device information and saves it in association with the device fingerprint for subsequent edge server queries. This device fingerprint is added to the playback request when the playback terminal plays video for risk assessment by the edge server. By using the above method, the playback terminal can actively obtain device information to acquire the device fingerprint without having to acquire it before video playback, thereby reducing the processing involved in video playback, reducing the waiting time during video playback, and improving the response speed of video playback.

[0088] In some embodiments of this application, based on the embodiments in this application, during the process of obtaining the device information of the playback terminal through a device fingerprinting tool, when a video playback command is received, the playback terminal will use the device fingerprinting tool to perform hash calculation based on the hardware and software information of the playback terminal to generate a device hash. Then, the device fingerprinting tool will check the system permission status and abnormal application installation status of the playback terminal to obtain the environment check result. Finally, the device hash and the environment check result will be packaged to generate the device information of the playback terminal. In this embodiment, the playback terminal obtains the hardware and software information of the playback terminal through a device fingerprinting tool to generate the device hash. The hardware information may be, for example, the device identification codes of various hardware components of the playback terminal, such as the identification codes or codes of the main hardware of the device, such as the processor, motherboard, memory, and graphics card. The software information is the operating system and installed software of the playback terminal, such as the type and version of the operating system and the version of the installed software. The device hash can be obtained by combining the hash values ​​of various hardware and software information, for example, by concatenation. The system permission status of the playback terminal refers to whether its operating system has been cracked or rooted, while the abnormal application installation status checks whether software used for video piracy exists on the playback terminal. The playback terminal packages the device hash and environment check results to generate device information. In some embodiments, the device information also includes encrypted hardware and software information for the server to decrypt and verify. In this way, the risk control server can identify the terminal through the device hash and analyze its risk status through the environment check results.

[0089] The implementation details of the technical solutions in the embodiments of this application are described below with specific examples. Please refer to... Figure 5 , Figure 5 This is a schematic system structure diagram of the video playback system in an embodiment of this application. Figure 5 As shown, the system mainly consists of client devices 510, edge nodes 520, and a Risk Control Engine (RCE) 530. In some cases, the system also requires the assistance of an origin server 540. Figure 5As shown, a Software Development Kit (SDK) for risk control is installed on the terminal device. The client device 510 first initializes the SDK, obtains the necessary configuration information and environment check information for the client device 510, and then passes this information to the backend risk control engine 530. The risk control engine 530 returns a device fingerprint to the device. When the device requests on-demand video content, it appends the device fingerprint to the packet header. The on-demand request is proxied through the CDN edge node 520. The edge node 520 extracts the fingerprint from the packet header and sends a request with the device fingerprint to the backend RCE using the application programming interface. The RCE responds with the risk status of the device. If the device is considered too risky, the process stops, the edge node 520 responds with a disallowed request, and the process stops there. If the risk status is acceptable, a request to obtain a key is sent to the Digital Rights Management (DRM) server 550. The DRM key server returns a key used to decrypt the content. If the video content has not yet been cached on the edge server, the edge server requests the next video content from the origin server 540. If already cached, there's no need to forward the video to the origin server (540). The video content will be returned to the edge server, and simultaneously cached for use on the next valid request. The edge server will then return the video content along with the DRM key to the client for playback.

[0090] Please see Figure 6 , Figure 6 This is a schematic flowchart illustrating the process of a playback terminal acquiring a device fingerprint in an embodiment of this application. Figure 6As shown, in operation 610, the software player integrates the SDK as part of the application. The client application playing the video needs to initialize the SDK before it can play the video. During initialization, in operation 620, the SDK acquires various hardware and software information about the terminal device. Hardware device information includes, for example, the International Mobile Equipment Identity (IMEI), International Mobile Subscriber Identity (IMSI), and device ID. In operation 630, software device information is also collected, such as the operating system version, browser information, and other application packages installed on the device. Then, in operation 640, the SDK performs various checks, such as checking the operating system's administrator privileges, checking the verification information or cracking status of installed software, to see if the device has been rooted or if any suspicious packages have been installed. In operation 650, the SDK creates a hash value and responds with all check results in an initialization data packet. The initialization data packet also includes selected business information, such as the RCE session ID, the client's username, IP address, and other information. It also includes the user's current action, such as retrieving on-demand video or obtaining DRM authorization. Then, in operation 660, the SDK sends this initialization data packet to the backend risk control engine server via the network (e.g., HTTPS). Upon receiving the initialization data packet, the risk control engine processes the information and returns the device fingerprint to the client device software.

[0091] Please see Figure 7 , Figure 7 This is a schematic flowchart of the risk control engine in an embodiment of this application. Figure 7As shown, in operation 710, the primary task of RCE is to obtain information from the end-user device and return the device fingerprint. In operation 720, RCE receives the hash values ​​of all device parameters and checks the device environment to construct the device fingerprint. In operation 730, for example, the device ID is encapsulated into the device fingerprint. In operation 740, RCE associates this information with the device ID in the encrypted device. While continuously receiving this information, in operation 750, RCE feeds this information into an artificial intelligence neural network model. If any parameter is potentially abnormal, the features input to the model generate a risk score that matches the abnormal state. In operation 760, this information is stored in a backend database that links the device ID with its associated risk score. This information can be queried via an application programming interface (API) and by edge functions running on CDN edge nodes. For example, in operation 760, the edge node sends a request with the device fingerprint to the RCE engine via the API and obtains a device risk overview. In operation 770, RCE responds to the API request to display the risk of the device corresponding to that device fingerprint.

[0092] Please see Figure 8 , Figure 8 This is a schematic flowchart illustrating the edge node processing procedure in an embodiment of this application. Figure 8As shown, an edge node CDN can run a serverless application. In operation 810, HTTP requests for video-on-demand (VOD) content first pass through the CDN. When the request passes through the edge node, the CDN can process it using a serverless function. The serverless function will activate the corresponding request based on the HTTP URL. When requesting any video content from this URL, the CDN expects a packet header containing the client's device fingerprint. Before requesting the video content, the client will perform the necessary initialization of the SDK and obtain the device fingerprint from the RCE through the process described above. When requesting the video content, the client will put the device fingerprint into the packet header. Then, in operation 820, the serverless function will extract the device fingerprint from the packet header. If there is no such packet header, the edge node will reject the request. If there is a device fingerprint, in operation 830, the serverless function will use the device fingerprint to call the RCE's backend API to obtain risk information for that specific device in operation 840. Once the RCE returns information, in operation 850, the CDN's serverless function will check the risk score according to the user-defined policy. In Operation 860, for example, if the acceptable risk score is 50, then as long as the score exceeds 50, the edge function will allow the request to proceed, sending the video to the playback terminal. If the video content is already cached on the edge server, the CDN will return the video content. If the content to be played is not on the CDN, the CDN will pass the request and forward it to the origin server to retrieve the video content. The origin server is the server where the video to be played is stored, such as the video website's server. If DRM is present on the video website, and the risk level is acceptable, the CDN will first obtain the content's encryption key via a request. Then, it will send the obtained key along with the video content to the playback terminal.

[0093] Please see Figure 9 , Figure 9 This is a schematic diagram illustrating the interactive relationships within the overall video playback process in this application embodiment. For example... Figure 9As shown, in step 910, when a user requests to play a video, the video player will call the SDK embedded in the application to start the player. Simultaneously, the SDK will initialize the corresponding backend services on the RCE server. After starting the player, the player will use the SDK to assess the device environment, such as whether it has been rooted or tampered with, whether any potential intrusion indicators or malware are detected, and many other signals. Then, in step 920, the player will provide device information to the RCE server for risk assessment and request a device fingerprint, receiving the device fingerprint generated by the RCE server in step 930. Then, in step 940, the application will append the fingerprint to the HTTP request header to obtain the video playlist. In step 950, the request will be received by the CDN node. After receiving the HTTP request, the CDN node will check the device fingerprint in the header before providing cached content services. The computational processing at the edge node will be provided by the edge computing function of the CDN node. Then, the edge computing function will check whether the header containing the device fingerprint exists in the HTTP request. If the header containing the device fingerprint does not exist, it will reject the request, and the playback terminal will not obtain the video content. If the packet header containing the device fingerprint is present, then in step 960, the edge computing function sends the device fingerprint to the backend RCE server. In step 970, the RCE server runs some artificial intelligence models to analyze the device fingerprint request and its reported device status. Based on these artificial intelligence models, it can determine whether there is an anomaly. In step 980, the edge computing function will obtain a response regarding the risk level of the device fingerprint based on the device status and device behavior. In step 990, if the RCE server determines that the playback terminal is not at risk, the edge function will continue to process the request and provide a playlist. After receiving the playlist, the player can request to play the actual video segment. This can also be done through the same process described above for risk protection. If DRM is also used for data protection, once the player receives the playlist, it will continue to execute the DRM process, obtaining the key to decrypt the content through the proprietary DRM used.

[0094] Specifically, when the solution proposed in this application is applied to anti-piracy scenarios, there are typically three specific situations. The first situation involves a valid user using their mobile phone and an application provided by a content provider to watch video-on-demand (VOD) content. The user first selects the content to watch and then presses the play button. This application is integrated with the RCE SDK, meaning it will obtain device information, including whether the device has been rooted, and include this information in the packet header when requesting the playlist / content file. Each time the playlist button is clicked, the RCE SDK requests a device fingerprint from the backend. When requesting the device fingerprint, the RCE SDK transmits the device information. The request is sent through a CDN node. The CDN node checks if the fingerprint exists; if it does, it checks with the backend RCE server. The backend RCE server records the device fingerprint and its history of behavior and characteristics. Based on this, it returns a risk profile. If deemed high-risk, the edge server rejects the request. If low-risk, it allows it to proceed. In this case, from the perspective of the AI ​​engine's analysis, this is a valid user, and their behavior is not abnormal. Furthermore, the user's client device (e.g., a mobile phone) is not rooted. Therefore, the information received by the edge node from the RCE server poses no risk, and the request is allowed to pass. The second scenario: Pirates directly obtain links and attempt to access the application or client device from outside using scripts. Since this request lacks a fingerprint, the edge node will reject it. The third scenario: Pirates use the application but root it when receiving video-on-demand content, secretly replacing the Content Decryption Module (CDM) of the DRM component to obtain the encryption key. Once the RCE SDK obtains the device's fingerprint, it sends detailed information about the rooted device to the RCE server. Additionally, the user's activity on the application is abnormal, bypassing specific pages and directly accessing links. Once the edge node obtains this device fingerprint and verifies it with the backend RCE server, it will report the device as risky because it is rooted and its behavior is abnormal. The edge node's functionality itself will reject the video manifest file and will not transmit any content.

[0095] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0096] The following describes the implementation of the apparatus of this application, which can be used to perform the media data processing method in the above embodiments of this application. Figure 10 A block diagram illustrating the composition of a media data processing apparatus in an embodiment of this application is shown schematically. Figure 10 As shown, the media data processing device 1000 mainly includes:

[0097] The request acquisition module 1010 is configured to acquire a video playback request sent by the playback terminal. The video playback request includes the device fingerprint of the playback terminal, which is generated based on the device information of the playback terminal.

[0098] The request sending module 1020 is configured to send a risk query request containing the device fingerprint to the risk control server according to the video playback request, so that the risk control server can obtain the risk status information of the playback terminal according to the device fingerprint. The risk status information is generated by risk assessment based on the device information of the playback terminal.

[0099] The video sending module 1030 is configured to send a video to be played to the playback terminal based on the risk status information sent by the risk control server, if the risk status information meets a predetermined risk control strategy, so as to play the video to be played on the playback terminal.

[0100] In some embodiments of this application, based on the above technical solutions, the video sending module 1030 specifically includes: sending a key request for a video to be played to a video permission server; receiving a decryption key for the video to be played sent by the video permission server; and sending the video to be played and the decryption key to the playback terminal, so that the playback terminal can decrypt and play the video to be played according to the decryption key.

[0101] In some embodiments of this application, based on the above technical solutions, the video sending module 1030 further includes: querying the video to be played from the cache server; if the cache server does not contain the video to be played, obtaining the video to be played from the source server of the video to be played according to the video playback request; and caching the video to be played in the cache server.

[0102] In some embodiments of this application, based on the above technical solutions, the video sending module 1030 is further configured to: send a playable video list to the playback terminal, the playable video list containing identification information of at least one playable video; receive a video selection request from the playback terminal, the video selection request containing identification information of the video to be played selected by the playback terminal according to the playable video list; and obtain the video to be played according to the identification information in the video selection request.

[0103] In some embodiments of this application, based on the above technical solutions, the video sending module 1030 is further configured to: receive device information sent by the playback terminal, wherein the device information includes the device hash and environment check result of the playback terminal, wherein the device hash is generated by hash calculation based on the hardware information and software information of the playback terminal, and the environment check result is generated by checking the system permission status and abnormal application installation status of the playback terminal; calculate and generate the device fingerprint of the playback terminal based on the device hash and the environment check result; perform risk assessment based on the device information to obtain the risk status information of the playback terminal; associate the device fingerprint with the risk status information and store it in the risk control server; and send the device fingerprint to the playback terminal.

[0104] In some embodiments of this application, based on the above technical solutions, the video sending module 1030 is specifically configured to: input the device information into the risk assessment model on the risk control server to obtain the risk score output by the risk assessment model; and determine the risk status information of the playback terminal based on the comparison result of the risk score and a preset scoring threshold.

[0105] In some embodiments of this application, based on the above technical solutions, the request sending module 1020 is specifically configured to: parse the video playback request and read the device fingerprint; if reading the device fingerprint from the video playback request fails, send a playback rejection notification to the playback terminal; if reading the device fingerprint from the video playback request succeeds, send a risk query request containing the device fingerprint to the risk control server.

[0106] In some embodiments of this application, based on the above technical solutions, the video sending module is further configured to: if the risk status information does not meet the predetermined risk control strategy, then stop processing the video playback request; and send terminal abnormal response information for the video playback request to the playback terminal.

[0107] Figure 11 A schematic block diagram illustrating the composition of a media data processing apparatus according to an embodiment of this application is shown. Figure 11 As shown, the media data processing device 1100 mainly includes:

[0108] The request module 1110 is configured to send a video playback request to the edge server according to the video playback instruction, so that the edge server executes the method of any of the above technical solutions, wherein the video playback request includes the device fingerprint of the playback terminal, and the device fingerprint is generated based on the device information of the playback terminal.

[0109] The video receiving module 1120 is configured to receive and play the video to be played sent by the edge server.

[0110] In some embodiments of this application, based on the above technical solutions, the request module 1110 is further configured to: obtain device information of the playback terminal through a device fingerprint tool when the playback terminal is initialized; send the device information to the risk control server so that the risk control server generates a device fingerprint of the playback terminal based on the device information; and receive the device fingerprint sent by the risk control server.

[0111] In some embodiments of this application, based on the above technical solutions, the request module 1110 is specifically configured to: when a video playback instruction is received, perform hash calculation based on the hardware and software information of the playback terminal using a device fingerprint tool to generate a device hash; check the system permission status and abnormal application installation status of the playback terminal using the device fingerprint tool to obtain an environment check result; and package the device hash and the environment check result to generate the device information of the playback terminal.

[0112] It should be noted that the apparatus provided in the above embodiments and the method provided in the above embodiments belong to the same concept, and the specific way in which each module performs the operation has been described in detail in the method embodiments, and will not be repeated here.

[0113] Figure 12 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0114] It should be noted that, Figure 12 The computer system 1200 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0115] like Figure 12 As shown, the computer system 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1202 or programs loaded from storage section 1208 into Random Access Memory (RAM) 1203. The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An Input / Output (I / O) interface 1205 is also connected to the bus 1204.

[0116] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.

[0117] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs various functions defined in the system of this application.

[0118] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0119] According to one aspect of the embodiments of this application, a method for processing video streams is provided, wherein the video streams are generated by the encoding method described in the above technical solutions, or decoded by the decoding method described in the above technical solutions. Specifically, in this application, the video to be played by the client can be a video stream, and the edge server can use the solution provided in this application to perform risk verification on the client, and provide the encoded video stream to the client after verification. The client can then use the solution provided in this application to obtain the video stream to be played from the edge server.

[0120] According to one aspect of the embodiments of this application, a method for processing video streams is provided, wherein the video stream is stored on a non-volatile computer-readable storage medium, the video stream being generated by the encoding method described above, or decoded by the decoding method described above.

[0121] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0122] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0123] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0124] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0125] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for processing media data, characterized in that, include: Obtain a video playback request sent by the playback terminal, wherein the video playback request contains the device fingerprint of the playback terminal, and the device fingerprint is generated based on the device information of the playback terminal; Based on the video playback request, a risk query request containing the device fingerprint is sent to the risk control server so that the risk control server can obtain the risk status information of the playback terminal based on the device fingerprint. The risk status information is generated by risk assessment based on the device information of the playback terminal. Based on the risk status information sent by the risk control server, if the risk status information meets the predetermined risk control strategy, the video to be played is sent to the playback terminal so that the video to be played can be played on the playback terminal.

2. The processing method according to claim 1, characterized in that, Sending the video to be played to the playback terminal for playback on the playback terminal includes: Send a key request for the video to be played to the video access control server; Receive the decryption key of the video to be played sent by the video permission server; The video to be played and the decryption key are sent to the playback terminal so that the playback terminal can decrypt and play the video to be played based on the decryption key.

3. The processing method according to claim 2, characterized in that, Before sending the video to be played and the decryption key to the playback terminal, the method includes: Retrieve the video to be played from the cache server; If the cache server does not contain the video to be played, then the video to be played is obtained from the source server of the video to be played according to the video playback request; The video to be played is cached on the cache server.

4. The processing method according to claim 1, characterized in that, Before sending the video to be played to the playback terminal, the method further includes: Send a list of playable videos to the playback terminal, wherein the list of playable videos contains identification information of at least one playable video; The system receives a video selection request from the playback terminal, the video selection request containing identification information of the video to be played selected by the playback terminal according to the playable video list; The video to be played is obtained based on the identification information in the video selection request.

5. The processing method according to claim 1, characterized in that, The method further includes: The device information sent by the playback terminal is received. The device information includes the device hash and environment check result of the playback terminal. The device hash is generated by hash calculation based on the hardware information and software information of the playback terminal. The environment check result is generated by checking the system permission status and abnormal application installation status of the playback terminal. The device fingerprint of the playback terminal is generated by calculating based on the device hash and the environment check results; A risk assessment is performed based on the device information to obtain the risk status information of the playback terminal; The device fingerprint is associated with the risk status information and stored in the risk control server; Send the device fingerprint to the playback terminal.

6. The processing method according to claim 5, characterized in that, The step of performing a risk assessment based on the device information to obtain the risk status information of the playback terminal includes: The device information is input into the risk assessment model on the risk control server to obtain the risk score output by the risk assessment model. The risk status information of the playback terminal is determined based on the comparison result between the risk score and the preset score threshold.

7. The processing method according to claim 1, characterized in that, The step of sending a risk query request containing the device fingerprint to the risk control server based on the video playback request includes: Analyze the video playback request and read the device fingerprint; If reading the device fingerprint from the video playback request fails, a playback rejection notification is sent to the playback terminal. If the device fingerprint is successfully read from the video playback request, a risk query request containing the device fingerprint is sent to the risk control server.

8. The processing method according to any one of claims 1 to 7, characterized in that, The method further includes: If the risk status information does not meet the predetermined risk control strategy, the processing of the video playback request will be suspended. Send terminal error response information to the playback terminal in response to the video playback request.

9. A method for processing media data, characterized in that, include: According to the video playback instruction, a video playback request is sent to the edge server so that the edge server performs the method as described in any one of claims 1 to 8, wherein the video playback request includes a device fingerprint of the playback terminal, and the device fingerprint is generated based on the device information of the playback terminal; Receive the video to be played sent by the edge server and play the video to be played.

10. The processing method according to claim 9, characterized in that, The method further includes: During the initialization of the playback terminal, the device information of the playback terminal is obtained through a device fingerprinting tool; The device information is sent to the risk control server so that the risk control server can generate a device fingerprint for the playback terminal based on the device information. Receive the device fingerprint sent by the risk control server.

11. The processing method according to claim 10, characterized in that, The step of obtaining the device information of the playback terminal through a device fingerprinting tool includes: When a video playback command is received, a device hash is generated by performing hash calculation based on the hardware and software information of the playback terminal using a device fingerprinting tool. The system permission status and abnormal application installation status of the playback terminal are checked using the device fingerprinting tool to obtain the environment check results; The device hash and the environment check results are packaged together to generate the device information of the playback terminal.

12. A media data processing apparatus, characterized in that, include: The request acquisition module is configured to acquire a video playback request sent by the playback terminal. The video playback request contains the device fingerprint of the playback terminal, which is generated based on the device information of the playback terminal. The request sending module is configured to send a risk query request containing the device fingerprint to the risk control server according to the video playback request, so that the risk control server can obtain the risk status information of the playback terminal according to the device fingerprint. The risk status information is generated by risk assessment based on the device information of the playback terminal. The video sending module is configured to send a video to be played to the playback terminal based on the risk status information sent by the risk control server. If the risk status information meets the predetermined risk control strategy, the video to be played is sent to the playback terminal.

13. A media data processing apparatus, characterized in that, include: The request module is configured to send a video playback request to an edge server according to a video playback instruction, so that the edge server performs the method as described in any one of claims 1 to 8, wherein the video playback request includes a device fingerprint of the playback terminal, and the device fingerprint is generated based on the device information of the playback terminal; The video receiving module is configured to receive and play the video to be played sent by the edge server.

14. An electronic device, characterized in that, include: processor; Memory for storing the executable instructions of the processor; The processor is configured to execute the media data processing method according to any one of claims 1 to 11 by executing the executable instructions.

15. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method for processing media data as described in any one of claims 1 to 11.

16. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions to cause the computer device to perform a method for processing media data as described in any one of claims 1 to 11.

17. A method for processing video bitstreams, characterized in that, The video stream is generated by the encoding method according to any one of claims 1-8, or decoded based on the decoding method according to any one of claims 9-11.

18. A method for processing video bitstreams, characterized in that, A video stream is stored on a non-volatile computer-readable storage medium, the video stream being generated by the encoding method according to any one of claims 1-8, or decoded based on the decoding method according to any one of claims 9-11.

Images