CN112804563B

CN112804563B - Media file playing method and device and storage medium

Info

Publication number: CN112804563B
Application number: CN201911104908.6A
Authority: CN
Inventors: 刘阿海
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-11-13
Filing date: 2019-11-13
Publication date: 2022-11-04
Anticipated expiration: 2039-11-13
Also published as: CN112804563A

Abstract

The invention provides a method, a device and a storage medium for playing a media file; the method comprises the following steps: responding to a playing instruction aiming at the media file, and sending a corresponding media data acquisition request; receiving a returned encrypted file, wherein a file header of the encrypted file comprises a Uniform Resource Locator (URL) corresponding to a digital rights management center, and a file body of the encrypted file comprises the media data; based on the URL, sending an authorization request corresponding to the media file; receiving a returned key corresponding to the encrypted file, wherein the key is returned after the digital rights management center passes the digital rights verification based on the authorization request; decrypting the encrypted file based on the returned secret key to obtain the media data; and calling a system player to play the media data. The invention can make users of different system versions able to view the media data encrypted by the digital copyright management technology.

Description

Media file playing method and device and storage medium

Technical Field

The present invention relates to the field of digital rights management technologies, and in particular, to a method and an apparatus for playing a media file, and a storage medium.

Background

With the rapid development of digital media technology, digital media content is widely used, and media content piracy technology and ways are becoming more and more. In order to prevent Digital media from being illegally copied and maliciously spread in the application process, many software manufacturers have introduced corresponding Digital Rights Management (DRM) technology, and use and distribution routes of media data are locked and limited by encryption technology, so as to achieve the basic goal of preventing unauthorized copying and use of media data.

Since the system player is relatively stable, the system player is preferentially adopted for playing media data, but before 8.0 version of Android (Android), the Android system player does not support the DRM technology and cannot play media data encrypted by DRM.

Disclosure of Invention

Embodiments of the present invention provide a method, an apparatus, and a storage medium for playing a media file, which enable users of different system versions to view media data encrypted by a digital rights management technique.

The technical scheme of the embodiment of the invention is realized as follows:

the embodiment of the invention provides a method for playing a media file, which comprises the following steps:

responding to a playing instruction aiming at the media file, and sending a corresponding media data acquisition request;

receiving a returned encrypted file, wherein a file header of the encrypted file comprises a Uniform Resource Locator (URL) corresponding to a digital rights management center, and a file body of the encrypted file comprises the media data;

based on the URL, sending an authorization request corresponding to the media file;

receiving a returned key corresponding to the encrypted file, wherein the key is returned after the digital rights management center passes the digital rights verification based on the authorization request;

decrypting the encrypted file based on the returned key to obtain the media data;

and calling a system player to play the media data.

An embodiment of the present invention provides a media file playing device, including:

the first sending module is used for responding to a playing instruction aiming at the media file and sending a corresponding media data acquisition request;

a first receiving module, configured to receive a returned encrypted file, where a file header of the encrypted file includes a URL corresponding to a digital rights management center, and a file body of the encrypted file includes the media data;

a second sending module, configured to send an authorization request corresponding to the media file based on the URL;

a second receiving module, configured to receive a returned key corresponding to the encrypted file, where the key is returned after the digital rights management center performs digital rights verification based on the authorization request;

the decryption module is used for decrypting the encrypted file based on the returned secret key to obtain the media data;

and the playing module is used for calling a system player to play the media data.

In the foregoing solution, the first sending module is further configured to send, in response to a play instruction for a media file, a corresponding media data acquisition request through a digital rights management plug-in, where the media data acquisition request carries a media file identifier.

In the above solution, the first receiving module is further configured to receive an encrypted file returned based on the media file identifier;

the encrypted file is the media data obtained by de-encapsulating the media file; and encrypting the media data through a key, placing a key identifier corresponding to the key and a URL (uniform resource locator) of a digital rights management center into a file header, and packaging the file header and the encrypted media data.

In the above scheme, the second sending module is further configured to obtain user identity information of a target user corresponding to the play instruction;

and sending an authorization request carrying a key identifier and user identity information to the digital rights management center so as to carry out digital rights verification based on the user identity information, and returning a key corresponding to the key identifier after the verification is passed.

In the above scheme, the decryption module is further configured to parse the encrypted file to obtain the encrypted media data;

and decrypting the encrypted media data based on the returned secret key to obtain the decrypted media data.

In the above solution, the decryption module is further configured to locally obtain a local key corresponding to the encrypted file;

combining the local key and the returned key to obtain a combined key;

decrypting the encrypted file based on the combination key.

In the above solution, the playing module is further configured to encapsulate the media data into a media file with a specific format;

and calling the system player to decode and play the media file with the specific format.

In the above solution, the apparatus further includes:

and the storage module is used for storing the returned key to the blockchain network.

An embodiment of the present invention provides an electronic device, including:

a memory for storing executable instructions;

and the processor is used for realizing the playing method of the media file provided by the embodiment of the invention when the processor executes the executable instructions stored in the memory.

The embodiment of the invention provides a storage medium, which stores executable instructions and is used for causing a processor to execute the storage medium to realize the method for playing the media file provided by the embodiment of the invention.

The embodiment of the invention has the following beneficial effects:

the invention receives the returned encrypted file; sending an authorization request corresponding to the media file; receiving a returned key corresponding to the encrypted file; decrypting the encrypted file based on the returned key to obtain media data; calling a system player to play the media data; in this way, since the encrypted file is decrypted before the system player is called, the system player acquires the decrypted media data, so that the system player before android8.0 can play the media data.

Drawings

Fig. 1 is a schematic diagram of an architecture of a playing system 100 for media files according to an embodiment of the present invention;

fig. 2 is a schematic structural diagram of an electronic device provided in an embodiment of the present invention;

fig. 3 is a flowchart illustrating a method for playing a media file according to an embodiment of the present invention;

fig. 4 is a schematic interface diagram of a video client provided by an embodiment of the present invention;

FIG. 5 is a schematic flow chart of obtaining an encrypted file according to an embodiment of the present invention;

fig. 6 is a schematic flowchart of acquiring a key according to an embodiment of the present invention;

fig. 7 is a schematic flowchart of video playing provided by an embodiment of the present invention;

fig. 8 is a schematic application architecture diagram of a blockchain network according to an embodiment of the present invention;

fig. 9 is a schematic structural diagram of a block chain in a block chain network 900 according to an embodiment of the present invention;

fig. 10 is a functional architecture diagram of a blockchain network 900 according to an embodiment of the present invention;

fig. 11 is a flowchart illustrating a method for playing a media file according to an embodiment of the present invention;

fig. 12 is a flowchart illustrating a method for playing a media file according to an embodiment of the present invention;

fig. 13 is a schematic structural diagram of a playing apparatus for media files according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail with reference to the accompanying drawings, the described embodiments should not be construed as limiting the present invention, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

In the description that follows, references to the terms "first \ second \ third" are intended merely to distinguish similar objects and do not denote a particular order, but rather are to be understood that the terms "first \ second \ third" may be interchanged under certain circumstances or sequences of events to enable embodiments of the invention described herein to be practiced in other than those illustrated or described herein.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to be limiting of the invention.

Before further detailed description of the embodiments of the present invention, terms and expressions mentioned in the embodiments of the present invention are explained, and the terms and expressions mentioned in the embodiments of the present invention are applied to the following explanations.

1) Digital rights management refers to techniques used by publishers to control the usage rights of protected objects, protected by digitized content (e.g.: software, music, movies) and hardware, the usage restrictions of a certain instance of the processing of the digitized product.

2) Media files, media available in the internet in various forms (e.g., video, audio, teletext, etc.) such as video files, audio files, articles including teletext, etc. presented in the client.

3) In response to the condition or state on which the performed operation depends, one or more of the performed operations may be in real-time or may have a set delay when the dependent condition or state is satisfied; there is no restriction on the order of execution of the operations performed unless otherwise specified.

4) Transactions (transactions), equivalent to the computer term "Transaction," include operations that need to be committed to a blockchain network for execution and do not refer solely to transactions in the context of commerce, which embodiments of the present invention follow in view of the convention colloquially used in blockchain technology.

For example, a deployment (deployment) transaction is used to install a specified smart contract to a node in a blockchain network and is ready to be invoked; the Invoke (Invoke) transaction is used to append records of the transaction in the blockchain by invoking smart contracts and to perform operations on the state database of the blockchain, including update operations (including adding, deleting, and modifying key-value pairs in the state database) and query operations (i.e., querying key-value pairs in the state database).

5) A Block chain (Blockchain) is an encrypted, chained storage structure of transactions formed from blocks (blocks).

6) A Blockchain Network (Blockchain Network) includes new blocks into a set of nodes of a Blockchain in a consensus manner.

7) Ledger (legger) is a general term for blockchains (also called Ledger data) and state databases synchronized with blockchains. Wherein, the blockchain records the transaction in the form of a file in a file system; the state database records the transactions in the blockchain in the form of different types of Key (Key) Value pairs for supporting fast query of the transactions in the blockchain.

8) Intelligent Contracts (Smart Contracts), also known as chain codes (chaincodes) or application codes, are programs deployed in nodes of a blockchain network, and the nodes execute the intelligent Contracts called in received transactions to perform operations of updating or querying key-value data of a state database.

9) Consensus (Consensus), a process in a blockchain network, is used to agree on transactions in a block among a plurality of nodes involved, the agreed block is to be appended to the end of the blockchain, and mechanisms for achieving Consensus include Proof of workload (PoW, proof of Work), proof of rights and interests (PoS, proof of Stake), proof of grant of shares (DPoS, cleared Proof of offer-stamp), proof of Elapsed Time (PoET, proof of Elapsed Time), and so on.

Referring to fig. 1, fig. 1 is a schematic structural diagram of a playing system 100 for media files according to an embodiment of the present invention, in order to support an exemplary application, a terminal 500 is connected to a content server 200 and a digital rights management center 300 through a network 400, where the network 400 may be a wide area network or a local area network, or a combination of the two.

A terminal 500 for sending a media data acquisition request to the content server 200 in response to a play instruction for a media file;

a content server 200, configured to obtain the encrypted file from the media database 600 and return the encrypted file;

the file header of the encrypted file comprises a Uniform Resource Locator (URL) corresponding to a digital copyright management center, and the file body of the encrypted file comprises media data;

the terminal 500 is further configured to send an authorization request corresponding to the media file to the digital rights management center based on the URL;

a digital rights management center 300 for obtaining a key of the encrypted file from the key database 700 and returning the key of the encrypted file;

the terminal 500 is further configured to decrypt the encrypted file based on the returned key to obtain media data; and calling a system player to play the media data.

In practical application, the content server and the digital rights management center may be a single configured server supporting various services, or may be configured as a server cluster; the terminal may be a smartphone, a tablet, a laptop, or any other type of user terminal, and may also be a wearable computing device, a Personal Digital Assistant (PDA), a desktop computer, a cellular phone, a media player, a navigation device, a game console, a television, or a combination of any two or more of these or other data processing devices.

Next, an electronic device implementing the method for playing a media file according to an embodiment of the present invention will be described. Referring to fig. 2, fig. 2 is a schematic structural diagram of an electronic device according to an embodiment of the present invention, where the electronic device shown in fig. 2 includes: a processor 210, a memory 250, a network interface 220, and a user interface 230. The various components in the electronic device are coupled together by a bus system 240. It is understood that the bus system 240 is used to enable connected communication between these components. The bus system 240 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are designated as bus system 240 in FIG. 2.

The Processor 210 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like, wherein the general purpose Processor may be a microprocessor or any conventional Processor, or the like.

The user interface 230 includes one or more output devices 231, including one or more speakers and/or one or more visual display screens, that enable the presentation of media content. The user interface 230 also includes one or more input devices 232, including user interface components to facilitate user input, such as a keyboard, mouse, microphone, touch screen display screen, camera, other input buttons and controls.

The memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard disk drives, optical disk drives, and the like. Memory 250 optionally includes one or more storage devices physically located remotely from processor 210.

The memory 250 includes volatile memory or nonvolatile memory, and may include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read Only Memory (ROM), and the volatile Memory may be a Random Access Memory (RAM). The memory 250 described in embodiments of the invention is intended to comprise any suitable type of memory.

In some embodiments, memory 250 may be capable of storing data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as exemplified below.

An operating system 251 including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

a network communication module 252 for communicating to other computing devices via one or more (wired or wireless) network interfaces 220, exemplary network interfaces 220 including: bluetooth, wireless compatibility authentication (WiFi), and Universal Serial Bus (USB), etc.;

a display module 253 to enable presentation of information (e.g., a user interface for operating peripherals and displaying content and information) via one or more output devices 231 (e.g., a display screen, speakers, etc.) associated with the user interface 230;

an input processing module 254 for detecting one or more user inputs or interactions from one of the one or more input devices 232 and translating the detected inputs or interactions.

In some embodiments, the playing device for media files provided by the embodiments of the present invention may be implemented in software, and fig. 2 shows a playing device 255 for media files stored in a memory 250, which may be software in the form of programs and plug-ins, and includes the following software modules: the first sending module 2551, the first receiving module 2552, the second sending module 2553, the second receiving module 2554, the decrypting module 2555 and the playing module 2556 are logical, so that any combination or further splitting can be performed according to the implemented functions, and the functions of the respective modules will be described below.

In other embodiments, the playing Device of the media file provided by the embodiments of the present invention may be implemented in hardware, and as an example, the playing Device of the media file provided by the embodiments of the present invention may be a processor in the form of a hardware decoding processor, which is programmed to execute the playing method of the media file provided by the embodiments of the present invention, for example, the processor in the form of the hardware decoding processor may be implemented by one or more Application Specific Integrated Circuits (ASICs), DSPs, programmable Logic Devices (PLDs), complex Programmable Logic Devices (CPLDs), field Programmable Gate Arrays (FPGAs), or other electronic elements.

Based on the above description of the playing system and the electronic device for the media file according to the embodiments of the present invention, a playing method for the media file according to the embodiments of the present invention is described next, and fig. 3 is a schematic flow chart of the playing method for the media file according to the embodiments of the present invention, and in some embodiments, the playing method for the media file is implemented by a terminal, for example, by using the terminal 500 in fig. 1, and the playing method for the media file according to the embodiments of the present invention is described with reference to fig. 1 and fig. 3.

Step 301: and the terminal responds to the playing instruction aiming at the media file and sends a corresponding media data acquisition request.

In some embodiments, a client, such as a music client, a video client, a microblog client, and the like, having a media content playing function is provided on the terminal, and a user can trigger a playing instruction for a media file by performing a click operation on a video playing key presented on a view interface on the client. The client receives a playing instruction aiming at the media file, responds to the playing instruction, and sends a corresponding media data acquisition request to the media data distribution server.

Exemplarily, taking a client as a video client as an example, and referring to fig. 4 as an interface schematic diagram of the video client provided by the embodiment of the present invention, referring to fig. 4, an interface of the video client presents information of different videos and play buttons corresponding to the videos, for example, introduction information of a series "you without secret", and by clicking the play button corresponding to the series, a play instruction for the series is triggered, so that the video client sends an acquisition request to a corresponding content server to acquire video data of the series.

It should be noted that the media data corresponds to the media files one to one, and the media files are packaged media data. In practical implementation, the encrypted file corresponding to the media data is stored in a media database, which may be included in the content server or may exist independently without being configured in the content server, where the content server may read the required media file from the media database to distribute the media file.

In some embodiments, in response to a play instruction for a media file, a corresponding media data acquisition request is sent through a digital rights management plug-in, where the media data acquisition request carries a media file identifier.

Here, in actual implementation, the data rights management plug-in is integrated in the client, and the client performs operations such as transmission of a media data acquisition request, reception of an encrypted file, an authorization request, acquisition of a key, decryption of the encrypted file, and the like through the data rights management plug-in.

It should be noted that, in the media database, the encrypted file corresponding to the media file is stored in correspondence with the identifier of the media file, so that the content server can search for the corresponding encrypted file according to the media file identifier carried in the data acquisition request. For example, when the media file is a video file, a video Identifier (ID) and an encrypted file pair are stored in the video file library, so that the video server finds the encrypted file matching the video ID based on the video ID.

Step 302: a returned encrypted file is received.

Here, the header of the encrypted file includes a URL corresponding to the digital rights management center, and the body of the encrypted file includes media data.

In some embodiments, an encrypted file returned based on the media file identification is received; the encrypted file is the media file which is unpacked to obtain the media data; and encrypting the media data through a secret key, placing a secret key identifier corresponding to the secret key and a URL (uniform resource locator) of a digital copyright management center into a file header, and packaging the file header and the encrypted media data to obtain the media data.

Here, in practical implementation, the encrypted file may be obtained by: acquiring a file header of a media file to determine the format of the media file; according to the format of the media file, performing decapsulation operation on the media file to obtain media data; and encrypting and packaging the media data through an encryption tool to obtain an encrypted file.

Fig. 5 is a schematic flowchart of obtaining an encrypted file according to an embodiment of the present invention, and referring to fig. 5, in some embodiments, an encryption tool may obtain the encrypted file by: firstly, a private signature key, a public signature key, a license key seed and a key identifier are created, and a key is generated by the license key seed and the key identifier and is used for encrypting and protecting media data; then, storing the information of the key identification, URL, version number and the like of the digital copyright management center in the head of the file, and signing the head of the file according to the private signature key; and finally, encrypting the media data, and packaging the encrypted media data and the header into an encrypted file with a specific format. For example, the encrypted file may be in the form of the extension asf,. Wma,. Wmv.

Step 303: based on the URL, an authorization request for the corresponding media file is sent.

In actual implementation, a terminal searches whether a valid key exists locally or not, and if so, the terminal directly obtains the key of the encrypted file from the local; if the retrieval is failed, the media file is linked to the digital copyright management center according to the URL, and an authorization request corresponding to the media file is sent to the data copyright management center.

In some embodiments, the terminal may send an authorization request for the media file by: acquiring user identity information of a target user corresponding to the playing instruction; and sending an authorization request carrying a key identifier and user identity information to the digital rights management center so as to carry out digital rights verification based on the user identity information, and returning a key corresponding to the key identifier after the verification is passed.

In actual implementation, the terminal determines user identity information according to account information of a user logged in at a client, acquires a key identifier from the head of an encrypted file, generates an authorization request corresponding to a media file based on the user identity information and the key identifier, and sends the authorization request to a digital rights management center. The digital copyright management center judges whether the user has the authority of playing the media file according to the user identity information, if so, a key corresponding to the key identification is obtained from a key database; otherwise, the information of request failure is returned.

For example, for a media file which is played only by a VIP user, the digital rights management center matches user identity information with user information in the VIP user information record to determine whether a target user is a VIP user, and if so, obtains a key corresponding to the key identifier and returns the key identifier to the terminal; for another example, for a media file that can be played only by a certain application platform, the digital rights management center may determine whether the source of the user identity information is a registered user of the application platform that can play the media file, and if so, obtain a key corresponding to the key identifier and return the key to the terminal.

Fig. 6 is a schematic flow diagram of acquiring a key according to an embodiment of the present invention, and referring to fig. 6, in some embodiments, a terminal may directly send a file header of an encrypted file and user identity information to a digital rights management center, and after receiving the file header of the encrypted file and the user identity information sent by a client, the digital rights management center generates a key, which is the same as that used in packaging media data, from a license key seed and a key identifier in the received file header, so as to use the key for decryption. Then, generating a copyright license, adding the encrypted key into the copyright license, adding a certificate obtained in the digital copyright license service, and signing the copyright license by using a public key in the certificate; and finally, transmitting the copyright license to the terminal. Here, the rights of the license, such as the number of plays, start and end times, and the like, may also be defined in the copyright license.

Step 304: a returned key corresponding to the encrypted file is received.

Here, the key is returned after the digital rights management center performs digital rights verification based on the authorization request.

Step 305: and decrypting the encrypted file based on the returned secret key to obtain the media data.

In practical implementation, the terminal may store the returned key, and store the key locally, so as to directly obtain the key from the local when the media file needs to be played next time. It should be noted that the obtained key is provided with permission rights, such as playing times, start and end times, and the like. When the playing times are exceeded, or the permission time is exceeded, the key is invalid.

In some embodiments, the digital rights management center sends the key carried in the rights license to the terminal, and the terminal verifies the rights license and stores the rights license in the license repository, and then decrypts the encrypted file with the key carried by the rights license.

In some embodiments, the terminal may obtain the media data by: analyzing the encrypted file to obtain encrypted media data; and decrypting the encrypted media data based on the returned key to obtain the decrypted media data.

In practical implementation, since the encrypted file includes a file header and a file body, here, the file body is parsed, and when the encrypted media data is obtained, the encrypted media data is then decrypted based on the returned key.

In some embodiments, the terminal may obtain the media data by: locally acquiring a local key corresponding to the encrypted file; combining the local key and the returned key to obtain a combined key; decrypting the encrypted file based on the combination key.

In actual implementation, when the digital rights management center sends the key to the terminal, the key may be intercepted, and if the key is intercepted by a hacker, the encrypted file can be decrypted and the media file can be played. The key is divided into two keys, one key is stored in a digital copyright management center, the other key is stored locally in a terminal, when the encrypted file is decrypted, the key is required to be obtained from the digital copyright management center firstly, then the locally stored key is obtained, and then the two keys are combined to obtain a combined key so as to decrypt the encrypted file through the combined key; therefore, the encrypted file can be decrypted only by acquiring two keys at the same time, and the security of the keys is enhanced.

