CN114979695A - Multi-process live broadcast method and device based on SRS, electronic equipment and storage medium - Google Patents
Multi-process live broadcast method and device based on SRS, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN114979695A CN114979695A CN202210574821.0A CN202210574821A CN114979695A CN 114979695 A CN114979695 A CN 114979695A CN 202210574821 A CN202210574821 A CN 202210574821A CN 114979695 A CN114979695 A CN 114979695A
- Authority
- CN
- China
- Prior art keywords
- live
- video stream
- live broadcast
- srs
- requests
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 205
- 230000008569 process Effects 0.000 claims abstract description 108
- 238000012544 monitoring process Methods 0.000 claims abstract description 44
- 238000004590 computer program Methods 0.000 claims description 12
- 238000013500 data storage Methods 0.000 claims description 12
- 238000004088 simulation Methods 0.000 abstract description 4
- 238000004891 communication Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 8
- 238000012545 processing Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 5
- 238000000605 extraction Methods 0.000 description 4
- 230000002452 interceptive effect Effects 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 230000002441 reversible effect Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000002699 waste material Substances 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
- H04N21/2408—Monitoring of the upstream path of the transmission network, e.g. client requests
-
- 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/21—Server components or server architectures
- H04N21/218—Source of audio or video content, e.g. local disk arrays
- H04N21/2187—Live feed
-
- 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
- H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
-
- 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/85—Assembly of content; Generation of multimedia applications
- H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The application relates to a multi-process live broadcast method and device based on SRS, electronic equipment and a storage medium, wherein the method comprises the following steps: acquiring a plurality of live broadcast stream pushing requests and corresponding live broadcast video stream data received through a preset anti-proxy monitoring port; dividing a plurality of live broadcast stream pushing requests to obtain a plurality of groups of live broadcast stream pushing requests; distributing each group of live broadcast stream pushing requests to a corresponding SRS process to respectively obtain live broadcast video stream data corresponding to a live broadcast stream pushing address corresponding to each group of live broadcast stream pushing requests through each SRS process in parallel, storing each group of live broadcast video stream data in parallel, and obtaining live broadcast video stream playing requests received through an anti-proxy monitoring port; and acquiring correspondingly stored live video stream data according to the live video stream playing request, and sending the live video stream data to a corresponding live video stream playing request client. And the plug flow request is distributed to a plurality of SRS processes at the rear end, so that the simulation of multithreading is realized, and the server resources are fully utilized.
Description
Technical Field
The present application relates to the field of communications technologies, and in particular, to a method and an apparatus for multi-process live broadcast based on SRS, an electronic device, and a storage medium.
Background
Srs (simple RTMP server) is a very excellent open source streaming media server software, which can be used in various scenes such as live broadcast/recorded broadcast/video customer service, and its location is an operation-level internet live broadcast server cluster.
For most of live broadcast services of small enterprises, in order to save cost and meet live broadcast requirements, a server is basically adopted to execute the live broadcast services, and particularly, live broadcast video stream processing is realized through an SRS thread. However, the SRS supports only a single thread and does not support multithreading, and when a plurality of live streaming requests are executed, only one live streaming request can be executed alone, which results in failure to fully utilize multiple cores, waste of server resources, and low efficiency.
Disclosure of Invention
Based on this, the application provides a multi-process live broadcast method, device, electronic device and storage medium based on an SRS, and a reverse proxy monitoring port is arranged to distribute a plurality of push stream requests to a plurality of SRS processes at the rear end, so that multi-thread simulation is realized, the problem of low efficiency caused by execution of a single push stream request by a single SRS process is solved, and server resources are fully utilized.
As a first aspect of the embodiments of the present application, a method for multi-process live broadcast based on SRS is provided, which includes the following steps:
acquiring a plurality of live broadcast stream pushing requests and corresponding live broadcast video stream data received through a preset anti-proxy monitoring port; the live streaming request comprises a live streaming address; the live video stream data corresponds to the live streaming addresses one by one; the anti-proxy monitoring port is configured with a plurality of monitoring sub-ports, and each monitoring sub-port is configured with an SRS process;
dividing a plurality of live streaming requests to obtain a plurality of groups of live streaming requests; distributing each group of live streaming requests to a corresponding SRS process, so as to respectively obtain live video stream data corresponding to a live streaming address corresponding to each group of live streaming requests in parallel through each SRS process, and store each group of live video stream data in parallel, wherein each group of live streaming requests at least comprises one live streaming request;
acquiring a live video stream playing request received through the anti-proxy monitoring port; and acquiring correspondingly stored live video stream data according to the live video stream playing request, and sending the live video stream data to a corresponding live video stream playing request client.
As a second aspect of the embodiments of the present application, there is provided a multi-process direct broadcast device based on an SRS, including:
the data acquisition module is used for acquiring a plurality of live broadcast stream pushing requests and corresponding live broadcast video stream data received through a preset anti-proxy monitoring port; the live streaming request comprises a live streaming address; the live video stream data corresponds to the live streaming addresses one by one; the anti-proxy monitoring port is configured with a plurality of monitoring sub-ports, and each monitoring sub-port is configured with an SRS process;
the data storage module is used for dividing the live streaming requests to obtain a plurality of groups of live streaming requests; each group of live broadcast stream pushing requests is distributed to a corresponding SRS process, so that live broadcast video stream data corresponding to a live broadcast stream pushing address corresponding to each group of live broadcast stream pushing requests are respectively obtained through the SRS processes in parallel, and the live broadcast video stream data of each group are stored in parallel, wherein each group of live broadcast stream pushing requests at least comprises one live broadcast stream pushing request;
the data playing module is used for acquiring a live video stream playing request received through the anti-proxy monitoring port; and acquiring correspondingly stored live video stream data according to the live video stream playing request, and sending the live video stream data to a corresponding live video stream playing request client.
As a third aspect of the embodiments of the present application, there is provided an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor, the processor being connected to the display and the storage; the computer program, when executed by the processor, implements the steps of the SRS-based multi-process live method as described in the first aspect.
As a fourth aspect of embodiments of the present application, a storage medium is provided, where the storage medium stores a computer program, and the computer program when executed by a processor implements the steps of the SRS-based multi-process live broadcast method according to the first aspect.
In the embodiment of the application, the plug flow request is distributed to the plurality of SRS processes at the rear end by arranging the anti-proxy monitoring port, so that the simulation of multithreading is realized, the effect of executing the plug flow request by a single SRS process is improved, the server resource is fully utilized, and the live broadcast efficiency is improved.
For a better understanding and practice, the present application is described in detail below with reference to the accompanying drawings.
Drawings
Fig. 1 is a schematic view of an application scenario of a multi-process live broadcast method based on an SRS according to an embodiment of the present application;
fig. 2 is a schematic flowchart of a multi-process live broadcast method based on an SRS according to a first embodiment of the present application;
fig. 3 is a schematic flowchart of S2 in the SRS-based multi-process live broadcast method according to the first embodiment of the present application;
fig. 4 is a schematic flowchart of S2 in a multi-process live broadcast method based on SRS according to a second embodiment of the present application;
fig. 5 is a schematic flowchart of S2 in a multi-process live broadcast method based on SRS according to a third embodiment of the present application;
fig. 6 is a schematic flowchart of S25 in a multi-process live broadcast method based on SRS according to a third embodiment of the present application;
fig. 7 is a schematic flowchart of S251 in a multi-process live broadcast method based on an SRS according to a third embodiment of the present application;
fig. 8 is a schematic flowchart of S3 in a multi-process direct broadcast method based on SRS according to a fourth embodiment of the present application;
fig. 9 is a schematic structural diagram of a multi-process direct broadcast device based on an SRS according to a fifth embodiment of the present application;
fig. 10 is a schematic structural diagram of a data storage module of a multi-process direct-broadcast device based on an SRS according to a fifth embodiment of the present application;
fig. 11 is a schematic structural diagram of a data playing module of a multi-process live broadcasting device based on an SRS according to a fifth embodiment of the present application;
fig. 12 is a schematic structural diagram of an electronic device according to a sixth embodiment of the present application.
Detailed Description
To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings. Where the following description refers to the accompanying drawings, like numerals in different drawings represent the same or similar elements, unless otherwise indicated.
It should be understood that the embodiments described in the examples described below do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims. 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 application.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Further, in the description of the present application, "a plurality" means two or more unless otherwise specified. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items, e.g., a and/or B, may mean: a exists alone, A and B exist simultaneously, and B exists alone; the character "/" generally indicates that the former and latter associated objects are in an "or" relationship.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms, but rather should be used to distinguish between similar items and not necessarily for describing a particular order or sequence, or for indicating or implying relative importance. The specific meaning of the above terms in the present application can be understood by those of ordinary skill in the art as appropriate. The word "if/if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
Referring to fig. 1, fig. 1 is a schematic view of an application scenario of a multi-process live broadcast method based on SRS according to an embodiment of the present application, where the application scenario includes an anchor client 110, a viewer client 120, and a server 130.
The anchor client 110 interacts with the viewer client 120 through the server 130. Specifically, the anchor client 110 and the viewer client 120 may both access the internet through a network access manner, and establish a data communication link with the server 130. The network may be any connection type of communication medium capable of implementing communication between the anchor client 110 and the server 130 and between the viewer client 120 and the server 130, such as a wired communication link, a wireless communication link, or a fiber optic cable, and the like, which is not limited herein.
It should be noted that the clients proposed in the embodiment of the present application include the anchor client 110 and the viewer client 120.
It is noted that there are many understandings of the concept of "client" in the prior art, such as: it may be understood as an application program installed in a computer device, or may be understood as a hardware device corresponding to a server.
In the embodiments of the present application, the term "client" refers to a hardware device corresponding to a server, and more specifically, refers to a computer device, such as: smart phones, smart interactive tablets, personal computers, and the like.
When the client is a mobile device such as a smart phone and a smart interactive tablet, the user can install a matched mobile application program on the client and can also access a Web application program on the client.
When the client is a non-mobile device such as a Personal Computer (PC), the user can install a matching PC application on the client, and similarly can access a Web application on the client.
The mobile terminal application refers to an application program that can be installed in the mobile device, the PC terminal application refers to an application program that can be installed in the non-mobile device, and the Web terminal application refers to an application program that needs to be accessed through a browser.
Specifically, the Web application program may be divided into a mobile version and a PC version according to the difference of the client types, and the page layout modes and the available server support of the two versions may be different.
In the embodiment of the application, the types of live application programs provided to the user are divided into a mobile end live application program, a PC end live application program and a Web end live application program. The user can autonomously select a mode of participating in the live webcasting according to different types of the client adopted by the user.
The present application divides clients into an anchor client 110 and a viewer client 120 depending on the identity of the user entering the client in the live room. It should be noted that in practical applications, the functions of the viewer client 120 and the anchor client 110 may be performed by the same client at different times. Thus, the same client may act as the viewer client 120 when viewing a live network broadcast, and may act as the anchor client 110 when publishing a live video.
The anchor client 110 is a terminal that sends a webcast video, and is generally a client used by an anchor user in webcast. The hardware at which the anchor client 110 is directed is essentially a computer device, and in particular, as shown in fig. 1, it may be a type of computer device such as a smart phone, smart interactive tablet, and personal computer.
The spectator client 120 is a client that receives and watches live video, and is typically a client used by a spectator user watching the video in the live video. The hardware at which the viewer client 120 is pointed is essentially a computer device, and in particular, as shown in fig. 1, it may be a type of computer device such as a smart phone, smart interactive tablet, and personal computer.
The server 130 may be a business server, and may be responsible for further connecting related audio data servers, video streaming servers, and other servers providing related support, etc. to form a logically associated server cluster for providing services to related terminal devices, such as the anchor client 110 and the viewer client 120 shown in fig. 1.
When an anchor user uses an anchor client 110 to carry out live streaming, the anchor client 110 generates a live streaming request and sends the live streaming request and an associated live video stream to a server, the server 130 responds to the live streaming request and stores the live video stream, when the audience user uses an audience client 120 to carry out live broadcasting, the audience client 120 generates a live broadcasting request and sends the live broadcasting request to the server 130, and the server 130 responds to the live broadcasting request and obtains a corresponding live video stream which is sent to the audience client 120 to be broadcasted. Here, srs (simple rtmpserver) is generally used for processing a live video stream.
In an actual situation, for most live broadcast services of small enterprises, in order to save cost and meet live broadcast requirements, a server is basically adopted to execute the live broadcast services, specifically, a live broadcast stream pushing request is acquired through a port, so that a live broadcast video stream corresponding to the live broadcast stream pushing request is processed through an SRS process corresponding to the port, however, the SRS supports only a single thread and does not support multiple threads, when a plurality of live broadcast stream pushing requests are executed, only one live broadcast stream pushing request can be executed independently, which results in that multiple cores cannot be fully utilized, server resources are wasted, and efficiency is low.
Referring to fig. 2, fig. 2 is a schematic flowchart of a multi-process live broadcasting method based on an SRS according to a first embodiment of the present application, where the multi-process live broadcasting method based on the SRS according to the embodiment of the present application is applied to an enterprise live broadcasting service, especially a live broadcasting service executed by a server, and specifically, the multi-process live broadcasting method based on the SRS according to the embodiment of the present application is executed by the server as an execution main body, where the method includes the following steps:
s1: the method comprises the steps of obtaining a plurality of live broadcast stream pushing requests and corresponding live broadcast video stream data received through a preset anti-proxy monitoring port.
In this embodiment, the server sets an anti-proxy snoop port based on NGINX, where the NGINX is a piece of high-performance WEB service software, supports a multi-protocol port reverse proxy, and supports a TCP port reverse proxy, i.e., a stream proxy.
Receiving live broadcast stream pushing requests and live broadcast video stream data sets sent by all anchor clients through the anti-proxy monitoring port, wherein the live broadcast stream pushing requests comprise live broadcast stream pushing addresses; and the live video stream data corresponds to the live stream pushing addresses one to one.
The anti-proxy monitoring port is provided with a plurality of monitoring sub-ports, and each monitoring sub-port is provided with an SRS process; each SRS process has a corresponding number, e.g., SRS1, SRS2, SRS3, etc.; the SRS is a simple and efficient real-time video server and supports RTMP/WebRTC/HLS/HTTP-FLV/SRT/GB 29191.
S2: dividing a plurality of live streaming requests to obtain a plurality of groups of live streaming requests; and distributing each group of live streaming requests to a corresponding SRS process, so as to respectively obtain live video stream data corresponding to a live streaming address corresponding to each group of live streaming requests in parallel through each SRS process, and store each group of live video stream data in parallel.
In this embodiment, the server divides a plurality of live streaming requests to obtain a plurality of groups of live streaming requests; each group of live streaming pushing requests at least comprises one live streaming pushing request;
in order to fully utilize multi-core resources, the server respectively starts each SRS process, allocates each group of live streaming pushing requests to a corresponding SRS process through a corresponding monitoring sub-port, so as to respectively obtain live video stream data corresponding to a live streaming pushing address corresponding to each group of live streaming pushing requests in parallel through each SRS process, and store each group of live video stream data in parallel.
In an optional embodiment, the server may equally divide a plurality of live streaming requests into live streaming requests whose number is consistent with the number of SRS processes according to the number of SRS processes. For example: the number of the current live broadcast stream pushing requests is 12, and the number of the SRS processes is 3, the live broadcast stream pushing requests are divided into 3 groups, each group of live broadcast stream pushing requests comprises 4 live broadcast stream pushing requests, so that each SRS process can continuously work and can execute the live broadcast stream pushing requests in time.
In another alternative embodiment, please refer to fig. 3, where fig. 3 is a schematic flowchart of S2 in the SRS-based multi-process live broadcasting method according to the first embodiment of the present application, including steps S21 to S22, which are as follows:
s21: and acquiring load information of each SRS process.
In this embodiment, the server analyzes each SRS process, and obtains the number of live streaming requests allowed to be executed by each SRS process as load information of each SRS process.
S22: and dividing a plurality of live streaming requests according to the number of the live streaming requests allowed to be executed by each SRS process to obtain a plurality of groups of live streaming requests.
In order to fully utilize multi-core resources, in this embodiment, a server divides a plurality of live streaming requests according to the number of live streaming requests allowed to be executed by each SRS process, so as to obtain a plurality of groups of live streaming requests;
specifically, the server may divide a number of the live streaming requests according to a preset proportion, where the proportion may be a coefficient associated with the number of live streaming requests allowed to be executed, for example: the number of the live streaming requests allowed to be executed of the SRS process corresponding to the SRS1 is 1, the number of the live streaming requests allowed to be executed of the SRS process corresponding to the SRS2 is 2, and the number of the live streaming requests allowed to be executed of the SRS process corresponding to the SRS3 is 3, so that the ratio of the SRS1 process, the SRS2 process and the SRS3 process is set to be 1:2: 3; if the number of the current live streaming push requests is 12, dividing a plurality of live streaming push requests according to the proportion corresponding to each SRS process, wherein each SRS process can be divided into the number of the live streaming push requests multiplied by the preset metering number, namely the number of the live streaming push requests corresponding to the SRS process numbered as SRS1 is 2, the number of the live streaming push requests corresponding to the SRS process numbered as SRS2 is 4, and the number of the live streaming push requests corresponding to the SRS process numbered as SRS3 is 6, so that the live streaming push requests are divided into a group of live streaming push requests with the number of 2, a group of live streaming push requests with the number of 4 and a group of live streaming requests with the number of 6, and the division of the live streaming push requests is realized.
In an optional embodiment, the live streaming push address includes live streaming push identifiers, and each live streaming push identifier has a unique corresponding live video stream data.
Referring to fig. 4, fig. 4 is a schematic flowchart of S2 in the SRS-based multi-process live broadcasting method according to the second embodiment of the present application, further including step S23, which is as follows:
s23: and acquiring a path of a preset virtual memory directory, and storing each group of live video stream data in the virtual memory directory in parallel through each SRS process.
In this embodiment, the server pre-configures a virtual memory directory, acquires a path of the virtual memory directory, and stores each set of live video stream data in the virtual memory directory in parallel through each SRS process, so that the read-write efficiency is improved by reducing the occupancy rate of disk I/O, thereby improving the live broadcast efficiency.
In an optional embodiment, the virtual memory directory includes a plurality of sub virtual memory directories corresponding to the live streaming identifier, where the sub virtual memory directories are storage spaces further divided under the virtual memory directory. Referring to fig. 5, fig. 5 is a schematic flow chart of S2 in the SRS-based multi-process live broadcasting method according to the third embodiment of the present application, further including steps S24 to S25, which are as follows:
s24: and acquiring live broadcast stream pushing identifiers in live broadcast stream pushing addresses corresponding to the live broadcast stream pushing requests of all groups, and acquiring live broadcast video stream data corresponding to the live broadcast stream pushing identifiers of all groups according to the live broadcast stream pushing identifiers.
In this embodiment, the server obtains a live streaming push identifier in a live streaming push address corresponding to the live streaming push request, and obtains live video stream data corresponding to each group of live streaming push identifiers according to the live streaming push identifier, where the live streaming push identifier is a unique identifier of each user who uses the anchor client to perform live streaming push, and the live streaming push identifier may be a registration name of the user, may also be a registration number of the user, and is not limited in detail here.
S25: acquiring a path of a sub-virtual memory directory corresponding to the live streaming pushing identifier according to the live streaming pushing identifier; and storing the live broadcast video stream data corresponding to each group of live broadcast stream pushing identifications in a corresponding sub-virtual memory directory through each SRS process.
In this embodiment, the server obtains, according to the live streaming identifier, a path of a sub-virtual memory directory corresponding to the live streaming identifier; and storing the live video stream data corresponding to each group of live streaming pushing identifications in a corresponding sub-virtual memory directory through each SRS process, so that the efficiency of a user for retrieving the live video stream data corresponding to the corresponding live streaming pushing identifications is improved.
Referring to fig. 6, fig. 6 is a schematic flowchart of S25 in a multi-process live broadcast method based on SRS according to a third embodiment of the present application, including step S251, which is as follows:
s251: and by configuring a distribution mode of each SRS process, each SRS process generates a plurality of live video clip files from the live video stream data according to a preset sequence, numbers the live video clip files according to the starting time and the ending time of recording live videos as required, and stores the live video clip files in a sub-virtual memory directory corresponding to the live streaming pushing identifier.
The SRS process is distributed in an HLS (http Live streaming) distribution manner, and specifically, in this embodiment, after a server acquires a Live video stream, the server configures the HLS distribution manner for each SRS process, each SRS process generates a plurality of Live video clip files from the Live video stream data according to a preset sequence, numbers the Live video clip files according to a start time and an end time of recording a Live video as needed, and stores the Live video clip files in a sub-virtual directory memory corresponding to the Live streaming identifier.
Wherein, the preset sequence may be a time sequence, for example: the time sequence of the playing of the frames of the live video stream.
Because the playing time lengths corresponding to each live video clip file are different, the live video clip files are numbered according to the starting time and the ending time of the live recorded video as required, specifically, 0-3 seconds of the live video stream are used for generating a first live video clip file, 4-8 seconds are used for generating a second live video clip file, 9-10 seconds are used for generating a third live video clip file, by analogy, as the playing time is prolonged, the more live video clip files are generated, and the generated live video clip files are numbered, the numbering starts from 1, 1 is added each time, that is, the number of the first live video clip file is 1, the number of the second live video clip file is 2, the number of the nth live video clip file is n (n is a positive integer), and the number is stored in the sub virtual memory directory corresponding to the live stream pushing identifier.
Referring to fig. 7, fig. 7 is a schematic flowchart of S251 in the SRS-based multi-process live broadcast method according to the third embodiment of the present application, including steps S2511 to S2512, which are specifically as follows:
s2511: and traversing the live video clip files under the corresponding sub-virtual memory directories through each SRS process to acquire the characteristic information of the live video clip files.
With the extension of the live broadcast time, the server generates more and more live broadcast video clip files in the sub virtual memory directory by the SRS distribution mode.
In order to quickly retrieve live video clip files, in this embodiment, a server traverses live video clip files in a sub-virtual memory directory through each SRS process to obtain feature information of the live video clip files, so as to generate an index file corresponding to the live video clip files, where the feature information includes names, numbers, and play durations of live video stream data;
specifically, the server may traverse the live video clip file in the sub virtual memory directory by using a SHELL script, and obtain file feature information of the live video clip file by using a multimedia stream information extraction tool, where the multimedia stream information extraction tool may be an information extraction tool for executing an FFprobe command.
S2512: dynamically assembling the characteristic information of the live video clip files through the SRS processes to obtain index files corresponding to the live video clip files, and storing the index files in the corresponding sub-virtual memory directories.
In this embodiment, the server dynamically assembles the feature information of the live video clip file through each SRS process according to the feature information of the live video clip file to obtain an index file corresponding to the live video clip file, and stores the index file in the corresponding sub-virtual memory directory;
specifically, when the server dynamically obtains the name and the playing duration of the live video clip file through the multimedia stream information extraction tool, the index file, such as live001.m3u8, is reassembled by using the name and the playing duration of the live video clip file.
S3: acquiring a live broadcast video stream playing request received through the anti-proxy monitoring port; and acquiring correspondingly stored live video stream data according to the live video stream playing request, and sending the live video stream data to a corresponding live video stream playing request client.
In this embodiment, the server obtains a live video stream playing request received through the anti-proxy monitoring port, obtains correspondingly stored live video stream data according to the live video stream playing request, and sends the live video stream data to a corresponding live video stream playing request client.
In an optional embodiment, the live video stream playing request includes a live request address, where the live request address includes a live push stream identifier and an index file identifier, the index file is represented as a unique identifier of each index file, and the index file identifier may be a name, a number, and the like of the index file, which is not limited in detail herein.
Referring to fig. 8, fig. 8 is a schematic flowchart of S3 in the SRS-based multi-process live broadcast method according to the fourth embodiment of the present application, including steps S31 to S32, which are specifically as follows:
s31: and sending the live broadcast video stream playing request to one SRS process, and acquiring a path of a sub-virtual memory directory corresponding to a live broadcast push flow identifier according to the live broadcast push flow identifier in the live broadcast video stream playing request.
In this embodiment, the server sends the live broadcast video stream playing request to one SRS process, and specifically, the server may obtain, from the SRS processes, an SRS process with the minimum number of live broadcast stream pushing requests allowed to be executed according to the load information obtained by obtaining the SRS processes, call a corresponding monitoring sub-port as a target SRS process, send the live broadcast video stream playing request to the target SRS process, execute the live broadcast video stream playing request by the SRS process, and obtain, according to a live broadcast stream pushing identifier in the live broadcast video stream playing request, a path of a sub-virtual memory directory corresponding to the live broadcast stream pushing identifier.
S32: and according to the index file identification in the live broadcast address and the path of the sub virtual memory directory corresponding to the live broadcast stream pushing identification, acquiring an index file corresponding to the live broadcast stream pushing identification in the live broadcast request address from the sub virtual memory directory, acquiring a live broadcast video clip file corresponding to the index file according to the index file, and sending the live broadcast video clip file to a corresponding live broadcast video stream playing request client.
In this embodiment, the server obtains, according to the index file identifier in the live broadcast address and the path of the sub-virtual memory directory corresponding to the live broadcast stream push identifier, the index file corresponding to the live broadcast stream push identifier in the live broadcast request address from the sub-virtual memory directory, obtains, according to the index file, the live broadcast video clip file corresponding to the index file, and sends the live broadcast video clip file to the corresponding live broadcast video stream play request client, so that the problems of delay and lag of conventional live broadcast video stream play are solved, and user experience is improved.
Referring to fig. 9, fig. 9 is a schematic structural diagram of a multi-process direct broadcast apparatus based on an SRS according to a fifth embodiment of the present application, where the apparatus may implement all or a part of a multi-process direct broadcast method based on the SRS through software, hardware, or a combination of the software and the hardware, and the apparatus 9 includes:
the data acquisition module 91 is configured to acquire a plurality of live streaming requests and corresponding live video stream data received through a preset anti-proxy monitoring port; the live streaming request comprises a live streaming address; the live video stream data corresponds to the live streaming addresses one by one; the anti-proxy monitoring port is configured with a plurality of monitoring sub-ports, and each monitoring sub-port is configured with an SRS process;
the data storage module 92 is configured to divide the plurality of live streaming requests to obtain a plurality of groups of live streaming requests; distributing each group of live streaming requests to a corresponding SRS process, so as to respectively obtain live video stream data corresponding to a live streaming address corresponding to each group of live streaming requests in parallel through each SRS process, and store each group of live video stream data in parallel, wherein each group of live streaming requests at least comprises one live streaming request;
a data playing module 93, configured to obtain a live video stream playing request received through the anti-proxy monitoring port; and acquiring correspondingly stored live video stream data according to the live video stream playing request, and sending the live video stream data to a corresponding live video stream playing request client.
Referring to fig. 10, fig. 10 is a schematic structural diagram of a data storage module of a multi-process direct broadcast device based on SRS according to a fifth embodiment of the present application, and in an optional embodiment, the data storage module 92 includes:
a load information obtaining module 921, configured to obtain load information of each SRS process, where the load information includes a number of live streaming requests that the SRS process allows to execute;
and the live streaming request obtaining module 922 is configured to divide a plurality of live streaming requests according to the number of live streaming requests allowed to be executed by each SRS process, so as to obtain a plurality of groups of live streaming requests.
In an alternative embodiment, the data storage module 92 includes:
a first path obtaining module 923, configured to obtain a path of a preset virtual memory directory, and store each set of live video stream data in the virtual memory directory in parallel through each SRS process.
In an alternative embodiment, the data storage module 92 includes:
a live streaming identifier obtaining module 924, configured to obtain live streaming identifiers in live streaming addresses corresponding to the live streaming requests of the groups, and obtain live video stream data corresponding to the live streaming identifiers of the groups according to the live streaming identifiers;
the live video stream data storage module 925 obtains a path of a sub-virtual memory directory corresponding to the live streaming pushing identifier according to the live streaming pushing identifier; storing the live broadcast video stream data corresponding to each group of live broadcast stream pushing identifications in a corresponding sub-virtual memory directory through each SRS process;
in an alternative embodiment, the data storage module 92 includes:
the live video segment file generating module 926 is configured to configure a distribution mode of each SRS process, generate a plurality of live video segment files from the live video stream data according to a preset sequence by each SRS process, number the live video segment files according to a start time and an end time of recording a live video as needed, and store the number in a sub-virtual memory directory corresponding to the live streaming identifier.
In an alternative embodiment, the data storage module 92 includes:
a feature information obtaining module 927, configured to obtain feature information of a live video clip file by traversing, by each SRS process, a live video clip file in the corresponding sub-virtual memory directory, where the feature information includes a name, a number, and a play duration of live video stream data;
an index file generation module 928, configured to dynamically assemble the feature information of the live video segment file through each SRS process, obtain an index file corresponding to the live video segment file, and store the index file in the corresponding sub-virtual memory directory.
Referring to fig. 11, fig. 11 is a schematic structural diagram of a data playing module of a multi-process live broadcasting device based on SRS according to a fifth embodiment of the present application, in an alternative embodiment, the data playing module 93 includes:
a second path obtaining module 931, configured to send the live broadcast video stream playing request to one SRS process, and obtain, according to a live broadcast stream pushing identifier in the live broadcast video stream playing request, a path of a sub virtual memory directory corresponding to the live broadcast stream pushing identifier;
and the live video stream playing module 932 is configured to obtain, in the sub-virtual memory directory, an index file corresponding to the live streaming identifier in the live streaming request address according to the index file identifier in the live address and a path of the sub-virtual memory directory corresponding to the live streaming identifier, obtain, according to the index file, a live video clip file corresponding to the index file, and send the live video clip file to a corresponding live video stream playing request client.
In the embodiment, a plurality of live broadcast stream pushing requests and corresponding live broadcast video stream data received by a preset anti-proxy monitoring port are obtained through an obtaining module; the live streaming request comprises a live streaming address; the live video stream data corresponds to the live streaming addresses one by one; the anti-proxy monitoring port is configured with a plurality of monitoring sub-ports, and each monitoring sub-port is configured with an SRS process; dividing the plurality of live streaming requests through a storage module to obtain a plurality of groups of live streaming requests; distributing each group of live streaming requests to a corresponding SRS process, so as to parallelly acquire live video stream data corresponding to a live streaming address corresponding to each group of live streaming requests through each SRS process respectively, and storing each group of live video stream data, wherein each group of live streaming requests at least comprises one live streaming request; acquiring a live video stream playing request received through the anti-proxy monitoring port through a playing module; and acquiring correspondingly stored live video stream data according to the live video stream playing request, and sending the live video stream data to a corresponding live video stream playing request client. By arranging the monitoring port, the plug-flow request is distributed to a plurality of SRS processes at the rear end, multi-thread simulation is realized, the effect of executing the plug-flow request by a single SRS process is improved, server resources are fully utilized, video stream data corresponding to the plug-flow request is stored in a virtual memory, the occupancy rate of disk I/O is reduced, the read-write efficiency is improved, and the live broadcast efficiency is improved.
Referring to fig. 12, fig. 12 is a schematic structural diagram of an electronic device according to a sixth embodiment of the present application, where the electronic device 10 includes: a processor 101, a memory 102, and a computer program 103 stored on the memory 102 and operable on the processor 101; the processor 101 is connected with the display 91 and the storage 102; the electronic device 10 may store a plurality of instructions, where the instructions are suitable for being loaded by the processor 101 and executing the steps of the SRS-based multi-process live broadcast method according to the foregoing embodiment, and specific execution processes may refer to specific descriptions of the first to fourth embodiments, which are not described herein again.
The Memory 102 may include a Random Access Memory (RAM) 102, and may also include a Read-Only Memory (Read-Only Memory) 102. Optionally, the memory 102 includes a non-transitory computer-readable medium. The memory 102 may be used to store instructions, programs, code sets, or instruction sets. The memory 102 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch instructions, etc.), instructions for implementing the above-mentioned method embodiments, and the like; the storage data area may store data and the like referred to in the above respective method embodiments. The memory 102 may optionally be at least one memory device located remotely from the processor 101.
The embodiments of the present application further provide a storage medium, where the storage medium may store multiple instructions, where the instructions are suitable for being loaded by a processor and being executed to perform the method steps in the first to fourth embodiments, and specific execution processes may refer to specific descriptions of the embodiments shown in the first to fourth embodiments, which are not described herein again.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the technical solution. 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 application.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus/terminal device and method may be implemented in other ways. For example, the above-described embodiments of the apparatus/terminal device are merely illustrative, and for example, the division of the modules or units is only one logical division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit may be implemented in the form of hardware, or may also be implemented in the form of a software functional unit.
The integrated modules/units, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow in the method of the embodiments described above can be realized by a computer program, which can be stored in a computer-readable storage medium and can realize the steps of the embodiments of the methods described above when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc.
The present application is not limited to the above-described embodiments, and various changes and modifications to the present application are intended to be included within the scope of the claims and the equivalent technology of the present application if they do not depart from the spirit and scope of the present application.
Claims (10)
1. A multi-process live broadcast method based on SRS is characterized by comprising the following steps:
acquiring a plurality of live broadcast stream pushing requests and corresponding live broadcast video stream data received through a preset anti-proxy monitoring port; the live streaming request comprises a live streaming address; the live video stream data corresponds to the live streaming addresses one by one; the anti-proxy monitoring port is configured with a plurality of monitoring sub-ports, and each monitoring sub-port is configured with an SRS process;
dividing a plurality of live streaming requests to obtain a plurality of groups of live streaming requests; distributing each group of live streaming requests to a corresponding SRS process, so as to respectively obtain live video stream data corresponding to a live streaming address corresponding to each group of live streaming requests in parallel through each SRS process, and store each group of live video stream data in parallel; each group of live streaming pushing requests at least comprises one live streaming pushing request;
acquiring a live broadcast video stream playing request received through the anti-proxy monitoring port; and acquiring correspondingly stored live video stream data according to the live video stream playing request, and sending the live video stream data to a corresponding live video stream playing request client.
2. The SRS-based multi-process live broadcast method according to claim 1, wherein the dividing of the plurality of live broadcast streaming requests to obtain the plurality of groups of live broadcast streaming requests comprises the steps of:
acquiring load information of each SRS process, wherein the load information comprises the number of live streaming push requests allowed to be executed by the SRS process;
and dividing a plurality of live streaming requests according to the number of the live streaming requests allowed to be executed by each SRS process to obtain a plurality of groups of live streaming requests.
3. The SRS-based multi-process live broadcast method according to claim 1 or 2, wherein the live broadcast streaming address includes live broadcast streaming identifiers, each live broadcast streaming identifier having uniquely corresponding live broadcast video stream data; the step of allocating each group of live streaming requests to a corresponding SRS process to obtain live video stream data corresponding to a live streaming address corresponding to each group of live streaming requests in parallel through each SRS process, and storing each group of live video stream data includes:
and acquiring a path of a preset virtual memory directory, and storing each group of live video stream data in the virtual memory directory in parallel through each SRS process.
4. The SRS-based multi-process live broadcast method according to claim 3, wherein the virtual memory directory includes a plurality of sub-virtual memory directories corresponding to the live broadcast stream pushing identifier; the method comprises the following steps that a preset path of a virtual memory directory is obtained, and each group of live video stream data is stored in the virtual memory directory in parallel through each SRS process, and further comprises the following steps:
acquiring live broadcast stream pushing identifiers in live broadcast stream pushing addresses corresponding to the live broadcast stream pushing requests of all groups, and acquiring live broadcast video stream data corresponding to the live broadcast stream pushing identifiers of all groups according to the live broadcast stream pushing identifiers;
acquiring a path of a sub-virtual memory directory corresponding to the live streaming pushing identifier according to the live streaming pushing identifier; and storing the live broadcast video stream data corresponding to each group of live broadcast stream pushing identifications in a corresponding sub-virtual memory directory through each SRS process.
5. The SRS-based multi-process live broadcast method according to claim 4, wherein the step of storing the live video stream data corresponding to each group of the live push flow identifications in a corresponding sub-virtual memory directory by each SRS process comprises the steps of:
and by configuring a distribution mode of each SRS process, each SRS process generates a plurality of live video clip files from the live video stream data according to a preset sequence, numbers the live video clip files according to the starting time and the ending time of recording live videos as required, and stores the live video clip files in a sub-virtual memory directory corresponding to the live streaming pushing identifier.
6. The SRS-based multi-process live broadcast method according to claim 5, wherein the live broadcast video stream data corresponding to each group of live broadcast stream pushing identifiers is stored in a corresponding sub-virtual memory directory by each SRS process, further comprising the steps of:
the method comprises the steps that a live video clip file under a corresponding sub-virtual memory directory is traversed through each SRS process, and the characteristic information of the live video clip file is obtained, wherein the characteristic information comprises the name, the number and the playing duration of live video stream data;
and dynamically assembling the characteristic information of the live video clip file through each SRS process to obtain an index file corresponding to the live video clip file, and storing the index file in the corresponding sub-virtual memory directory.
7. The SRS-based multi-process direct broadcast method according to claim 6, wherein:
the live video stream playing request comprises a live request address, wherein the live request address comprises a live stream pushing identifier and an index file identifier;
the method comprises the following steps of obtaining correspondingly stored live video stream data according to the live video stream playing request, and sending the live video stream data to a corresponding live video stream playing request client, wherein the live video stream playing request comprises the following steps:
sending the live broadcast video stream playing request to one SRS process, and acquiring a path of a sub-virtual memory directory corresponding to a live broadcast push flow identifier according to the live broadcast push flow identifier in the live broadcast video stream playing request;
and according to the index file identification in the live broadcast address and the path of the sub virtual memory directory corresponding to the live broadcast stream pushing identification, acquiring an index file corresponding to the live broadcast stream pushing identification in the live broadcast request address from the sub virtual memory directory, acquiring a live broadcast video clip file corresponding to the index file according to the index file, and sending the live broadcast video clip file to a corresponding live broadcast video stream playing request client.
8. A multi-process live broadcast device based on SRS is characterized by comprising:
the data acquisition module is used for acquiring a plurality of live broadcast stream pushing requests and corresponding live broadcast video stream data received through a preset anti-proxy monitoring port; the live streaming request comprises a live streaming address; the live video stream data corresponds to the live streaming addresses one by one; the anti-proxy monitoring port is configured with a plurality of monitoring sub-ports, and each monitoring sub-port is configured with an SRS process;
the data storage module is used for dividing the live streaming requests to obtain a plurality of groups of live streaming requests; distributing each group of live streaming requests to a corresponding SRS process, so as to respectively obtain live video stream data corresponding to a live streaming address corresponding to each group of live streaming requests in parallel through each SRS process, and store each group of live video stream data in parallel, wherein each group of live streaming requests at least comprises one live streaming request;
the data playing module is used for acquiring a live video stream playing request received through the anti-proxy monitoring port; and acquiring correspondingly stored live video stream data according to the live video stream playing request, and sending the live video stream data to a corresponding live video stream playing request client.
9. An electronic device comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, the processor being coupled to the display, the memory; the processor when executing the computer program realizes the steps of the SRS-based multi-process live broadcast method according to any one of claims 1 to 7.
10. A storage medium, characterized by: the storage medium stores a computer program which, when executed by a processor, implements the steps of the SRS-based multi-process live method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210574821.0A CN114979695B (en) | 2022-05-25 | 2022-05-25 | SRS-based multi-process live broadcast method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210574821.0A CN114979695B (en) | 2022-05-25 | 2022-05-25 | SRS-based multi-process live broadcast method and device, electronic equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114979695A true CN114979695A (en) | 2022-08-30 |
| CN114979695B CN114979695B (en) | 2024-04-09 |
Family
ID=82955310
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210574821.0A Active CN114979695B (en) | 2022-05-25 | 2022-05-25 | SRS-based multi-process live broadcast method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114979695B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115243070A (en) * | 2022-09-21 | 2022-10-25 | 广州市保伦电子有限公司 | Automatic recovery method for live broadcast stream progress abnormity and processing terminal |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014533899A (en) * | 2012-10-02 | 2014-12-15 | クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ | SRS optimization for multipoint coordinated transmission and reception |
| CN107577494A (en) * | 2017-08-30 | 2018-01-12 | 微梦创科网络科技（中国）有限公司 | A kind of method and device based on multi-process race live broadcast in both illustration and text |
| WO2019114129A1 (en) * | 2017-12-13 | 2019-06-20 | 平安科技（深圳）有限公司 | Scheduling device and method for push server and computer-readable storage medium |
| CN111225222A (en) * | 2018-11-26 | 2020-06-02 | 北京奇虎科技有限公司 | Video stream playing method, device and system based on screen data of RTMP (real time Messaging protocol) |
| CN113014941A (en) * | 2021-03-01 | 2021-06-22 | 深圳市邻友通科技发展有限公司 | Open streaming media on-demand method, device, server and access platform |
| CN114500436A (en) * | 2021-12-22 | 2022-05-13 | 天翼云科技有限公司 | Data transmission method and device and electronic equipment |
-
2022
- 2022-05-25 CN CN202210574821.0A patent/CN114979695B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014533899A (en) * | 2012-10-02 | 2014-12-15 | クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ | SRS optimization for multipoint coordinated transmission and reception |
| CN107577494A (en) * | 2017-08-30 | 2018-01-12 | 微梦创科网络科技（中国）有限公司 | A kind of method and device based on multi-process race live broadcast in both illustration and text |
| WO2019114129A1 (en) * | 2017-12-13 | 2019-06-20 | 平安科技（深圳）有限公司 | Scheduling device and method for push server and computer-readable storage medium |
| CN111225222A (en) * | 2018-11-26 | 2020-06-02 | 北京奇虎科技有限公司 | Video stream playing method, device and system based on screen data of RTMP (real time Messaging protocol) |
| CN113014941A (en) * | 2021-03-01 | 2021-06-22 | 深圳市邻友通科技发展有限公司 | Open streaming media on-demand method, device, server and access platform |
| CN114500436A (en) * | 2021-12-22 | 2022-05-13 | 天翼云科技有限公司 | Data transmission method and device and electronic equipment |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115243070A (en) * | 2022-09-21 | 2022-10-25 | 广州市保伦电子有限公司 | Automatic recovery method for live broadcast stream progress abnormity and processing terminal |
| CN115243070B (en) * | 2022-09-21 | 2022-12-27 | 广州市保伦电子有限公司 | Automatic recovery method for live broadcast stream progress abnormity and processing terminal |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114979695B (en) | 2024-04-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108391179B (en) | Live broadcast data processing method and device, server, terminal and storage medium | |
| CN104539977B (en) | Method for previewing and device is broadcast live | |
| CN107645561B (en) | Picture preview method of cloud mobile phone | |
| US20140165119A1 (en) | Offline download method, multimedia file download method and system thereof | |
| CN112073758B (en) | Cloud desktop screen projection method and device, computer equipment, computer readable storage medium and cloud desktop screen projection interaction system | |
| US9712835B2 (en) | Video encoding system and method | |
| CN106534916B (en) | A kind of video living transmission system for cafe environment based on three layers of service device framework | |
| CN106301865B (en) | Data processing method and device applied to service providing device | |
| CN103002274A (en) | Mobile multimedia real-time transcoding play system and method based on offline download | |
| CN108512814B (en) | Media data processing method, device and system | |
| EP3176995A1 (en) | Method, device, server, and system for synchronizing member benefits among multiple devices | |
| CN105516733B (en) | Interactive system and its exchange method | |
| CN104363509B (en) | A kind of video conversion method, device, play system and terminal | |
| CN104185040A (en) | Application synchronization method, application server and terminal | |
| CN105610869B (en) | Method and device for scheduling streaming media | |
| CN114979695B (en) | SRS-based multi-process live broadcast method and device, electronic equipment and storage medium | |
| CN114598931A (en) | Streaming method, system, device and medium for multi-open cloud game | |
| CN111385593A (en) | Cross-platform live content synchronization method and device, storage medium and server | |
| CN113139123A (en) | Resource recommendation method, device, server and storage medium | |
| US20170134457A1 (en) | Broadcast-linked service based on cloud streaming, broadcast-linked service client apparatus, trigger content providing server | |
| WO2016202202A1 (en) | Device connection method and apparatus, and smart television system | |
| CN113115065B (en) | Live broadcast-based data processing method and device | |
| CN106302617B (en) | Data processing method and device applied to computing device | |
| CN113301374A (en) | Live broadcast audio and video processing method and device, client and server | |
| CN106209860B (en) | Real-time classroom streaming media live broadcast load distribution 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 | ||
| CB02 | Change of applicant information |
Country or region after: China Address after: No. 56 Nanli East Road, Shiqi Town, Panyu District, Guangzhou City, Guangdong Province, 510000 Applicant after: Guangdong Baolun Electronics Co.,Ltd. Address before: No.19 Chuangyuan Road, Zhongcun street, Panyu District, Guangzhou, Guangdong 510000 Applicant before: GUANGZHOU ITC ELECTRONIC TECHNOLOGY Co.,Ltd. Country or region before: China |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |