CN118055262A - Multicast live broadcast method and system - Google Patents
Multicast live broadcast method and system Download PDFInfo
- Publication number
- CN118055262A CN118055262A CN202410200245.2A CN202410200245A CN118055262A CN 118055262 A CN118055262 A CN 118055262A CN 202410200245 A CN202410200245 A CN 202410200245A CN 118055262 A CN118055262 A CN 118055262A
- Authority
- CN
- China
- Prior art keywords
- multicast
- playing
- rtp
- data packet
- rtc
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 24
- 239000000872 buffer Substances 0.000 claims description 13
- 230000002159 abnormal effect Effects 0.000 claims description 7
- 230000008569 process Effects 0.000 claims description 7
- 230000003139 buffering effect Effects 0.000 claims description 5
- 230000001360 synchronised effect Effects 0.000 abstract description 6
- 230000005540 biological transmission Effects 0.000 description 7
- 230000006870 function Effects 0.000 description 5
- 239000003795 chemical substances by application Substances 0.000 description 3
- 239000012634 fragment Substances 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000007429 general method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention provides a multicast live broadcast method and a system, wherein the method comprises the following steps: the multicast server outputs a multicast RTP data packet; the RTC unicast server receives the multicast RTP data packet output by the multicast server for caching and establishes a key frame index; when a playing end performs live broadcast, firstly, data is requested from an RTC unicast server end through unicast, after key frame data is obtained, quick start is performed, and after a period of time of broadcast, RTP data packets are obtained from a multicast network; when the playing end detects that a data packet is lost or multicast is interrupted, the playing end uses the RTC unicast to perform data compensation, so that the live broadcasting stability is ensured, and meanwhile, the playing end provides a frame tracking function, so that the pictures are consistent when different playing ends play the same channel. By adopting the technical scheme of the invention to carry out multicast live broadcast, the time delay is low, the reliability is high, the played content is synchronous, and the user experience is good.
Description
Technical Field
The invention relates to the technical field of broadcast television, in particular to a multicast live broadcast method and system with low time delay, high reliability and synchronous play.
Background
In the field of broadcasting and television, with the continuous advance of bidirectional and optical fiber transformation of a broadcasting and television network, the IP live broadcast service of the broadcasting and television network also develops rapidly, and becomes one of the most important services of future broadcasting and television. Currently, the mainstream IP live broadcast technology includes HLS (HTTP Live Streaming) live broadcast and multicast live broadcast.
HLS live broadcast cuts TS video stream into small fragments, and the TS fragments are continuously downloaded in an HTTP progressive mode to realize live broadcast. The live broadcasting mode has larger delay, and generally needs 3-4 fragments of delay, and the delay is more than 10S. HLS live broadcast is a unicast mode, and when the concurrency of users increases, a large amount of bandwidth resources and server resources are consumed.
The multicast live broadcast adopts a multicast protocol, and audio and video data is directly copied to an OLT (optical LINE TERMINAL) at the edge through network equipment, so that the transmission efficiency is improved, the bandwidth of a backbone network and the occupation of a server are reduced, and the multicast live broadcast is a better live broadcast mode. There are two general methods for multicast live broadcast at present:
the first is that multicast content is RTP (Real-time Transport Protocol, real-time transmission protocol) data, forward error correction is realized by adopting FEC, and fast start-up and channel switching after key frame data are acquired by adopting an out-of-band FCC unicast server. The method adopts FEC to correct errors and compensates for packet loss to a certain extent, but under the condition of higher packet loss rate, the method can not recover, so that mosaics are played; meanwhile, when the multicast network is abnormal, live broadcast is interrupted.
Second, multicast content is HLS slice, while an HLS unicast server is deployed as a reliability supplement to multicast. When live broadcast, the player initiates a request to the HLS service agent of the terminal through the HLS protocol, the HLS service agent downloads TS slices to the HLS unicast server, then switches to multicast received data, assembles the HLS slices through the multicast data, and when the multicast network is abnormal, the HLS service agent is seamlessly switched to the HLS unicast server for downloading, thereby realizing a reliable multicast mode. The method adopts an HLS playing protocol, which results in large live broadcast delay.
The first multicast live broadcast mode has insufficient reliability, and unicast cannot be switched when the multicast network is abnormal. In the second multicast live broadcast mode, the playing end adopts the HLS protocol, the live broadcast time delay is larger, and the experience effect is poor.
The two multicast modes cannot ensure that pictures played by a plurality of playing ends are consistent for the same channel, synchronization of played contents cannot be realized, and the pictures seen by different playing ends are prior and later, so that user watching experience is poor.
Disclosure of Invention
The invention aims to provide a multicast live broadcast method and a system with low time delay, high reliability and synchronous playing, aiming at the technical problems of insufficient reliability, large time delay and asynchronous playing of the multicast live broadcast method in the prior art.
In an embodiment of the present invention, there is provided a multicast live broadcast method, including:
The multicast server outputs a multicast RTP data packet;
the RTC unicast server receives the multicast RTP data packet output by the multicast server for caching and establishes a key frame index;
When a playing end performs live broadcast, firstly, data is requested from an RTC unicast server through unicast, key frame data is obtained and then quickly started, then, after a period of time, the playing end switches to multicast, and RTP data packets are obtained from the multicast;
when the playing end detects that a data packet is lost or multicast is interrupted, requesting data from the RTC unicast server end to perform data compensation;
when the playing end plays, the playing data in the buffer memory is detected and frame tracking is carried out, so that the played data is kept at a constant time.
In the embodiment of the invention, the RTC unicast server receives the multicast RTP data packet output by the multicast server for caching and establishes a key frame index, and the method comprises the following steps:
adding multicast, and connecting RTP data packets sent by a multicast server;
Analyzing the RTP data packet to obtain the sequence number of the RTP data packet;
analyzing the RTP data packet, obtaining key frame information, and establishing an index;
And establishing an RTP buffer queue for buffering the RTP data for the latest period of time.
In the embodiment of the invention, the playing end requests data from the RTC unicast server end in the following modes:
request an RTP data packet specifying an RTP sequence number;
request to specify RTP data packet that RTP sequence number begins; and
The request specifies the RTP packet at the beginning of the key frame.
In the embodiment of the invention, the process of the playing end tracking frames comprises the following steps:
Periodically checking the cache time length;
judging whether the cache time length exceeds a set threshold value;
if the cache duration exceeds the set threshold, calculating the timeout duration T1;
by T1, a play time length T2 for playing at X times the normal play speed is calculated,
T2＝T1÷(X-1)；
And starting X-time speed playing, and after playing for T2 time, resuming normal speed playing.
In the embodiment of the invention, when the playing end performs live broadcast playing, the RTC unicast server end starts to send RTP data packets from the key frames, and after a period of time, the playing end joins multicast and switches to multicast playing.
In an embodiment of the present invention, there is also provided a multicast live broadcast system, including:
a multicast server, an RTC unicast server and a play end,
The multicast service end is used for outputting multicast RTP data packets;
the RTC unicast server is used for receiving the multicast RTP data packet output by the encoder, caching the multicast RTP data packet and establishing a key frame index;
The playing end is used for receiving the RTP data packet and playing the RTP data packet in a live broadcast mode, when the playing end plays the live broadcast mode, firstly, data is requested from the RTC unicast server end through unicast, after key frame data are obtained, the playing end is started quickly, then, after playing for a period of time, the playing end is switched to multicast, and the RTP data packet is obtained from multicast;
When the playing end detects that a data packet is lost or multicast is interrupted, requesting data from the RTC unicast server end to perform data compensation;
When the playing end plays, the playing data in the buffer memory is detected and frame tracking is carried out, so that the played data is kept at a constant time.
In the embodiment of the present invention, the RTC unicast server receives a multicast RTP packet output by a multicast server, buffers the multicast RTP packet, and establishes a key frame index, including:
adding multicast, receiving RTP data packet sent by multicast server;
Analyzing the RTP data packet to obtain the sequence number of the RTP data packet;
analyzing the RTP data packet, obtaining key frame information, and establishing an index;
And establishing an RTP buffer queue for buffering the RTP data for the latest period of time.
In the embodiment of the present invention, the playing end requests data from the RTC unicast server end, including the following modes:
request an RTP data packet specifying an RTP sequence number;
request to specify RTP data packet that RTP sequence number begins; and
The request specifies the RTP packet at the beginning of the key frame.
In the embodiment of the invention, the process of frame tracking by the playing end comprises the following steps:
Periodically checking the cache time length;
judging whether the cache time length exceeds a set threshold value;
if the cache duration exceeds the set threshold, calculating the timeout duration T1;
by T1, a play time length T2 for playing at X times the normal play speed is calculated,
T2＝T1÷(X-1)；
And starting X-time speed playing, and after playing for T2 time, resuming normal speed playing.
In the embodiment of the invention, when the playing end performs live broadcast playing, the RTC unicast server end starts to send RTP data packets from the key frames, the playing end joins multicast after playing for a period of time, switches to multicast playing, and performs data compensation by using RTC unicast when packet loss occurs in multicast or multicast is abnormal.
Compared with the prior art, the technical scheme of the invention has the advantages that the live broadcasting time delay is low, the multicast and the unicast are both transmitted by UDP, the transmitted content is RTP packets, the transmission efficiency is high, the playing end can play after obtaining the RTP packets, and meanwhile, the playing end has the frame tracking function, the playing time delay can be further reduced, and the live broadcasting time delay is within 1 second; the multicast live broadcast is reliable, when packet loss occurs in multicast receiving and multicast network is abnormal, the RTC unicast is used for compensation, and live broadcast watching is not influenced; the multi-player terminal plays the picture synchronization, the player terminal has the function of chasing frames, and when a plurality of players play the same channel, the play pictures are synchronous, and the user watching experience is good.
Drawings
Fig. 1 is a schematic structural diagram of a multicast live broadcast system according to an embodiment of the present invention.
Fig. 2 is a schematic diagram of the structure of an RTP packet according to an embodiment of the invention.
Fig. 3 is a schematic flow chart of receiving, by the RTC unicast server, a multicast RTP packet output by the multicast server according to an embodiment of the present invention.
Fig. 4 is a flowchart of the operation of the playback end according to the embodiment of the present invention.
Fig. 5 is a flowchart of a playback end chase frame according to an embodiment of the present invention.
Detailed Description
The present invention will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present invention more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
The implementation of the present invention is described in detail below in connection with specific embodiments.
As shown in fig. 1, in an embodiment of the present invention, a multicast live broadcast system is provided, which includes a multicast server, an RTC unicast server, and a play end. The following description will be given separately.
The multicast server is used for outputting multicast RTP data packets.
It should be noted that, the RTP protocol is one of the most common protocols in the video transmission field, and the RTC unicast server and the playing end join in a multicast group, so that RTP data output by the multicast server can be received.
As shown in fig. 2, the structure of the RTP packet includes a header and a packet body, the header is 12 bytes, and the packet body length is UDP data except the header, and is generally 7 TS packets, namely 1316 bytes. The RTP data packet head has 2 byte serial number, the serial number is continuously increased, and the serial number is circulated after reaching the maximum value, which is the basis of packet loss retransmission, multicast and unicast switching.
The RTC unicast server is used for receiving the multicast RTP data packet output by the multicast server, caching the multicast RTP data packet and establishing a key frame index.
The RTC unicast server adopts RTC (Real-Time Communication ) unicast, which uses UDP as a transmission protocol of the bottom layer, and has high transmission efficiency and low delay. In the embodiment of the invention, the employable RTC unicast protocol includes SRT protocol, webRTC protocol and quit protocol, which is not limited in the invention.
As shown in fig. 3, in the embodiment of the present invention, a process of receiving, by the RTC unicast server, a multicast RTP packet output by the multicast server includes:
Adding multicast, and receiving RTP data packets sent by the multicast server;
Analyzing the RTP data packet to obtain the sequence number of the RTP data packet;
analyzing the RTP data packet, obtaining key frame information, and establishing an index;
An RTP buffer queue is established to buffer the latest RTP data for a period of time (such as 5 seconds).
And the playing end is used for receiving the RTP data packet and playing the RTP data packet in a live mode. As shown in fig. 4, when the playing end performs live broadcast, firstly, data is requested from the RTC unicast server end through unicast, after key frame data is obtained, the playing is started quickly, after M seconds (e.g. 2 seconds) of playing, the playing end joins in multicast, and starts to receive multicast data. When the playing end detects that a data packet is lost or multicast is interrupted, the RTC unicast is utilized to compensate the data. It should be noted that, the playing end is usually disposed at a far end of the multicast network, and there may be a situation that the data packet is lost or the multicast is interrupted during the process of receiving the multicast RTP data packet due to the network.
In the embodiment of the present invention, the playing side requests data from the RTC unicast server side, including the following three modes. The following description will be given separately.
First kind: the request specifies the RTP data packet of RTP sequence number, this request is applicable to the case of data packet loss, the request format is as follows:
rtc://192.168.0.1:9002/cctv1rtp＝1,2,4，
Where rtp=1, 2,4 means that only three RTP packets with RTP packet numbers 1,2,4 are requested.
And after the RTC unicast server receives the first request, the RTC unicast server only transmits RTP data packets with specified sequence numbers.
Second kind: the request specifies the RTP data packet from which the RTP sequence number starts, and the request is applicable to the case of multicast interruption, and the request format is as follows:
rtc://192.168.0.1:9002/cctv1rtp＝5-，
wherein rtp=5-, means that the request is from RTP packet with RTP sequence number 5 and the following RTP packets.
And after the RTC unicast server receives the second request, starting from the appointed RTP data packet sequence number, and always transmitting data.
Third kind: the request specifies the RTP packet at the beginning of the key frame, and this request is applicable to the case of starting live broadcast just before, and the format of the request is as follows:
rtc://192.168.0.1:9002/cctv1？
The RTP parameter is not carried and indicates that the RTP packet starts from the key frame.
And after the RTC unicast server receives the third request, the RTC unicast server always transmits data from the key frame RTP data packet.
Further, after receiving the RTC unicast for a period of time (e.g., 2S), the playing end starts to join in the multicast, and receives the multicast RTP packet, and if the sequence number of the first multicast RTP packet is N1, the RTC unicast stops the RTC unicast after receiving the RTP packet of N1, and switches to multicast reception.
When the playing end plays, the playing data in the buffer memory is detected and frame tracking is carried out, so that the played data is kept at a constant time. The frame tracking function can enable the playing frames to be synchronous when a plurality of playing ends play the same channel, and the user watching experience is good. As shown in fig. 5, the following frame tracking process of the playing end is as follows:
Periodically checking the cache time length;
judging whether the cache time length exceeds a set threshold value;
if the cache duration exceeds the set threshold, calculating the timeout duration T1;
Calculating a play duration T2 at X times (X is a set multiple, and X is more than 1, such as 1.5 times) speed through T1, wherein T2=T1/X-1;
and starting X-time speed playing, and after playing for T2 time, resuming normal speed playing.
In summary, by adopting the technical scheme of the invention, both multicast and unicast are transmitted by adopting UDP, the transmitted content is RTP packet, the transmission efficiency is high, the playing end can play after obtaining the RTP packet, and meanwhile, the playing end has the frame tracking function, the live broadcast time delay is low, and the live broadcast time delay is within 1 second. The multicast live broadcast is reliable, when packet loss occurs in multicast receiving and multicast network is abnormal, the RTC unicast is used for compensation, and live broadcast watching is not influenced. The multi-player terminal plays the picture synchronization, the player terminal has the function of chasing frames, and when a plurality of players play the same channel, the play pictures are synchronous, and the user watching experience is good.
The foregoing description of the preferred embodiments of the invention is not intended to be limiting, but rather is intended to cover all modifications, equivalents, and alternatives falling within the spirit and principles of the invention.
Claims (10)
1. A method of multicasting a live broadcast, comprising:
The multicast server outputs a multicast RTP data packet;
the RTC unicast server receives the multicast RTP data packet output by the multicast server for caching and establishes a key frame index;
When a playing end performs live broadcast, firstly, data is requested from an RTC unicast server through unicast, key frame data is obtained and then quickly started, then, after a period of time, the playing end switches to multicast, and RTP data packets are obtained from the multicast;
when the playing end detects that a data packet is lost or multicast is interrupted, requesting data from the RTC unicast server end to perform data compensation;
when the playing end plays, the playing data in the buffer memory is detected and frame tracking is carried out, so that the played data is kept at a constant time.
2. The method of multicasting live broadcast of claim 1, wherein the RTC unicast server receives and buffers the multicast RTP packet output by the multicast server and establishes the key frame index, comprising:
adding multicast, and connecting RTP data packets sent by a multicast server;
Analyzing the RTP data packet to obtain the sequence number of the RTP data packet;
analyzing the RTP data packet, obtaining key frame information, and establishing an index;
And establishing an RTP buffer queue for buffering the RTP data for the latest period of time.
3. The method for multicasting live broadcast of claim 1, wherein the playing side requests data from the RTC unicast server side by:
request an RTP data packet specifying an RTP sequence number;
request to specify RTP data packet that RTP sequence number begins; and
The request specifies the RTP packet at the beginning of the key frame.
4. The method of multicasting direct broadcasting according to claim 1, wherein the process of broadcasting end chase frame includes:
Periodically checking the cache time length;
judging whether the cache time length exceeds a set threshold value;
if the cache duration exceeds the set threshold, calculating the timeout duration T1;
Calculating a play time length T2 of playing at X times of a normal play speed through T1, wherein T2=T1/X-1;
and starting X-time speed playing, and after playing for T2 time, resuming normal speed playing.
5. The method of claim 1, wherein the RTC unicast server transmits RTP packets from the key frames when the playing end performs the live broadcast, and the playing end joins the multicast after a period of time, and switches to the multicast play.
6. A multicast live broadcast system, comprising
A multicast server, an RTC unicast server and a play end,
The multicast service end is used for outputting multicast RTP data packets;
the RTC unicast server is used for receiving the multicast RTP data packet output by the encoder, caching the multicast RTP data packet and establishing a key frame index;
The playing end is used for receiving the RTP data packet and playing the RTP data packet in a live broadcast mode, when the playing end plays the live broadcast mode, firstly, data is requested from the RTC unicast server end through unicast, after key frame data are obtained, the playing end is started quickly, then, after playing for a period of time, the playing end is switched to multicast, and the RTP data packet is obtained from multicast;
When the playing end detects that a data packet is lost or multicast is interrupted, requesting data from the RTC unicast server end to perform data compensation;
When the playing end plays, the playing data in the buffer memory is detected and frame tracking is carried out, so that the played data is kept at a constant time.
7. The multicast live broadcast system of claim 6, wherein the RTC unicast server receiving the multicast RTP packet output by the multicast server for buffering and establishing a key frame index comprises:
adding multicast, receiving RTP data packet sent by multicast server;
Analyzing the RTP data packet to obtain the sequence number of the RTP data packet;
analyzing the RTP data packet, obtaining key frame information, and establishing an index;
And establishing an RTP buffer queue for buffering the RTP data for the latest period of time.
8. The multicast live broadcast system of claim 6, wherein the playing side requests data from the RTC unicast server side by:
request an RTP data packet specifying an RTP sequence number;
request to specify RTP data packet that RTP sequence number begins; and
The request specifies the RTP packet at the beginning of the key frame.
9. The multicast live broadcast system of claim 6, wherein the process of playing the end chase frame comprises:
Periodically checking the cache time length;
judging whether the cache time length exceeds a set threshold value;
if the cache duration exceeds the set threshold, calculating the timeout duration T1;
Calculating a play time length T2 of playing at X times of a normal play speed through T1, wherein T2=T1/X-1;
and starting X-time speed playing, and after playing for T2 time, resuming normal speed playing.
10. The multicast live broadcast system of claim 6, wherein the RTC unicast server transmits RTP packets from the key frames when the playing end performs live broadcast, the playing end joins the multicast after playing for a period of time, switches to multicast play, and performs data compensation by using the RTC unicast when packet loss occurs in the multicast or the multicast is abnormal.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410200245.2A CN118055262A (en) | 2024-02-23 | 2024-02-23 | Multicast live broadcast method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410200245.2A CN118055262A (en) | 2024-02-23 | 2024-02-23 | Multicast live broadcast method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN118055262A true CN118055262A (en) | 2024-05-17 |
Family
ID=91047870
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410200245.2A Pending CN118055262A (en) | 2024-02-23 | 2024-02-23 | Multicast live broadcast method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118055262A (en) |
-
2024
- 2024-02-23 CN CN202410200245.2A patent/CN118055262A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2369840B1 (en) | Channel switching method, device and system | |
| EP1869887B1 (en) | Milestone synchronization in broadcast multimedia streams | |
| JP5363473B2 (en) | Method and apparatus for improved media session management | |
| US9344682B2 (en) | Multi-media management | |
| US8255555B2 (en) | Reception apparatus and method for reducing time delay in channel switching | |
| CN108696772B (en) | Real-time video transmission method and device | |
| EP1694030A1 (en) | Multimedia content delivery system | |
| EP2191666B1 (en) | Access network handover for a mobile television system | |
| US8325589B2 (en) | Access network handover for a mobile television system | |
| EP2101500A1 (en) | A video on demand controlling method, a client device and a switch controlling equipment | |
| EP2466911B1 (en) | Method and device for fast pushing unicast stream in fast channel change | |
| CN113014586B (en) | RTP data packet out-of-order processing and framing method and system | |
| US8959240B2 (en) | Method, apparatus and system for rapid acquisition of multicast realtime transport protcol sessions | |
| CN108370281B (en) | Data rate adaptation for multicast delivery of streaming content | |
| MX2011012652A (en) | Method, apparatus and system for reducing media delay. | |
| WO2010114450A1 (en) | Methods and arrangements for channel change in an iptv network | |
| US20120117265A1 (en) | Method and communication system for implementing stream services, and relevant device | |
| US8811478B2 (en) | Data transmission method and apparatus | |
| Okerman et al. | Fast startup multicast streaming on operator iptv networks using hesp | |
| CN118055262A (en) | Multicast live broadcast method and system | |
| WO2011095118A1 (en) | Method, apparatus and system for processing network time shift | |
| CN111093090A (en) | TCP-based multicast channel fast switching system and method | |
| WO2018041092A1 (en) | Multimedia resource synchronous pushing method based on heterogeneous network | |
| CN114786029B (en) | Intelligent set top box and live channel switching method | |
| JP2001148717A (en) | Data server device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination |