CN117857856A - Method for switching multiple source stations of live broadcast system - Google Patents

Method for switching multiple source stations of live broadcast system Download PDF

Info

Publication number
CN117857856A
CN117857856A CN202311700599.5A CN202311700599A CN117857856A CN 117857856 A CN117857856 A CN 117857856A CN 202311700599 A CN202311700599 A CN 202311700599A CN 117857856 A CN117857856 A CN 117857856A
Authority
CN
China
Prior art keywords
source
switching
push
stations
stream
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
Application number
CN202311700599.5A
Other languages
Chinese (zh)
Inventor
郑锋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tianyi Cloud Technology Co Ltd
Original Assignee
Tianyi Cloud Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Tianyi Cloud Technology Co Ltd filed Critical Tianyi Cloud Technology Co Ltd
Priority to CN202311700599.5A priority Critical patent/CN117857856A/en
Publication of CN117857856A publication Critical patent/CN117857856A/en
Pending legal-status Critical Current

Links

Landscapes

  • Information Transfer Between Computers (AREA)

Abstract

The invention discloses a method for switching multiple source stations of a live broadcast system, which comprises the steps of firstly, configuring source stations, writing mapping relations of all source stations and source stations with switchable targets into a configuration center, wherein the source station configuration comprises push flow and pull flow; step two, uplink push flow switching, wherein the uplink push flow end is connected with the source station, and whether switching is needed is judged according to push flow configuration information corresponding to the current source station; the invention adopts a method for switching multiple source stations of a system, the mapping relation of the switching source stations is stored in a configuration center, when the source stations receive push stream or return source, whether to redirect a request to a target source station is determined according to configuration, different redirection is realized according to the request types received by the source stations, data interaction of different source stations in a transdistrict can occur after the source stations are switched, at the moment, the source stations return audio and video data through a certain node of the source stations, push stream and return source of the audio and video are switched, and the push stream and the pull stream of increment and storage are not influenced after the switching.

Description

Method for switching multiple source stations of live broadcast system
Technical Field
The invention relates to the technical field of audio and video live broadcasting, in particular to a method for switching multiple source stations of a live broadcasting system.
Background
In the live audio and video broadcasting process, after receiving a client request, when the CDN forwards or returns source audio and video data to a source, a plurality of live source clusters generally exist, and in order to balance loads among the source clusters or solve an abnormal problem of a certain source, switching of the source clusters is required for live streaming.
The conventional technology is usually implemented by manually switching addresses or through interface communication, and since live broadcasting is a real-time scenario, manual intervention can increase switching time, and therefore, a method for switching multiple source stations of a live broadcasting system needs to be designed to solve the problem.
Disclosure of Invention
The invention aims to provide a method for switching multiple source stations of a live broadcast system, which aims to solve the problems in the background technology.
In order to achieve the above purpose, the present invention provides the following technical solutions: a method for switching multiple source stations of a live broadcast system, the switching method comprising the steps of:
firstly, data is received, and a CDN receives a data request of a client;
step two, data transfer pushing, namely transferring audio data to a source station;
thirdly, configuring source stations, and writing mapping relations of all source stations and source stations with switchable targets into a configuration center, wherein the source station configuration comprises push flow and pull flow;
step four, uplink push flow switching, wherein the uplink push flow end is connected with the source station, and whether switching is needed is judged according to push flow configuration information corresponding to the current source station;
fifth, switching the downlink back source, establishing connection between the downlink pull stream end and the source station, and judging whether switching is needed according to pull stream configuration information corresponding to the current source station;
step six, cross-region data interaction, wherein after the source stations are switched, data of different source stations in the cross region are interacted, live stream is pushed to the source station A, and stream is pulled from the source station B;
and seventhly, returning the source audio and video data, namely returning the source audio and video data to a certain node of the source station A by the source station B, so that live streams pushed to the source station A are switched to the source station B, and the source pulling streams returned from an inlet of the source station B are switched to the source station A.
Preferably, s1, s2, s3 are denoted by the source station, the push flows of s1, s3 are switched to s3 source station, the pull flow of s1 is pulled from s3 back to the source, and the switching of the push flows is configured as:
{s1:s3,s2:s3}(1);
the switching of the pull stream is configured to:
{s1:s3}(2)。
preferably, the domain name of the push stream is configured as follows:
{ s1: push1.Com, s2: push2.Com, s3: push3.Com } (4); domain name configuration of the pull stream:
{s1:play1.com,s2:play2.com,s3:play3.com}(5)。
preferably, when the source station in the third step receives push flow or return source, the redirection to the target source station is determined according to the configuration, and the request types received by the source station have different redirection implementations.
Preferably, the uplink push switching in the fourth step is performed by a push protocol, where the push protocol is rtmp, a user-defined rtmpon Status message is returned, and the cdn node side needs to be slightly modified, so that the message can be identified and be redirected to a new target source station.
Preferably, the rtmp push request returns a redirect and target source address via an rtmp message.
Preferably, the downstream source-back switching in the fifth step is performed by a pull stream protocol, where the pull stream protocol is http, and is implemented by redirecting by http302, and the calculated pull stream address is returned by an http Location header, where the http is expressed as:
HTTP/1.1302Found (6); the http Location is expressed as:
Location:http://play3.com/live/stream.flvsecret=xxx&expireTime=yy y(7)。
preferably, the http pull stream source request is redirected back to the target source address by http 302.
Preferably, the cross-region data interaction in the sixth step is implemented after the source station switches through data, and the cross-region data interaction can enable the live broadcast to be interacted.
Preferably, in the seventh step, the audio and video data of the back source is switched by switching the interactive live stream through uplink push stream switching and downlink back source switching, so as to realize push and back source switching of the switched audio and video.
The invention has the technical effects and advantages that:
the invention adopts a method for switching multiple source stations of a system, the mapping relation of the switching source stations is stored in a configuration center, when the source stations receive push stream or return source, whether to redirect a request to a target source station is determined according to configuration, different redirection is realized according to the request types received by the source stations, data interaction of different source stations in a transdistrict can occur after the source stations are switched, at the moment, the source stations return audio and video data through a certain node of the source stations, push stream and return source of the audio and video are switched, and the push stream and the pull stream of increment and storage are not influenced after the switching.
Drawings
FIG. 1 is a schematic diagram of a main structure of the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
The invention provides a method for switching multiple source stations of a live broadcast system as shown in figure 1, which comprises the following steps:
firstly, data is received, and a CDN receives a data request of a client;
step two, data transfer pushing, namely transferring audio data to a source station;
it should be noted that the source station refers to an actual video stream address, and typically, the address may be directly played by the video player.
Thirdly, configuring source stations, and writing mapping relations of all source stations and source stations with switchable targets into a configuration center, wherein the source station configuration comprises push flow and pull flow;
it should be noted that, the mapping relationship of the switching source station is stored in the configuration center, when the source station receives push flow or return source, it is determined whether to redirect the request to the target source station according to the configuration, and different redirecting implementations are implemented according to the request type received by the source station, for example, rtmp push flow request can return the redirecting and target source station address through rtmp message; the http pull stream returns to the source request, and then the target return source address can be redirected through the http 302; other protocols may be similarly custom implemented. After the source station is switched, data interaction of different source stations in a cross region can occur, and the situation that live broadcast streams are pushed to the source station A but pulled from the source station B is caused, and the source station B is required to return source audio and video data to a certain node of the source station A at this time.
Step four, uplink push flow switching, wherein the uplink push flow end is connected with the source station, and whether switching is needed is judged according to push flow configuration information corresponding to the current source station;
it should be noted that, push is a process of pushing live content to a server. The push stream has higher requirements on the network, if the network is unstable, the live broadcast effect is poor, the phenomenon of blocking and the like can occur when the audience watches the live broadcast, and the watching experience is poor. Audio and video data must also be encapsulated using a transport protocol to become streaming data for push streaming. The typical streaming protocols include RTSP, RTMIPO, HLS, and the delay of using RTMP transmission is usually 1-3 seconds, so that RTMP is the most typical streaming protocol in live mobile phone broadcasting for a scene with very high real-time requirement. And finally, pushing the audio and video stream data to a network end through a certain Qos algorithm, and distributing through the CDN.
Fifth, switching the downlink back source, establishing connection between the downlink pull stream end and the source station, and judging whether switching is needed according to pull stream configuration information corresponding to the current source station;
it should be noted that, the pulling is a process of pulling the live content existing in the server by using the designated address. The pulling flow refers to the process that the server has live content, establishes connection with the server according to the protocol type (such as RTMP, RTP, RTSP, HTTP, etc.), receives data and pulls. The core processing of the streaming end decodes and renders at the player end, and functions such as chat rooms, praise and gift systems and the like are integrated in the interactive live broadcast. The streaming end now supports three protocols RTMP, HLS, HDL (HTTP-FLV), wherein under the condition of stable network, the delay control of HDL protocol can reach 1s, thereby completely meeting the business requirement of interactive live broadcast.
Step six, cross-region data interaction, wherein after the source stations are switched, data of different source stations in the cross region are interacted, live stream is pushed to the source station A, and stream is pulled from the source station B;
and seventhly, returning the source audio and video data, namely returning the source audio and video data to a certain node of the source station A by the source station B, so that live streams pushed to the source station A are switched to the source station B, and the source pulling streams returned from an inlet of the source station B are switched to the source station A.
Specifically, s1, s2 and s3 are denoted by the source station, the push flows of s1 and s3 are switched to the s3 source station, the pull flow of s1 is pulled from s3 back to the source, and the switching of the push flows is configured to:
{s1:s3,s2:s3}(1);
the switching of the pull stream is configured to:
{s1:s3}(2)。
specifically, the domain name of the push stream is configured as follows:
{ s1: push1.Com, s2: push2.Com, s3: push3.Com } (4); domain name configuration of the pull stream:
{s1:play1.com,s2:play2.com,s3:play3.com}(5)。
further, when the source station in the third step receives push flow or return source, the redirection to the target source station is determined according to the configuration, and the request types received by the source station have different redirection implementations.
In the audio and video live broadcast process, after the CDN receives the client request, when the CDN forwards or returns the source audio and video data to the source, a plurality of live source clusters generally exist, and in order to balance a load between the source or solve an abnormal problem of a certain source, the CDN needs to switch the source to the live stream.
The full name of CDN is Content Delivery Network, the content delivery network. The basic idea is to avoid the bottleneck and link on the internet which possibly affects the data transmission speed and stability as much as possible, so that the content is transmitted faster and more stably. CDNs employ more cache servers (CDN edge nodes) deployed in areas or networks where user access is relatively centralized. When a user accesses a website, the global loading technology is utilized to direct the access of the user to a cache server closest to the user, and the cache server responds to the user request.
Through a layer of intelligent virtual network formed by node servers placed everywhere in the network and based on the existing internet, the CDN system can redirect the user's request to the service node nearest to the user in real time according to the network flow and the comprehensive information of the connection of each node, the load condition, the distance to the user, the response time and the like. The method aims to enable the user to obtain the required content nearby, solve the problem of congestion of the Internet network and improve the response speed of the user for accessing the website.
The CDN technology has the greatest advantage of accelerating the access of the website, namely, the physical distance between the user and the content is shortened, and the waiting time of the user is shortened. Moreover, the cache servers distributed to the different lines also allow for acceleration of access across operators. In addition, CDNs have security benefits. After the content is distributed, the IP of the source server is hidden, and the probability of being attacked is greatly reduced. And when a certain server fails, the system can call the adjacent healthy server to perform service, so that the influence on the user is avoided.
Further, the uplink push switching in the fourth step is performed by a push protocol, where the push protocol is rtmp, a user-defined rtmpon Status message is returned, and the cdn node side needs to be slightly modified, so that the message can be identified and then is forwarded to a new target source station again.
It should be noted that, when the uplink push end establishes connection with the source station, whether switching is needed is determined according to push configuration information corresponding to the current source station, if switching is needed, if the push protocol is rtmp, a user-defined rtmp onStatus message may be returned, as shown in table 1:
TABLE 1
While the cdn node side needs to be slightly modified to recognize the message and re-push to the new destination source.
Further, the rtmp plug flow request returns a redirect and target source station address through an rtmp message.
It should be noted that, the rtmp protocol is an abbreviation of Real Time Message Protocol (real-time information transmission protocol), which is an application layer protocol proposed by Adobe corporation, and is used to solve the problems of Multiplexing (Multiplexing) and Packetizing (Packetizing) of multimedia data transmission streams.
rtmp provides a bi-directional message multiplexing service between two peer communication terminals via a reliable transport protocol (e.g., TCP) for transmitting parallel video, audio and data with time information. Implementation of a typical protocol gives different types of messages different priorities, which affect the order of queues sent by the underlying layers of messages when transmission capacity is limited.
rtmp has mainly the following advantages: rtmp is a protocol developed specifically for streaming media, optimizing the bottom layer is more excellent than other protocols, while it Adobe Flash supports well, and essentially all encoders (cameras, etc.) support rtmp output. The market of PC is huge, PC is mainly Windows, and Windows browser basically supports Flash. In addition, rtmp is suitable for long-time playing, has been tested, and has no problem when being connected with 100 ten thousand seconds, namely, continuous playing for more than 10 days. The delay of the rtmp is relatively low, the delay is generally between 1 and 3s, and the delay is generally enough for video conferences and interactive live broadcasting.
Rtmp is one of the most commonly used transmission protocols in real-time live scenes, especially in push uplink, due to the good support of protocol design for low latency, audio and video synchronization, etc.
Specifically, the downstream source switching in the fifth step is performed by a pull stream protocol, the pull stream protocol is http, the pull stream protocol is realized by http302 redirection, the calculated pull stream address is returned by an http Location header, and the http is expressed as:
HTTP/1.1302Found (6);
the httpLocation is expressed as:
Location:http://play3.com/live/stream.flvsecret=xxx&expireTime=yyy (7)。
it should be noted that, when the downstream pull-stream end establishes connection with the source station, whether switching is needed is determined according to pull-stream configuration information corresponding to the current source station, if switching is needed, if the pull-stream protocol is http (such as http-flv/hls, etc.), the method can be implemented by adopting http302 redirection, that is, the calculated pull-stream address is returned through the httpLocation header, for example:
HTTP/1.1302Found
Location:http://play3.com/live/stream.flvsecret=xxx&expireTime=yyy
further, the http pull stream source request is redirected back to the target source address through http 302.
Note that FLV (FlashVideo) is another video format proposed by Adobe corporation, and is a streaming media data storage container format transmitted over a network. Its format is relatively simple and lightweight, and does not require large media header information. The whole FLV consists of TheFLVHeader, theFLVBody and other tags, so that the loading speed is extremely high, and the file encapsulated in the FLV format is suffixed with the FLV.
The http-flv encapsulates streaming media data into flv format, and then transmits the streaming media data to the client through an http protocol, and selects a corresponding program to process corresponding Content according to Content-Type in the protocol by means of MIME characteristics, so that the streaming media can be transmitted through http. Compared with rtmp protocol, the http-flv can penetrate the firewall well, is based on http/80 transmission, and effectively avoids interception by the firewall. In addition, it can skip flexible scheduling/load balancing through http302, supporting the use of https encryption transmission.
Furthermore, the cross-region data interaction in the sixth step is realized after the source station is switched by the data, and the cross-region data interaction can enable the live broadcast to have interaction.
Furthermore, the audio and video data of the back source in the seventh step is switched by the interactive live stream through the uplink push stream switching and the downlink back source switching, so as to realize the push and back source switching of the switched audio and video.
After the source station is switched, the live stream is pushed to the source station A, but the stream is pulled from the source station B, and the source station B needs to send back the source audio and video data to a certain node of the source station A at this time, so that the live stream pushed to the source station A is switched to the source station B, and the live stream is switched to the source station A from the entrance of the source station B.
In the actual use process, an uplink push stream rtmp protocol and a downlink pull stream http-flv are taken as embodiments, and the configuration scheme is as follows:
pushing flow:
and (3) switching configuration: { s1:s3, s2:s3}
Domain name configuration: { s1: push1.Com, s2: push2.Com, s3: push3.Com }
And (3) drawing:
and (3) switching configuration: { s3:s1, s2:s1}
Domain name configuration: { s1: play1.Com, s2: play2.Com, s3: play3.Com }
The rtmponStatus message is as follows:
RealTimeMessagingProtocol(AMF0CommandonStatus('NetStream.Push.Redirect'))
RTMPHeader
00……=Format:0
.000101=ChunkStreamID:5
Timestamp:0
Bodysize:96
TypeID:AMF0Command(0x14)
StreamID:1
RTMPBody
String'onStatus'
Number0
Null
Object(3items)
Property'level'String'status'
Property'code'String'NetStream.Push.Redirect'
Property'description'String's3'
the http302 message is as follows:
HTTP/1.1302Found
Location:http://play1.com/live/stream.flvsecret=xxx&expireTime=yyy
according to the embodiment, all live broadcast streams pushed to the s1 or s2 source stations are switched to the s3 source station, all live broadcast streams returned from the s2 or s3 source station entrance are switched to the s1 source station, the push and return sources of the audio and video can be switched, the push and the pull streams of the increment and the stock are not affected after the switching, and the purposes of automatically switching a plurality of live broadcast source stations, reducing manual intervention, shortening switching time and improving the stability of the whole live broadcast system are achieved.
Finally, it should be noted that: the foregoing description is only illustrative of the preferred embodiments of the present invention, and although the present invention has been described in detail with reference to the foregoing embodiments, it will be apparent to those skilled in the art that modifications may be made to the embodiments described, or equivalents may be substituted for elements thereof, and any modifications, equivalents, improvements or changes may be made without departing from the spirit and principles of the present invention.

