CN111935547A - Traceable encrypted live broadcast method and traceable encrypted live broadcast system - Google Patents
Traceable encrypted live broadcast method and traceable encrypted live broadcast system Download PDFInfo
- Publication number
- CN111935547A CN111935547A CN202010836151.6A CN202010836151A CN111935547A CN 111935547 A CN111935547 A CN 111935547A CN 202010836151 A CN202010836151 A CN 202010836151A CN 111935547 A CN111935547 A CN 111935547A
- Authority
- CN
- China
- Prior art keywords
- judging whether
- decryption
- successful
- watermark
- decryption key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 43
- 238000010586 diagram Methods 0.000 description 4
- 239000011159 matrix material Substances 0.000 description 4
- 238000012544 monitoring process Methods 0.000 description 4
- 230000000007 visual effect Effects 0.000 description 4
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/4405—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video stream decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4627—Rights management associated to the content
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/835—Generation of protective data, e.g. certificates
- H04N21/8358—Generation of protective data, e.g. certificates involving watermark
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Databases & Information Systems (AREA)
- Television Systems (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
The invention discloses a traceable encrypted live broadcast method and a traceable encrypted live broadcast system, wherein the method comprises the following steps: after the player is initialized, whether the playing address and the watermark code acquired by the interface are successfully authenticated is judged, if so, the following steps are carried out: generating a watermark through the returned watermark coding; judging whether the request for playing the address is successful, if so, then: judging whether a decryption key exists or not, judging whether the ts slicing request is successful or not, if so, then: judging whether decryption is needed, if so, then: judging whether a decryption key exists in the key storage, if so, then: judging whether decryption based on the decryption key is successful, if so, then: and filling the ts slicing result after the decryption is successful into a player for playing. The invention can add watermark coding to the video picture played by each user under the condition of only providing one path of live video source stream, so that the pictures watched by each user are different, the transcoding cost and the storage cost of the live stream are saved, and the video can be effectively prevented from being illegally played.
Description
Technical Field
The invention relates to the technical field of multimedia, in particular to a traceable encrypted live broadcast method and a traceable encrypted live broadcast system.
Background
At present, with the development of multimedia technology and the popularization of the internet, watching live webcasts has gradually become a part of daily entertainment of people. Due to the influence of epidemic situations, many programs cannot be recorded by visitors, so that cloud recording is urgent. Cloud recording, in turn, risks the user from revealing the content of the program recording. Current live DRM (Digital Rights Management) schemes cannot track which user plays video frames through which video frames are leaked. If the pictures to track the video that each user must play cannot be the same, this requires that the pictures that each user is viewing by the live stream cannot be the same, which means that each user is provided with a separate video stream. For example, 500 different live video source streams are required for the same live stream if 500 people watch it, to distinguish different users.
Therefore, how to effectively prevent the illegal broadcast is an urgent problem to be solved.
Disclosure of Invention
In view of this, the present invention provides a traceable encrypted live broadcasting method, which can effectively prevent the video from being illegally broadcast.
The invention provides a traceable encrypted live broadcast method, which comprises the following steps:
after the player is initialized, whether the playing address and the watermark code acquired by the interface are successfully authenticated is judged, if so, the following steps are carried out:
generating a watermark through the returned watermark coding;
judging whether the request for playing the address is successful, if so, then:
judging whether a decryption key exists, if so, then:
judging whether the ts slicing request is successful, if so, then:
judging whether decryption is needed;
judging whether a decryption key exists in the key storage, if so, then:
judging whether decryption based on the decryption key is successful, if so, then:
and filling the ts slicing result after the decryption is successful into a player for playing.
Preferably, the method further comprises:
polling the authentication service heartbeat interface at preset time intervals, judging whether the current user is effective, if not, then:
and ending the playing.
Preferably, the method further comprises:
when a decryption key exists, judging whether the decryption key is requested successfully, if so, then:
storing the decryption key.
Preferably, the method further comprises:
and judging whether to load a new slice or not based on the buffer area and the index, if so, then:
returning to perform the judgment again whether ts slicing is successful or not based on the decryption key request.
Preferably, the preset time is two seconds.
A traceable encrypted live system comprising:
the first judgment module is used for judging whether the playing address and the watermark code acquired by the interface are successfully authenticated or not after the player is initialized;
the generating module is used for generating a watermark through the returned watermark coding when the authentication is successful;
the second judging module is used for judging whether the request playing address is successful or not;
the third judging module is used for judging whether a decryption key exists or not when the request playing address is successful;
the fourth judging module is used for judging whether the ts slicing request is successful or not;
the fifth judgment module is used for judging whether decryption is needed or not when the ts slicing request is successful;
the sixth judgment module is used for judging whether a decryption key exists in the key storage when decryption is needed;
a seventh judging module, configured to, when a decryption key exists in the key storage, judge whether decryption based on the decryption key is successful;
and the playing module is used for filling the ts slicing result after the decryption success to the player for playing when the decryption based on the decryption key succeeds.
Preferably, the system further comprises:
the eighth judging module is used for polling the authentication service heartbeat interface at preset time intervals and judging whether the current user is valid;
and the ending module is used for ending the playing when the current user is not valid.
Preferably, the system further comprises:
a ninth judging module, configured to judge whether the decryption key is requested successfully when there is a decryption key;
and the storage module is used for storing the decryption key when the request for the decryption key is successful.
Preferably, the system further comprises:
a tenth judging module, configured to judge whether to load a new slice based on the buffer and the index;
the fourth judging module is further configured to, when it is judged that a new slice is loaded based on the buffer and the index, perform judgment again whether the ts slice is successfully requested based on the decryption key.
Preferably, the preset time is two seconds.
In summary, the present invention discloses a traceable encrypted live broadcast method, which first judges whether the playing address and the watermark code obtained by the interface are successfully authenticated after the player is initialized, if so, the following steps are performed: generating a watermark through the returned watermark coding; then judging whether the request for playing the address is successful, if so: judging whether a decryption key exists or not, then judging whether the ts slicing request is successful or not, if so: judging whether decryption is needed, if so, then: judging whether a decryption key exists in the key storage, if so, then: judging whether decryption based on the decryption key is successful, if so, then: and filling the ts slicing result after the decryption is successful into a player for playing. The invention can add watermark coding to the video picture played by each user under the condition of only providing one path of live video source stream, so that the pictures watched by each user are different, the transcoding cost and the storage cost of the live stream are saved, and the video can be effectively prevented from being illegally played.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
FIG. 1 is a flow chart of an embodiment 1 of a traceable encrypted live broadcast method disclosed by the present invention;
FIG. 2 is a flowchart of embodiment 2 of a traceable encrypted live broadcast method disclosed by the present invention;
fig. 3 is a schematic structural diagram of an embodiment 1 of a traceable encrypted live broadcast system disclosed by the present invention;
fig. 4 is a schematic structural diagram of embodiment 2 of a traceable encrypted live broadcast system disclosed in the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
As shown in fig. 1, which is a flowchart of embodiment 1 of a traceable encrypted live broadcast method disclosed in the present invention, the method may include the following steps:
s101, after the player is initialized, judging whether the playing address and the watermark code acquired by the interface are successfully authenticated, if so, entering S102:
after the player is initialized, the authentication interface is firstly requested to acquire a playing address and a watermark code.
S102, generating a watermark through the returned watermark coding;
and when the authentication is successful, generating the watermark through the returned watermark coding. When the watermark is dynamically generated, namely after the video picture is analyzed, the dynamically generated watermark is covered on the video picture to identify the unique user, so that the purpose of tracking the user through the picture can be achieved, the user is prevented from revealing a live broadcast source, and evidence can be provided when infringement occurs. The watermark is divided into a common watermark and a hidden watermark, and the bright watermark can facilitate visual tracking of a corresponding playing user; the hidden watermark is a hidden encrypted picture and is used for hidden tracking users. The clear watermark visually identifies the user by adding a dynamically generated character identifier which is fully covered with a user code on the DOM, monitors whether the DOM element is changed or not in real time by monitoring the change of the DOM element, and regenerates the dynamic watermark when the DOM element is changed to cover the dynamic watermark on a video picture so as to achieve the aim of preventing the user from tampering the watermark. The pseudo-hidden watermark is generated by using a user unique code, the dot matrix character watermark covers a video picture, and the watermark is an intermediate state between a clear watermark and a hidden watermark, so that a user cannot obviously sense watermark addition, but still has some picture quality loss. And (3) hidden watermarking, namely dynamically intercepting the current video picture as carrier data by using a Canvas, and then adding hidden watermark information to the video picture by using algorithms such as LBS (location based service) and the like under the condition that a user hardly senses the hidden watermark information.
In addition, when the authentication fails, the user is prompted to fail in authentication, and the whole process is ended.
S103, judging whether the request for playing the address is successful, if so, entering S104:
after generating the watermark, further judging whether the request playing address is successful.
S104, judging whether a decryption key exists;
when the request for playing the address is successful, whether a decryption key exists is further judged. In addition, when the request for playing the address fails, whether the retry times are exceeded is further judged, if not, the judgment is returned again to judge whether the request for playing the address succeeds, if so, a user is prompted that the video source loading fails, and the whole process is ended.
S105, judging whether the ts slicing is successfully requested, if so, entering S106:
after judging whether the decryption key exists, further judging whether the ts slice is successfully requested.
S106, judging whether decryption is needed, if so, entering S107:
when the ts slice is requested successfully, further judging whether decryption is needed; in addition, when the request ts slice fails, whether the request ts slice exceeds the retry times is further judged, if not, whether the request ts slice is successful is returned to be judged again, if yes, a user is prompted that the video source loading fails, and the whole process is finished.
S107, judging whether a decryption key exists in the key storage, if so, entering S108:
when decryption is needed, whether a decryption key is stored in the key storage is further judged.
S108, judging whether the decryption is successful or not based on the decryption key, if so, entering S109:
when the key storage has the decryption key, whether decryption by the decryption key is successful is further judged.
And S109, filling the ts slicing result after the decryption is successful into the player for playing.
And when the decryption is successful, filling the ts slicing result into the player for playing. And when the decryption fails, prompting the user that the video source loading fails and ending the whole process.
In summary, in the above embodiment, after the player is initialized, it is determined whether the playing address and the watermark code obtained by the interface are successfully authenticated, if yes, then: generating a watermark through the returned watermark coding; then judging whether the request for playing the address is successful, if so: judging whether a decryption key exists or not, then judging whether the ts slicing request is successful or not, if so: judging whether decryption is needed, if so, then: judging whether a decryption key exists in the key storage, if so, then: judging whether decryption based on the decryption key is successful, if so, then: and filling the ts slicing result after the decryption is successful into a player for playing. Under the condition of only providing one path of live video source stream, the watermark coding is added to the video picture played by each user, so that the pictures watched by each user are different, the transcoding cost and the storage cost of the live stream are saved, and the video can be effectively prevented from being illegally played.
As shown in fig. 2, which is a flowchart of embodiment 2 of the traceable encrypted live broadcast method disclosed in the present invention, the method may include the following steps:
s201, after the player is initialized, judging whether the playing address and the watermark code acquired by the interface are successfully authenticated, if so, entering S202:
after the player is initialized, the authentication interface is firstly requested to acquire a playing address and a watermark code.
S202, generating a watermark through the returned watermark coding;
and when the authentication is successful, generating the watermark through the returned watermark coding. When the watermark is dynamically generated, namely after the video picture is analyzed, the dynamically generated watermark is covered on the video picture to identify the unique user, so that the purpose of tracking the user through the picture can be achieved, the user is prevented from revealing a live broadcast source, and evidence can be provided when infringement occurs. The watermark is divided into a common watermark and a hidden watermark, and the bright watermark can facilitate visual tracking of a corresponding playing user; the hidden watermark is a hidden encrypted picture and is used for hidden tracking users. The clear watermark visually identifies the user by adding a dynamically generated character identifier which is fully covered with a user code on the DOM, monitors whether the DOM element is changed or not in real time by monitoring the change of the DOM element, and regenerates the dynamic watermark when the DOM element is changed to cover the dynamic watermark on a video picture so as to achieve the aim of preventing the user from tampering the watermark. The pseudo-hidden watermark is generated by using a user unique code, the dot matrix character watermark covers a video picture, and the watermark is an intermediate state between a clear watermark and a hidden watermark, so that a user cannot obviously sense watermark addition, but still has some picture quality loss. And (3) hidden watermarking, namely dynamically intercepting the current video picture as carrier data by using a Canvas, and then adding hidden watermark information to the video picture by using algorithms such as LBS (location based service) and the like under the condition that a user hardly senses the hidden watermark information.
In addition, when the authentication fails, the user is prompted to fail in authentication, and the whole process is ended.
S203, judging whether the request for playing the address is successful, if so, entering S204:
after generating the watermark, further judging whether the request playing address is successful.
S204, judging whether a decryption key exists, if so, entering S211:
when the request for playing the address is successful, whether a decryption key exists is further judged. In addition, when the request for playing the address fails, whether the retry times are exceeded is further judged, if not, the judgment is returned again to judge whether the request for playing the address succeeds, if so, a user is prompted that the video source loading fails, and the whole process is ended.
S205, judging whether the ts slicing request is successful, if so, entering S206:
after judging whether the decryption key exists, further judging whether the ts slice is successfully requested.
S206, judging whether decryption is needed, if yes, entering S207:
when the ts slice is requested successfully, further judging whether decryption is needed; in addition, when the request ts slice fails, whether the request ts slice exceeds the retry times is further judged, if not, whether the request ts slice is successful is returned to be judged again, if yes, a user is prompted that the video source loading fails, and the whole process is finished.
S207, judging whether a decryption key exists in the key storage, if so, entering S208:
when decryption is needed, whether a decryption key is stored in the key storage is further judged.
S208, judging whether the decryption is successful based on the decryption key, if so, entering S209:
when the key storage has the decryption key, whether decryption by the decryption key is successful is further judged.
And S209, filling the ts slicing result after the decryption is successful into a player for playing.
And when the decryption is successful, filling the ts slicing result into the player for playing. And when the decryption fails, prompting the user that the video source loading fails and ending the whole process.
S210, judging whether to load a new slice or not based on the buffer area and the index, if so, returning to the step S205:
and after the ts slice result is filled in the player to be played, further judging whether to load a new slice according to the condition of the buffer area and the slice index, and returning to judge whether the ts slice is requested to be successfully or not again when the new slice is loaded.
S211, judging whether the request for decrypting the key succeeds, if so, entering S212:
and when the decryption key is judged to exist, further judging whether the request for the decryption key succeeds.
S212, storing the decryption key;
when the request for the decryption key is successful, the decryption key is further stored.
S213, polling the authentication service heartbeat interface at preset intervals, judging whether the current user is valid, if not, entering S214:
and in the playing process, the authentication service heartbeat interface is further polled at preset time intervals to judge whether the current user is effective. For example, the authentication service heartbeat interface is polled every two seconds to determine whether the current user is valid.
And S214, ending the playing.
And when the current user is not valid, prompting the end of the playing and ending the playing.
In summary, in the present invention, under the condition of one path of encrypted source stream, the front end performs watermark addition on the live stream, and each user generates different watermark codes for tracking and watching users, so as to achieve the purpose of preventing the users from recording and playing screens or playing steams; in addition, the front end adds the video image watermark to the live stream and detects the watermark deletion, so that the front end can be prevented from deleting the watermark.
As shown in fig. 3, which is a schematic structural diagram of embodiment 1 of a traceable encrypted live broadcast system disclosed in the present invention, the system may include:
the first judging module 301 is configured to judge whether the interface acquires the play address and the watermark code is successfully authenticated after the player is initialized;
after the player is initialized, the authentication interface is firstly requested to acquire a playing address and a watermark code.
A generating module 302, configured to generate a watermark through the returned watermark encoding when the authentication is successful;
and when the authentication is successful, generating the watermark through the returned watermark coding. When the watermark is dynamically generated, namely after the video picture is analyzed, the dynamically generated watermark is covered on the video picture to identify the unique user, so that the purpose of tracking the user through the picture can be achieved, the user is prevented from revealing a live broadcast source, and evidence can be provided when infringement occurs. The watermark is divided into a common watermark and a hidden watermark, and the bright watermark can facilitate visual tracking of a corresponding playing user; the hidden watermark is a hidden encrypted picture and is used for hidden tracking users. The clear watermark visually identifies the user by adding a dynamically generated character identifier which is fully covered with a user code on the DOM, monitors whether the DOM element is changed or not in real time by monitoring the change of the DOM element, and regenerates the dynamic watermark when the DOM element is changed to cover the dynamic watermark on a video picture so as to achieve the aim of preventing the user from tampering the watermark. The pseudo-hidden watermark is generated by using a user unique code, the dot matrix character watermark covers a video picture, and the watermark is an intermediate state between a clear watermark and a hidden watermark, so that a user cannot obviously sense watermark addition, but still has some picture quality loss. And (3) hidden watermarking, namely dynamically intercepting the current video picture as carrier data by using a Canvas, and then adding hidden watermark information to the video picture by using algorithms such as LBS (location based service) and the like under the condition that a user hardly senses the hidden watermark information.
In addition, when the authentication fails, the user is prompted to fail in authentication, and the whole process is ended.
A second judging module 303, configured to judge whether the request for playing the address is successful;
after generating the watermark, further judging whether the request playing address is successful.
A third determining module 304, configured to determine whether a decryption key exists when the request for playing the address is successful;
when the request for playing the address is successful, whether a decryption key exists is further judged. In addition, when the request for playing the address fails, whether the retry times are exceeded is further judged, if not, the judgment is returned again to judge whether the request for playing the address succeeds, if so, a user is prompted that the video source loading fails, and the whole process is ended.
A fourth determining module 305, configured to determine whether the ts slice is successfully requested;
after judging whether the decryption key exists, further judging whether the ts slice is successfully requested.
A fifth judging module 306, configured to judge whether decryption is required when the ts slicing request is successful;
when the ts slice is requested successfully, further judging whether decryption is needed; in addition, when the request ts slice fails, whether the request ts slice exceeds the retry times is further judged, if not, whether the request ts slice is successful is returned to be judged again, if yes, a user is prompted that the video source loading fails, and the whole process is finished.
A sixth judging module 307, configured to judge whether a decryption key exists in the key storage when decryption is required;
when decryption is needed, whether a decryption key is stored in the key storage is further judged.
A seventh determining module 308, configured to determine whether decryption based on the decryption key is successful when the decryption key exists in the key storage;
when the key storage has the decryption key, whether decryption by the decryption key is successful is further judged.
And a playing module 309, configured to, when decryption is successful based on the decryption key, fill the ts slice result after decryption is successful in a player for playing.
And when the decryption is successful, filling the ts slicing result into the player for playing. And when the decryption fails, prompting the user that the video source loading fails and ending the whole process.
In summary, in the above embodiment, after the player is initialized, it is determined whether the playing address and the watermark code obtained by the interface are successfully authenticated, if yes, then: generating a watermark through the returned watermark coding; then judging whether the request for playing the address is successful, if so: judging whether a decryption key exists or not, then judging whether the ts slicing request is successful or not, if so: judging whether decryption is needed, if so, then: judging whether a decryption key exists in the key storage, if so, then: judging whether decryption based on the decryption key is successful, if so, then: and filling the ts slicing result after the decryption is successful into a player for playing. Under the condition of only providing one path of live video source stream, the watermark coding is added to the video picture played by each user, so that the pictures watched by each user are different, the transcoding cost and the storage cost of the live stream are saved, and the video can be effectively prevented from being illegally played.
As shown in fig. 4, which is a schematic structural diagram of embodiment 2 of a traceable encrypted live broadcast system disclosed in the present invention, the system may include:
a first determining module 401, configured to determine whether the interface acquires the playing address and the watermark code is successfully authenticated after the player is initialized;
after the player is initialized, the authentication interface is firstly requested to acquire a playing address and a watermark code.
A generating module 402, configured to generate a watermark through the returned watermark encoding when the authentication is successful;
and when the authentication is successful, generating the watermark through the returned watermark coding. When the watermark is dynamically generated, namely after the video picture is analyzed, the dynamically generated watermark is covered on the video picture to identify the unique user, so that the purpose of tracking the user through the picture can be achieved, the user is prevented from revealing a live broadcast source, and evidence can be provided when infringement occurs. The watermark is divided into a common watermark and a hidden watermark, and the bright watermark can facilitate visual tracking of a corresponding playing user; the hidden watermark is a hidden encrypted picture and is used for hidden tracking users. The clear watermark visually identifies the user by adding a dynamically generated character identifier which is fully covered with a user code on the DOM, monitors whether the DOM element is changed or not in real time by monitoring the change of the DOM element, and regenerates the dynamic watermark when the DOM element is changed to cover the dynamic watermark on a video picture so as to achieve the aim of preventing the user from tampering the watermark. The pseudo-hidden watermark is generated by using a user unique code, the dot matrix character watermark covers a video picture, and the watermark is an intermediate state between a clear watermark and a hidden watermark, so that a user cannot obviously sense watermark addition, but still has some picture quality loss. And (3) hidden watermarking, namely dynamically intercepting the current video picture as carrier data by using a Canvas, and then adding hidden watermark information to the video picture by using algorithms such as LBS (location based service) and the like under the condition that a user hardly senses the hidden watermark information.
In addition, when the authentication fails, the user is prompted to fail in authentication, and the whole process is ended.
A second judging module 403, configured to judge whether the request for playing the address is successful;
after generating the watermark, further judging whether the request playing address is successful.
A third determining module 404, configured to determine whether a decryption key exists when the request for playing the address is successful;
when the request for playing the address is successful, whether a decryption key exists is further judged. In addition, when the request for playing the address fails, whether the retry times are exceeded is further judged, if not, the judgment is returned again to judge whether the request for playing the address succeeds, if so, a user is prompted that the video source loading fails, and the whole process is ended.
A fourth determining module 405, configured to determine whether the ts slicing request is successful;
after judging whether the decryption key exists, further judging whether the ts slice is successfully requested.
A fifth determining module 406, configured to determine whether decryption is required when the ts slicing request is successful;
when the ts slice is requested successfully, further judging whether decryption is needed; in addition, when the request ts slice fails, whether the request ts slice exceeds the retry times is further judged, if not, whether the request ts slice is successful is returned to be judged again, if yes, a user is prompted that the video source loading fails, and the whole process is finished.
A sixth determining module 407, configured to determine whether a decryption key exists in the key storage when decryption is required;
when decryption is needed, whether a decryption key is stored in the key storage is further judged.
A seventh determining module 408, configured to determine whether decryption is successful based on the decryption key when the decryption key exists in the key storage;
when the key storage has the decryption key, whether decryption by the decryption key is successful is further judged.
And a playing module 409, configured to, when decryption is successful based on the decryption key, fill the ts slice result after decryption is successful in a player for playing.
And when the decryption is successful, filling the ts slicing result into the player for playing. And when the decryption fails, prompting the user that the video source loading fails and ending the whole process.
A tenth determining module 410, configured to determine whether to load a new slice based on the buffer and the index;
the fourth determining module 405 is further configured to perform a determination again whether the ts slice is successfully requested based on the decryption key when it is determined that a new slice is loaded based on the buffer and the index.
And after the ts slice result is filled in the player to be played, further judging whether to load a new slice according to the condition of the buffer area and the slice index, and returning to judge whether the ts slice is requested to be successfully or not again when the new slice is loaded.
A ninth determining module 411, configured to determine whether the decryption key is requested successfully when there is a decryption key;
and when the decryption key is judged to exist, further judging whether the request for the decryption key succeeds.
A storage module 412, configured to store the decryption key when the request for the decryption key is successful;
when the request for the decryption key is successful, the decryption key is further stored.
An eighth determining module 413, configured to poll the authentication service heartbeat interface every preset time, and determine whether the current user is valid;
and in the playing process, the authentication service heartbeat interface is further polled at preset time intervals to judge whether the current user is effective. For example, the authentication service heartbeat interface is polled every two seconds to determine whether the current user is valid.
An end module 414, configured to end the playing when the current user is not valid.
And when the current user is not valid, prompting the end of the playing and ending the playing.
In summary, in the present invention, under the condition of one path of encrypted source stream, the front end performs watermark addition on the live stream, and each user generates different watermark codes for tracking and watching users, so as to achieve the purpose of preventing the users from recording and playing screens or playing steams; in addition, the front end adds the video image watermark to the live stream and detects the watermark deletion, so that the front end can be prevented from deleting the watermark.
The embodiments in the present description are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other. The device disclosed by the embodiment corresponds to the method disclosed by the embodiment, so that the description is simple, and the relevant points can be referred to the method part for description.
Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (10)
1. A traceable encrypted live broadcast method is characterized by comprising the following steps:
after the player is initialized, whether the playing address and the watermark code acquired by the interface are successfully authenticated is judged, if so, the following steps are carried out:
generating a watermark through the returned watermark coding;
judging whether the request for playing the address is successful, if so, then:
judging whether a decryption key exists;
judging whether the ts slicing request is successful, if so, then:
judging whether decryption is needed, if so, then:
judging whether a decryption key exists in the key storage, if so, then:
judging whether decryption based on the decryption key is successful, if so, then:
and filling the ts slicing result after the decryption is successful into a player for playing.
2. The method of claim 1, further comprising:
polling the authentication service heartbeat interface at preset time intervals, judging whether the current user is effective, if not, then:
and ending the playing.
3. The method of claim 2, further comprising:
when a decryption key exists, judging whether the decryption key is requested successfully, if so, then:
storing the decryption key.
4. The method of claim 3, further comprising:
and judging whether to load a new slice or not based on the buffer area and the index, if so, then:
returning to perform the judgment again whether ts slicing is successful or not based on the decryption key request.
5. The method of claim 4, wherein the predetermined time is two seconds.
6. A traceable encrypted live broadcast system, comprising:
the first judgment module is used for judging whether the playing address and the watermark code acquired by the interface are successfully authenticated or not after the player is initialized;
the generating module is used for generating a watermark through the returned watermark coding when the authentication is successful;
the second judging module is used for judging whether the request playing address is successful or not;
the third judging module is used for judging whether a decryption key exists or not when the request playing address is successful;
the fourth judging module is used for judging whether the ts slicing request is successful or not;
the fifth judgment module is used for judging whether decryption is needed or not when the ts slicing request is successful;
the sixth judgment module is used for judging whether a decryption key exists in the key storage when decryption is needed;
a seventh judging module, configured to, when a decryption key exists in the key storage, judge whether decryption based on the decryption key is successful;
and the playing module is used for filling the ts slicing result after the decryption success to the player for playing when the decryption based on the decryption key succeeds.
7. The system of claim 6, further comprising:
the eighth judging module is used for polling the authentication service heartbeat interface at preset time intervals and judging whether the current user is valid;
and the ending module is used for ending the playing when the current user is not valid.
8. The system of claim 7, further comprising:
a ninth judging module, configured to judge whether the decryption key is requested successfully when there is a decryption key;
and the storage module is used for storing the decryption key when the request for the decryption key is successful.
9. The system of claim 8, further comprising:
a tenth judging module, configured to judge whether to load a new slice based on the buffer and the index;
the fourth judging module is further configured to, when it is judged that a new slice is loaded based on the buffer and the index, perform judgment again whether the ts slice is successfully requested based on the decryption key.
10. The system of claim 9, wherein the preset time is two seconds.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010836151.6A CN111935547A (en) | 2020-08-18 | 2020-08-18 | Traceable encrypted live broadcast method and traceable encrypted live broadcast system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010836151.6A CN111935547A (en) | 2020-08-18 | 2020-08-18 | Traceable encrypted live broadcast method and traceable encrypted live broadcast system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111935547A true CN111935547A (en) | 2020-11-13 |
Family
ID=73304783
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010836151.6A Pending CN111935547A (en) | 2020-08-18 | 2020-08-18 | Traceable encrypted live broadcast method and traceable encrypted live broadcast system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111935547A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113609506A (en) * | 2021-08-17 | 2021-11-05 | 南京数睿数据科技有限公司 | Text digital watermark tampering monitoring method based on NLP technology |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101917611A (en) * | 2010-08-31 | 2010-12-15 | 北京德博正业科技有限公司 | Video output device capable of tracking propagating sources |
| CN105282617A (en) * | 2014-06-12 | 2016-01-27 | 李英元 | Video-on-demand system capable of realizing picture identification differentiation |
| US20160247536A1 (en) * | 2013-02-20 | 2016-08-25 | Intel Corporation | Techniques for adding interactive features to videos |
| CN106791873A (en) * | 2016-11-28 | 2017-05-31 | 武汉优信众网科技有限公司 | A kind of traceable Electronic Paper line adding method of offline video |
| CN106982355A (en) * | 2017-04-06 | 2017-07-25 | 浙江宇视科技有限公司 | The video monitoring system and anti-leak server of a kind of anti-image leakage |
-
2020
- 2020-08-18 CN CN202010836151.6A patent/CN111935547A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101917611A (en) * | 2010-08-31 | 2010-12-15 | 北京德博正业科技有限公司 | Video output device capable of tracking propagating sources |
| US20160247536A1 (en) * | 2013-02-20 | 2016-08-25 | Intel Corporation | Techniques for adding interactive features to videos |
| CN105282617A (en) * | 2014-06-12 | 2016-01-27 | 李英元 | Video-on-demand system capable of realizing picture identification differentiation |
| CN106791873A (en) * | 2016-11-28 | 2017-05-31 | 武汉优信众网科技有限公司 | A kind of traceable Electronic Paper line adding method of offline video |
| CN106982355A (en) * | 2017-04-06 | 2017-07-25 | 浙江宇视科技有限公司 | The video monitoring system and anti-leak server of a kind of anti-image leakage |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113609506A (en) * | 2021-08-17 | 2021-11-05 | 南京数睿数据科技有限公司 | Text digital watermark tampering monitoring method based on NLP technology |
| CN113609506B (en) * | 2021-08-17 | 2023-12-08 | 南京数睿数据科技有限公司 | NLP technology-based text digital watermark tampering monitoring method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0899688B1 (en) | Generating, detecting, recording, and reproducing a watermarked moving image | |
| US8595854B2 (en) | Processing recordable content in a stream | |
| US6618484B2 (en) | Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels | |
| CA2465282C (en) | A system and method for secure distribution and evaluation of compressed digital information | |
| US20020078178A1 (en) | Content distribution control | |
| JP4408601B2 (en) | Information reproducing apparatus and secure module | |
| CN106534053B (en) | Media file permission control method, server and equipment | |
| KR101705010B1 (en) | Processing recordable content in a stream | |
| CN111935547A (en) | Traceable encrypted live broadcast method and traceable encrypted live broadcast system | |
| Yu | Digital multimedia at home and content rights management | |
| CN112257035A (en) | Digital work copyright protection method and device based on playing platform | |
| US8631145B2 (en) | System and method for playing content on certified devices | |
| US8898801B2 (en) | Method for protecting a digital rights file description | |
| KR100610638B1 (en) | A system and a method for providing multimedia contents on demand | |
| US11284169B2 (en) | Method of and a device for rendering content data of a content data stream based on a level of toxicity of the content data stream | |
| US20090327692A1 (en) | Method and device for distributing secure digital audiovisual contents by interoperable solutions | |
| KR100939174B1 (en) | Method and system for preventing to copy illegality contents | |
| KR100712921B1 (en) | Mobile communication terminal enable to play content in short time and its operating method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20201113 |