CN101212406A - Multicast Channel Quick Start System - Google Patents

Abstract

The invention discloses a system for quickly starting a multicast channel, comprising: a streaming server, a head end and at least one player, wherein the head end generates or transfers media data of the channel and sends it; the player is provided with a buffer for playing The media data; the stream server is provided with a historical buffer, and the historical buffer stores a historical code stream; receives the code stream sent by the head end and stores it in the historical buffer, when the stream server receives After the multicast request of the player, the stream server fills the historical code stream of the historical buffer into the buffer of the player in unicast mode, and when the player joins the multicast group, the The stream server stops sending the unicast code stream; the player receives the multicast code stream after joining the multicast group, and splices the multicast code stream and the unicast code stream. The present invention effectively improves the playback start-up speed, realizes the quick start of the playback of the multicast channel, and improves user experience.

Description

Multicast Channel Quick Start System

technical field

The invention relates to a streaming media technology, in particular to a system and method for quickly starting a multicast channel.

Background technique

In an existing streaming media channel system, the headend, streaming server and player are the most basic components. Usually, the TCP/IP protocol is used to transfer the code stream and signaling, and the player and the streaming server are exchanged using the RTSP protocol. Signaling, carrying payloads in formats such as RTP or TS on top of UDP or TCP protocols, and transmitting media data. In general, UDP is more commonly used than TCP.

Multicast is a kind of UDP. Due to history and many existing networks cannot support multicast well, when the network cannot support multicast protocol, the stream server can only receive the code stream sent by the head end, and then pass TCP The protocol or the point-to-point UDP protocol is distributed to each player. The process of distributing the code stream to one of the players is called unicast. In an IPTV channel system, unicast is one of the most basic functions of a streaming server.

Multicast is a protocol for sending the same data from a single point to multiple points in the TCP/IP protocol. The sender only needs to send a multicast UDP packet to the multicast IP address, and then the router on the network will distribute and copy the data to Interested receivers, regardless of the number of receivers, the workload of the sender is constant, and at the same time, the design of the multicast protocol can minimize the amount of data transmitted on the network. This feature makes multicast very suitable for the transmission of channel data.

If the network supports the multicast protocol, the player can directly receive the multicast stream sent by the headend by joining the multicast group, thereby greatly reducing the workload of the streaming server and network traffic. Since the code stream is transmitted through multicast, no stream server is required to participate in the middle, which reduces a point of failure and improves the reliability of the system.

As shown in Figure 1, the multicast channel subsystem is a subsystem of the streaming media channel system. Generally speaking, logically, there is no streaming server involved, and it only consists of a headend and a number of players. Without signaling interaction capabilities, the headend can only send code streams in an inherent way according to the requirements of the media encoding method. For example, according to a certain time interval, the I-frame data of the video media is sent regularly. When the headend sends the media stream, the direction of data transmission is one-way, from the headend to the player.

The client is manipulated by the user, and may join the multicast receiving code stream at any point in time, so the starting point of the received code stream is random.

And quite a few encoding methods, especially video encoding methods, must receive a complete key frame (for example, the I frame of video encoding), and its decoding result is complete and correct. The code stream received before receiving the key frame cannot be completely decoded correctly, either it can only be discarded, or it is decoded forcibly, but the decoded data is wrong. For the video, there will be abnormal phenomena such as mosaic or pause, and the same affect user experience.

It takes a period of time from the start of receiving data to the reception of the code stream of the key frame. This period is called the key frame waiting time. The key frame waiting time depends on the key frame sending frequency, and the average value is 1/2 of the key frame sending interval.

At the same time, in order to prevent transmission jitter, the client generally sets a buffer. It needs to save the received code stream in the buffer first. When the buffer is filled to a certain size, the media data is taken out from the buffer, decoded and played. . The filling of this buffer also takes a period of time, which is called the buffer filling time.

At the same time, it also takes a period of time from the player joining the multicast group to receiving the multicast packet. This period of time is called the time to join the multicast, and the time to join the multicast depends on the network structure. Under certain network structures or environments, this time may be very long.

In an IPTV channel system with a code rate greater than 1 Mbps, the key frame sending interval is often set to about 2 seconds, and the buffer filling time is also about 2 seconds. That is to say, from the time when the user starts ordering a channel to watching the program normally, it takes an average of about 3 seconds of waiting time, excluding the time to join the multicast. When people watch TV, the waiting time they can tolerate when switching channels is often within 1 second, so it is necessary to adopt some technical solutions to improve the playback start-up speed and improve user experience.