Step 306: and calling a system player to play the media data.

Here, since the encrypted media data has already been decrypted, the system player acquires the unencrypted media data, and even the system player before android8.0 can play the media data.

In some embodiments, the terminal may play the media data by: packaging the media data into a media file with a specific format; and calling a system player to decode and play the media file with the specific format.

Here, the media data is packaged into a media file with a specific format that can be read by the system server, and a micro local streaming server is created, and then the system player is called, so that the system server obtains the media file with the specific format from the client, and decodes and plays the media file with the specific format.

Taking a media file as an example, where a video includes two parts, namely an image and an audio, fig. 7 is a schematic flow diagram of video playing provided in an embodiment of the present invention, and referring to fig. 7, a system player decapsulates a video file through a demultiplexer to obtain an audio packet queue and an image packet queue, and then performs audio decoding on the audio packet queue to obtain an audio frame queue; and carrying out image decoding on the image packet to obtain an image frame queue; and displaying the image frame and outputting the sound of the audio frame. It should be noted that, each time one frame of audio frame and one frame of image frame are read, output is performed until the data reading is completed.

In some embodiments, the blockchain technology may be further combined, and after the returned key corresponding to the encrypted file is received, the key of the encrypted file is stored in the blockchain network, so that the key of the decrypted file can be directly obtained from the blockchain network when the media file needs to be played next time.

Here, after receiving the returned key corresponding to the encrypted file, generating a transaction for storing the key, and submitting the generated transaction to a node of the blockchain network, so that the node shares the transaction with the transaction and then stores the corresponding key to the blockchain network; before storing the key to the blockchain network, the server can also obtain the digest information of the key corresponding to the key; and storing the obtained digest information of the key to the blockchain network.

Referring to fig. 8, fig. 8 is a schematic diagram of an application architecture of a blockchain network according to an embodiment of the present invention, which includes a service agent 500, an authentication center 800, and a blockchain network 900 (exemplarily illustrating a consensus node 910-1 to a consensus node 910-3), which are described below.

The type of blockchain network 900 is flexible and may be, for example, any of a public chain, a private chain, or a federation chain. Taking a public link as an example, electronic devices such as a user terminal and a server of any service entity can access the blockchain network 900 without authorization; taking a federation chain as an example, an electronic device (e.g., a terminal/server) under the jurisdiction of a service entity after obtaining authorization may access the blockchain network 900, and at this time, become a special type of node, i.e., a client node, in the blockchain network 900.

In some embodiments, the client node may act as a mere watcher of the blockchain network 900, i.e., provides functionality to support the business entity to initiate transactions (e.g., for uplink storage of data or querying of data on the chain), and the server node may be implemented by default or selectively (e.g., depending on the specific business requirements of the business entity) for the functions of the consensus node 910 of the blockchain network 900, such as a ranking function, a consensus service, and an accounting function, etc. Therefore, the data and the service processing logic of the service subject can be migrated to the blockchain network 900 to the maximum extent, and the credibility and traceability of the data and service processing process are realized through the blockchain network 900.

Consensus nodes in blockchain network 900 receive transactions submitted by client nodes from business entity 500, perform transactions to update ledgers or query ledgers, and various intermediate or final results of performing transactions may be returned to business entity's client nodes for display.

An exemplary application of the blockchain network is described below by taking an example in which a service agent accesses the blockchain network to realize playing of a media file.

Referring to fig. 8, a service entity 500 involved in playing a media file registers from a certificate authority 800 to obtain a digital certificate, where the digital certificate includes a public key of the service entity and a digital signature signed by the certificate authority 800 on the public key and identity information of the service entity, and is used to be attached to a transaction together with the digital signature of the service entity for the transaction, and is sent to a blockchain network, so that the blockchain network takes the digital certificate and signature from the transaction, verifies the authenticity of the message (i.e., whether the message is not tampered) and the identity information of the service entity sending the message, and verifies the blockchain network according to the identity, for example, whether the service entity has the right to initiate the transaction. Clients running on electronic devices (e.g., terminals or servers) hosted by the business entity may request access from the blockchain network 900 to become client nodes.

The client node of the service body 500 is used for playing the media file, for example, in response to a playing instruction for the media file, sending a corresponding media data acquisition request; receiving a returned encrypted file, wherein the file header of the encrypted file comprises a Uniform Resource Locator (URL) corresponding to a digital copyright management center, and the file body of the encrypted file comprises the media data; based on the URL, sending an authorization request corresponding to the media file; receiving a returned key corresponding to the encrypted file, wherein the key is returned after the digital copyright management center passes the digital copyright verification based on the authorization request; storing the key to the blockchain network; decrypting the encrypted file based on the returned secret key to obtain media data; and calling a system player to play the media data.

The operation of sending the key to the blockchain network 900 may be to set service logic in the client node 510 in advance, and when receiving the returned key corresponding to the encrypted file, the client node 510 automatically sends the key to the blockchain network 900, or a service person of the service agent 500 logs in the client node 510, manually packages the key, and sends the key to the blockchain network 900. Upon transmission, the client node 510 generates a transaction for the corresponding storage operation based on the corresponding key, in which transaction the smart contract that needs to be invoked to effect the storage operation and the parameters passed to the smart contract are specified, the transaction also carries the client node's 510 digital certificate, a signed digital signature (e.g., a digest of the transaction encrypted using a private key in the client node's 510 digital certificate), and broadcasts the transaction to the consensus node 910 in the blockchain network 900.

