WO2011022983A1 - Procédé, dispositif et système de données vidéo de multidiffusion - Google Patents

Procédé, dispositif et système de données vidéo de multidiffusion Download PDF

Info

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
Application number
PCT/CN2010/072463
Other languages
English (en)
Chinese (zh)
Inventor
桑卓
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2011022983A1 publication Critical patent/WO2011022983A1/fr

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

La présente invention se rapporte à un procédé, à un dispositif et à un système de données vidéo de multidiffusion. le procédé comprend les étapes suivantes : un serveur de retransmission reçoit du client la signalisation de demande de commande pour demander les données vidéo, la signalisation de demande de commande comprenant les informations de demande de synchronisation (S202); le serveur de retransmission génère les informations de réponse de synchronisation selon les informations de demande de synchronisation et les données vidéo stockées provenant d'un serveur de multidiffusion, les informations de réponse de synchronisation comprenant les paramètres pour commander la lecture des données vidéo (S204); le serveur de retransmission envoie les données vidéo et la signalisation de réponse de commande avec les informations de réponse de synchronisation, la signalisation de réponse de commande comprenant les informations de réponse de synchronisation de telle sorte que le client lise les données vidéo selon les paramètres présents dans les informations de réponse de synchronisation (S206). Avec la solution, on peut éviter la génération de données vidéo erronées chez le client et synchroniser la lecture des données vidéo chez le client afin d'améliorer l'expérience de l'utilisateur.
PCT/CN2010/072463 2009-08-26 2010-05-05 Procédé, dispositif et système de données vidéo de multidiffusion WO2011022983A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200910168144.7 2009-08-26
CN200910168144.7A CN101998143B (zh) 2009-08-26 2009-08-26 组播视频数据的方法、单播服务器及客户端

Publications (1)

Publication Number Publication Date
WO2011022983A1 true WO2011022983A1 (fr) 2011-03-03

Family

ID=43627203

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/072463 WO2011022983A1 (fr) 2009-08-26 2010-05-05 Procédé, dispositif et système de données vidéo de multidiffusion

Country Status (2)

Country Link
CN (1) CN101998143B (fr)
WO (1) WO2011022983A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111246222B (zh) * 2020-03-20 2022-04-08 深圳宇翊技术股份有限公司 一种实现pis在录播和垫播状态下多播控音视频同步方法
CN111447482A (zh) * 2020-05-13 2020-07-24 威盛电子股份有限公司 串流媒体同步播放方法及串流媒体同步播放系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101022401A (zh) * 2006-02-14 2007-08-22 中国移动通信集团公司 基于服务器的播出指令提供组播的方法
JP2008054078A (ja) * 2006-08-25 2008-03-06 Oki Electric Ind Co Ltd マルチキャストシステム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101453350B (zh) * 2003-04-23 2010-11-10 华为技术有限公司 可控组播业务的实现方法
CN101998174B (zh) * 2009-08-24 2012-11-28 中兴通讯股份有限公司 组播rtp会话快速接入的方法、服务器、客户端及系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101022401A (zh) * 2006-02-14 2007-08-22 中国移动通信集团公司 基于服务器的播出指令提供组播的方法
JP2008054078A (ja) * 2006-08-25 2008-03-06 Oki Electric Ind Co Ltd マルチキャストシステム

Also Published As

Publication number Publication date
CN101998143A (zh) 2011-03-30
CN101998143B (zh) 2014-03-12

Similar Documents

Publication Publication Date Title
JP5788473B2 (ja) 端末の出力を同期させる方法およびシステム
JP5363473B2 (ja) 改善されたメディア・セッション管理の方法と装置
JP5930429B2 (ja) ファイル配信方式を使用したｉｐブロードキャストストリーミングサービスの配信
CN109889543B (zh) 视频传输的方法、根节点、子节点、p2p服务器和系统
US8988486B2 (en) Adaptive video communication channel
WO2011022994A1 (fr) Procédé, appareil et système d'acquisition rapide de sessions de protocole de transport de multidiffusion en temps réel
JP4702397B2 (ja) コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システム
WO2011153868A1 (fr) Procédé, appareil et système pour la commutation de voies
JP5421346B2 (ja) 高速チャンネル変更におけるユニキャストストリームの高速送信方法および装置
WO2017096935A1 (fr) Procédé et serveur de commutation de canal rapide, et système iptv
WO2010066135A1 (fr) Procédé, dispositif et système de commutation de canal
EP2566128B1 (fr) Procédé et serveur pour l'obtention d'information clé pendant une commutation de canal rapide
WO2010075743A1 (fr) Procédé et dispositif pour afficher le temps d'une télévision sur protocole internet (iptv)
WO2011000253A1 (fr) Procédé de traitement de flux multimédia et système de communication et dispositifs associés
JP2012522457A (ja) マルチキャスト配信を通じてメディアを提供するシステムのための方法及び装置
US20070008969A1 (en) Apparatuses and methods for delivering data stream content to consumer devices
TW201828709A (zh) 在無清單檔案媒體串流期間偵測及發信新初始化區段
CN108366044B (zh) 一种VoIP远程音视频共享方法
WO2012083841A1 (fr) Procédé, terminal et système pour changer de canal
WO2009015539A1 (fr) Procédé de commande multidiffusion pour service de demande de contenu multimédia et son système
WO2011137848A1 (fr) Procédé et système pour le collage d'une annonce publicitaire, dispositif de collage et dispositif côté tête de réseau
WO2010108416A1 (fr) Procédé, dispositif et système de communication pour la transmission de messages de données en codage vidéo évolutif
JP5610743B2 (ja) コンテンツ受信方法及び装置
WO2011022983A1 (fr) Procédé, dispositif et système de données vidéo de multidiffusion
CN101212407A (zh) 组播频道快速启动的方法

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