Most of the players have set the maximum waiting time. If the multicast packet is not received within the specified time, the playback will be considered as a failure and the playback will be stopped. In some special cases, the time to join the multicast is greater than the maximum waiting time, which may also cause playback failure.

In the patent application with the application number CN200410069507, some technical solutions for improving the switching speed of multicast channels are mentioned. The core of the method is when the user terminal leaves the current multicast channel, according to the location information accessed by the user terminal, it is judged whether there are other user terminals connected to the location information under the multicast channel, and according to the judgment As a result, the multicast replication table of the corresponding multicast channel is maintained. Its purpose is to solve the problem of long switching time when the player switches from one multicast channel to another. It works at the level of network equipment and does not solve the aforementioned problems.

Contents of the invention

The technical problem solved by the invention is to provide a multicast channel quick start system, which improves the playback start speed and realizes quick start of multicast channel playback.

The technical solution is as follows:

The multicast channel quick start system includes: a head end and at least one player, wherein,

The headend generates or transfers the media data of the channel and sends it;

The player is provided with a buffer for playing the media data;

The streaming server is provided with a historical buffer, and the historical buffer stores a historical code stream; receives the code stream sent by the head end and saves it in the historical buffer, when the stream server receives the player's After the multicast request, the streaming server fills the buffer of the player with the historical code stream of the historical buffer in unicast mode, and when the player joins the multicast group, the streaming server stops sending unicast broadcast stream;

After the player joins the multicast group, it receives the multicast code stream, and splices the multicast code stream and the unicast code stream.

Preferably, the stream server sends the code stream in TCP mode.

Preferably, when the history buffer is exhausted, the stream server sends a fast sending end notification to the player.

Preferably, the player fills the buffer with RTP received by the unicast channel and the multicast channel, and filters received duplicate RTP packets before filling.

Preferably, after the player joins the multicast group, it receives the multicast code stream.

Preferably, the stream server fills the buffer of the player with the historical code stream in a unicast manner starting from a key frame of the historical code stream in the historical buffer.

The technical effect is as follows:

The present invention solves the problem of slow playback start-up speed caused by the accumulation of key frame waiting time, buffer time and multicast joining time, effectively improves the playback start-up speed, realizes the quick start of multicast channel playback, and improves the user experience. At the same time, the present invention can also effectively prevent accidental errors, such as playing failures caused by joining the multicast for too long.

In the fast sending unicast stage, the TCP protocol is used, which can prevent excessive network traffic and packet loss caused by communication link congestion; The player receives the multicast packet to prevent the gap between the two code streams from being spliced; after the fast sending is over, the player is allowed to join the multicast to prevent the addition of the multicast code stream during the fast sending stage, which further stimulates the communication The link is congested.

The player will join the multicast group after receiving the fast sending end mark sent by the streaming server, so as to shorten the unicast time of the streaming server as much as possible, that is, reduce the workload of the streaming server as much as possible; after receiving the multicast packet, notify the streaming server as soon as possible to stop the unicast broadcast to minimize the overlapping transmission time of unicast and multicast streams on the communication link. The stream server can choose to start sending from the key frame from the historical code stream, and the player can decode and play the code stream after receiving the code stream, and the key frame waiting time is reduced to 0.

When the player notifies the stream server to stop unicast, it attaches the marked information of the media package. The stream server can judge whether all the media packages have been sent between the media packages. If not, it will continue to send until the notification specified Up to the media package, it is guaranteed that unicast and multicast streams can be seamlessly spliced together. Regardless of the length of time the player joins the multicast, it will not affect the player's normal playback of the multicast channel, and the impact of the joining time on the playback start-up speed is reduced to zero.

The invention can also solve the occasional play failure abnormality caused by the player joining the multicast for a long time and exceeding the maximum waiting time of the player.

Description of drawings

Fig. 1 is a structural diagram of a multicast channel system in the prior art;

Fig. 2 is a structural diagram of the multicast channel system adopted by the present invention;

Fig. 3 is a basic flowchart of the method of the present invention.

Detailed ways

The preferred embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings.