When the transaction is received in the consensus node 910 in the blockchain network 900, the digital certificate and the digital signature carried in the transaction are verified, and after the verification is successful, whether the service agent 500 has the transaction right is determined according to the identity of the service agent 500 carried in the transaction, and the transaction failure is caused by any verification judgment of the digital signature and the right verification. After verification is successful, node 910 signs its own digital signature (e.g., by encrypting the digest of the transaction using the private key of node 910-1) and continues to broadcast in blockchain network 900.

After the consensus node 910 in the blockchain network 900 receives the transaction successfully verified, the transaction is filled into a new block and broadcast. When a new block is broadcasted by the consensus node 910 in the block chain network 900, performing a consensus process on the new block, if the consensus is successful, appending the new block to the tail of the block chain stored in the new block, updating the state database according to a transaction result, and executing a transaction in the new block: for transactions submitting updated pick-up records, the pick-up records are added to the state database.

As an example of a block chain, referring to fig. 9, fig. 9 is a schematic structural diagram of a block chain in a block chain network 900 according to an embodiment of the present invention, where a header of each block may include hash values of all transactions in the block, and also includes hash values of all transactions in a previous block, a record of a newly generated transaction is filled in the block, and after being identified by nodes in the block chain network, the record is appended to a tail of the block chain to form a chain growth, and a chain structure based on hash values between blocks ensures tamper resistance and forgery resistance of transactions in the block.

An exemplary functional architecture of the blockchain network provided by the embodiment of the present invention is described below, referring to fig. 10, fig. 10 is a schematic functional architecture diagram of a blockchain network 900 provided by the embodiment of the present invention, which includes an application layer 901, a consensus layer 902, a network layer 903, a data layer 904, and a resource layer 905, and the following description is separately provided.

Resource layer 905 encapsulates the computing, storage, and communication resources that implement the nodes in blockchain network 900.

Data layer 904 encapsulates various data structures that implement the ledger, including blockchains implemented as files in a file system, keyed state databases, and presence certificates (e.g., hash trees of transactions in blocks).

The network layer 903 encapsulates the functions of a Point-to-Point (P2P) network protocol, a data propagation mechanism and a data verification mechanism, an access authentication mechanism, and a service agent identity management.

The P2P network protocol implements communication between nodes in the blockchain network 900, the data propagation mechanism ensures propagation of transactions in the blockchain network 900, and the data verification mechanism is used to implement reliability of data transmission between nodes based on an encryption method (e.g., digital certificate, digital signature, public/private key pair); the access authentication mechanism is used for authenticating the identity of the service subject added to the block chain network 900 according to an actual service scene, and endowing the service subject with the authority of accessing the block chain network 900 when the authentication is passed; the business entity identity management is used to store the identity of the business entities that are allowed to access the blockchain network 900, as well as the permissions (e.g., the types of transactions that can be initiated).

Consensus layer 902 encapsulates the functions of node-to-node block agreement mechanisms (i.e., consensus mechanisms), transaction management, and ledger management in blockchain network 900. The consensus mechanism comprises consensus algorithms such as POS, POW and DPOS, and the pluggable consensus algorithm is supported.

The transaction management is used for verifying the digital signature carried in the transaction received by the verification node, verifying the identity information of the service body and judging and confirming whether the service body has the authority to carry out the transaction (reading the related information from the identity management of the service body) according to the identity information; for the service agents authorized to access the blockchain network 900, the service agents all have digital certificates issued by the certificate authority, and the service agents sign the submitted transactions by using private keys in the digital certificates of the service agents, so that the legal identities of the service agents are declared.

The ledger administration is used to maintain blockchains and state databases. For the block with the consensus, adding the block to the tail of the block chain; and executing the transaction in the acquired consensus block, updating the key-value pairs in the state database when the transaction comprises an updating operation, inquiring the key-value pairs in the state database when the transaction comprises an inquiring operation, and returning an inquiring result to the server node of the business main body. Supporting query operations for multiple dimensions of a state database, comprising: querying the chunk based on the chunk sequence number (e.g., a hash value of the transaction); inquiring the block according to the block hash value; inquiring a block according to the transaction serial number; inquiring the transaction according to the transaction serial number; inquiring account data of a business main body according to an account (serial number) of the business main body; and inquiring the block chain in the channel according to the channel name.

The application layer 901 encapsulates various services that can be implemented by the blockchain network, including tracing, crediting, and verifying transactions.

The invention receives the returned encrypted file; sending an authorization request corresponding to the media file; receiving a returned key corresponding to the encrypted file; decrypting the encrypted file based on the returned secret key to obtain media data; calling a system player to play the media data; in this way, since the encrypted file is decrypted before the system player is called, the system player acquires the decrypted media data, so that the system player before android8.0 can play the media data.

The following describes a method for playing a media file according to an embodiment of the present invention, by taking a media file as an example of playing a video file. Fig. 11 is a schematic flowchart of a method for playing a media file according to an embodiment of the present invention, and referring to fig. 11, the method for playing a media file according to the embodiment of the present invention includes:

step 701: and the video provider decapsulates the video file to obtain video data.

Here, the video provider refers to a publisher of the video, i.e., an owner of video copyright.

Step 702: and the video provider encrypts the video data through the key and places the key identification of the key and the URL of the data copyright center into a file header.

In practical implementation, after video data is encrypted by a key, information such as a key identifier, a URL (uniform resource locator) of a digital copyright management center, a version number and the like is stored in the head of a file, and the head of the file is signed according to a private signature key.

Step 703: and the video provider encapsulates the file header and the encrypted media data to obtain an encrypted file.

Here, the encrypted media data is packaged together with the header into an encrypted file of a specific format. For example, the encrypted file may be in the form of an extension of. Wmv.

Step 704: and the video provider stores the encrypted file to a database of the video server.

Here, the encrypted file is paired with a video identification and stored in a database of the video server.

Step 705: and the video provider stores the key and the key identification pair in a database of the digital rights management center.

Step 706: the video client receives a playing instruction for the video.

Here, the user may trigger a play instruction for the video by performing a click operation on a video play button presented in the view interface on the video client.

Step 707: and the video client sends a video data acquisition request carrying the video identification.

Here, the client transmits a corresponding media data acquisition request through the DRM plug-in response to the play instruction.

Step 708: and the video server returns the encrypted file corresponding to the video identifier.

Here, the video server obtains the corresponding encrypted file through the video identifier, and returns the encrypted file to the video client.

Step 709: and the video client sends an authorization request carrying the user identity information and the key identification.

Step 710: and the digital copyright management center performs identity verification based on the user identity information.

For example, for a video file which only a VIP user has permission to play, the digital rights management center matches the user identity information with the user information in the VIP user information record to determine whether the target user is the VIP user.

Step 711: after the verification is passed, the digital rights management center returns the key corresponding to the key identifier.

Step 712: and the video client analyzes the encrypted file to obtain encrypted video data.

Step 713: and the video client decrypts the encrypted video data through the returned key to obtain the decrypted video data.

Step 714: and the video client calls the system player to play the decrypted video data.

In actual implementation, the client encapsulates the video data to obtain a video file, and calls the system player to enable the video player to decode and play the video file.

In the following, an exemplary application of the embodiments of the present invention in a practical application scenario will be described. Fig. 12 is a schematic flowchart of a method for playing a media file according to an embodiment of the present invention, and the method for playing media data according to the embodiment of the present invention is described below with reference to fig. 12.

Step 801: and decapsulating the media file to obtain media data, and encrypting the media data through an encryption tool.

In actual implementation, the encryption tool creates a private signing key, a public signing key, a license key seed and a key identification, and generates a key from the license key seed and the key identification for encrypting and protecting the media data.

Step 802: and packaging the encrypted media data into an encrypted file with a specific format.

In actual implementation, the key identification, the URL of the digital copyright management center, the version number and other information are stored in the header of the file, the header of the file is signed according to the private signature key, and the encrypted media data and the header are packaged into an encrypted file with a specific format. For example, the encrypted file may be in the form of an extension of asf,. Wma,. Wmv.

Step 803: the key of the encrypted media data is matched with the key identification and stored in the key database.

Step 804: and matching the encrypted file with the media file identifier and storing the encrypted file in a media database.

Step 805: the client obtains the encrypted file from the content server through the DRM plugin in response to a play instruction for the media file.

Here, the DRM plug-in is integrated in the client, and the client may be a music client, a video client, a microblog client, or the like having a media content playing function.

In practical implementation, a user may perform a click operation on a media file playing button presented in the view interface on the client to trigger a playing instruction for a media file. The client receives a playing instruction aiming at the media file, responds to the playing instruction, and sends a corresponding media data acquisition request through the DRM plug-in. Here, the media data acquisition request carries the media file identifier, so that the content server can find the corresponding encrypted file according to the media file identifier carried in the data acquisition request, and return the encrypted file to the client.

Step 806: the DRM plug-in obtains the key of the encrypted file from the digital rights management center based on the URL.

In actual implementation, the client links to the digital rights management center according to the URL, and sends an authorization request corresponding to the media file to the digital rights management center. The digital copyright management center judges whether the user has the authority of playing the media file according to the user identity information, and if so, acquires a key corresponding to the key identifier from a key database; otherwise, returning the information of the request failure.

Step 807: the DRM plug-in decrypts the encrypted file through the key to obtain the media data, repackages the audio and video data into the media stream after the decryption is successful, creates a micro local stream server, calls a system player and plays the media data.

In actual implementation, the encrypted file is analyzed to obtain encrypted media data; decrypting the encrypted media data based on the returned secret key to obtain decrypted media data; after media data are packaged into a media file with a specific format, a miniature local stream server is created; and calling the system player, namely acquiring the media file with the specific format from the DRM plug-in of the client by the system player, and decoding and playing the media file with the specific format.

In some embodiments, when the digital rights management center sends the key to the terminal, there is a possibility that the key is intercepted, and if the key is intercepted by a hacker, the encrypted file can be decrypted, and the media file can be played. By dividing the key into two keys, one key is stored in the digital copyright management center and the other key is stored in the local terminal, the two keys are acquired at the same time, and the encrypted file can be decrypted so as to strengthen the security of the key.

Here, since the encrypted media data is already decrypted, the system player acquires the unencrypted media data, and even the system player before android8.0 can play the media data.

Continuing with the exemplary structure of the playing apparatus 255 for media files provided in the embodiment of the present invention implemented as software modules, fig. 13 is a schematic structural diagram of the playing apparatus for media files provided in the embodiment of the present invention, and referring to fig. 13, the software modules in the playing apparatus 255 for media files may include:

a first sending module 2551, configured to send a corresponding media data obtaining request in response to a play instruction for a media file;

a first receiving module 2552, configured to receive a returned encrypted file, where a header of the encrypted file includes a URL corresponding to a digital rights management center, and a body of the encrypted file includes the media data;

a second sending module 2553, configured to send an authorization request corresponding to the media file based on the URL;

a second receiving module 2554, configured to receive a returned key corresponding to the encrypted file, where the key is returned by the drm center after the drm center passes the drm authentication based on the authorization request;

a decryption module 2555, configured to decrypt the encrypted file based on the returned key, so as to obtain the media data;

a playing module 2556, configured to invoke a system player to play the media data.

In some embodiments, the first sending module 2551 is further configured to send, through the drm plug-in, a corresponding media data obtaining request in response to a play instruction for the media file, where the media data obtaining request carries a media file identifier.

In some embodiments, the first receiving module 2552 is further configured to receive an encrypted file returned based on the media file identifier;

the encrypted file is the media file which is unpacked to obtain the media data; and encrypting the media data through a key, placing a key identifier corresponding to the key and a URL (uniform resource locator) of a digital rights management center into a file header, and packaging the file header and the encrypted media data.

In some embodiments, the second sending module 2553 is further configured to obtain user identity information of a target user corresponding to the playing instruction;

In some embodiments, the decryption module 2555 is further configured to parse the encrypted file to obtain the encrypted media data;

In some embodiments, the decryption module 2555 is further configured to locally obtain a local key corresponding to the encrypted file;

combining the local key and the returned key to obtain a combined key;

decrypting the encrypted file based on the combined key.

In some embodiments, the playing module 2556 is further configured to encapsulate the media data into a media file with a specific format;

In some embodiments, the apparatus further comprises: and the storage module is used for storing the returned key to the block chain network.

Embodiments of the present invention provide a storage medium storing executable instructions, where the executable instructions are stored, and when executed by a processor, will cause the processor to execute a method for playing a media file provided by an embodiment of the present invention, for example, the method shown in fig. 3.

In some embodiments, the storage medium may be memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.

In some embodiments, the executable instructions may be in the form of a program, software module, script, or code written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

By way of example, executable instructions may correspond, but do not necessarily have to correspond, to files in a file system, and may be stored in a portion of a file that holds other programs or data, such as in one or more scripts in a hypertext Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).

As an example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices located at one site or distributed across multiple sites and interconnected by a communication network.

The above description is only an example of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present invention are included in the protection scope of the present invention.

Claims

1. A method for playing a media file, the method comprising:

receiving a returned encrypted file, wherein a file header of the encrypted file comprises a Uniform Resource Locator (URL) corresponding to a digital rights management center and a key identifier corresponding to a key for decrypting the encrypted file, and a file body of the encrypted file comprises encrypted media data corresponding to the media file;

decapsulating the encrypted file to obtain a file header and a file body of the encrypted file;

based on the URL of the file header, sending an authorization request which corresponds to the media file and carries the key identifier;

receiving a returned key corresponding to the key identifier, wherein the key is returned after the digital rights management center passes the digital rights verification based on the authorization request;

analyzing the file body of the encrypted file to obtain encrypted media data corresponding to the media file;

locally acquiring a local key corresponding to the encrypted file;

combining the local key and the returned key to obtain a combined key;

decrypting the encrypted media data based on the combined key to obtain media data corresponding to the media file;

and calling a system player to play the media data.

2. The method of claim 1, wherein sending a corresponding media data acquisition request in response to a play instruction for a media file comprises:

and responding to a playing instruction aiming at the media file, and sending a corresponding media data acquisition request through the digital copyright management plug-in, wherein the media data acquisition request carries a media file identifier.

3. The method of claim 2, wherein the receiving the returned encrypted file comprises:

receiving an encrypted file returned based on the media file identifier;

4. The method as claimed in claim 3, wherein said sending an authorization request carrying said key identifier corresponding to said media file comprises:

acquiring user identity information of a target user corresponding to the playing instruction;

and sending an authorization request carrying a key identifier and user identity information to the digital rights management center so as to verify the digital rights based on the user identity information, and returning a key corresponding to the key identifier after the verification is passed.

5. The method of claim 1, wherein the invoking the system player to play the media file comprises:

packaging the media data into a media file with a specific format;

6. The method of claim 1, wherein the method further comprises:

storing the returned key to the blockchain network.

7. An apparatus for playing a media file, the apparatus comprising:

the first receiving module is used for receiving a returned encrypted file, wherein the file header of the encrypted file comprises a URL (uniform resource locator) corresponding to a digital copyright management center and a key identifier corresponding to a key for decrypting the encrypted file, and the file body of the encrypted file comprises encrypted media data corresponding to the media file; decapsulating the encrypted file to obtain a file header and a file body of the encrypted file;

a second sending module, configured to send, based on the URL of the file header, an authorization request carrying the key identifier corresponding to the media file;

a second receiving module, configured to receive a returned key corresponding to the key identifier, where the key is returned after the digital rights management center performs digital rights verification based on the authorization request;

the decryption module is used for analyzing the file body of the encrypted file to obtain encrypted media data corresponding to the media file; locally acquiring a local key corresponding to the encrypted file; combining the local key and the returned key to obtain a combined key; decrypting the encrypted media data based on the combined key to obtain media data corresponding to the media file;

8. A storage medium storing executable instructions for causing a processor to perform a method of playing a media file as claimed in any one of claims 1 to 6 when executed.