WO2011022983A1 - Method, device and system of multi-cast video data - Google Patents
Method, device and system of multi-cast video data Download PDFInfo
- Publication number
- WO2011022983A1 WO2011022983A1 PCT/CN2010/072463 CN2010072463W WO2011022983A1 WO 2011022983 A1 WO2011022983 A1 WO 2011022983A1 CN 2010072463 W CN2010072463 W CN 2010072463W WO 2011022983 A1 WO2011022983 A1 WO 2011022983A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- video data
- client
- server
- synchronization
- information
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
- H04L12/1877—Measures taken prior to transmission
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
Definitions
- the present invention relates to the field of communications, and in particular to a method, apparatus, and system for multicast video data.
- RAMS Random Acquisition of Multicast RTP Sessions
- IETF Internet Engineering Task Force
- RTP Real-time Transport Protocol
- 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).
- IPTV Internet Protocol Television
- 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.
- 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.
- RTP Receiver RTP Receiver
- 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.
- the time for different clients to access the same multicast group may not be the same.
- 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.
- the larger the time interval between adjacent random access points the greater the difference in playback delay between clients.
- 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.
- 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.
- 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.
- a method of multicasting video data is provided.
- the method for multicast video data 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.
- 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.
- 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.
- 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.
- 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.
- a retransmission server is provided.
- the retransmission server 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.
- 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
- 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
- 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.
- 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.
- 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.
- a system for multicast video data may include the above-described retransmission server and the client.
- 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.
- 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.
- 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.
- 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.
- the delay of video data actually sent by different clients and the multicast server is not uniform.
- 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.
- 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 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.
- 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.
- 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.
- 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 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 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.
- 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 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
- 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.
- a system for multicast video data 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.
- SFGMP Source Filtering Group Management Protocol
- 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.
- Multicast RI Multicast Reference Information
- 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
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.
- 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.
- the control signaling needs to contain the necessary content for multicast fast access.
- FIG. 5 is a structural block diagram of a retransmission server according to an embodiment of the present invention.
- 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
- 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.
- the delay of video data actually sent by different clients and the multicast server is not uniform.
- 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.
- 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. 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.
- the delay of video data actually sent by different clients and the multicast server is not uniform.
- 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.
- 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 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
- 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.
- 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.
- 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.
- 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.
- the invention is not limited to any specific combination of hardware and software.
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
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
组番视频 :据的方法、 装置及*** 技术领域 本发明涉及通信领域, 具体而言, 涉及一种组播视频数据的方法、 装置 及***。 背景技术 互联网工程任务组 ( Internet Engineering Task Force, 简称为 IETF ) 的 组播实时传输协议 ( Real-time Transport Protocol, 简称为 RTP )会话的快速 接入 ( Rapid Acquisition of Multicast RTP Sessions, 简称为 RAMS )技术方案, 提供了一种在 RTP组播会话中媒体客户端快速接入组播的方法。 图 1是根据 相关技术的 IETF的 RAMS方案的***的结构框图, 利用该方法可以减少媒 体客户端在加入 RTP 组播会话前的延迟时间, 在诸如互联网协议电视 ( Internet Protocol Television, 简称为 IPTV )之类的媒体客户端需要频繁切 换组播组的流媒体组播业务时,釆用 RAMS方案的媒体客户端可以快速的切 换频道, 减少视频画面播放的等待时间, 提高了用户体 -险。 由于媒体客户端呈现视频画面必须要从随机接入点开始, 因此, 在传统 的组播视频服务中, 为了保证不同时间加入组播组的不同媒体客户端都能播 放视频画面, 组播月艮务器一般釆用以固定的周期发送快速接入点的方法, 同 时, 为了让新加入组播组的客户端能够更快速的呈现视频画面, 上述固定的 周期都很短。 视频的随机接入点釆用帧内编码,其编码时间和编码后的帧大小都远远 大于釆用帧间编码方式的普通帧, 因此, 视频流随机接入点之间的时间间隔 与编解码以及传输效率成反比。 如图 1所示,在上述 RAMS方案中,重传月艮务器( Retransmission Server, 简称为 RS )根据 RTP接收器 ( RTP Receiver, 简称为 RR ) 的请求将接入信 息 ( Reference Information, 简称为 RI ) 通过单播的方式快发给 RR, RR从 接收到的 RI 中解析出流媒体视频的随机接入点, 并使用该随机接入点, 从 该重传月艮务器接收视频数据, 并 4巴该视频数据播放给用户观看。 其中, 该从 重传服务器接收的视频数据是重传服务器预先从组播服务器接收并保存的,
其与组播服务器实际发送的视频数据是存在一定延迟的。 因此, 在 RAMS方案中, RR首次加入组播组的随机接入点不再从组播 地址收取, 而是通过从 RS快发的 RI中获取, 因此, 媒体客户端首次播放画 面的延迟时间不再受视频流随机接入点发送周期的长短影响, 因此, RAMS 可以釆用将随机接入点之间的时间间隔增大的方式, 同时不影响新加入组播 组的客户端快速的呈现视频画面, 从而提高了编解码和传输效率。 但是, 不同客户端接入同一个组播组的时间可能并不相同。 这样, 根据 上述 RAMS方法, 它们从 RI所解析出的视频的随机接入点是不同的, 这将 导致它们与组播服务器实际发送的视频数据是存在的延迟是不同的 (即, 它 们分别与组播服务器实际发送的视频数据的延迟存在延迟差),进而这将导致 不同客户端在相同时刻所播放的视频画面是不同的。 并且, 相邻随机接入点 之间的时间间隔越大,客户端之间的播放延迟差就越大。在 IPTV、视频会议、 远程教育等流媒体组播应用中, 媒体客户端之间过大的延迟差会使用户体验 下降, 甚至能够导致信息错误传递, 影响用户正常的业务使用。 4十对相关技术中不同客户端在不同时间接入同一个组播组时,它们与组 播服务器实际发送的视频数据的延迟不统一的问题, 目前尚未提出有效的解 决方案。 发明内容 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
4十对不同客户端在不同时间接入同一个组播组时在相同时刻所播放的 视频画面不同步的问题而提出本发明, 为此, 本发明的主要目的在于提供一 种组播视频数据的方案, 以解决上述问题至少之一。 为了实现上述目的, 才艮据本发明的一个方面, 提供了一种组播视频数据 的方法。 根据本发明的组播视频数据的方法包括:重传服务器接收来自客户端的 用于请求视频数据的控制请求信令, 其中, 控制请求信令中携带有同步请求 信息; 重传服务器根据同步请求信息, 并根据已存储的来自组播服务器的视 频数据生成同步响应信息, 其中, 同步响应信息中携带有用于控制视频数据 的播放的参数; 重传服务器向客户端发送视频数据和携带有同步响应信息的 控制响应信令, 其中, 以便于客户端根据同步响应信息中携带的参数播放视 频数据。
优选地, 在客户端根据参数播放视频数据之后, 客户端确定停止从重传 服务器接收视频数据, 客户端根据控制响应信令中携带的组播服务器的信息 从组播服务器接收并播放视频数据。 优选地, 客户端向重传服务器发送控制信令, 其中, 控制信令用于指示 重传服务器停止向客户端发送视频数据。 优选地, 客户端通过以下依据确定停止从重传服务器接收视频数据: 客 户端在播放过程中已经忽略了同步响应信息中携带的参数中的忽略帧数, 其 中, 忽略帧数为不需要播放的视频帧的数量。 优选地, 参数至少包括以下之一: 忽略帧数, 该忽略帧数为不需要播放 的视频帧的数量; 忽略帧间隔, 该忽略帧间隔为两个相邻的不被播放的视频 帧之间的视频帧的数量。 为了实现上述目的,根据本发明的另一个方面,提供了一种重传服务器。 根据本发明的重传服务器用于组播视频数据, 包括: 第一接收模块, 用 于接收来自客户端的用于请求视频数据的控制请求信令, 其中, 控制请求信 令中携带有同步请求信息; 第二接收模块, 用于接收并存储来自组播服务器 的视频数据; 生成模块, 用于根据同步请求信息, 并根据已存储的来自组播 服务器的视频数据生成同步响应信息, 其中, 同步响应信息中携带有用于控 制视频数据的播放的参数; 第一发送模块, 用于向客户端发送视频数据和携 带有同步响应信息的控制响应信令, 其中, 控制响应信令中携带有同步响应 信息, 以便于客户端根据同步响应信息中携带的参数播放视频数据。 优选地, 参数至少包括以下之一: 忽略帧数, 该忽略帧数为不需要播放 的视频帧的数量; 忽略帧间隔, 该忽略帧间隔为两个相邻的不被播放的视频 帧之间的视频帧的数量。 为了实现上述目的, 根据本发明的又一方面, 提供了一种客户端。 根据本发明的客户端用于组播视频数据, 包括: 同步请求模块, 用于生 成同步请求信息, 并将同步请求信息写入控制请求信令中, 控制请求信令用 于请求组播服务器的数据视频; 第二发送模块, 用于向已存储来自组播服务 器的视频数据的重传服务器发送控制请求信令; 第三接收模块, 用于接收来 自重传服务器的响应于控制请求信令的控制响应信令和视频数据, 其中, 控
制响应信令中携带有同步响应信息; 播放模块, 用于根据同步响应信令中携 带的用于控制视频数据的播放的参数播放视频数据。 优选地, 该客户端还包括: 判断模块, 用于判断是否停止从重传服务器 接收视频数据; 第一控制模块, 用于在判断模块的判断结果为是的情况下, 根据组播服务器的信息从组播服务器接收并播放视频数据的后续视频数据, 其中, 控制响应信令中还携带有组播服务器的信息。 优选地, 该客户端还包括: 第二控制模块, 用于在判断模块的判断结果 为是的情况下, 向重传服务器发送控制信令, 其中, 控制信令用于指示重传 服务器停止向客户端发送视频数据。 为了实现上述目的, 根据本发明的又一方面, 提供了一种组播视频数据 的***, 该***可以包括上述重传月艮务器与上述客户端。 通过本发明, 釆用客户端和重传服务器间进行数据同步, 在客户端不播 放忽略的帧数的方式, 解决了不同客户端在不同时间接入同一个组播组时在 相同时刻所播放的视频画面不同步的问题,进而避免了客户端出现错误视频、 使客户端的视频能够同步播放以及提高了用户体验。 附图说明 此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部 分, 本发明的示意性实施例及其说明用于解释本发明, 并不构成对本发明的 不当限定。 在附图中: 图 1是根据相关技术的 IETF的 RAMS方案***的结构框图; 图 2是才艮据本发明实施例的组播视频数据的方法的流程图; 图 3是根据本发明实施例的组播视频数据的***的结构框图; 图 4是才艮据本发明实施例的组播视频数据的具体方法的流程图; 图 5是根据本发明实施例的重传服务器的结构框图; 图 6是才艮据本发明实施例的客户端的结构框图; 图 7是根据本发明实施例的客户端的具体的结构框图。
具体实施方式 需要说明的是, 在不冲突的情况下, 本申请中的实施例及实施例中的特 征可以相互组合。 下面将参考附图并结合实施例来详细说明本发明。 在以下实施例中,在附图的流程图示出的步 4聚可以在诸如一组计算机可 执行指令的计算机***中执行, 并且, 虽然在流程图中示出了逻辑顺序, 但 是在某些情况下, 可以以不同于此处的顺序执行所示出或描述的步骤。 根据本发明的实施例, 提供了一种组播视频数据的方法。 图 2是才艮据本发明实施例的组播视频数据的方法的流程图,如图 2所示, 该方法包括如下的步骤 S202至步骤 S206: 步骤 S202, 重传服务器接收来自客户端的用于请求视频数据的控制请 求信令, 其中, 控制请求信令中携带有同步请求信息; 步骤 S204, 重传服务器根据所述同步请求信息, 并根据已存储的来自 组播服务器的视频数据生成同步响应信息, 其中, 同步响应信息中携带有播 放视频数据的参数; 步骤 S206, 重传月艮务器向客户端发送视频数据和携带有所述同步响应 信息的控制响应信令, 其中, 控制响应信令中携带有同步响应信息, 以便于 客户端根据同步响应信息中携带的参数播放视频数据。 相关技术中,不同客户端与组播服务器实际发送的视频数据的延迟不统 一。 本发明实施例中, 通过重传服务器向客户端发送用于控制视频数据播放 的参数, 使得客户端能够在播放过程中, 能够根据该参数控制该视频数据的 播放。 本实施例能分别控制不同客户端播放的视频数据与组播服务器实际发 送的视频数据相同步, 从而使得不同客户端之间能够同步播放视频数据, 并 提高用户体验。 优选地, 在步骤 S206之后, 客户端根据参数播放视频数据, 然后, 客 户端确定停止从重传服务器接收视频数据, 客户端根据控制响应信令中携带 的组播服务器的信息从组播服务器接收并播放来自重传服务器的视频数据。 需要说明的是, 通过本优选实施例, 可以实现在客户端与重传服务器同 步之后, 将客户端与重传服务器的连接转到与组播服务器的连接, 从而实现
该客户端的组播业务。 优选地, 在步骤 S206 之后, 客户端发送控制信令给 重传服务器, 其中, 该控制信令用于指示重传服务器停止向客户端发送视频 数据。 需要说明的是, 通过本优选实施例, 可以实现在客户端与重传服务器同 步之后, 将客户端与重传服务器的连接转到与组播服务器的连接, 从而实现 该客户端的组播业务。 在本发明实施例中,客户端确定停止从重传服务器接收视频数据的依据 为:客户端在播放过程中已经忽略了同步响应信息中携带参数中的忽略帧数, 其中, 忽略帧数是不需要播放而可以忽略的视频帧的数量。 需要说明的是, 通过本优选实施例, 重传服务器预先在该参数中设置了 忽略帧数, 当客户端在播放过程中已经忽略了该预先设置的忽略帧数, 即可 确定停止从重传服务器接收视频数据。 在本发明实施例中, 上述参数包括以下至少之一: 忽略帧数, 即不需要 播放的视频帧的数量; 忽略帧间隔, 即两个相邻的不被播放的视频帧之间的 视频帧的数量。 下面将结合实例对本发明实施例的实现过程进行详细描述。 在 RAMS方案中, 视频数据和控制信息由 RTP/RTCP协议承载, 因此, 在才艮据本发明实施例的后续处理流程说明中, 所传递的组播和单播视频数据 均由 RTP 协议 7 载, 而 -据本发明实施例的同步信息的控制信令则作为 RTCP包的扩展内容在重传服务器和媒体客户端之间传递。 图 3 是根据本发明实施例的组播视频数据的***的结构框图, 如图 3 所示, 本发明实施例的组播视频数据的***包括: 组播服务器, 用于组播视频数据。 组播路由器, 用于接收来自组播服务器的视频数据; 向重传服务器、 媒 体客户端组播视频数据; 转发重传服务器与媒体客户端之间的单播视频数据 和控制信令; 处理源过滤组管理协议 ( Source Filtering Group Management Protocol , 简称为 SFGMP ) 消息。 重传服务器, 用于接收并存储来自组播服务器的组播视频数据, 与媒体
客户端进行控制信令通讯, 利用单播、 快发的方式向媒体客户端发送已存储 的组播视频数据。 媒体客户端,用于接收并播放组播视频数据与从重传服务器单播快发来 的组播视频数据, 与重传服务器进行控制信令通讯, 发送 SFGMP消息到组 播路由器。 本发明实施例在 RAMS结构中添加了以下模块: 服务器同步模块, 位于重传服务器中, 具有如下功能: 计算媒体客户端 视频数据同步需要的信息; 将数据同步响应信息写入控制响应信令中, 其中, 控制响应信令可以是 RTCP-I消息。 客户端同步模块, 位于媒体客户端中, 具有如下功能: 生成数据同步请 求信息, 并将同步请求信息写入控制请求信令中, 其中, 控制请求信令可以 是 RTCP-R消息中; 根据 RTCP-I消息中的视频数据的同步响应信息设置视 频数据的播放方式。 图 4是根据本发明实施例的组播视频数据的具体方法的流程图, 如图 4 所示, 该方法在 RAMS***中的应用包括以下步 4聚: 步骤 1: 组播服务器将组播视频媒体发送到组播路由器和重传服务器, 重传服务器对接收到的组播视频数据和组播接入信息 ( Multicast Reference Information , 简称为组播 RI ) 进行存储, 其中, 组播视频数据的客户端同步 源标识符( Synchronization Source Identifier, 简称为 SSRC )作为上述存储信 息的索引。 步骤 2: 媒体客户端启动组播快速接入服务, 生成 RTCP-R消息, 以便 于接收组播视频数据。 其中, RTCP-R 消息中除了包括原有信息, 还需要包 括客户端同步模块生成的同步请求信息。 上述同步请求信息包括但不限于一 个媒体客户端是否需要数据同步的标志。 同步请求信息的格式遵循类型、 长 度、 值 (Type, Length, Value, 简称为 TLV)格式定义, 例如: 0 1 2 3 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 01234567890123456789012345678901
+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+
Type=l I Length=4 Value: 1 | +—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+— +—+—+ Type=l I Length=4 Value: 1 |
其中, 各字段取值及含义如下: 类型: 同步请求信息的类型取值为 1。 该字段占一个字节。 长度: 完整的同步请求信息的长度为 4, 单位字节。 该字段占两个字节。 值: 在需要数据同步的情况下, 取值为 1; 否则, 取值为 0。 该字段占 一个字节。 步骤 3: 媒体客户端发送 RTCP-R消息至重传服务器。 步骤 4: 重传服务器解析 RTCP-R消息, 才艮据同步请求信息的取值和重 传服务器自身是否具有数据同步能力来判断是否应提供数据同步服务。 如果 同步请求信息取值为 1且重传服务器具有数据同步能力则进入步骤 5, 否则 进入步骤 6。 步骤 5: 服务端同步模块根据已存储的组播视频数据生成同步响应信 息, 并将同步响应信息写入 RTCP-I 中, 其中, 同步响应信息中至少包括: 忽略帧数, 即不需要播放的视频帧的数量; 忽略帧间隔, 即为两个相邻的不 被播放的视频帧之间的视频帧的数量。 同步响应信息格式遵循 TLV 格式定 义, 单播视频数据正常播放速度的倍数信息举例如下: 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 0 1 2 3
01234567890123456789012345678901 01234567890123456789012345678901
Type=l I Length=4 Value=N | Type=l I Length=4 Value=N |
各字段取值及含义如下: 类型: 忽略帧数的类型取值为 1。 该字段占一个字节。 长度: 忽略帧数信息的长度为 4, 单位字节。 该字段占两个字节。
值: 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 0 1 2 3
01234567890123456789012345678901 01234567890123456789012345678901
+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+ +—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+— +—+—+
1 Type=2 | Length=4 | Value=V | 1 Type=2 | Length=4 | Value=V |
+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+ 各字段取值及含义如下: 类型: 忽略帧间隔的类型取值为 2。 该字段占一个字节。 长度: 忽略帧间隔信息的长度为 4, 单位字节。 该字段占两个字节。 值: V, 单位为帧。 该字段占一个字节。 其中, 生成同步响应信息的方法举例如下: 假设:最新随机接入点与组播视频数据的当前视频帧之间的视频帧数量 为 N, 两个相邻的不需要播放的视频帧之间的视频帧数量为 V, 则同步响应 信息中的忽略帧数 =N, 忽略帧间隔 =V。 步骤 6: 重传服务器单播快发 RTCP-I消息和视频数据到媒体客户端。 步骤 7:媒体客户端根据 RTCP-I消息中关于加入组播组方法的组播 RI, 加入组播组, 并开始接收来自组播服务器的组播视频数据。 步骤 8: 媒体客户端判断 RTCP-I消息中是否有同步响应信息。 如果有 同步响应信息则进入步骤 9, 否则进入步骤 10。 步骤 9: 客户端同步模块根据同步响应信息设置单播视频数据的播放方 式, 设置方法为: 在播放忽略帧间隔数量的视频帧后, 忽略一个视频帧。 媒 体客户端按照该设置不播放被忽略的视频帧。 在本发明实施例中, 播放忽略 帧数为 N, 忽略帧间隔为 V。
步骤 10: 媒体客户端播放单播视频数据。 步骤 11 : 媒体客户端判断是否需要停止快速接入服务, 其中, 快速接 入服务至少包括: 接收和播放重传服务器发送的单播视频数据; 与重传服务 器之间的控制信令通讯。 判断停止该服务的依据为, 媒体客户端在播放过程 中已经忽略了同步响应信息中的忽略帧数, 在本发明实施例中, 如果媒体客 户端已经忽略播放了 N帧, 则进入步 4聚 12, 否则进入步 4聚 10。 步骤 12: 媒体客户端发送控制信令到重传服务器, 该控制信令可以是 RTCP-T 消息, 重传月艮务器结束单播快发视频数据, 媒体客户端发送 RTCP BYE到重传服务器, 结束二者之间的 RTP/RTCP通讯, 媒体客户端和重传服 务器均结束快速接入服务。 媒体客户端结束播放单播媒体流, 开始正常播放 组播媒体流。 在上述各步骤中,控制信令需要包含用于组播快速接入的所必须的内容+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+— +—+—+ 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.
(例如: 组播 RI、 媒体包序号、 带宽限制、 SSRC、 客户端緩冲区大小等内 容)、视频数据和控制信令在装置和模块之间的传递方法,不属于本发明方案, 本发明方案对此并无具体要求。 根据本发明的实施例, 提供了一种重传服务器。 图 5是根据本发明实施例的重传服务器的结构框图, 如图 5所示, 该重 传服务器包括: 第一接收模块 52、 第二接收模块 54、 生成模块 56和第一发 送模块 58 , 下面对该结构进行详细说明。 第一接收模块 52 , 用于接收来自客户端的用于请求视频数据的控制请 求信令, 其中, 控制请求信令中携带有同步请求信息; 第二接收模块 54 , 用 于接收并存储来自组播服务器的视频数据; 生成模块 56 连接至第一接收模 块 52和第二接收模块 54 , 用于根据第一接收模块 52接收的同步请求信息, 并根据第二接收模块 54 接收的视频数据生成同步响应信息, 其中, 同步响 应信息中携带有用于控制视频数据的播放的参数; 第一发送模块 58 连接至 生成模块 56 , 用于向客户端发送视频数据和携带有生成模块 56生成的用于 控制视频数据的播放的参数的控制响应信令, 以便于客户端根据该参数播放 视频数据。 相关技术中,不同客户端与组播服务器实际发送的视频数据的延迟不统 一。 本发明实施例中, 通过重传服务器向客户端发送用于控制视频数据播放
的参数, 使得客户端能够在播放过程中, 能够根据该参数控制该视频数据的 播放。 本实施例能分别控制不同客户端播放的视频数据与组播服务器实际发 送的视频数据相同步, 从而使得不同客户端之间能够同步播放视频数据, 并 提高用户体验。 其中, 该参数包括以下至少之一: 忽略帧数, 该忽略帧数为不需要播放 的视频帧的数量; 忽略帧间隔, 该忽略帧间隔为两个相邻的不被播放的视频 帧之间的视频帧的数量。 图 6是根据本发明实施例的客户端的结构框图, 如图 6所示, 该客户端 包括: 同步请求模块 62、第二发送模块 64、第三接收模块 66和播放模块 68 , 下面对该结构进行详细说明。 同步请求模块 62 , 用于生成同步请求信息, 并将同步请求信息写入控 制请求信令中, 控制请求信令用于请求组播服务器的视频数据; 第二发送模 块 64连接至同步请求模块 62 , 用于向已存储来自组播服务器的视频数据的 重传服务器发送同步请求模块 62生成的控制请求信令; 第三接收模块 66 , 用于接收来自重传服务器的响应于控制请求信令的控制响应信令和视频数 据, 其中, 控制响应信令中携带有同步响应信息; 播放模块 68 连接至第三 接收模块 66 , 用于根据同步响应信令中携带的用于控制视频数据的播放的参 数。 相关技术中,不同客户端与组播服务器实际发送的视频数据的延迟不统 一。 本发明实施例中, 通过重传服务器向客户端发送用于控制视频数据播放 的参数, 使得客户端能够在播放过程中, 能够根据该参数控制该视频数据的 播放。 本实施例能分别控制不同客户端播放的视频数据与组播服务器实际发 送的视频数据相同步, 从而使得不同客户端之间能够同步播放视频数据, 并 提高用户体验。 图 7是根据本发明实施例的客户端的具体的结构框图, 如图 7所示, 该 客户端还包括: 确定模块 72、 第一控制模块 74和第二控制模块 76。 下面对 该结构进行详细说明。 确定模块 72连接至播放模块 66 , 用于确定停止从重传服务器接收视频 数据; 第一控制模块 74连接至确定模块 72 , 用于在确定模块 72确定停止从
重传服务器接收视频数据时, 根据组播服务器的信息从组播服务器接收并播 放视频数据的后续视频数据, 其中, 控制响应信令中还携带有组播月艮务器的 信息。 第二控制模块 76, 用于在确定模块 72确定停止从重传 艮务器接收视频 数据时, 向重传服务器发送控制信令, 其中, 控制信令用于指示重传服务器 停止向客户端发送视频数据。 需要说明的是, 通过本优选实施例, 可以实现在客户端与重传服务器同 步之后, 将客户端与重传服务器的连接转到与组播服务器的连接, 从而实现 该客户端的组播业务。 其中, 确定模块 72具体用于判断在播放过程中是否已经忽略了同步响 应信息中的忽略帧数, 其中, 参数包括忽略帧数, 忽略帧数为不需要播放的 视频帧的数量。 综上所述, 通过本发明实施例, 避免了客户端出现错误视频, 使客户端 的视频能够同步播放, 提高了用户的体验。 显然, 本领域的技术人员应该明白, 上述的本发明的各模块或各步骤可 以用通用的计算装置来实现, 它们可以集中在单个的计算装置上, 或者分布 在多个计算装置所组成的网络上, 可选地, 它们可以用计算装置可执行的程 序代码来实现, 从而, 可以将它们存储在存储装置中由计算装置来执行, 或 者将它们分别制作成各个集成电路模块, 或者将它们中的多个模块或步骤制 作成单个集成电路模块来实现。 这样, 本发明不限制于任何特定的硬件和软 件结合。 以上所述仅为本发明的优选实施例而已, 并不用于限制本发明, 对于本 领域的技术人员来说, 本发明可以有各种更改和变化。 凡在本发明的 ^"神和 原则之内, 所作的任何修改、 等同替换、 改进等, 均应包含在本发明的保护 范围之内。
(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
权 利 要 求 书 Claims
1. 一种组播视频数据的方法, 其特征在于, 包括: 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. 居权利要求 1所述的方法, 其特征在于, 在所述客户端 居所述参数 播放所述视频数据之后, 还包括: 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.
3. 居权利要求 2所述的方法, 其特征在于, 在所述客户端确定停止从所 述重传服务器接收所述视频数据之后, 还包括: 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.
4. 根据权利要求 2或 3所述的方法, 其特征在于, 所述客户端通过以下依 据确定停止从所述重传服务器接收所述视频数据: The method according to claim 2 or 3, wherein the client stops receiving the video data from the retransmission server by determining:
所述客户端在播放过程中已经忽略了所述同步响应信息中携带的 所述参数中的忽略帧数, 其中, 所述忽略帧数为不需要播放的视频帧的 数量。
才艮据权利要求 1所述的方法, 其特征在于, 所述参数包括以下至少之一: 忽略帧数, 所述忽略帧数为不需要播放的视频帧的数量; 忽略帧间隔,所述忽略帧间隔为两个相邻的不被播放的视频帧之间 的视频帧的数量。 一种重传服务器, 用于组播视频数据, 其特征在于, 包括: 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;
第一发送模块,用于向所述客户端发送所述视频数据和携带有所述 同步响应信息的控制响应信令, 以便于所述客户端才艮据所述同步响应信 息中携带的所述参数播放所述视频数据。 根据权利要求 6所述的重传服务器, 其特征在于, 所述参数包括以下至 少之一: 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.
9. 根据权利要求 8所述的客户端, 其特征在于, 还包括: 确定模块, 用于确定停止从所述重传 艮务器接收所述视频数据; 第一控制模块,用于根据所述组播服务器的信息从所述组播服务器 接收并播放所述视频数据的后续视频数据, 其中, 所述控制响应信令中 还携带有所述组播服务器的信息。 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.
10. —种组播视频数据的***, 其特征在于, 包括权利要求 6所述的重传服 务器以及权利要求 8所述的客户端。
A system for multicast video data, comprising the retransmission server of claim 6 and the client of claim 8.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200910168144.7A CN101998143B (en) | 2009-08-26 | 2009-08-26 | Method for multicasting video data, unicast server and client |
CN200910168144.7 | 2009-08-26 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2011022983A1 true WO2011022983A1 (en) | 2011-03-03 |
Family
ID=43627203
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2010/072463 WO2011022983A1 (en) | 2009-08-26 | 2010-05-05 | Method, device and system of multi-cast video data |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN101998143B (en) |
WO (1) | WO2011022983A1 (en) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111246222B (en) * | 2020-03-20 | 2022-04-08 | 深圳宇翊技术股份有限公司 | Method for realizing multicast control audio and video synchronization of PIS (peer to peer system) in recorded broadcast and broadcast-on-demand states |
CN111447482A (en) * | 2020-05-13 | 2020-07-24 | 威盛电子股份有限公司 | Synchronous playing method and system for streaming media |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101022401A (en) * | 2006-02-14 | 2007-08-22 | ***通信集团公司 | Method for providing group broadcasting based on broadcast instruction of server |
JP2008054078A (en) * | 2006-08-25 | 2008-03-06 | Oki Electric Ind Co Ltd | Multicast system |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100477591C (en) * | 2003-04-23 | 2009-04-08 | 华为技术有限公司 | Method for implementing controllable multicast operation |
CN101998174B (en) * | 2009-08-24 | 2012-11-28 | 中兴通讯股份有限公司 | Quick access method, server, client and system of multicast RTP (real time protocol) session |
-
2009
- 2009-08-26 CN CN200910168144.7A patent/CN101998143B/en active Active
-
2010
- 2010-05-05 WO PCT/CN2010/072463 patent/WO2011022983A1/en active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101022401A (en) * | 2006-02-14 | 2007-08-22 | ***通信集团公司 | Method for providing group broadcasting based on broadcast instruction of server |
JP2008054078A (en) * | 2006-08-25 | 2008-03-06 | Oki Electric Ind Co Ltd | Multicast system |
Also Published As
Publication number | Publication date |
---|---|
CN101998143A (en) | 2011-03-30 |
CN101998143B (en) | 2014-03-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5788473B2 (en) | Method and system for synchronizing terminal output | |
CN109889543B (en) | Video transmission method, root node, child node, P2P server and system | |
JP5363473B2 (en) | Method and apparatus for improved media session management | |
JP5930429B2 (en) | Distribution of IP broadcast streaming service using file distribution method | |
CN101998174B (en) | Quick access method, server, client and system of multicast RTP (real time protocol) session | |
US8988486B2 (en) | Adaptive video communication channel | |
WO2011153868A1 (en) | Channel switching method, apparatus and system | |
JP5421346B2 (en) | High-speed transmission method and apparatus for unicast stream in high-speed channel change | |
WO2017096935A1 (en) | Fast channel switching method and server, and iptv system | |
WO2010066135A1 (en) | Channel switching method, device and system | |
EP2566128B1 (en) | Method and server for obtaining key information during fast channel switching | |
WO2010075743A1 (en) | Method and device for displaying time of internet protocol television (iptv) | |
WO2011000253A1 (en) | Media stream processing method and communication system and related devices | |
JP2009284282A (en) | Content server, information processing apparatus, network device, content distribution method, information processing method, and content distribution system | |
JP2012522457A (en) | Method and apparatus for a system for providing media through multicast distribution | |
US20070008969A1 (en) | Apparatuses and methods for delivering data stream content to consumer devices | |
TW201828709A (en) | Detecting and signaling new initialization segments during manifest-file-free media streaming | |
CN108366044B (en) | VoIP remote audio/video sharing method | |
WO2012083841A1 (en) | Method, terminal and system for changing channel | |
WO2009015539A1 (en) | Multicast control method for service of demanding the media content and the system thereof | |
WO2011137848A1 (en) | Method and system for splicing advertisement, splicer and head end device | |
WO2010108416A1 (en) | Method, device and communication system for forwarding scalable video coding data messages | |
JP5610743B2 (en) | Content receiving method and apparatus | |
WO2011022983A1 (en) | Method, device and system of multi-cast video data | |
CN101212407A (en) | Multicast channel quick start method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 10811148 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 10811148 Country of ref document: EP Kind code of ref document: A1 |