As shown in Figure 2, a multicast channel system consists of a headend, a streaming server and a number of different players. The headend and the streaming server are logically two entities, which can be two different physical entities or the same physical implementation. The streaming server continuously receives streams from the headend in real time and saves them in its own history buffer.

The headend is responsible for generating or transferring the media data of the channel, and sending it to different client devices, without signaling interaction with the player.

A player is a device with a buffer, manipulated by the end user, that receives and plays media data. For IPTV, it is more called a set-top box (STB).

The streaming server is an entity that provides personalized streaming media services for different users or players through signaling interaction. In the present invention, the streaming server is provided with a history buffer, and provides personalized streaming media services for different users or players through signaling interaction. The history buffer area saves the historical code stream. When the stream server receives the player’s multicast request, the stream server starts from the key frame of the historical code stream in the historical buffer and fills the historical code stream into the player’s buffer. After the player joins the multicast group, the streaming server stops sending unicast streams.

The process is as follows:

Step 1: The user manipulates the player to choose to play a certain multicast channel.

Step 2: The player sends a request to play the multicast channel to the streaming server.

Step 3: The stream server sends the historical code stream quickly.

The stream server selects a part or all of the code streams from the historical code streams in the buffer, and sends the unicast code streams to the player who ordered the channel in a fast sending mode. The code streams to be sent quickly start from a certain point in history , to the most recently received continuous stream.

In the streaming media system, the code stream sent by the headend or the streaming server should meet the requirements of the player to play media during this period of time. If the sending rate does not match the demand within a short period of time, it is generally called rate blocking. If the sending rate continuously exceeds the playback requirement for a long period of time, it is called fast sending.

In this step, the streaming server can optionally use other methods to further optimize the effect, including:

The code stream is sent in TCP mode, instead of the UDP transmission protocol commonly used in streaming media applications. Use the best-effort method to send the historical code stream at the fastest possible rate, complete the filling of the player buffer in the shortest time at the maximum rate allowed by the communication link, and fill the buffer Time is compressed to a minimum. Retrieve the historical code stream and send it from the beginning of the key frame.

Step 4: The streaming server sends a quick sending end notification to the player.

Because the sending rate of fast sending is greater than the normal sending rate of the headend, that is, the rate at which the streaming server receives the bitstream from the headend and fills the historical bitstream buffer, the historical buffer will eventually be exhausted.

When the history buffer is exhausted, the streaming server sends a fast sending end notification to the player.

At this step, a number of different simple transform methods are possible, including:

A short period of time before the history buffer is exhausted or a long period of time after the end of the fast sending notification; or, the streaming server notifies the player of the number of fast sending that it will send according to the previous signaling interaction. The amount of data received, calculate the end point of the fast transmission by itself; or, the player calculates the end point of the fast transmission according to the received rate.

Step 5: The player joins the multicast group before and after the end point of the fast sending;

Step 6: The streaming server sends the unicast stream at the normal rate:

After the fast sending is over, the stream server sends the code stream to the player while receiving it from the head end.

This step may be skipped if the following steps are executed quickly.

Step 7: After the player receives the multicast packet, it notifies the stream server to stop sending the unicast stream.

In this step, the player can go one step further, and include the marking information of the media packet received from the multicast in the notification, for example, the marking information can be an RTP packet number or a time stamp, and the like.

Step 8: After receiving the stop notification, the streaming server stops sending unicast streams.

If the marked information of the media packet is attached to the notification, the stream server can go further and judge whether all the media packets between the media packets have been sent by judging and comparing the RTP packet sequence number or the size of the time stamp. , continue sending until the media package specified in the notification.

The streaming server needs to receive the multicast stream from the player before it can stop sending unicast. Therefore, no matter how long the player has joined the multicast, it will not affect the player’s normal playback of the multicast channel. The effect of playback start speed is reduced to 0.

Step 9: The player splices the streams received from the streaming server and multicast into a single stream for playback.

As shown in FIG. 3 , in an IPTV system, the method of the present invention can improve the startup speed of the player when ordering channels.

This IPTV system consists of three basic entities: a headend, a streaming server, and a player (also known as a set-top box). The head end and streaming server are connected to the network through Gigabit Ethernet, the set-top box is connected to the network through 4Mbps ADSL, and the entire network uses TCP/IP protocol.