Claims (10)

1. A method for switching multiple source stations of a live broadcast system, the switching method comprising the following steps:
firstly, data is received, and a CDN receives a data request of a client;
step two, data transfer pushing, namely transferring audio data to a source station;
thirdly, configuring source stations, and writing mapping relations of all source stations and source stations with switchable targets into a configuration center, wherein the source station configuration comprises push flow and pull flow;
step four, uplink push flow switching, wherein the uplink push flow end is connected with the source station, and whether switching is needed is judged according to push flow configuration information corresponding to the current source station;
fifth, switching the downlink back source, establishing connection between the downlink pull stream end and the source station, and judging whether switching is needed according to pull stream configuration information corresponding to the current source station;
step six, cross-region data interaction, wherein after the source stations are switched, data of different source stations in the cross region are interacted, live stream is pushed to the source station A, and stream is pulled from the source station B;
and seventhly, returning the source audio and video data, namely returning the source audio and video data to a certain node of the source station A by the source station B, so that live streams pushed to the source station A are switched to the source station B, and the source pulling streams returned from an inlet of the source station B are switched to the source station A.
2. A method of switching multiple source stations of a live broadcast system according to claim 1, wherein the source stations are denoted s1, s2, s3, wherein the push streams of s1, s3 are switched to s3 source stations, wherein the pull stream of s1 is pulled back from s3, and wherein the switching of push streams is configured to:
{ s1: s3, s2: s3} (1); the switching of the pull stream is configured to:
{s1:s3}(2)。
3. the method for switching multiple sources in a live broadcast system according to claim 2, wherein the domain name of the push stream is configured to:
{ s1: push1.Com, s2: push2.Com, s3: push3.Com } (4); domain name configuration of the pull stream:
{s1:play1.com,s2:play2.com,s3:play3.com}(5)。
4. a method for switching between multiple source stations in a live broadcast system according to claim 1, wherein when the source station in the third step receives push stream or return source, it decides to redirect to the target source station according to configuration, and the request types received by the source station have different redirection implementation.
5. The method for switching multiple source stations in a live broadcast system according to claim 1, wherein the uplink push switch in the fourth step is switched by a push protocol, the push protocol is rtmp, a custom rtmponStatus message is returned, and the cdn node side needs to be slightly modified to identify the message and forward the message to a new target source station again.
6. The method of claim 5, wherein the rtmp push request is returned to the redirect and destination source address via rtmp messages.
7. The method for switching multiple sources of a live broadcast system according to claim 1, wherein the downstream source switching in the fifth step is performed by a pull stream protocol, the pull stream protocol is http, the pull stream protocol is implemented by http302 redirection, the calculated pull stream address is returned by an httpLocation header, and the http is expressed as:
HTTP/1.1302Found (6); the http Location is expressed as:
Location:http://play3.com/live/stream.flvsecret=xxx&expireTime=yyy(7)。
8. the method of claim 7, wherein the http pull stream source request is redirected back to the target source address by http 302.
9. The method for switching multiple source stations in a live broadcast system according to claim 1, wherein the cross-zone data interaction in the sixth step is implemented after the source stations are switched by data, and the cross-zone data interaction causes interaction of live broadcast streams.
10. The method for switching multiple sources of a live broadcast system according to claim 1, wherein the audio and video data of the source-returning in the seventh step is implemented by switching interactive live broadcast streams through uplink push stream switching and downlink source-returning switching.
CN202311700599.5A 2023-12-12 2023-12-12 Method for switching multiple source stations of live broadcast system Pending CN117857856A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311700599.5A CN117857856A (en) 2023-12-12 2023-12-12 Method for switching multiple source stations of live broadcast system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311700599.5A CN117857856A (en) 2023-12-12 2023-12-12 Method for switching multiple source stations of live broadcast system

