WO2011022983A1

WO2011022983A1 - Method, device and system of multi-cast video data

Info

Publication number: WO2011022983A1
Application number: PCT/CN2010/072463
Authority: WO
Inventors: 桑卓
Original assignee: 中兴通讯股份有限公司
Priority date: 2009-08-26
Filing date: 2010-05-05
Publication date: 2011-03-03
Also published as: CN101998143A; CN101998143B

Abstract

A method, device and system of multi-cast video data are disclosed. The method includes: a retransmission server receives the control requiring signaling for requiring the video data from the client, in which the control requiring signaling comprises the synchronization requiring information(S202); the retransmission server generates the synchronization responding information according to the synchronization requiring information and the stored video data from multi-cast server, in which the synchronization responding information comprises the parameters for controlling the play of the video data(S204); the retransmission server sends the video data and the control responding signaling with the synchronization responding information, in which, the control responding signaling comprises the synchronization responding information so that the client plays the video data according to the parameters in the synchronization responding information(S206). With the solution, it can avoid generating the error video data in the client, and make the video in the client play synchronously to improve the experience of the user.

Description

FIELD OF THE INVENTION The present invention relates to the field of communications, and in particular to a method, apparatus, and system for multicast video data. BACKGROUND OF THE INVENTION Rapid Acquisition of Multicast RTP Sessions (RAMS) for the Internet Engineering Task Force (IETF) Real-time Transport Protocol (RTP) The technical solution provides a method for a media client to quickly access multicast in an RTP multicast session. 1 is a structural block diagram of a system of a RAMS scheme of an IETF according to the related art, by which a delay time of a media client before joining an RTP multicast session can be reduced, such as Internet Protocol Television (IPTV). When a media client like this needs to frequently switch the streaming media multicast service of the multicast group, the media client using the RAMS scheme can quickly switch channels, reduce the waiting time for video picture playback, and improve the user body-risk. Since the media client must present the video picture from the random access point, in the traditional multicast video service, the video screen can be played in different media clients that join the multicast group at different times. The server generally uses a method of transmitting a fast access point in a fixed period. At the same time, in order to enable a client newly joining the multicast group to present a video picture more quickly, the above fixed period is short. The random access point of the video uses intraframe coding, and the encoding time and the encoded frame size are far larger than the normal frame using the interframe coding mode. Therefore, the time interval between the random access points of the video stream and the editing Decoding and transmission efficiency are inversely proportional. As shown in FIG. 1 , in the foregoing RAMS scheme, a retransmission server (Retransmission Server, referred to as RS) according to a request of an RTP receiver (RTP Receiver, RR for short) will access information (reference information, referred to as RI) is sent to the RR by unicast, and the RR parses the random access point of the streaming media from the received RI, and uses the random access point to receive video data from the retransmission server. And 4 bar of the video data is played to the user to watch. The video data received from the retransmission server is received and saved by the retransmission server from the multicast server in advance. There is a certain delay between the video data actually sent by the multicast server. Therefore, in the RAMS scheme, the random access point where the RR joins the multicast group for the first time is no longer received from the multicast address, but is obtained by the RI from the RS fast-transmitting. Therefore, the delay time of the first time the media client plays the picture is not It is affected by the length of the transmission period of the random access point of the video stream. Therefore, the RAMS can use the method of increasing the time interval between random access points without affecting the fast presentation of the video by the client newly joining the multicast group. The picture, which improves the codec and transmission efficiency. However, the time for different clients to access the same multicast group may not be the same. Thus, according to the RAMS method described above, the random access points of the video they parsed from the RI are different, which causes them to be different from the delay in which the video data actually transmitted by the multicast server is present (ie, they are respectively There is a delay difference in the delay of the video data actually sent by the multicast server, and this will result in different video images played by different clients at the same time. Moreover, the larger the time interval between adjacent random access points, the greater the difference in playback delay between clients. In streaming media multicast applications such as IPTV, video conferencing, and distance education, excessive delays between media clients can degrade the user experience, and can even lead to incorrect information transmission, affecting the normal business use of users. When the different clients in the related technologies access the same multicast group at different times, the delays of the video data actually transmitted by the multicast server are not uniform, and no effective solution has been proposed yet. Summary of the invention

The present invention is directed to the problem that video images played at the same time are not synchronized when different clients access the same multicast group at different times. To this end, the main object of the present invention is to provide a multicast video data. The program to solve at least one of the above problems. In order to achieve the above object, according to an aspect of the present invention, a method of multicasting video data is provided. The method for multicast video data according to the present invention includes: the retransmission server receives control request signaling from the client for requesting video data, wherein the control request signaling carries synchronization request information; and the retransmission server according to the synchronization request information And generating synchronization response information according to the stored video data from the multicast server, where the synchronization response information carries parameters for controlling playback of the video data; the retransmission server sends the video data to the client and carries the synchronization response information. Control response signaling, wherein the client is configured to play video data according to parameters carried in the synchronization response information. Preferably, after the client plays the video data according to the parameter, the client determines to stop receiving the video data from the retransmission server, and the client receives and plays the video data from the multicast server according to the information of the multicast server carried in the control response signaling. Preferably, the client sends control signaling to the retransmission server, where the control signaling is used to instruct the retransmission server to stop sending video data to the client. Preferably, the client stops receiving video data from the retransmission server according to the following basis: the client has ignored the number of ignored frames in the parameter carried in the synchronization response information during the playing process, where the number of ignored frames is not required to be played. The number of frames. Preferably, the parameter includes at least one of the following: ignoring the number of frames, the number of ignored frames is the number of video frames that do not need to be played; ignoring the frame interval, the ignored frame interval is between two adjacent unplayed video frames The number of video frames. In order to achieve the above object, according to another aspect of the present invention, a retransmission server is provided. The retransmission server according to the present invention is used for multicasting video data, and includes: a first receiving module, configured to receive control request signaling for requesting video data from a client, where the control request signaling carries synchronization request information a second receiving module, configured to receive and store video data from the multicast server, and a generating module, configured to generate synchronization response information according to the stored video data from the multicast server according to the synchronization request information, where the synchronization response The information carries a parameter for controlling the playing of the video data. The first sending module is configured to send the video data and the control response signaling carrying the synchronization response information to the client, where the control response signaling carries the synchronization response information. , so that the client plays the video data according to the parameters carried in the synchronization response information. Preferably, the parameter includes at least one of the following: ignoring the number of frames, the number of ignored frames is the number of video frames that do not need to be played; ignoring the frame interval, the ignored frame interval is between two adjacent unplayed video frames The number of video frames. In order to achieve the above object, according to still another aspect of the present invention, a client is provided. The client according to the present invention is configured to multicast video data, including: a synchronization request module, configured to generate synchronization request information, and write synchronization request information into control request signaling, where the control request signaling is used to request the multicast server. a second sending module, configured to send control request signaling to a retransmission server that has stored video data from the multicast server; and a third receiving module, configured to receive, in response to the control request signaling, the retransmission server Control response signaling and video data, wherein The system response signal carries the synchronization response information; and the playing module is configured to play the video data according to the parameter carried in the synchronization response signaling for controlling the playing of the video data. Preferably, the client further includes: a determining module, configured to determine whether to stop receiving video data from the retransmission server; and a first control module, configured to: according to the information of the multicast server, if the judgment result of the determining module is yes The multicast server receives and plays subsequent video data of the video data, where the control response signaling further carries information of the multicast server. Preferably, the client further includes: a second control module, configured to send, to the retransmission server, control signaling, where the determination result of the determining module is yes, where the control signaling is used to indicate that the retransmission server stops The client sends video data. In order to achieve the above object, according to still another aspect of the present invention, a system for multicast video data is provided, and the system may include the above-described retransmission server and the client. Through the invention, the data synchronization between the client and the retransmission server is performed, and the number of ignored frames is not played on the client, and the different clients are played at the same time when accessing the same multicast group at different times. The problem that the video picture is not synchronized, thereby avoiding the error video on the client, enabling the video of the client to be played synchronously and improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, In the drawings: FIG. 1 is a structural block diagram of a RAMS scheme system of an IETF according to the related art; FIG. 2 is a flowchart of a method for multicasting video data according to an embodiment of the present invention; FIG. 3 is a flowchart according to an embodiment of the present invention. FIG. 4 is a flow chart of a specific method for multicast video data according to an embodiment of the present invention; FIG. 5 is a structural block diagram of a retransmission server according to an embodiment of the present invention; 6 is a structural block diagram of a client according to an embodiment of the present invention; FIG. 7 is a specific structural block diagram of a client according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict. The invention will be described in detail below with reference to the drawings in conjunction with the embodiments. In the following embodiments, the steps shown in the flowchart of the accompanying drawings may be performed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some In this case, the steps shown or described may be performed in a different order than the ones described herein. In accordance with an embodiment of the present invention, a method of multicasting video data is provided. 2 is a flowchart of a method for multicasting video data according to an embodiment of the present invention. As shown in FIG. 2, the method includes the following steps S202 to S206: Step S202, the retransmission server receives the request from the client. Requesting control request signaling of the video data, where the control request signaling carries synchronization request information; Step S204, the retransmission server generates a synchronization response according to the stored video data from the multicast server according to the synchronization request information Information, wherein the synchronization response information carries a parameter for playing the video data; Step S206, the retransmission server sends the video data to the client and the control response signaling carrying the synchronization response information, where the control response signal The command carries the synchronization response information, so that the client plays the video data according to the parameters carried in the synchronization response information. In the related art, the delay of video data actually sent by different clients and the multicast server is not uniform. In the embodiment of the present invention, the parameter for controlling video data playing is sent to the client by the retransmission server, so that the client can control the playing of the video data according to the parameter during the playing process. In this embodiment, the video data played by different clients can be separately synchronized with the video data actually sent by the multicast server, so that video data can be played synchronously between different clients, and the user experience is improved. Preferably, after the step S206, the client plays the video data according to the parameter, and then the client determines to stop receiving the video data from the retransmission server, and the client receives the information from the multicast server according to the information of the multicast server carried in the control response signaling. Play video data from the retransmission server. It should be noted that, by using the preferred embodiment, after the client synchronizes with the retransmission server, the connection between the client and the retransmission server is transferred to the connection with the multicast server, thereby realizing The multicast service of the client. Preferably, after step S206, the client sends control signaling to the retransmission server, where the control signaling is used to instruct the retransmission server to stop sending video data to the client. It should be noted that, by using the preferred embodiment, after the client synchronizes with the retransmission server, the connection between the client and the retransmission server is transferred to the connection with the multicast server, thereby implementing the multicast service of the client. In the embodiment of the present invention, the client determines to stop receiving video data from the retransmission server according to the fact that the client has ignored the number of ignored frames in the parameter carried in the synchronization response information during the playing process, wherein the number of ignored frames is not required. The number of video frames that can be ignored while playing. It should be noted that, by using the preferred embodiment, the retransmission server sets the number of ignored frames in the parameter in advance. When the client has ignored the preset number of ignored frames during playback, it can be determined to stop the retransmission server. Receive video data. In the embodiment of the present invention, the foregoing parameters include at least one of the following: ignoring the number of frames, that is, the number of video frames that do not need to be played; ignoring the frame interval, that is, video frames between two adjacent video frames that are not played. quantity. The implementation process of the embodiment of the present invention will be described in detail below with reference to examples. In the RAMS scheme, the video data and the control information are carried by the RTP/RTCP protocol. Therefore, in the subsequent processing flow description according to the embodiment of the present invention, the transmitted multicast and unicast video data are all carried by the RTP protocol 7 And, the control signaling of the synchronization information according to the embodiment of the present invention is passed between the retransmission server and the media client as an extension of the RTCP packet. 3 is a structural block diagram of a system for multicasting video data according to an embodiment of the present invention. As shown in FIG. 3, a system for multicast video data according to an embodiment of the present invention includes: a multicast server, configured to multicast video data. a multicast router, configured to receive video data from the multicast server; multicast video data to the retransmission server and the media client; forward unicast video data and control signaling between the retransmission server and the media client; Source Filtering Group Management Protocol (SFGMP) message. A retransmission server for receiving and storing multicast video data from the multicast server, and the media The client performs control signaling communication, and sends the stored multicast video data to the media client by using unicast and fast transmission. The media client is configured to receive and play the multicast video data and the multicast video data that is unicasted and sent from the retransmission server, perform control signaling communication with the retransmission server, and send the SFGMP message to the multicast router. The embodiment of the present invention adds the following modules to the RAMS structure: The server synchronization module is located in the retransmission server and has the following functions: calculating information required for video client data synchronization; writing data synchronization response information into control response signaling The control response signaling may be an RTCP-I message. The client synchronization module, located in the media client, has the following functions: generating data synchronization request information, and writing synchronization request information into the control request signaling, wherein the control request signaling may be in an RTCP-R message; according to RTCP The synchronization response information of the video data in the -I message sets the playback mode of the video data. 4 is a flowchart of a specific method for multicasting video data according to an embodiment of the present invention. As shown in FIG. 4, the application of the method in the RAMS system includes the following steps: Step 1: The multicast server will multicast the video. The media is sent to the multicast router and the retransmission server, and the retransmission server stores the received multicast video data and multicast access information (Multicast Reference Information, referred to as multicast RI), where the client of the multicast video data is stored. A Synchronization Source Identifier (SSRC) is used as an index of the above stored information. Step 2: The media client starts the multicast fast access service and generates an RTCP-R message to receive the multicast video data. The RTCP-R message needs to include the synchronization request information generated by the client synchronization module in addition to the original information. The above synchronization request information includes, but is not limited to, a flag of whether a media client needs data synchronization. The format of the synchronization request information is defined in the format of type, length, and value (TLV), for example: 0 1 2 3

01234567890123456789012345678901

+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+— +—+—+ Type=l I Length=4 Value: 1 |

The values and meanings of the fields are as follows: Type: The type of the synchronization request information is 1. This field occupies one byte. Length: The length of the complete synchronization request message is 4, in bytes. This field occupies two bytes. Value: If data synchronization is required, the value is 1; otherwise, the value is 0. This field occupies one byte. Step 3: The media client sends an RTCP-R message to the retransmission server. Step 4: The retransmission server parses the RTCP-R message to determine whether the data synchronization service should be provided according to whether the value of the synchronization request information and the retransmission server itself have data synchronization capabilities. If the synchronization request information has a value of 1 and the retransmission server has data synchronization capability, go to step 5, otherwise go to step 6. Step 5: The server synchronization module generates synchronization response information according to the stored multicast video data, and writes the synchronization response information into the RTCP-I, where the synchronization response information includes at least: the number of ignored frames, that is, the playback does not need to be performed. The number of video frames; the frame interval is ignored, which is the number of video frames between two adjacent video frames that are not played. The synchronous response information format conforms to the TLV format definition. The multiple information of the normal playback speed of unicast video data is as follows:

0 1 2 3

01234567890123456789012345678901

Type=l I Length=4 Value=N |

The values and meanings of the fields are as follows: Type: The type of the number of ignored frames is 1. This field occupies one byte. Length: The length of the ignored frame number information is 4, in bytes. This field occupies two bytes. Value: N, the unit is the frame. This field occupies one byte. Examples of unicast video data playback duration information are as follows:

0 1 2 3

01234567890123456789012345678901

+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+— +—+—+

1 Type=2 | Length=4 | Value=V |

+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+— +—+—+ The values and meanings of the fields are as follows: Type: The type of the ignored frame interval is 2. This field occupies one byte. Length: Ignore the frame interval information length is 4, in bytes. This field occupies two bytes. Value: V, the unit is the frame. This field occupies one byte. The method for generating the synchronization response information is as follows: Assume that the number of video frames between the latest random access point and the current video frame of the multicast video data is N, between two adjacent video frames that do not need to be played. The number of video frames is V, then the number of ignored frames in the synchronization response information = N, and the frame interval = V is ignored. Step 6: The retransmission server unicasts the fast RTCP-I message and video data to the media client. Step 7: The media client joins the multicast group according to the multicast RI of the RTCP-I message about joining the multicast group method, and starts to receive the multicast video data from the multicast server. Step 8: The media client determines whether there is synchronization response information in the RTCP-I message. If there is synchronous response information, go to step 9, otherwise go to step 10. Step 9: The client synchronization module sets the play mode of the unicast video data according to the synchronization response information, and the setting method is: after playing the video frame that ignores the number of frame intervals, one video frame is ignored. The media client does not play ignored video frames according to this setting. In the embodiment of the present invention, the number of play ignore frames is N, and the frame interval is ignored as V. Step 10: The media client plays unicast video data. Step 11: The media client determines whether it is necessary to stop the fast access service, where the fast access service at least includes: receiving and playing the unicast video data sent by the retransmission server; and controlling signaling communication with the retransmission server. The reason for determining that the service is stopped is that the media client has ignored the number of ignored frames in the synchronization response information during the playback process. In the embodiment of the present invention, if the media client has ignored playing N frames, the process proceeds to step 4 12, otherwise go to step 4 to gather 10. Step 12: The media client sends control signaling to the retransmission server. The control signaling may be an RTCP-T message, and the retransmission server ends the unicast fast transmission video data, and the media client sends the RTCP BYE to the retransmission server. End the RTP/RTCP communication between the two, and both the media client and the retransmission server end the fast access service. The media client ends playing the unicast media stream and starts to play the multicast media stream normally. In the above steps, the control signaling needs to contain the necessary content for multicast fast access.

(For example: multicast RI, media packet sequence number, bandwidth limitation, SSRC, client buffer size, etc.), video data and control signaling between the device and the module, are not in the solution of the present invention, the present invention The program has no specific requirements for this. According to an embodiment of the present invention, a retransmission server is provided. FIG. 5 is a structural block diagram of a retransmission server according to an embodiment of the present invention. As shown in FIG. 5, the retransmission server includes: a first receiving module 52, a second receiving module 54, a generating module 56, and a first sending module 58, The structure will be described in detail below. The first receiving module 52 is configured to receive control request signaling for requesting video data from the client, where the control request signaling carries synchronization request information, and the second receiving module 54 is configured to receive and store the multicast request. The video data of the server is connected to the first receiving module 52 and the second receiving module 54 for generating a synchronization response according to the synchronization request information received by the first receiving module 52 and according to the video data received by the second receiving module 54. The information, wherein the synchronization response information carries a parameter for controlling the playing of the video data; the first sending module 58 is connected to the generating module 56, configured to send the video data to the client and carry the video generated by the generating module 56 for controlling the video. The control response signaling of the parameters of the playing of the data, so that the client plays the video data according to the parameter. In the related art, the delay of video data actually sent by different clients and the multicast server is not uniform. In the embodiment of the present invention, the retransmission server sends a message to the client for controlling video data playback. The parameters enable the client to control the playback of the video data according to the parameter during playback. In this embodiment, the video data played by different clients can be separately synchronized with the video data actually sent by the multicast server, so that video data can be played synchronously between different clients, and the user experience is improved. The parameter includes at least one of the following: ignoring the number of frames, the number of ignored frames is the number of video frames that need not be played; ignoring the frame interval, the ignored frame interval is between two adjacent unplayed video frames The number of video frames. FIG. 6 is a structural block diagram of a client according to an embodiment of the present invention. As shown in FIG. 6, the client includes: a synchronization requesting module 62, a second sending module 64, a third receiving module 66, and a playing module 68. The structure is described in detail. The synchronization requesting module 62 is configured to generate synchronization request information, and write the synchronization request information into the control request signaling, where the control request signaling is used to request the video data of the multicast server; the second sending module 64 is connected to the synchronization requesting module 62. And the control request signaling generated by the synchronization requesting module 62 is sent to the retransmission server that has stored the video data from the multicast server. The third receiving module 66 is configured to receive the response request signaling from the retransmission server. The control response signaling and the video data, wherein the control response signaling carries the synchronization response information; the playing module 68 is connected to the third receiving module 66, and configured to control the playing of the video data according to the synchronization response signaling. parameter. In the related art, the delay of video data actually sent by different clients and the multicast server is not uniform. In the embodiment of the present invention, the parameter for controlling video data playing is sent to the client by the retransmission server, so that the client can control the playing of the video data according to the parameter during the playing process. In this embodiment, the video data played by different clients can be separately synchronized with the video data actually sent by the multicast server, so that video data can be played synchronously between different clients, and the user experience is improved. FIG. 7 is a structural block diagram of a client according to an embodiment of the present invention. As shown in FIG. 7, the client further includes: a determining module 72, a first control module 74, and a second control module 76. The structure will be described in detail below. The determining module 72 is coupled to the playing module 66 for determining to stop receiving video data from the retransmission server; the first control module 74 is coupled to the determining module 72 for determining to stop at the determining module 72 When the retransmission server receives the video data, it receives and plays the subsequent video data of the video data from the multicast server according to the information of the multicast server, where the control response signaling further carries the information of the multicast server. The second control module 76 is configured to: when the determining module 72 determines to stop receiving video data from the retransmission server, send control signaling to the retransmission server, where the control signaling is used to indicate that the retransmission server stops sending video to the client. data. It should be noted that, by using the preferred embodiment, after the client synchronizes with the retransmission server, the connection between the client and the retransmission server is transferred to the connection with the multicast server, thereby implementing the multicast service of the client. The determining module 72 is specifically configured to determine whether the number of ignored frames in the synchronization response information has been ignored during the playing process, where the parameter includes the number of ignored frames, and the number of ignored frames is the number of video frames that need not be played. In summary, the embodiment of the present invention avoids the occurrence of an error video on the client, enables the video of the client to be played synchronously, and improves the user experience. Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device, or they may be separately fabricated into individual integrated circuit modules, or they may be Multiple modules or steps are made into a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software. The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the scope of the present invention are intended to be included within the scope of the present invention.

Claims

A method for multicasting video data, comprising:

The retransmission server receives the control request signaling for requesting the video data from the client, where the control request signaling carries synchronization request information; the retransmission server according to the synchronization request information, and according to the The stored video data from the multicast server generates synchronization response information, where the synchronization response information carries parameters for controlling playback of the video data;

Transmitting, by the retransmission server, the video data and control response signaling carrying the synchronization response information to the client, so that the client-according to the information carried in the synchronization response information The parameter plays the video data.

2. The method according to claim 1, wherein after the client plays the video data by using the parameter, the method further includes:

The client determines to stop receiving the video data from the retransmission server; the client receives the information from the multicast server according to the information of the multicast server carried in the control response signaling Play the video data.

The method of claim 2, after the client determines to stop receiving the video data from the retransmission server, the method further includes:

The client sends control signaling to the retransmission server, where the control signaling is used to instruct the retransmission server to stop sending the video data to the client.

The method according to claim 2 or 3, wherein the client stops receiving the video data from the retransmission server by determining:

The number of ignored frames in the parameter carried in the synchronization response information is ignored by the client, and the number of ignored frames is the number of video frames that do not need to be played. The method according to claim 1, wherein the parameter comprises at least one of the following: ignoring the number of frames, the number of ignored frames is the number of video frames that do not need to be played; ignoring the frame interval, the ignoring The frame interval is the number of video frames between two adjacent video frames that are not played. A retransmission server, configured to multicast video data, includes:

a first receiving module, configured to receive, by the client, control request signaling for requesting the video data, where the control request signaling carries synchronization request information;

a second receiving module, configured to receive and store the video data from the multicast server, and a generating module, configured to generate, according to the synchronization request information, according to the stored video data from the multicast server Synchronization response information, wherein the synchronization response information carries parameters for controlling playback of the video data;

a first sending module, configured to send the video data and the control response signaling carrying the synchronization response information to the client, so that the client is configured according to the information carried in the synchronization response information The parameter plays the video data. The retransmission server according to claim 6, wherein the parameter comprises at least one of the following:

The number of frames is ignored, the number of ignored frames is the number of video frames that need not be played; the frame interval is ignored, and the ignored frame interval is the number of video frames between two adjacent video frames that are not played. A client for multicast video data, comprising:

a synchronization requesting module, configured to generate synchronization request information, and write the synchronization request information into control request signaling, where the control request signaling is used to request video data of the multicast server; a retransmission server that has stored video data from the multicast server to send the control request signaling;

a third receiving module, configured to receive control response signaling and the video data in response to the control request signaling from the retransmission server, where the control response signaling carries synchronization response information;

a playing module, configured to play the video data according to a parameter carried in the synchronization response signaling for controlling playback of the video data.

The client according to claim 8, further comprising: a determining module, configured to determine to stop receiving the video data from the retransmission server; a first control module, configured to The information of the multicast server receives and plays subsequent video data of the video data from the multicast server, where the control response signaling further carries information of the multicast server.

And a second control module, configured to send control signaling to the retransmission server, where the control signaling is used to instruct the retransmission server to stop sending the video data to the client.

A system for multicast video data, comprising the retransmission server of claim 6 and the client of claim 8.