The media is audio and video data, in which the audio is encoded in AAC mode. AAC encoding does not require key frames, and the decoder can decode it as soon as it receives the media packet; the video is encoded in MPEG4, and the decoder using MPEG4 must receive a complete I frame before it can be decoded. The follow-up media data decoding work is completely completed, and the key frame is an I frame. The transmission protocol of the code stream is RTP, and the information exchange protocol between the set-top box and the streaming server is RTSP.

The normal output bit rate of the head end is 1.5Mbps, and an I frame is sent every 2 seconds on average. The set-top box starts decoding and playing after the buffer is filled with 2 seconds of media data. The average time for the set-top box to join the multicast and receive the first multicast packet is 0.5 seconds.

Under the present method, when a set-top box requests a multicast channel, theoretically, it takes 3.5 seconds on average to start playing, and a minimum of 2.5 seconds to start playing. And adopt the method of the present invention, only need the buffer filling time of 1.5*2÷4=0.75 second in theory, can finish buffer filling work, start to play. In this embodiment, the measured results show that most of the on-demand start times are less than 1.0 second.

The process of a set-top box on-demand multicast channel is as follows:

1. The set-top box sends an RTSP DESCRIBE request to the streaming server;

2. The streaming server responds with RTSP 200 success;

3. The set-top box sends an RTSP SETUP request for the video track;

4. The streaming server responds with RTSP 200 success;

5. The set-top box sends an RTSP SETUP request for the audio track;

6. The streaming server responds with RTSP 200 success;

7. The set-top box sends an RTSP PLAY request for the audio track;

8. The streaming server responds with RTSP 200 success;

9. The stream server sends the fast-delivery unicast stream code through the TCP channel;

10. After the historical code stream is exhausted, the stream server notifies the set-top box that the fast sending is over through the RTSP SET_PARAMETER SpeedUp: End signaling;

11. After receiving the RTSP SET_PARAMETER Speed Up: End signaling, the set-top box responds to RTSP 200 successfully and joins the multicast group;

12. The stream server receives and transmits at the same time, and continues to send unicast streams to the set-top box at a normal rate through the TCP channel;

13. After receiving the multicast packet, the set-top box sends an RTSP PAUSE request, and in the request, attaches the Track ID corresponding to the received first multicast packet and the RTP sequence number of the RTP packet;

14. According to the Track ID and the RTP packet serial number, the stream server judges whether there are other RTP packets that have not been received and sent between this packet, and if so, stop sending immediately, otherwise continue to send until this packet;

15. After the stream server stops sending packets, it responds with RTSP 200 success;

16. The set-top box continues to receive multicast packets;

17. The set-top box fills the buffer with the RTP received from the unicast channel and the multicast channel, and filters the received duplicate RTP packets before filling;

18. When the buffer is filled to a sufficient size, take out the RTP packet from the buffer and send it to the decoder for decoding and playback.

Claims (6)

1. A multicast channel quick start system, comprising: a head end and at least one player, wherein, The headend generates or transfers the media data of the channel and sends it; The player is provided with a buffer for playing the media data; It is characterized in that it also includes: The streaming server is provided with a historical buffer, and the historical buffer stores a historical code stream; receives the code stream sent by the head end and saves it in the historical buffer, when the stream server receives the player's After the multicast request, the streaming server fills the buffer of the player with the historical code stream of the historical buffer in unicast mode, and when the player joins the multicast group, the streaming server stops sending unicast broadcast stream; After the player joins the multicast group, it receives the multicast code stream, and splices the multicast code stream and the unicast code stream. 2 . The multicast channel quick start system according to claim 1 , wherein the stream server sends code stream in TCP mode. 3 . 3. The multicast channel quick start system according to claim 1, characterized in that, when the history buffer is exhausted, the streaming server sends a quick sending end notification to the player. 4. The multicast channel quick start system according to claim 1, wherein the player fills the buffer with the RTP received by the unicast channel and the multicast channel, and filters the received repeated RTP packets. 5. The multicast channel quick start system according to claim 1, characterized in that, after the player joins the multicast group, it receives the multicast code stream. 6. The multicast channel quick start system according to claim 1, characterized in that, the stream server starts from the key frame of the historical code stream in the historical buffer, and fills the historical code stream into the playback channel in unicast mode buffer of the device.

Images