Publications (1)

Publication Number Publication Date
CN117857856A true CN117857856A (en) 2024-04-09

Family

ID=90531098

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311700599.5A Pending CN117857856A (en) 2023-12-12 2023-12-12 Method for switching multiple source stations of live broadcast system

Country Status (1)

Country Link
CN (1) CN117857856A (en)

Similar Documents

Publication Publication Date Title
US10609101B2 (en) Streaming of segmented content
EP1252575B1 (en) A system and method for rewriting a media resource request and/or response between origin server and client
US10516717B2 (en) Network-initiated content streaming control
EP3595268B1 (en) Streaming media resource distribution method, system, edge node and central dispatching system
EP2897340B1 (en) Routing proxy for adaptive streaming
TWI580237B (en) Unicast abr streaming
US9158769B2 (en) Systems and methods for network content delivery
EP2104287B1 (en) A method for client node network topology construction and a system for stream media delivery
US20010029525A1 (en) Method of utilizing a single uniform resource locator for resources with multiple formats
US20020023164A1 (en) Method and apparatus for client-side authentication and stream selection in a content distribution system
US20020042817A1 (en) System and method for mirroring and caching compressed data in a content distribution system
US20020040404A1 (en) System and method for performing broadcast-enabled disk drive replication in a distributed data delivery network
RU2647654C2 (en) System and method of delivering audio-visual content to client device
EP1806870B1 (en) Method for providing data and data transmission system
KR20200051696A (en) Data distribution method and distribution server
US11909844B2 (en) Packet processing of streaming content in a communications network
CN117857856A (en) Method for switching multiple source stations of live broadcast system
CN112788050A (en) System and method for realizing low-delay live broadcast based on content distribution network
Bouten et al. An autonomic delivery framework for HTTP adaptive streaming in multicast-enabled multimedia access networks
US20230412661A1 (en) Providing transparent multicast content via mobile telecommunication network
US20240187499A1 (en) Packet processing of streaming content in a communications network
JP2024504885A (en) Systems, methods, and computer-readable media for streaming data access

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