WO2010054543A1 - 一种频道切换方法、装置和系统 - Google Patents

一种频道切换方法、装置和系统 Download PDF

Info

Publication number
WO2010054543A1
WO2010054543A1 PCT/CN2009/071338 CN2009071338W WO2010054543A1 WO 2010054543 A1 WO2010054543 A1 WO 2010054543A1 CN 2009071338 W CN2009071338 W CN 2009071338W WO 2010054543 A1 WO2010054543 A1 WO 2010054543A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
packet
client
channel
real
Prior art date
Application number
PCT/CN2009/071338
Other languages
English (en)
French (fr)
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 华为技术有限公司
Priority to EP09825718A priority Critical patent/EP2352289A4/en
Publication of WO2010054543A1 publication Critical patent/WO2010054543A1/zh
Priority to US13/109,153 priority patent/US20110219414A1/en

Links

Classifications

    • 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/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • 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/1881—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with schedule organisation, e.g. priority, sequence management
    • 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/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26616—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for merging a unicast channel into a multicast channel, e.g. in a VOD application, when a client served by unicast channel catches up a multicast channel to save bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2668—Creating a channel for a dedicated end-user group, e.g. insertion of targeted commercials based on end-user profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6408—Unicasting

Definitions

  • the invention relates to a Chinese patent application filed on November 17, 2008 by the Chinese Patent Office, Application No. 200810177329. X, entitled “A Channel Switching Method, Apparatus and System” Priority is hereby incorporated by reference in its entirety.
  • Technical field
  • the present invention relates to the field of communications technologies, and in particular, to a channel switching method, apparatus, and system. Background technique
  • IPTV Internet Protocol Television
  • IPTV Internet Protocol Television
  • the factors that cause the channel switching delay include: the time spent leaving the original channel multicast group, the time spent adding the new channel multicast group, the time when the Set Top Box (STB) cache fills the data, and the time spent waiting for the I frame. . Among them, waiting for the time consumed by the I frame is the most important factor.
  • IPTV generally uses an audio-video compression coding algorithm to encode a picture into an image sequence consisting of an I frame, a P frame, and a B frame.
  • the I frame is a completely encoded frame of the entire picture, which can be independently decoded and displayed, and provides reference for decoding of related P and B frames.
  • the P frame cannot be independently decoded and displayed, and must receive the referenced I frame or the previous P.
  • the frame can only be decoded and displayed; the B frame can not be decoded and displayed independently, and must be decoded after receiving the referenced previous frame (1 frame or frame) and the next frame (P frame).
  • the P frame and the B frame mainly describe the interframe difference, and thus have higher coding efficiency than the I frame.
  • the multimedia data stream corresponding to the IPTV channel needs to be buffered by the cache device.
  • the terminal initiates a session and requests an I frame or a picture group from the cache device (Group of Picture, GOP), joins the multicast group corresponding to the destination channel, and the GOP contains the I frame.
  • the cache device pushes the I frame or the GOP to the terminal through unicast, and the terminal buffers the obtained I frame or GOP, and starts decoding and displaying the received The image sequence; when the terminal finds that the I frame or GOP acquired from the cache device overlaps with the real-time multicast stream, stops acquiring the I frame or the GOP from the cache device.
  • TCP Transmission Control Protocol
  • IP Internet Protocol
  • the terminal When the terminal switches channels, the terminal initiates a separate session to the cache device to trigger the push of the cache data, that is, initiate a unicast connection separately.
  • the cache device will have to support tens of thousands of concurrent session connections at the same time, and the current server can support more than 2500 concurrent connections. .
  • the network scale applicable to the prior art solution is limited by the number of concurrent connections, and the scalability is poor, and it is difficult to support the application requirements of a large number of users simultaneously switching channels.
  • the cache device uses a different maintenance system than the network device, which increases the investment cost and maintenance cost of the IPTV system deployment and operation. Summary of the invention
  • Embodiments of the present invention provide a channel switching method, apparatus, and system for reducing channel switching time and simplifying a user terminal.
  • the multicast IP packet that is pushed is synchronized with the real-time multicast IP4 message of the live channel, If the multicast IP packet that is pushed is synchronized with the real-time multicast IP packet, the multicast IP packet that is cached is pushed to the client, and the real-time multicast IP packet is sent to the multicast IP packet. The client.
  • a cache module configured to cache a multicast IP packet of a live channel
  • a push module configured to receive a channel switching request that is sent by the client to the live channel, and push the multicast IP packet buffered by the cache module to the client;
  • a determining module configured to determine whether the multicast IP packet pushed by the push module is synchronized with the real-time multicast IP packet of the live channel
  • a sending module configured to send the real-time multicast IP4 message to the client when the determining module determines that the pushed multicast IP packet is synchronized with the real-time multicast IP4 message.
  • a multicast source configured to send a multicast IP packet of a live channel to the channel switching device
  • a channel switching device configured to cache a multicast IP packet of the live channel sent by the multicast source, and receive a channel switching request that is sent by the client to switch to the live channel, and push the cache to the client. Determining whether the multicast IP address and the real-time multicast IP packet of the live channel are synchronized, if the pushed multicast IP packet and the real-time multicast are The IP packet is synchronized, and the cached multicast IP packet is sent to the client, and the real-time multicast IP packet is sent to the client.
  • the client is configured to receive a real-time multicast IP packet of the live channel or a multicast IP address of the live channel buffered by the channel switching device.
  • the method for switching the buffered multicast IP packet by the device outside the terminal is switched, and the user terminal is not needed to be modified, thereby improving the universality and scalability of the channel switching scheme.
  • FIG. 1 is a flowchart of a channel switching method according to an embodiment of the present invention
  • 2 is a flowchart of a specific implementation manner of channel switching in an embodiment of the present invention
  • FIG. 3 is a structural diagram of a channel switching apparatus according to an embodiment of the present invention
  • FIG. 4 is a specific structural diagram of a channel switching apparatus according to an embodiment of the present invention.
  • FIG. 5 is a structural diagram of a channel switching system according to an embodiment of the present invention. detailed description
  • FIG. 1 it is a flowchart of a channel switching method according to an embodiment of the present invention, which includes the following steps:
  • Step 101 Cache multicast IP packets of each live channel.
  • the GOP and I frame start and end indications can be performed on the buffered multicast IP packet, indicating the starting position of the multicast IP address that the terminal can independently decode.
  • the indication method may be that the video key information is identified by Deep Packets Inspect (DPI), such as a Program Association Table (PAT) identifier, a Program Map Table (PMT) identifier, and an I frame identifier.
  • DPI Deep Packets Inspect
  • PAT Program Association Table
  • PMT Program Map Table
  • I frame identifier an I frame identifier
  • the video source may perform special information identification in some fields or bits in the header, and when the multicast IP packet is buffered, the video key information is identified according to the special information identifier.
  • Step 102 Receive a channel switching request that is sent by the client and switch to the live channel, and push the cached multicast IP packet of the live channel to the client according to the channel switching request.
  • the multicast IP4 of the channel requested by the client that is requested by the client is pushed to the client.
  • the first multicast IP address that is pushed to the client is the terminal that can be independently decoded from the real-time multicast IP packet of the channel that the client requests to switch to, such as the GOP start message, that is, the I frame. , or PAT/PMT message.
  • the channel switching request sent by the client triggers the push-cached multicast IP packet and reuses Internet Group Management Protocol (IGMP) signaling.
  • IGMP Internet Group Management Protocol
  • the method further includes extracting a media access control (MAC) address of the client from the channel switching request, and setting the destination MAC address of the multicast IP packet to the MAC address of the client. That is, the source MAC address carried in the IGMP signaling in the channel switching request, and then the modified multicast IP packet is used as the multicast IP packet pushed to the client.
  • MAC media access control
  • Step 103 Determine whether the multicast IP packet that is pushed is synchronized with the real-time multicast IP packet of the live channel, and if the multicast IP address that is pushed is synchronized with the real-time multicast IP address of the live channel, execute Step 104.
  • the method for judging whether the pushed multicast IP packet is synchronized with the real-time multicast IP packet includes: determining whether the pushed multicast IP packet and the received real-time multicast IP packet can be seamlessly connected, if the push When the multicast IP packet is seamlessly connected to the received real-time multicast IP packet, the multicast IP packet is synchronized with the real-time multicast IP packet of the live channel.
  • Step 104 Stop pushing the cached multicast IP packet to the client, and send the real-time multicast IP packet to the client.
  • the multicast IP packet and the real-time multicast IP packet are synchronized. If the multicast IP packet is synchronized with the real-time multicast IP packet, Then, the cached multicast IP packet is stopped, the client is added to the multicast group, and the real-time multicast IP packet is sent to the client; the multicast IP packet in the cached requested channel is pushed. If the cached multicast IP packet is not synchronized with the real-time multicast IP packet, the cached multicast IP packet is pushed. When the cached multicast IP packet is pushed, the real-time multicast IP packet is forbidden. Send to the client to avoid having two streams at the same time.
  • channel switching is implemented by using a method of pushing a buffered multicast IP packet by a device outside the terminal, and the user terminal is not needed to be modified, thereby improving the universality and scalability of the channel switching scheme.
  • a flowchart of a specific implementation manner of channel switching in an embodiment of the present invention includes the following steps:
  • Step 201 The head end sends a live channel media stream to the access node.
  • the head end is the source device initiated by the channel media stream, such as an edge server flanked by the metro network device.
  • the way the headend gets the media stream includes recording from satellite TV or forwarding from other wired networks.
  • Access The nodes include devices such as Digital Subscriber Line Access Multiplexer (DSLAM) devices deployed by operators, Optical Line Terminal (OLT) devices, and IP switches.
  • DSLAM Digital Subscriber Line Access Multiplexer
  • OLT Optical Line Terminal
  • IP switches IP switches.
  • the network connection between the headend and the access node may be through a core network, a metropolitan area network, an aggregation network, and other networking modes.
  • the access node can receive the live channel media stream from the head end and can pass through other network devices.
  • the live channel media stream can be sent through the static multicast configuration mode, configured by the operator, regardless of whether the user is watching the user under the access node.
  • the channel the live channel media stream is sent to the access node; the live channel media stream can also be dynamically added to the multicast group.
  • the live channel media stream is not sent to the access node, and when at least one user is watching a channel, the live channel media stream is sent to the access node.
  • the manner in which an access node dynamically joins a multicast group can save network bandwidth. However, if a user switches to a certain channel under the access node, and no user is watching the channel before the access node, the access node dynamically The process of requesting to join the multicast group will introduce additional delays for the user to switch channels.
  • Step 202 The access node caches the multicast IP address of the live channel, and indicates the starting position of the multicast IP packet that the terminal can independently decode in the cache.
  • the cached multicast IP packets and the multicast IP packets sent to the client through normal multicast are from the same source. Therefore, there is no difference in format between the two.
  • the real-time transport protocol (RTP) packet or the transport stream (TS) packet of the video content in the multicast IP packet is not modified.
  • Step 203 The access node sends a live channel media stream to the client.
  • the client is a terminal device for the user to watch the IPTV and initiate a channel switching request, and the client's channel switching request may be triggered by the user by operating a remote controller or other software terminal.
  • the client-to-access node can pass through a routing device such as a home gateway.
  • the connections between the client access nodes include a Digital Subscriber Line (DSL) line and a Passive Optical Network (Passive Optical Network). PON), Ethernet, etc.
  • DSL Digital Subscriber Line
  • Passive Optical Network Passive Optical Network
  • PON Passive Optical Network
  • Ethernet etc.
  • the access node may delay sending the live channel media stream to the client, or directly send the live channel media stream to the client without delay. If the access node delays sending the live channel media stream to the client, the multicast IP packet buffered by the access node may be in time. A media stream that exceeds the real-time channel live broadcast facilitates the time gap problem that occurs when the access node switches from the push-cached multicast IP packet to the normal-channel multicast group packet.
  • Step 204 The client sends a channel switching request to the access node.
  • the client When the user wishes to switch channels, the client sends a channel switching request to the access node.
  • the channel switch request generally includes the leave command and the join command in the IGMP signaling.
  • Step 205 The access node queries the cached terminal that is the closest to the real-time multicast IP packet to independently decode the packet.
  • the terminal that queries the nearest real-time multicast IP 4 can independently decode the message.
  • the live channel content may be a Moving Pictures Experts Group (MPEG) 2 code or an H.264 code.
  • the transmission format of the live channel content may be MPEG2 TS package, or It is a Network Abstraction Layer (NAL) package.
  • NAL Network Abstraction Layer
  • the most recent terminal independently decodable message in the embodiment of the present invention may be differently defined for different encoding technologies and different transmission encapsulation formats. For example, for MPEG2 TS encapsulated video, the terminal may independently decode 4 ⁇ text and may be defined as a GOP. The first 4 essays.
  • Step 206 The access node pushes the buffered multicast IP packet to the client.
  • the unicast MAC is used as the destination MAC address to push the buffered multicast IP packet to the client.
  • the IP packet is a multicast packet.
  • the destination MAC address is a unicast MAC address
  • the access node will only send the buffered multicast IP address to the client requesting the switching channel.
  • the IP packet extracted from the cached multicast IP packet stream that is sent by the client from the access node is the same as the IP packet extracted from the normal multicast group packet. Therefore, the client does not need to modify it. Processing mechanism.
  • Step 207 The access node determines whether the pushed multicast IP packet is synchronized with the real-time multicast IP packet sent by the other client, if the pushed cached multicast IP packet and the real-time multicast sent to other clients If the IP address of the IP address is not synchronized with the real-time multicast IP address sent to other clients, step 206 is performed.
  • Step 208 The access node stops sending the buffered multicast IP packet, and sends the real-time multicast IP packet to the client instead.
  • the access node pushes the cached multicast IP packet to the client, it determines whether the pushed multicast IP packet is synchronized with the real-time multicast IP packet. Since the real-time multicast IP packet sent to the client has a certain delay, the pushed multicast IP address can be synchronized with the real-time multicast IP4 message. After the access node does not forward the real-time multicast IP packet, the access node considers the pushed multicast IP packet and the real-time multicast IP 4 after the access node pushes the buffered multicast IP packet.
  • a small number of packets that occur during the handover process from the cached multicast IP address to the real-time multicast IP address can be compensated by the client requesting retransmission or by the access node at a lower rate.
  • the client receives two multimedia data streams. Because the process takes a short time, the pushed cached multicast IP packet takes up less space and the push rate is lower, which does not affect the client. The bandwidth between the endpoint and the access node.
  • the access node stops pushing the cached multicast IP address to the client and sends the real-time multicast IP packet to the client. Then, the client obtains the real-time multicast packet of the channel in multicast mode and enters the steady state. If the pushed multicast IP packet is not synchronized with the real-time multicast IP packet, the access node continues to push the cached multicast. IP packets to the client.
  • the access node in the embodiment of the present invention does not constitute a limitation of the technical solution of the present invention.
  • Devices that implement channel switching are not limited to access nodes, but also include devices located at other network locations, such as Broadband Remote Access Server (BRAS) devices.
  • the BRAS device sends a code stream of the channel to each user who views a certain channel, and implements the channel switching method in the embodiment of the present invention instead of the access node.
  • BRAS Broadband Remote Access Server
  • the BRAS device sends a code stream of the channel to each user who views a certain channel, and implements the channel switching method in the embodiment of the present invention instead of the access node.
  • the operator can directly provide the live channel message replication by the BRAS device in the case of a small number of users in the previous period to implement channel switching.
  • the channel is switched by using the method of pushing the buffered multicast IP packet, and the user terminal is not required to be modified, and the number of concurrent connections is not limited, thereby reducing the cost of deployment and operation of the IPTV system, and improving the channel switching scheme.
  • Adaptability and scalability reduce channel switching latency.
  • FIG. 3 it is a structural diagram of a channel switching apparatus according to an embodiment of the present invention, including: a buffering module 310, configured to cache a multicast IP packet of each live channel.
  • the cache module 310 is configured to receive a code stream of all live channels, set a cache space for each live channel, and cache a multicast IP packet of the live channel. For each live channel message, only one copy of the data can be cached. Since the cache space of each live channel is independent, when provided to the user When the fast channel switching service is used, the start of reading the cached multicast IP packets does not affect the multicast IP packets that are cached when the fast channel switching service is provided for other users.
  • the pushing module 320 is configured to receive a channel switching request that is sent by the client to switch to the live channel, and push the multicast IP packet buffered by the cache module 310 to the client.
  • the push module 320 is configured to receive a channel switching request sent by the client, and push the multicast IP packet of the channel to which the request is to be switched to the client according to the received order of the buffered multicast IP packet.
  • the first multicast IP packet that is sent to the client is the terminal that can be independently decoded from the real-time multicast IP packet of the channel that the client requests to switch to, such as the GOP start packet, that is, the I frame. Or PAT/PMT message.
  • the channel switching request sent by the client triggers the push-cached multicast IP packet and reuses the IGMP signaling.
  • the method further includes extracting the MAC address of the client from the channel switching request, and setting the destination MAC address of the multicast IP packet to the MAC address of the client, that is, the IGMP letter in the channel switching request.
  • the multicast IP packet can be sent to a specific client without being sent to other clients joining the channel multicast group.
  • the determining module 330 is configured to determine whether the multicast IP packet pushed by the push module 320 is synchronized with the real-time multicast IP packet sent by other clients.
  • the sending module 340 is configured to: when the determining module 330 determines that the pushed multicast IP packet is synchronized with the real-time multicast IP packet sent by the other client, the real-time multicast IP packet is sent to the client that requests the channel switching. .
  • the determining module 330 determines whether the cached multicast IP packet is synchronized with the real-time multicast IP packet, if the cached multicast IP address is used. After the message is synchronized with the real-time multicast IP packet, the push module 320 stops pushing the buffered multicast IP packet, and the sending module 340 sends the real-time multicast IP packet to the client; in the cached channel that is switched to If the multicast IP packet is not synchronized with the real-time multicast IP packet, the push module 320 continues to push the buffered multicast IP packet. In this process, the sending is prohibited. The module 340 sends the real-time multicast IP packet to the client to avoid the existence of two data streams at the same time.
  • the channel is switched by using the method of pushing the buffered multicast IP packet, and the user is not required to be modified.
  • the terminal improves the universality and scalability of the channel switching scheme.
  • FIG. 4 it is a specific structural diagram of a channel switching apparatus according to an embodiment of the present invention, including: a buffering module 410, configured to cache a multicast IP packet of each live channel.
  • the cache module 410 is configured to receive a code stream of all channels, set a buffer space for each channel, and cache a multicast IP packet of the TV channel. For each channel message, only one copy of the data can be cached. Since the buffer space of each channel is independent, when the fast channel switching service is provided for the user, the starting point of reading the cached multicast IP packet does not affect the read buffer when the fast channel switching service is provided for other users. Multicast IP packet.
  • the labeling module 420 is configured to mark the multicast IP packet buffered by the cache module 410, and indicate the starting position of the multicast IP address that the terminal can independently decode in the cache.
  • the above indication manner may be that the key information of the video is identified by the DPI, for example, the PAT identifier, the PMT identifier, the I frame identifier, etc.; the special information may be identified by the video source in some fields or bits in the header, in the cache group.
  • the labeling module 420 identifies the video key information according to the special information identifier.
  • the push module 430 is configured to receive a channel switching request that is sent by the client to switch to the live channel, and push the multicast IP packet buffered by the cache module 410 to the client.
  • the push module 430 is configured to receive a channel switching request sent by the client, and push the multicast IP packet of the channel to which the cache request is switched to the client according to the received order of the buffered multicast IP packet.
  • the first multicast IP packet to be pushed is the terminal that can be independently decoded by the terminal closest to the real-time multicast IP packet of the TV channel that the client requests to switch to.
  • a GOP start message ie an I frame, or
  • the query module 440 is configured to query the cached module 410 to buffer the multicast IP packet from the real-time multicast IP4.
  • the nearest terminal can independently decode the message.
  • the query module 440 queries the cached multicast IP address.
  • the nearest terminal can decode the message independently.
  • the push module 430 pushes the terminal independently decodable message as the first pushed multicast IP packet and pushes it to the client.
  • the setting module 450 is configured to extract the MAC address of the client from the channel switching request, and set the destination MAC address of the buffered multicast IP packet to the MAC address of the client requesting the channel switching.
  • the channel switching request sent by the client triggers the push-cached multicast IP packet and reuses IGMP signaling.
  • the setting module 450 sets the destination MAC address of the buffered multicast IP address to the source MAC address carried in the IGMP signaling in the channel switching request, that is, the client.
  • the MAC address of the terminal itself.
  • the determining module 460 is configured to determine whether the multicast IP packet pushed by the push module 430 is synchronized with the real-time multicast IP packet.
  • the sending module 470 is configured to send the real-time multicast IP packet to the client when the determining module 460 determines that the pushed multicast IP packet is synchronized with the real-time multicast IP packet.
  • the determining module 460 determines whether the cached multicast IP packet is synchronized with the real-time multicast IP packet, if the cached multicast IP packet is in real time.
  • the push module 430 stops the push of the cached multicast IP packet, and the sending module 470 sends the real-time multicast IP packet to the client; in the cached TV channel that is switched to During the process of pushing the multicast IP packet, if the cached multicast IP packet is not synchronized with the real-time multicast IP packet, the push module 430 continues to push the cached multicast IP packet, and the sending module 470 prohibits the real-time multicast. IP packets are sent to the client to prevent two data streams from being present at the same time.
  • the channel is switched by using the method of pushing the buffered multicast IP packet, and the user terminal is not required to be modified, and the number of concurrent connections is not limited, thereby reducing the cost of deployment and operation of the IPTV system, and improving the channel switching scheme.
  • the adaptability and scalability, and the embodiment of the present invention reduces the handover delay by directly pushing the first terminal that is closest to the real-time multicast IP address.
  • FIG. 5 it is a structural diagram of a channel switching system according to an embodiment of the present invention, including: a multicast source 510, configured to send a multicast IP packet of a live channel to the channel switching device 520.
  • the multicast source 510 is a source device initiated by the channel media stream, such as an edge server flanked by the metropolitan area network device.
  • the manner in which the multicast source 510 obtains the media stream includes recording from satellite television or forwarding from other wired networks.
  • the channel switching device 520 includes devices such as a DSLAM device, an OLT device, and an IP switch deployed by an operator.
  • the network connection between the multicast source 510 and the channel switching device 520 may be through a core network, a metropolitan area network, an aggregation network, and other networking modes.
  • the channel switching device 520 is configured to cache the multicast IP packet of the live channel sent by the multicast source 510, receive the channel switching request sent by the client 530 to switch to the live channel, and push the buffered multicast IP4 to the client 530. If the multicast IP address of the push is synchronized with the real-time multicast IP address of the live channel, if the multicast IP packet is synchronized with the real-time multicast IP packet, the cache is stopped from being pushed to the client 530. The multicast IP packet is sent to the client 530.
  • the channel switching device 520 receives the code streams of all live channels, sets a cache space for each live channel, and buffers multicast IP packets of the live channel. For each live channel message, only one copy of the data can be cached. After receiving the channel switching request sent by the client 530, the channel switching device 520 pushes the multicast IP packet of the channel to which the request is to be switched to the client 530 according to the order in which the buffered multicast packets are received.
  • the channel switching device 520 pushes the buffered multicast IP packet to the client 530, it can determine whether the buffered multicast IP packet is synchronized with the real-time multicast IP packet, if the cached multicast IP packet and the real-time group are When the IP packet is synchronized, the multicast IP packet is pushed and sent, and the real-time multicast IP packet is sent to the client 530.
  • the channel switching device 520 is further configured to perform message marking on the buffered multicast IP packet, and indicate a starting position of the multicast IP address that can be independently decoded by the terminal in the cache.
  • the indication mode may be that the key information of the video is identified by the DPI, such as the PAT, the PMT identifier, the I frame identifier, etc., or the special information may be identified by the video source in some fields or bits in the packet header, and the multicast IP packet is cached.
  • the channel switching device 520 identifies the video key information based on the special information identifier.
  • the channel switching device 520 is further configured to query, in the cached multicast IP packet, the multicast IP packet that can be independently decoded by the terminal that is closest to the real-time multicast IP packet of the live channel.
  • the channel switching device 520 can independently decode the 4 ⁇ ⁇ ⁇ , ⁇ ⁇ , , , , , ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ The text is pushed to the client 530 as the first multicast IP packet to be pushed.
  • the channel switching device 520 is further configured to extract the MAC address of the client 530 from the channel switching request, and set the destination MAC address of the buffered multicast IP packet to the MAC address of the client 530.
  • the channel switching request sent by the client triggers the push-cached multicast IP packet and reuses IGMP signaling.
  • the destination MAC address of the buffered multicast IP address is set to the source MAC address carried in the IGMP signaling in the channel switching request. That is, the MAC address of the client 530 itself.
  • the client 530 is configured to receive a real-time multicast IP packet of the live channel or a multicast IP address of the live channel buffered by the channel switching device 520.
  • the client 530 is a terminal device for the user to watch the IPTV and initiate a channel switching request, and the channel switching request of the client 530 may be triggered by the user by operating a remote controller or other software terminal.
  • the client 530 to the channel switching device 520 can pass through a routing device such as a home gateway, and the connection between the client access nodes includes a DSL line, a PON, an Ethernet, and the like.
  • the channel is switched by using the method of pushing the buffered multicast IP packet, and the user terminal is not needed to be modified, thereby improving the universality and scalability of the channel switching scheme.
  • the present invention can be implemented by means of software plus a necessary general hardware platform or by hardware. Based on such understanding, the technical solution of the present invention is essentially Or the part contributing to the prior art can be embodied in the form of a software product stored in a storage medium, including a plurality of instructions for making a terminal device (which can be a mobile phone, a personal computer, a server) , or a network device, etc.) performs the methods described in various embodiments of the present invention.
  • a terminal device which can be a mobile phone, a personal computer, a server
  • a network device etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

一种频道切换方法、 装置和系统 本申请要求于 2008 年 11 月 17 日提交中国专利局、 申请号为 200810177329. X , 发明名称为 "一种频道切换方法、 装置和系统" 的中国 专利申请的优先权， 其全部内容通过引用结合在本申请中。 技术领域
本发明涉及通信技术领域， 特别是涉及一种频道切换方法、 装置和系统。 背景技术
因特网协议电视（ Internet Protocol Television, IPTV )是一种利用宽带有线 网， 集互联网、 多媒体、 通讯等多种技术于一体， 向家庭用户提供包括数字在 内的多种交互式服务的崭新技术。 随着普及程度的提高， IPTV得到了世界范围 内的认可。 然而， IPTV切换频道时存在着很大的时延， 一直困扰着 IPTV用户 及运营商。
导致频道切换时延的因素包括： 离开原频道组播组消耗的时间、 加入新频 道组播组消耗的时间、 机顶盒（Set Top Box, STB ) 緩存填充数据消耗的时间 和等待 I帧消耗的时间。 其中， 等待 I帧消耗的时间是最主要的因素。
IPTV—般使用视音频压缩编码算法， 将画面编码为由 I 帧、 P 帧和 B 帧 组成的图像序列。 I 帧是整个画面完整编码的帧， 可以独立解码显示， 并为相 关的 P 帧和 B 帧的解码提供参考； P 帧不能被独立解码显示， 必须在接收到 所参考的 I帧或前一个 P帧后才能被解码显示； B 帧也不能被独立地解码显示， 必须在接收到所参考的前一帧 （1帧或卩帧）和后一帧 （P帧）后才能被解码显 示。 P 帧和 B 帧主要描述帧间差异， 因而比 I 帧具有更高的编码效率。
由于 P 帧和 B 帧的数量远远多于 I 帧， 当用户切换频道时 , 大部分情况 下遇到的是 P 帧或 B 帧， 导致等待 I帧消耗的时间较长， 频道切换速度慢， 影 响终端用户观看 IPTV节目的感受， 降低用户的忠诚度。
现有技术中， 切换频道前， 需要由緩存设备緩存 IPTV频道对应的多媒体 数据流。 切换频道时， 终端发起会话， 从緩存设备请求 I帧或画面组（Group of Picture, GOP ) , 同时加入目的频道对应的组播组， GOP中包含 I帧； 緩存设 备将 I帧或 GOP通过单播推送给终端， 终端緩存获得的 I帧或 GOP, 并开始解 码显示接收到的图像序列； 当终端发现从緩存设备获取到的 I帧或 GOP与实时 组播流重复时， 停止从緩存设备获取 I帧或 GOP。
发明人在实现本发明的过程中， 发现现有技术至少存在如下问题： 在频道切换的过程中， 终端需要发起的两个不同的传输控制协议
( Transsmission Control Protocol, TCP ) /因特网协议 ( Internet Protocol, IP )栈 Socket, 即单播 Socket和组播 Socket。 其中 , 单播 Socket用于获取緩存的 I帧 或 GOP, 组播 Socket用于获取实时频道组播数据流。 终端接收到两个多媒体数 据流后， 需要对两个数据流进行排序和拼接处理， 使两个数据流在同一个画面 中显示。 由于排序和流拼接处理， 以及两个 Socket的存在， 需要相应地改造 终端， 从而提高了终端的复杂度和成本， 限制了快速频道切换方案的普适性。
终端在切换频道时， 向緩存设备发起单独的会话， 以触发緩存数据的推送， 即单独发起一个单播连接。 如果大量用户同时切换频道， 比如 IPTV节目播放 广告的时候， 成千上万的用户同时切换频道， 緩存设备将必须同时支持上万个 并发会话连接， 而现在的服务器能支持的并发连接不超过 2500。 考虑到 IPTV 系统的海量用户， 现有技术方案适用的网络规模受到并发连接数的限制， 可扩 展性差， 难以支持大量用户同时切换频道的应用需求。 另外， 緩存设备釆用与 网络设备不同的维护系统， 增加了 IPTV系统部署和运营的投资成本和维护成 本。 发明内容
本发明实施例提供一种频道切换方法、 装置和系统， 用于减少频道切换时 间， 简化用户终端。
本发明实施例提出的频道切换方法， 包括：
緩存直播频道的组播因特网协议 IP报文；
接收客户端发送的切换到所述直播频道的频道切换请求， 向所述客户端推 送緩存的所述组播 IP报文；
判断推送的所述组播 IP 4艮文与所述直播频道的实时组播 IP 4艮文是否同步， 如果推送的所述组播 IP报文与所述实时组播 IP报文同步， 则停止向所述客户 端推送緩存的所述组播 IP报文， 将所述实时组播 IP报文发送到所述客户端。
本发明实施例提出的频道切换装置， 包括：
緩存模块， 用于緩存直播频道的组播 IP报文；
推送模块， 用于接收客户端发送的切换到所述直播频道的频道切换请求， 向所述客户端推送所述緩存模块緩存的组播 IP报文；
判断模块， 用于判断所述推送模块推送的组播 IP报文与所述直播频道的实 时组播 IP报文是否同步；
发送模块， 用于在所述判断模块判断所述推送的组播 IP报文与所述实时组 播 IP 4艮文同步时， 将所述实时组播 IP 4艮文发送到所述客户端。
本发明实施例提出的频道切换系统， 包括：
组播源， 用于向频道切换装置发送直播频道的组播 IP报文；
频道切换装置， 用于緩存所述组播源发送的所述直播频道的组播 IP报文， 接收客户端发送的切换到所述直播频道的频道切换请求， 向所述客户端推送緩 存的所述组播 IP 4艮文； 判断推送的所述组播 IP 4艮文与所述直播频道的实时组 播 IP报文是否同步，如果所述推送的组播 IP报文与所述实时组播 IP报文同步， 则停止向所述客户端推送所述緩存的组播 IP报文， 将所述实时组播 IP报文发 送到所述客户端；
客户端， 用于接收所述直播频道的实时组播 IP报文或所述频道切换装置緩 存的所述直播频道的组播 IP 4艮文。
本发明实施例釆用由终端外的设备推送緩存的组播 IP报文的方法切换频 道， 无需改造用户终端， 从而， 提高了频道切换方案的普适性和可扩展性。 附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实施 例或现有技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面描述 中的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付 出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1为本发明实施例中的一种频道切换方法流程图； 图 2为本发明实施例中频道切换的一种具体实现方式流程图； 图 3为本发明实施例中的一种频道切换装置结构图；
图 4为本发明实施例中频道切换装置的一种具体结构图；
图 5为本发明实施例中的一种频道切换系统结构图。 具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行清 楚、 完整地描述， 显然， 所描述的实施例是本发明一部分实施例， 而不是全部 的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有作出创造性劳 动前提下所获得的所有其他实施例， 都属于本发明保护的范围。
如图 1所示， 为本发明实施例中的一种频道切换方法流程图， 包括以下 步骤：
步骤 101 , 緩存每个直播频道的组播 IP报文。
緩存承载直播频道的组播 IP报文时 ,还可以对緩存的组播 IP报文进行 GOP 和 I帧始末标示， 标明终端可独立解码的组播 IP 4艮文的起始位置。 标示方式可 以是通过深度 4艮文检测 （ Deep Packets Inspect, DPI ) 识别视频关键信息， 例如 节目关联表 ( Program Association Table, PAT )标识、节目映射表 ( Program Map Table, PMT ) 标识、 I帧标识等； 也可以由视频源在 4艮文头中的某些字段或比 特位进行特殊信息标识， 在緩存组播 IP报文时， 根据上述特殊信息标识识别出 视频关键信息。
步骤 102, 接收客户端发送的切换到直播频道的频道切换请求， 根据该频 道切换请求向客户端推送緩存的该直播频道的组播 IP报文。
接收到客户端发送的切换到所述直播频道的频道切换请求后， 按照緩存的 组播 IP报文的接收顺序， 向客户端推送緩存的该客户端所请求切换到的频道的 组播 IP 4艮文。 第一个被推送给客户端的组播 IP 4艮文， 是距离客户端请求切换 到的频道的实时组播 IP报文最近的终端可独立解码报文， 如 GOP起始报文， 即 I帧， 或者 PAT/PMT报文。
客户端发送的频道切换请求， 触发推送緩存的组播 IP报文， 重用因特网组 管理协议（Internet Group Management Protocol, IGMP )信令。 上述推送緩存的 组播 IP 4艮文到客户端之前， 还包括从频道切换请求中提取客户端的介质访问控 制 （ Media Access Control, MAC )地址， 将组播 IP报文的目的 MAC地址设置 成客户端的 MAC地址， 即频道切换请求中 IGMP信令携带的源 MAC地址， 然 后将修改后的组播 IP报文作为推送到客户端的组播 IP报文。通过上述设置 MAC 地址的操作， 緩存的组播 IP报文能够发送给特定的客户端， 而不会发送到加入 频道组播组的其他用户端。
步骤 103 ,判断推送的组播 IP报文与该直播频道的实时组播 IP报文是否同 步， 如果推送的组播 IP 4艮文与该直播频道的实时组播 IP 4艮文同步， 则执行步 骤 104。
判断推送的组播 IP报文与实时组播 IP报文是否同步的方式， 还包括： 判 断推送的组播 IP报文与收到的实时组播 IP报文是否能够无缝衔接， 如果推送 的组播 IP报文与收到的实时组播 IP报文能够无缝衔接， 则判断推送的组播 IP 报文与该直播频道的实时组播 IP报文同步。
步骤 104, 停止向客户端推送緩存的组播 IP报文， 将实时组播 IP报文发送 到该客户端。
推送緩存的组播 IP报文到客户端的过程中， 可以判断推送的组播 IP报文 与实时组播 IP报文是否同步， 如果推送的组播 IP报文与实时组播 IP报文同 步， 则停止推送緩存的组播 IP报文， 将该客户端加入组播组并将实时组播 IP报文发送到客户端； 在上述的緩存的被请求的频道的组播 IP报文被推 送过程中， 如果緩存的组播 IP报文与实时组播 IP报文不同步， 则继续推送 緩存的组播 IP报文， 在推送緩存的组播 IP报文时， 禁止将实时组播 IP报文 发送到客户端， 以免同时存在两个数据流。
本发明实施例釆用由终端外的设备推送緩存的组播 IP报文的方法实现频道 切换， 无需改造用户终端， 提高了频道切换方案的普适性和可扩展性。
如图 2所示， 为本发明实施例中频道切换的一种具体实现方式流程图， 包括以下步骤：
步骤 201 , 头端向接入节点发送直播频道媒体流。
头端为频道媒体流发起的源头设备，如侧挂于城域网络设备的边缘服务器。 头端获取媒体流的方式包括从卫星电视录制， 或者从其他有线网络转发。 接入 节点包括运营商部署的数字用户线路接入复用器（ Digital Subscriber Line Access Multiplexer, DSLAM ) 设备、 光线路终端 ( Optical Line Terminal, OLT ) 设备 和 IP交换机等设备。 头端与接入节点之间的网络连接可以是通过核心网、 城域 网、 汇聚网， 以及其他组网方式。
接入节点从头端接收直播频道媒体流可以经过其他网络设备， 直播频道媒 体流的发送可以是通过静态组播配置的方式实现， 由运营商配置， 不论接入节 点下是否有用户在观看某个频道， 该直播频道媒体流都会发送给接入节点； 直 播频道媒体流的发送也可以通过动态加入组播组的方式实现， 当接入节点服务 的用户中， 没有用户在观看某个频道时， 该直播频道媒体流不会发送给该接入 节点， 当至少有一个用户在观看某个频道时， 直播频道媒体流才会发送给该接 入节点。 接入节点动态加入组播组的方式可以节省网络带宽， 但是如果接入节 点下有用户切换到某个频道， 而之前该接入节点下没有用户在观看这个频道， 这时由接入节点动态去请求加入该组播组的过程会给用户切换频道带来额外延 时。
步骤 202, 接入节点緩存直播频道的组播 IP 4艮文， 标明终端可独立解码的 组播 IP报文在緩存中的起始位置。
緩存的组播 IP报文和通过正常组播方式发送给用户端接收的组播 IP报文 来自同一个源头， 因此， 二者在格式上没有区别。 緩存过程中， 对组播 IP报文 里可能 ? 载视频内容的实时传送协议 ( Real-time Transport Protocol, RTP )包或 者传输流 （ Transport Stream, TS ) 包等不做修改。
步骤 203 , 接入节点向客户端发送直播频道媒体流。
客户端为用户观看 IPTV及发起频道切换请求的终端设备， 客户端的频道 切换请求可以是由用户通过操作遥控器或其他软件终端触发。 客户端到接入节 点之间可以经过家庭网关等带路由功能的设备， 客户端接入节点之间的连接包 括数字用户线（ Digital Subscriber Line, DSL )线路、无源光纤网络（ Passive Optical Network, PON ) 、 以太网等。
接入节点从头端接收到直播频道媒体流之后， 可以延时发送直播频道媒体 流到客户端， 也可以不作延时， 直接发送直播频道媒体流到客户端。 如果接入 节点延时发送直播频道媒体流到客户端，接入节点緩存的组播 IP报文可能在时 间上超过实时频道直播的媒体流， 有利于解决接入节点从推送緩存的组播 IP报 文切换到发送普通频道组播组报文时出现的时间缺口问题。
步骤 204, 客户端向接入节点发送频道切换请求。
用户希望切换频道时， 由客户端向接入节点发送频道切换请求。 对于使用 组播技术实现直播频道播放的应用场景来说， 频道切换请求一般包括 IGMP信 令中的 leave命令和 join命令。
步骤 205 , 接入节点查询緩存的距离实时组播 IP报文最近的终端可独立解 码报文。
接入节点从客户端接收频道切换请求后 , 查询距离实时组播 IP 4艮文最近的 终端可独立解码 4艮文。 由于视频编码技术的不同， 直播频道内容可以是动态图 像专家组 （ Moving Pictures Experts Group, MPEG ) 2编码， 也可以是 H.264编 码， 直播频道内容的传输封装格式可以是 MPEG2 TS封装， 也可以是网络提取 层 （ Network Abstraction Layer, NAL ) 封装等。 本发明实施例中的最近的终端 可独立解码报文可以是针对不同编码技术及传输封装格式不同而区别定义， 例 如，对于 MPEG2 TS封装的视频， 终端可独立解码 4艮文可以定义为 GOP起始 4艮 文。
步骤 206, 接入节点向客户端推送緩存的组播 IP报文。
接入节点查询到最近的终端可独立解码 4艮文后， 以单播 MAC为目的 MAC 地址的方式推送緩存的组播 IP报文到客户端。 虽然 IP报文为组播报文， 但是 由于目的 MAC为单播 MAC地址， 接入节点只会把緩存的组播 IP 4艮文发送给 请求切换频道的客户端， 不会组播发送给所有加入到组播组的客户端。 客户端 从接入节点单独推送下来的緩存的组播 IP报文流中提取的 IP报文， 与从普通 组播组报文流中提取的 IP报文形式相同，因此，客户端不用额外修改处理机制。
步骤 207, 接入节点判断推送的组播 IP报文与其向其他客户端发送的实时 组播 IP报文是否同步， 如果推送的緩存的组播 IP报文与向其他客户端发送的 实时组播 IP 4艮文同步， 则执行步骤 208； 如果推送的緩存的组播 IP 4艮文与向其 他客户端发送的实时组播 IP 4艮文不同步， 则执行步骤 206。
步骤 208, 接入节点停止发送緩存的组播 IP报文， 而改为发送实时组播 IP 报文到客户端。 接入节点向客户端推送緩存的组播 IP报文时， 判断推送的组播 IP报文与 实时组播 IP报文是否同步。 由于发送给客户端的实时组播 IP报文有一定的延 时， 所以推送的组播 IP 4艮文能够与实时组播 IP 4艮文同步。 对于接入点不对实 时组播 IP报文延时发送的应用场景， 接入节点将緩存的组播 IP报文推送完毕 后， 即可认为推送的组播 IP 4艮文与实时组播 IP 4艮文同步， 向客户端发送实时 组播 IP 4艮文。 对于由緩存的组播 IP 4艮文到实时组播 IP 4艮文的切换过程中出现 的少量丢包， 可以通过客户端请求重传的方式弥补， 也可以通过由接入节点以 较低速率继续推送緩存的组播 IP报文一段时间弥补。在上述弥补丢包的过程中， 客户端会接收到两个多媒体数据流， 由于该过程时间较短， 推送的緩存的组播 IP报文占用空间较小、推送速率较低， 不会影响客户端与接入节点之间的带宽。
如果推送的组播 IP报文与实时组播 IP报文同步， 则接入节点停止推送緩 存的组播 IP 4艮文到客户端， 向客户端发送实时组播 IP 4艮文。 随后， 客户端通 过组播方式获取该频道的实时组播报文， 进入稳态； 如果推送的组播 IP报文与 实时组播 IP报文不同步， 则接入节点继续推送緩存的组播 IP报文到客户端。
需要强调的是， 本发明实施例中的接入节点并不构成对本发明技术方案的 限定。 实现频道切换功能的设备， 不限于接入节点， 还包括位于其他网络位置 的设备， 如宽带远程接入服务器 （ Broadband Remote Access Server, BRAS )设 备。 BRAS设备给每个观看某个频道的用户都发送一份该频道的码流， 代替接 入节点实施本发明实施例中的频道切换方法。 运营商在部署 IPTV网络结构时， 在前期用户数量不大的情况下， 可以直接由 BRAS设备提供直播频道报文的复 制， 实现频道切换。
本发明实施例釆用推送緩存的组播 IP报文的方法切换频道， 无需改造用户 终端， 且不受并发连接数目的限制， 降低了 IPTV系统部署和运营的成本， 提 高了频道切换方案的普适性和可扩展性， 减少了频道切换时延。
如图 3所示， 为本发明实施例中的一种频道切换装置结构图， 包括： 緩存模块 310, 用于緩存每个直播频道的组播 IP报文。
具体来说， 緩存模块 310用于接收所有直播频道的码流， 对每个直播频道 设置緩存空间， 緩存直播频道的组播 IP报文。 对每个直播频道的报文， 可以只 緩存一份数据。 由于每个直播频道的緩存空间是独立的， 因此， 当为用户提供 快速频道切换服务时， 读取緩存的组播 IP报文的起始点不同不影响为其他用户 提供快速频道切换服务时读取緩存的组播 IP报文。
推送模块 320, 用于接收客户端发送切换到直播频道的频道切换请求， 向 客户端推送緩存模块 310緩存的组播 IP报文。
具体来说， 推送模块 320用于接收客户端发送的频道切换请求， 按照緩存 的组播 IP报文的接收顺序， 向客户端推送緩存其请求切换到的频道的组播 IP 报文。 第一个被推送给客户端的组播 IP报文， 是距离客户端请求切换到的频道 的实时组播 IP报文最近的终端可独立解码报文， 如 GOP起始报文， 即 I帧， 或者 PAT/PMT报文。
客户端发送的频道切换请求， 触发推送緩存的组播 IP报文， 重用 IGMP信 令。 推送緩存的组播 IP报文到客户端之前， 还包括从频道切换请求中提取客户 端的 MAC地址， 将组播 IP报文的目的 MAC地址设置成客户端的 MAC地址， 即频道切换请求中 IGMP信令携带的源 MAC地址，通过上述设置 MAC地址的 操作， 组播 IP报文能够发送给特定的客户端， 而不会发送到加入频道组播组的 其他用户端。
判断模块 330, 用于判断推送模块 320推送的组播 IP报文与向其他客户端 发送的实时组播 IP报文是否同步。
发送模块 340, 用于在判断模块 330判断推送的组播 IP报文与向其他客户 端发送的实时组播 IP报文同步时， 将实时组播 IP报文发送到该请求频道切换 的客户端。
推送模块 320推送緩存的组播 IP报文到请求频道切换的客户端的过程中， 可以由判断模块 330判断緩存的组播 IP报文与实时组播 IP报文是否同步， 如 果緩存的组播 IP报文与实时组播 IP报文同步， 则推送模块 320停止推送緩存 的组播 IP报文， 发送模块 340将实时组播 IP报文发送到客户端； 在上述的 緩存的被切换到的频道的组播 IP报文被推送过程中， 如果緩存的组播 IP 报文与实时组播 IP报文不同步，则推送模块 320继续推送緩存的组播 IP报文， 在此过程中， 禁止发送模块 340将实时组播 IP报文发送到客户端， 以免同 时存在两个数据流。
本发明实施例釆用推送緩存的组播 IP报文的方法切换频道， 无需改造用户 终端， 提高了频道切换方案的普适性和可扩展性。
如图 4所示， 为本发明实施例中频道切换装置的一种具体结构图， 包括： 緩存模块 410, 用于緩存每个直播频道的组播 IP报文。
具体来说， 緩存模块 410用于接收所有频道的码流， 对每个频道设置緩存 空间，緩存电视频道的组播 IP报文。对每个频道的报文， 可以只緩存一份数据。 由于每个频道的緩存空间是独立的， 因此， 当为用户提供快速频道切换服务时， 读取緩存的组播 IP报文的起始点不同不影响为其他用户提供快速频道切换服务 时读取緩存的组播 IP报文。
标示模块 420, 用于对緩存模块 410緩存的组播 IP报文进行报文标示， 标 明终端可独立解码的组播 IP 4艮文在緩存中的起始位置。
上述标示方式可以是通过 DPI识别视频关键信息 , 例如 PAT标识、 PMT 标识 , I帧标识等； 也可以由视频源在 4艮文头中的某些字段或比特位进行特殊信 息标识， 在緩存组播 IP报文时， 标示模块 420根据上述特殊信息标识识别出视 频关键信息。
推送模块 430, 用于接收客户端发送切换到直播频道的频道切换请求， 向 客户端推送緩存模块 410緩存的组播 IP报文。
具体来说， 推送模块 430用于接收客户端发送的频道切换请求， 按照緩存 的组播 IP报文的接收顺序， 向客户端推送緩存的请求切换到的频道的组播 IP 报文。 第一个被推送的组播 IP报文， 是距离客户端请求切换到的电视频道的实 时组播 IP报文最近的终端可独立解码报文。 如 GOP起始报文， 即 I帧， 或者
PAT/PMT报文。
查询模块 440, 用于查询緩存模块 410緩存的组播 IP报文中距离实时组播 IP 4艮文最近的终端可独立解码 4艮文。
推送模块 430接收客户端发送的频道切换请求后， 由查询模块 440查询緩 存的组播 IP 4艮文中距离实时组播 IP 4艮文最近的终端可独立解码 4艮文。 推送模 块 430将该终端可独立解码报文作为第一个被推送的组播 IP报文， 推送到客户 端„
设置模块 450, 用于从频道切换请求中提取客户端的 MAC地址， 将緩存的 组播 IP报文的目的 MAC地址设置成请求频道切换的客户端的 MAC地址。 客户端发送的频道切换请求， 触发推送緩存的组播 IP报文， 重用 IGMP信 令。 推送模块 430推送緩存的组播 IP报文到客户端前， 由设置模块 450将緩存 的组播 IP 4艮文的目的 MAC地址设置成频道切换请求中 IGMP信令携带的源 MAC地址， 即客户端自身的 MAC地址。 通过上述设置 MAC地址的操作， 组 播 IP报文能够发送给特定的客户端， 而不会发送到加入频道组播组的其他客户 端„
判断模块 460,用于判断推送模块 430推送的组播 IP报文与实时组播 IP报 文是否同步。
发送模块 470, 用于在判断模块 460判断推送的组播 IP报文与实时组播 IP 报文同步时， 将实时组播 IP报文发送到客户端。
推送模块 430推送緩存的组播 IP报文到客户端的过程中， 可以由判断模块 460判断緩存的组播 IP报文与实时组播 IP报文是否同步， 如果緩存的组播 IP报文与实时组播 IP报文同步， 则通知推送模块 430停止推送緩存的组播 IP 报文， 由发送模块 470将实时组播 IP报文发送到客户端； 在上述的緩存的 被切换到的电视频道的组播 IP报文被推送过程中，如果緩存的组播 IP报文 与实时组播 IP报文不同步， 则推送模块 430继续推送緩存的组播 IP报文， 禁 止发送模块 470将实时组播 IP报文发送到客户端， 以免同时存在两个数据 流。
本发明实施例釆用推送緩存的组播 IP报文的方法切换频道， 无需改造用户 终端， 且不受并发连接数目的限制， 降低了 IPTV系统部署和运营的成本， 提 高了频道切换方案的普适性和可扩展性， 并且， 本发明实施例通过最先推动距 离实时组播 IP 4艮文最近的第一个终端可独立解码 4艮文减少了切换时延。
如图 5所示， 为本发明实施例中的一种频道切换系统结构图， 包括： 组播源 510, 用于向频道切换装置 520发送直播频道的组播 IP报文。
组播源 510为频道媒体流发起的源头设备， 如侧挂于城域网络设备的边缘 服务器。 组播源 510获取媒体流的方式包括从卫星电视录制， 或者从其他有线 网络转发。 频道切换装置 520包括运营商部署的 DSLAM设备、 OLT设备和 IP 交换机等设备。 组播源 510与频道切换装置 520之间的网络连接可以是通过核 心网、 城域网、 汇聚网， 以及其他组网方式。 频道切换装置 520, 用于緩存组播源 510发送的直播频道的组播 IP报文， 接收客户端 530发送的切换到直播频道的频道切换请求， 向客户端 530推送緩 存的组播 IP 4艮文； 判断推送的组播 IP 4艮文与直播频道的实时组播 IP 4艮文是否 同步， 如果推送的组播 IP报文与实时组播 IP报文同步， 则停止向客户端 530 推送緩存的组播 IP报文， 将实时组播 IP报文发送到客户端 530。
频道切换装置 520接收所有直播频道的码流， 对每个直播频道设置緩存空 间， 緩存直播频道的组播 IP报文。 对每个直播频道的报文， 可以只緩存一份数 据。 频道切换装置 520接收客户端 530发送的频道切换请求后， 按照緩存的组 播 IP报文的接收顺序， 向客户端 530推送緩存其请求切换到的频道的组播 IP 报文。 频道切换装置 520推送緩存的组播 IP报文到客户端 530的过程中， 可以 判断緩存的组播 IP报文与实时组播 IP报文是否同步， 如果緩存的组播 IP报文 与实时组播 IP报文同步， 则停止推送緩存的组播 IP报文， 由将实时组播 IP 报文发送到客户端 530。
频道切换装置 520, 还用于对緩存的所述组播 IP报文进行报文标示， 标明 终端可独立解码的组播 IP 4艮文在緩存中的起始位置。
标示方式可以是通过 DPI识别视频关键信息， 例如 PAT、 PMT标识， I帧 标识等； 也可以由视频源在报文头中的某些字段或比特位进行特殊信息标识， 在緩存组播 IP报文时， 频道切换装置 520根据上述特殊信息标识识别出视频关 键信息。
频道切换装置 520, 还用于查询緩存的组播 IP报文中， 距离直播频道的实 时组播 IP报文最近的终端可独立解码的组播 IP报文。
频道切换装置 520接收客户端 530发送的频道切换请求后， 由查询緩存的 组播 IP 4艮文中距离实时组播 IP 4艮文最近的终端可独立解码 4艮文， 将该终端可 独立解码报文作为第一个被推送的组播 IP报文， 推送到客户端 530。
频道切换装置 520,还用于从频道切换请求中提取客户端 530的 MAC地址， 将緩存的组播 IP报文的目的 MAC地址设置成客户端 530的 MAC地址。
客户端发送的频道切换请求， 触发推送緩存的组播 IP报文， 重用 IGMP信 令。 频道切换装置 520推送緩存的组播 IP报文到客户端前， 将緩存的组播 IP 4艮文的目的 MAC地址设置成频道切换请求中 IGMP信令携带的源 MAC地址， 即客户端 530自身的 MAC地址。 通过上述设置 MAC地址的操作， 组播 IP报 文能够发送给特定的客户端， 而不会发送到加入频道组播组的其他客户端。
客户端 530, 用于接收直播频道的实时组播 IP报文或频道切换装置 520緩 存的直播频道的组播 IP 4艮文。
客户端 530为用户观看 IPTV及发起频道切换请求的终端设备，客户端 530 的频道切换请求可以是由用户通过操作遥控器或其他软件终端触发。客户端 530 到频道切换装置 520之间可以经过家庭网关等带路由功能的设备， 客户端接入 节点之间的连接包括 DSL线路、 PON、 以太网等。
本发明实施例釆用推送緩存的组播 IP报文的方法切换频道，无需改造用户 终端， 提高了频道切换方案的普适性和可扩展性。
通过以上的实施方式的描述， 本领域的技术人员可以清楚地了解到本 发明可借助软件加必需的通用硬件平台的方式来或通过硬件来实现， 基于 这样的理解， 本发明的技术方案本质上或者说对现有技术做出贡献的部分 可以以软件产品的形式体现出来， 该计算机软件产品存储在一个存储介质 中， 包括若干指令用以使一台终端设备（可以是手机， 个人计算机， 服务 器， 或者网络设备等）执行本发明各个实施例所述的方法。
最后应说明的是： 以上实施例仅用以说明本发明的技术方案， 而非对 其限制； 尽管参照前述实施例对本发明进行了详细的说明， 本领域的普通 技术人员应当理解： 其依然可以对前述实施例所记载的技术方案进行修 改， 或者对其中部分技术特征进行等同替换； 而这些修改或者替换， 并不 使相应技术方案的本质脱离本发明实施例技术方案的精神和范围。

Claims

权 利 要 求 书
1、 一种频道切换方法， 其特征在于， 包括：
緩存直播频道的组播因特网协议 IP报文；
接收客户端发送的切换到所述直播频道的频道切换请求， 向所述客户端推 送緩存的所述组播 IP报文；
判断推送的所述组播 IP 4艮文与所述直播频道的实时组播 IP 4艮文是否同步， 如果推送的所述组播 IP报文与所述实时组播 IP报文同步， 则停止向所述客户 端推送緩存的所述组播 IP报文， 将所述实时组播 IP报文发送到所述客户端。
2、 如权利要求 1所述的方法， 其特征在于， 在所述緩存直播频道的组播 IP
4艮文之后， 还包括：
标明终端可独立解码的组播 IP 4艮文在緩存中的起始位置。
3、 如权利要求 2所述的方法， 其特征在于， 向所述客户端推送的第一个緩 存的组播 IP报文为所述緩存的组播 IP报文中， 距离所述直播频道的实时组播 IP 4艮文最近的终端可独立解码的组播 IP 4艮文。
4、 如权利要求 3所述的方法， 其特征在于， 在所述接收客户端发送的切换 到所述直播频道的频道切换请求之后， 所述方法还包括：
查询所述距离所述直播频道的实时组播 IP 4艮文最近的终端可独立解码的组 播 IP报文。
5、 如权利要求 1所述的方法， 其特征在于， 在所述向客户端推送緩存的所 述组播 IP 4艮文之前， 所述方法还包括：
从所述频道切换请求中提取所述客户端的介质访问控制 MAC地址， 将所 述緩存的组播 IP 4艮文的目的 MAC地址设置成所述客户端的 MAC地址。
6、 一种频道切换装置， 其特征在于， 包括：
緩存模块， 用于緩存直播频道的组播 IP报文；
推送模块， 用于接收客户端发送的切换到所述直播频道的频道切换请求， 向所述客户端推送所述緩存模块緩存的组播 IP报文；
判断模块， 用于判断所述推送模块推送的组播 IP报文与所述直播频道的实 时组播 IP报文是否同步；
发送模块， 用于在所述判断模块判断所述推送的组播 IP报文与所述实时组 播 IP报文同步时， 将所述实时组播 IP报文发送到所述客户端。
7、 如权利要求 6所述的装置， 其特征在于， 还包括：
标示模块， 用于对所述緩存模块緩存的所述组播 IP报文进行报文标示， 标 明终端可独立解码的组播 IP 4艮文在緩存中的起始位置。
8、 如权利要求 7所述的装置， 其特征在于， 还包括：
查询模块， 用于查询所述緩存模块緩存的所述组播 IP报文中， 距离所述直 播频道的实时组播 IP 4艮文最近的终端可独立解码的组播 IP 4艮文。
9、 如权利要求 6所述的装置， 其特征在于， 还包括：
设置模块， 用于从所述频道切换请求中提取所述客户端的 MAC地址， 将 所述緩存的组播 IP报文的目的 MAC地址设置成所述客户端的 MAC地址。
10、 一种频道切换系统， 其特征在于， 包括：
组播源， 用于向频道切换装置发送直播频道的组播 IP报文；
频道切换装置， 用于緩存所述组播源发送的所述直播频道的组播 IP报文， 接收客户端发送的切换到所述直播频道的频道切换请求， 向所述客户端推送緩 存的所述组播 IP 4艮文； 判断推送的所述组播 IP 4艮文与所述直播频道的实时组 播 IP报文是否同步，如果所述推送的组播 IP报文与所述实时组播 IP报文同步， 则停止向所述客户端推送所述緩存的组播 IP报文， 将所述实时组播 IP报文发 送到所述客户端；
客户端， 用于接收所述直播频道的实时组播 IP报文或所述频道切换装置緩 存的所述直播频道的组播 IP 4艮文。
11、 如权利要求 10所述的系统， 其特征在于， 所述频道切换装置， 还用于 对所述緩存的所述组播 IP 4艮文进行 4艮文标示， 标明终端可独立解码的组播 IP 报文在緩存中的起始位置。
12、 如权利要求 10所述的系统， 其特征在于， 所述频道切换装置， 还用于 查询所述緩存的组播 IP报文中， 距离所述直播频道的实时组播 IP报文最近的 终端可独立解码的组播 IP 4艮文。
13、 如权利要求 10所述的系统， 其特征在于， 所述频道切换装置， 还用于 从所述频道切换请求中提取所述客户端的 MAC地址， 将所述緩存的组播 IP报 文的目的 MAC地址设置成所述客户端的 MAC地址。
PCT/CN2009/071338 2008-11-17 2009-04-17 一种频道切换方法、装置和系统 WO2010054543A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP09825718A EP2352289A4 (en) 2008-11-17 2009-04-17 METHOD, DEVICE AND CHANNEL SWITCHING SYSTEM
US13/109,153 US20110219414A1 (en) 2008-11-17 2011-05-17 Method, apparatus, and system for switching channels

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810177329.X 2008-11-17
CN200810177329.XA CN101742269A (zh) 2008-11-17 2008-11-17 一种频道切换方法、装置和系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/109,153 Continuation US20110219414A1 (en) 2008-11-17 2011-05-17 Method, apparatus, and system for switching channels

Publications (1)

Publication Number Publication Date
WO2010054543A1 true WO2010054543A1 (zh) 2010-05-20

Family

ID=42169611

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/071338 WO2010054543A1 (zh) 2008-11-17 2009-04-17 一种频道切换方法、装置和系统

Country Status (4)

Country Link
US (1) US20110219414A1 (zh)
EP (1) EP2352289A4 (zh)
CN (1) CN101742269A (zh)
WO (1) WO2010054543A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120163290A1 (en) * 2010-12-28 2012-06-28 Broadcom Corporation Internet protocol low noise block front end architecture

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101753973B (zh) * 2008-12-12 2013-01-02 华为技术有限公司 一种频道切换方法、装置和系统
US10949458B2 (en) 2009-05-29 2021-03-16 Inscape Data, Inc. System and method for improving work load management in ACR television monitoring system
US10375451B2 (en) 2009-05-29 2019-08-06 Inscape Data, Inc. Detection of common media segments
US9055309B2 (en) 2009-05-29 2015-06-09 Cognitive Networks, Inc. Systems and methods for identifying video segments for displaying contextually relevant content
US8595781B2 (en) 2009-05-29 2013-11-26 Cognitive Media Networks, Inc. Methods for identifying video segments and displaying contextual targeted content on a connected television
US9449090B2 (en) 2009-05-29 2016-09-20 Vizio Inscape Technologies, Llc Systems and methods for addressing a media database using distance associative hashing
US10116972B2 (en) 2009-05-29 2018-10-30 Inscape Data, Inc. Methods for identifying video segments and displaying option to view from an alternative source and/or on an alternative device
US9838753B2 (en) 2013-12-23 2017-12-05 Inscape Data, Inc. Monitoring individual viewing of television events using tracking pixels and cookies
US10192138B2 (en) 2010-05-27 2019-01-29 Inscape Data, Inc. Systems and methods for reducing data density in large datasets
CN102572547B (zh) * 2010-12-15 2014-06-11 中兴通讯股份有限公司 快速接入组播组的同步方法、同步装置和终端
CN102647624A (zh) * 2011-02-18 2012-08-22 中兴通讯股份有限公司 一种码流数据的干扰处理方法和系统
CN103716677A (zh) * 2012-09-28 2014-04-09 珠海扬智电子科技有限公司 选择与自订功能频道的装置及其方法
CN105103566B (zh) * 2013-03-15 2019-05-21 构造数据有限责任公司 用于识别视频片段以便显示上下文相关内容的系统和方法
WO2014145947A1 (en) 2013-03-15 2014-09-18 Zeev Neumeier Systems and methods for identifying video segments for displaying contextually relevant content
US20150012660A1 (en) * 2013-07-05 2015-01-08 Nokia Corporation Method and apparatus for quick content channel discovery, streaming, and switching
US9955192B2 (en) 2013-12-23 2018-04-24 Inscape Data, Inc. Monitoring individual viewing of television events using tracking pixels and cookies
CA2973740C (en) 2015-01-30 2021-06-08 Inscape Data, Inc. Methods for identifying video segments and displaying option to view from an alternative source and/or on an alternative device
CA2982797C (en) 2015-04-17 2023-03-14 Inscape Data, Inc. Systems and methods for reducing data density in large datasets
US10080062B2 (en) 2015-07-16 2018-09-18 Inscape Data, Inc. Optimizing media fingerprint retention to improve system resource utilization
AU2016291690B2 (en) 2015-07-16 2020-08-27 Inscape Data, Inc. Prediction of future views of video segments to optimize system resource utilization
AU2016293601B2 (en) 2015-07-16 2020-04-09 Inscape Data, Inc. Detection of common media segments
JP6763019B2 (ja) 2015-07-16 2020-09-30 インスケイプ データ インコーポレイテッド メディアセグメント識別効率向上のために探索索引を区分するためのシステムおよび方法
CN105100888B (zh) * 2015-07-17 2017-12-19 上海斐讯数据通信技术有限公司 一种基于olt设备的iptv频道切换加速的方法
CN105516115B (zh) * 2015-12-02 2019-06-18 华为软件技术有限公司 一种频道快速播放的方法及用户设备ue
CN105376613B (zh) 2015-12-10 2019-05-10 华为技术有限公司 一种快速频道切换方法、服务器及iptv系统
CN105516672A (zh) * 2015-12-17 2016-04-20 四川物联亿达科技有限公司 一种基于物联传感云的实时流媒体播放系统及方法
CN106937155B (zh) * 2015-12-29 2020-06-02 北京华为数字技术有限公司 接入设备、因特网协议电视iptv系统和频道切换方法
US10250486B2 (en) * 2016-10-14 2019-04-02 Gvbb Holdings S.A.R.L. System and method for isochronous switching of packetized media streams
CN106792120B (zh) * 2017-02-07 2020-06-16 海信视像科技股份有限公司 视频画面的显示方法、装置和终端
KR102690528B1 (ko) 2017-04-06 2024-07-30 인스케이프 데이터, 인코포레이티드 미디어 시청 데이터를 사용하여 디바이스 맵의 정확도를 향상시키는 시스템 및 방법
KR101986099B1 (ko) * 2018-01-05 2019-06-05 (주)에프씨아이 웨이크업 빈도를 줄이기 위한 필터링 방법 및 장치
CN109067578B (zh) * 2018-07-31 2021-05-25 杭州迪普科技股份有限公司 一种组播快速切换的方法和装置
CN111586460A (zh) * 2020-04-03 2020-08-25 深圳市天威视讯股份有限公司 一种频道切换方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1881925A (zh) * 2006-05-10 2006-12-20 上海市电信有限公司 在因特协议音视频广播网络直播频道切换的方法及结构
CN1893364A (zh) * 2005-03-28 2007-01-10 阿尔卡特公司 广播多媒体流中的关键信息同步
CN101009812A (zh) * 2005-12-02 2007-08-01 阿尔卡特公司 基于网络的即时回放和时移重放
CN101047838A (zh) * 2006-03-27 2007-10-03 中兴通讯股份有限公司 一种减少直播频道切换响应时间的方法
CN101132521A (zh) * 2007-09-25 2008-02-27 华为技术有限公司 一种实现iptv频道切换的方法和装置

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6763019B2 (en) * 2002-03-05 2004-07-13 Nokia Corporation Method and system for authenticated fast channel change of media provided over a DSL connection
US7073189B2 (en) * 2002-05-03 2006-07-04 Time Warner Interactive Video Group, Inc. Program guide and reservation system for network based digital information and entertainment storage and delivery system
EP1680886B1 (en) * 2003-10-07 2010-02-24 Thomson Licensing Multicast over unicast in a network
US7562375B2 (en) * 2003-10-10 2009-07-14 Microsoft Corporation Fast channel change
US20060018335A1 (en) * 2004-07-26 2006-01-26 Koch Christopher D Multicast to unicast traffic conversion in a network
US7505447B2 (en) * 2004-11-05 2009-03-17 Ruckus Wireless, Inc. Systems and methods for improved data throughput in communications networks
EP1675399A3 (en) * 2004-12-23 2009-04-29 Bitband Technologies Ltd. Fast channel switching for digital TV
US7804831B2 (en) * 2005-04-01 2010-09-28 Alcatel Lucent Rapid media channel changing mechanism and access network node comprising same
US7965771B2 (en) * 2006-02-27 2011-06-21 Cisco Technology, Inc. Method and apparatus for immediate display of multicast IPTV over a bandwidth constrained network
US8416797B2 (en) * 2006-11-10 2013-04-09 Telefonaktiebolaget Lm Ericsson (Publ) Providing IPTV multicasts
US20080181256A1 (en) * 2006-11-22 2008-07-31 General Instrument Corporation Switched Digital Video Distribution Infrastructure and Method of Operation
EP2103127A4 (en) * 2006-12-20 2011-01-26 Ericsson Telefon Ab L M METHOD AND NODE IN IPTV NETWORK
US8769591B2 (en) * 2007-02-12 2014-07-01 Cisco Technology, Inc. Fast channel change on a bandwidth constrained network
CN101060617B (zh) * 2007-05-22 2010-07-28 华为技术有限公司 一种视频点播控制方法、客户端设备和切换控制装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1893364A (zh) * 2005-03-28 2007-01-10 阿尔卡特公司 广播多媒体流中的关键信息同步
CN101009812A (zh) * 2005-12-02 2007-08-01 阿尔卡特公司 基于网络的即时回放和时移重放
CN101047838A (zh) * 2006-03-27 2007-10-03 中兴通讯股份有限公司 一种减少直播频道切换响应时间的方法
CN1881925A (zh) * 2006-05-10 2006-12-20 上海市电信有限公司 在因特协议音视频广播网络直播频道切换的方法及结构
CN101132521A (zh) * 2007-09-25 2008-02-27 华为技术有限公司 一种实现iptv频道切换的方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2352289A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120163290A1 (en) * 2010-12-28 2012-06-28 Broadcom Corporation Internet protocol low noise block front end architecture
US10038493B2 (en) * 2010-12-28 2018-07-31 Avago Technologies General Ip (Singapore) Pte. Ltd Internet protocol low noise block front end architecture

Also Published As

Publication number Publication date
CN101742269A (zh) 2010-06-16
EP2352289A4 (en) 2012-06-27
EP2352289A1 (en) 2011-08-03
US20110219414A1 (en) 2011-09-08

Similar Documents

Publication Publication Date Title
WO2010054543A1 (zh) 一种频道切换方法、装置和系统
US8935736B2 (en) Channel switching method, channel switching device, and channel switching system
US8495688B2 (en) System and method for fast start-up of live multicast streams transmitted over a packet network
CA2761846C (en) Method, apparatus and system for reducing media delay
US20120063462A1 (en) Method, apparatus and system for forwarding video data
WO2011153868A1 (zh) 频道切换方法、装置及系统
WO2009039741A1 (fr) Procédé et dispositif permettant la commutation de chaînes iptv
CA2903319A1 (en) Devices, systems, and methods for converting or translating dynamic adaptive streaming over http (dash) to http live streaming (hls)
CN101316357A (zh) 一种频道切换的方法、终端和媒体服务器
WO2010048825A1 (zh) 丢包抑制重传的方法、网络节点和系统
WO2018174367A1 (ko) 방송 신호 송수신 방법 및 장치
CN110324580B (zh) 一种基于视联网的监控视频播放方法及装置
WO2007045140A1 (fr) Methode en temps reel pour transferer des donnees multimedia
WO2010114450A1 (en) Methods and arrangements for channel change in an iptv network
CN101489101B (zh) 一种ip电视频道切换处理方法、装置和系统
TW201204037A (en) Use of picture-in-picture stream for internet protocol television fast channel change
KR100848309B1 (ko) 고속 버퍼링 스위치를 이용한 인터넷 방송 서비스 제공방법 및 그 장치
WO2010115376A1 (zh) 一种媒体流切换方法、装置和系统
WO2009140909A1 (zh) 强制组播的方法和系统、以及路由设备、终端设备
WO2009089755A1 (fr) Procédé et dispositif pour améliorer l'expérience de l'utilisateur de la télévision par ip
WO2018186550A1 (ko) 방송 신호 송수신 방법 및 장치
El Alami et al. A new method to reduce the bandwidth of IPTV systems

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: 09825718

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2009825718

Country of ref document: EP