[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2010025635A1 - 一种播放切换方法、媒体服务器、用户终端和系统 - Google Patents

一种播放切换方法、媒体服务器、用户终端和系统 Download PDF

Info

Publication number
WO2010025635A1
WO2010025635A1 PCT/CN2009/072694 CN2009072694W WO2010025635A1 WO 2010025635 A1 WO2010025635 A1 WO 2010025635A1 CN 2009072694 W CN2009072694 W CN 2009072694W WO 2010025635 A1 WO2010025635 A1 WO 2010025635A1
Authority
WO
WIPO (PCT)
Prior art keywords
media server
user terminal
media
iptv user
iptv
Prior art date
Application number
PCT/CN2009/072694
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 华为技术有限公司
Publication of WO2010025635A1 publication Critical patent/WO2010025635A1/zh

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/1083—In-session procedures
    • H04L65/1093—In-session procedures by adding participants; by removing participants
    • 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/1083—In-session procedures
    • H04L65/1094—Inter-user-equipment sessions transfer or sharing

Definitions

  • Playback switching method media server, user terminal and system
  • the present invention relates to the field of communications, and in particular, to a method for playing handover, a media server, a user terminal, and a system. Background technique
  • IPTV Internet Protoc book ol Television
  • IPTV media servers provide users with media services such as live broadcast, on-demand, recording, time-shifting and other value-added multimedia services based on IP networks through IPTV user terminals (eg, IPTV set-top boxes, PC terminals, and mobile terminals).
  • IPTV user terminals eg, IPTV set-top boxes, PC terminals, and mobile terminals.
  • the IPTV system is a distributed network system. The media data is distributed on the media server at the edge of the network. The IPTV system can locate most media play requests initiated by the user terminal to the edge of the network, and directly provide information to the user by the edge media server. Media playback service.
  • IP network Unlike traditional analog TV and digital TV, which is widely deployed, a powerful IP network can not only support IPTV systems to deliver high-quality media data to user terminals, but also enable users to rely on the interaction capabilities of IP networks to interact with media content.
  • IP network since the IP network only provides a "best effort" data transmission service, in the case where the IP network suddenly has congestion, the IPTV user terminal may not receive the media data transmitted by the media server in a short time. This will cause a brief interruption in media playback.
  • the IPTV user terminal will completely lose the connection with the media server currently providing the service. The above interruption of playback will result in the user not being able to watch the program normally, which will greatly affect the user's experience.
  • the IPTV application server sends an address of a set of media servers to the IPTV user terminal.
  • the IPTV user terminal connects to other media servers in the set of addresses to obtain data.
  • the invention provides a play switching method, a media server, a user terminal and a system, which solves the data conflict problem caused by the play switching when a play interruption occurs while implementing seamless handover. Specifically include:
  • a method for playing a switch comprising:
  • the IPTV user terminal sends data
  • Media data is provided to the IPTV user terminal according to the handover request.
  • a method for playing a switch comprising:
  • a media server comprising the following modules:
  • a receiving module configured to receive a handover request sent by the IPTV user terminal, where the handover request includes an identifier of the first media server;
  • a sending module configured to send a first stop notification according to the handover request; and provide media data to the IPTV user terminal according to the handover request.
  • An IPTV user terminal including:
  • a sending module configured to send a handover request to the second media server, request the second media server to notify the first media server to stop sending media data to the network television IPTV user terminal, and request the second media server to send the IPTV user
  • the terminal sends media data
  • the receiving module is configured to receive and play media data.
  • a play switching system comprising a plurality of first media servers and a second media server:
  • a second media server configured to receive a handover request sent by the network television IPTV user terminal, and switch according to the Sending a stop notification to the first media server, informing it to stop sending media data to the IPTV user terminal; and delivering media data to the IPTV user terminal;
  • a first media server configured to receive the stop notification, and stop sending media data to the IPTV user terminal according to the stop notification
  • the second media server After receiving the handover request sent by the terminal, the second media server sends the media data to the terminal according to the handover request, so that the user terminal can play the seamless handover after receiving the media data interruption of the first media server, and further
  • the interaction between the second media server and the first media server avoids the problem of data collision caused by repeated transmission of data.
  • the entire switching operation is only between the IPTV user terminal and each media server, without the participation of a third party.
  • FIG. 1 is a structural diagram of a system for implementing playback switching according to an embodiment of the present invention
  • FIG. 2 is a schematic structural diagram of a media server according to an embodiment of the present invention.
  • FIG. 3 is a schematic structural diagram of an IPTV user terminal according to an embodiment of the present disclosure.
  • FIG. 4 is a flowchart of a method for playing handover according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of a method for playing a handover according to an embodiment of the present invention. detailed description
  • FIG. 1 is a structural diagram of a system for implementing play switching according to an embodiment of the present invention.
  • the system includes: an IPTV application server 100, and a plurality of media servers.
  • two instances are included, including a first media server 101 and a second media server 102.
  • the system provides IPTV service to the IPTV user terminal 103 and implements play switching.
  • the media server provided in this embodiment can serve as both the first media server and the second media server.
  • other numbers of media servers may be included in the system, and the specific working principle is the same as this embodiment. among them:
  • the IPTV application server 100 is configured to record status information of all media servers (including the first media server and the second media server) in the system, such as whether the current status is available, and update the status information, where the update may be a real-time update or Periodic updates, etc.
  • the status information may be recorded by using an identifier description of the available media server and a corresponding status, and the recording manner may be in the form of an IP address list or the like; receiving a play service request sent by the IPTV user terminal 103, and selecting a suitable one from the status information.
  • Available media services for providing services to the IPTV user terminal 103 And sending an identifier of the available media server to the IPTV user terminal 103.
  • the IPTV application server 100 can also actively update the available media server identifiers in the IPTV user terminal 103.
  • the second media server 102 is configured to receive a handover request sent by the IPTV user terminal 103, where the handover request includes a handover identifier, an identifier of the first media server 101, and session information of the first media server 101 and the IPTV user terminal 103. Session ID (Identity, label).
  • the second media server 102 sends a stop notification to the first media server according to the information in the request, informing it to stop transmitting the media data to the IPTV user terminal 103.
  • the sending of the stop notification may be multiple times. When the stop notification is sent multiple times, the second media server 102 may send the first media server.
  • the second media server 102 further provides media data to the IPTV user terminal 103 according to the handover request sent by the IPTV user terminal 103; for example, if the handover request message is The playing status information, such as the playing time point information or the starting frame number of the playing, provides the media data to the IPTV user terminal 103 according to the information; or after receiving the stop confirmation message of the first media server 101, The media data is further provided to the IPTV user terminal 103 based on the request sent by the IPTV user terminal 103.
  • the UDP (User Datagram Protocol)-based suspension request may not be accepted by the media server, and two media servers may simultaneously send media data to an IPTV application terminal.
  • the second media server 102 may further determine whether the second media server is providing media data to the IPTV user terminal 103 after receiving the handover request sent by the IPTV user terminal 103, and if yes, suspend the The IPTV user terminal 103 sends the media data; according to the information in the request, such as the first media server identifier, the original session information, etc., sends a stop notification to the first media server 101, notifying that it stops sending the media data to the IPTV user terminal 103, and then And continuing to send the media data to the IPTV user terminal 103; after receiving the stop confirmation message of the first media server 101, the media data may continue to be sent to the IPTV user terminal 103; and may further be based on the play status in the handover request. Interest, such as the time point information to restore the IPTV user terminal 103
  • the first media server 101 is configured to receive a play request sent by the IPTV user terminal 103, and provide media data to the IPTV user terminal 103 according to the play request.
  • the first media server 101 can also feed back its own available state to the IPTV application server 100, and the feedback manner may be multiple, such as instant feedback or periodic feedback, etc.; the first media server 101 may further store media data, for example, Audio and video data;
  • the first media server 101 is further configured to receive a stop notification sent by the second media server 102, and the receiving of the stop notification may be implemented by monitoring a corresponding UDP port, such as a UDP port 654.
  • the receiving of the stop notification may be implemented by monitoring a corresponding UDP port, such as a UDP port 654.
  • the information in the stop notification such as the original session information
  • the original session ID or other identification information may be used to stop the media playing session corresponding to the ID and stop the IPTV user.
  • Terminal 103 sends media Data.
  • the first media server 101 can further send a stop confirmation message to the second media server 102 informing the second server 102 that it has ceased to provide media data to the IPTV user terminal 103.
  • the system for playing handover may also not include the IPTV application server 100, and the first media server 101 and the second media server 102 directly provide the IPTV user terminal 103 with its own available status information.
  • the media server includes: a receiving module 201, a determining module 202, a sending module 203, and a stopping module 204;
  • the receiving module 201 is configured to receive a play request or a handover request sent by the IPTV user terminal 103, where the handover request includes an identifier of the first media server, and may also be used to receive the first stop confirmation message and receive the second stop notification.
  • the determining module 202 is configured to determine, after the receiving module 201 receives the switching request, whether media data is being provided to the IPTV user terminal;
  • the sending module 203 is configured to: feed back the media server available status information to the IPTV application server 100 or the IPTV user terminal, and send corresponding media data to the IPTV user terminal 103; and send the first stop notification according to the handover request;
  • the switching request is to provide media data to the IPTV user terminal, and the module may also be configured to send a second stop confirmation message.
  • the stopping module 204 stops providing the media data to the terminal according to the second stop notification.
  • the sending module 203 may be further configured to suspend the location according to when the determining module 202 determines that the media data is being provided to the IPTV user terminal.
  • the IPTV user terminal provides media data; and provides media data to the IPTV user terminal after transmitting a stop notification to the first media server or after receiving a stop confirmation message of the first media server.
  • the sending module 203 may further obtain the playing state information in the switching request, such as the interruption time point, the recovery time point, the playback end time point, the interrupted frame number, the end frame number, etc., and select the IPTV according to the playing state information.
  • the media data required by the user terminal 103 is delivered to the IPTV user terminal 103.
  • the sending module 203 may further obtain the original connection information to be terminated in the stop notification after the receiving module 201 receives the stop notification sent by the second media server, and may be the original session information, such as the original session ID, and stop the ID.
  • the corresponding media played session stops sending media data to the IPTV user terminal 103.
  • FIG. 3 is a schematic structural diagram of an IPTV user terminal according to an embodiment of the present invention. As shown, the IPTV user terminal includes a receiving module 301 and a sending module 302.
  • the receiving module 301 is configured to receive and play media data, and from an IPTV application server or a media server. Obtaining an identifier of an available media server, such as an IP address of an available media server; and receiving available media server update information delivered by the IPTV application server, for example, an updated list of available media server IP addresses;
  • the sending module 302 is configured to send a play service request to the IPTV application server 100, requesting it to deliver a set of available media server information, for example, an IP address of the available media server; sending a play request to the first media server, or when When a play interruption occurs or a duplicate data data sent by one or more media servers is received at the same time, a data conflict occurs, and a handover request is sent to the second media server, requesting the second media server to notify the first media server to stop the IPTV user. Transmitting, by the terminal, the media data, and requesting the second media server to send the media data to the IPTV user terminal; the handover request is added by adding a new header field in a Play method of the Real Time Streaming Protocol (RTSP) achieve.
  • RTSP Real Time Streaming Protocol
  • the internal structure of the IPTV user terminal 103 may be implemented in the form of a software module or in hardware, except for the implementation as shown in FIG. 3 above.
  • the embodiment is used to implement the functions of the foregoing IPTV application terminal 103, and the specific principle is the same as the foregoing implementation, and details are not described herein again.
  • the embodiment of the present invention provides a method for playing handover when the first media server is interrupted.
  • the following describes the seamless handover method with reference to FIG. 4, including the following steps:
  • Step 401 The IPTV user terminal sends a play service request to the IPTV application server, requesting it to provide an identifier of the available media server.
  • Step 402 The IPTV application server responds to the application sent by the IPTV user terminal, and provides an identifier of the available media server, for example, sends an IP address of a group of media servers, and may include IP addresses of the first media server and the second media server as described above. It can also include the IP address of more media servers. In another embodiment of the present invention, the IPTV application server may also send update information of the available media server IP address to the IPTV application server;
  • Step 403 The IPTV user terminal sends a play request to the first media server.
  • Step 404 The first media server receives the play request sent by the IPTV user terminal, and according to the play request, such as the IPTV user terminal identifier in the request, may be an IP address of the IPTV user terminal, and a play status information, such as a media, in the request.
  • Step 405 The first media server itself or its network device has a transient or long-term failure, or the IP network is congested, and the transmission of media data is interrupted;
  • Step 406 The IPTV user terminal will not receive the media data required by the IPTV user terminal due to the fault or the network congestion phenomenon described in the foregoing step 405. At this time, the IPTV user terminal detects the play interruption phenomenon and sends the message to the second media server. Sending a handover request, the handover request may carry the following parameters, as shown in Table 1: table
  • Parameter 702 and parameter 703 can appear when parameter 701 takes the value "Yes".
  • the second media server may select one server from the available media server identifiers delivered by the IPTV application server, or The second media server is further selected according to the network condition.
  • Step 407 The second media server sends a stop notification to the first media server according to the handover request.
  • the notification may include original connection information in the handover request, and may be original session information, such as the original session ID, the first media server.
  • the identifier of the first media server stops sending media data to the IPTV user terminal, and the UDP (User Datagram Protocol)-based suspension request may be caused by the network or the server itself. If the media server is not able to be accepted by the media server, the media server may send the media data to the IPTV application terminal at the same time. Therefore, in another embodiment of the present invention, the second media server may also send the stop notification before the sending stop notification. Further determining whether the second media server is delivering the same media data to the IPTV user terminal, and if the media data is being delivered, stopping sending media data to the IPTV user terminal, and then sending the media data to the first media server. Stop notification.
  • the interaction between the media servers is recommended to be transmitted in the UDP mode.
  • the reliability of the UDP interaction is low.
  • the media server sends a stop notification multiple times, and the manner of sending the message may be multiple times sent at a certain frequency, or may be sent periodically, or customized according to the communication status of the network.
  • Step 408 After receiving the stop notification sent by the second media server, the first media server stops the related session according to the related information in the notification, such as the original session ID, and stops sending the media data to the related IPTV user terminal.
  • the first media server may be Received the specified UDP port after startup.
  • the UDP port used for listening is defined as 654.
  • the first media server determines, according to the information in the original session ID, whether the session ID included in the notification exists in the current server, and if so, stops the session corresponding to the ID, and if not, continues. monitor.
  • the first media server in this step may further send a stop confirmation message to the second media server after stopping the related session, to inform that it has stopped sending the media data to the IPTV user terminal.
  • Step 409 The second media server, according to the play status information in the handover request, for example: the media information that is required to be played, may be the name of the media file, the number, or the media play start time, the media play end time, and the play The start frame number, the end frame number of the play, and the like, and the media data required by the IPTV user terminal is transmitted.
  • the media information that is required to be played may be the name of the media file, the number, or the media play start time, the media play end time, and the play The start frame number, the end frame number of the play, and the like, and the media data required by the IPTV user terminal is transmitted.
  • the second media server in the step may further send the media data required by the second media server to the IPTV user terminal after receiving the stop confirmation message sent by the first media server.
  • two media servers may appear, that is, the first media server and the second media server simultaneously
  • the IPTV user terminal transmits media data.
  • the IPTV user terminal finds that the first media server and the second media server simultaneously send duplicate media data and a data conflict occurs, the IPTV user terminal sends a handover request to the second media server again, requesting the The first media server sends a stop notification.
  • the switch request at this time carries the recoverable time point before the data conflict occurs, for example, the last time point before the data collision occurs, or the frame number of the last frame that is normally played before the data collision occurs.
  • the second media server will start transmitting media data to the IPTV user terminal from the recoverable time point.
  • This example proposes to extend the widely used RTSP (RFC 2326).
  • the specific protocol extensions are as follows: C->S: PLAY rtsp: ⁇ audio. example.com/twister. en RTSP/1.0
  • OutdatelP IP of Media Server (in this case, the IP address of the first media server)
  • This header field is an optional header field.
  • the IPTV user terminal will send a Play method (where the Play method is a handover request) to the first media server, where the header field is carried.
  • a new description of the header field based on the RTSP protocol is shown in Table 2, where:
  • Parameter name parameter description example 501 Is the switch required to perform the switching operation? YES/N0
  • the 501 indicates whether the Play method carrying the header field requires the second media server to send a stop notification to other media servers.
  • the 502 header field identifies to which server a stop notification (in the present invention, the identity of the first media server) is sent.
  • the 503 header field identifies which session needs to be stopped.
  • the two header fields 502 and 503 take effect only when the header field corresponding to 501 is assigned Yes.
  • the 504 header field identifies the range of media data required, including the recoverable point in time. It should be pointed out that the parameter values given in Table 2 are only for explaining the usage, and can be flexibly defined in practical applications.
  • Step 601 The IPTV user terminal receives the media data sent by the first media server and the second media server at the same time, and a data conflict occurs;
  • Step 602 The IPTV user terminal generates a handover request and sends the handover request to the second media server.
  • the handover request includes a handover identifier and address information of the first media server, session information of the first media server and the IPTV user terminal, such as a session ID, and may also include IPTV user terminal location information, such as an IP address of the IPTV user terminal, first.
  • the IP address of the media server, and the port information; the original connection information, or the media information required to be played, may be the name and number of the media file; and the playback time control information, which may be the media playback start time and the media playback end time.
  • Step 603 The second media server stops sending media data to the IPTV user terminal.
  • Step 604 The second media server sends a stop notification to the first media server.
  • Step 605 The second media server continues to send the media data to the IPTV user terminal.
  • the second media service may continue to the IPTV user terminal after receiving the stop confirmation message fed back by the first media server. Send media data.
  • the playback switching method of the present invention has other implementation manners, for example, when the data conflict of the IPTV user terminal is caused by more than two media servers simultaneously transmitting data to the IPTV user terminal,
  • the 502 header field identifier of Table 2 will carry the identifiers of the plurality of media services causing the conflict.
  • the 503 header domain identifiers will carry multiple session IDs respectively corresponding to multiple media servers.
  • the media server that receives the handover request in this way will simultaneously send a stop notification to the other multiple media servers that caused the data collision.
  • the present invention can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is a better implementation. .
  • the technical solution of the embodiments of the present invention may be embodied in the form of a software product in essence or in the form of a software product, which is stored in a storage medium and includes a plurality of instructions for making
  • the mobile device (which may be a cell phone, personal computer, media player, etc.) performs the methods described in various embodiments of the present invention.
  • the storage medium referred to herein is, for example, a ROM/RAM, a magnetic disk, an optical disk, or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

一种播放切换方法、 媒体服务器、 用户终端和系统
本申请要求于 2008年 9月 2日提交中国专利局、 申请号为 200810141751.X、 发明名 称为"一种播放切换的方法、 媒体服务器、 用户终端和系统"的中国专利申请的优先权， 其 全部内容通过引用结合在本申请中。 技术领域 说
本发明涉及通信领域， 具体涉及一种播放切换的方法、 媒体服务器、 用户终端和系统。 背景技术
作为"三网融合"的重要形式， IPTV(Internet Protoc书ol Television, 网络电视)业务已经成为 通信行业重点发展的业务方向， 其用户规模正在迅速扩张。 IPTV 的主要业务形态是 IPTV 媒体服务器通过 IPTV用户终端 （例如： IPTV机顶盒， PC终端， 手机终端） 为用户提供基 于 IP网络的直播、 点播、 录播、 时移等媒体服务和其它增值多媒体服务。 IPTV系统是一个 分布式的网络系统， 其媒体数据分布在网络边缘的媒体服务器上， IPTV系统能够将由用户 终端发起的大多数媒体播放请求定位到网络边缘， 直接由边缘的媒体服务器为用户提供相 关的媒体播放服务。 与传统的模拟电视和正在广泛部署的数字电视不同， 强大的 IP网络不 仅能够支持 IPTV系统向用户终端传送高质量的媒体数据， 还支持用户依靠 IP网络的交互 能力实现和媒体内容的互动。 但是， 在另一方面， 由于 IP网络仅提供"尽力而为"的数据传 送服务，在 IP网络突然发生拥塞的情况下， IPTV用户终端可能在短时间内接收不到媒体服 务器发送来的媒体数据， 这将导致媒体播放的短暂中断。 在更为严重的情况下， 当局部的 网络设备或媒体服务器本身出现长时间故障时， IPTV用户终端将彻底失去和当前提供服务 的媒体服务器之间的连接。 以上播放中断的情况将导致用户无法正常收看节目， 这将极大 地影响用户的体验。
现有技术中存在播放中断的切换方法。 IPTV应用服务器向 IPTV用户终端下发一组媒 体服务器的地址， 在发生播放中断时， IPTV用户终端将连接到这组地址中的其他媒体服务 器上获取数据。
发明人通过研究发现， 现有技术由于存在网络拥塞， 因此 IPTV用户终端可能只是暂时 无法从媒体服务器获得数据， 在网络拥塞解除后， IPTV用户终端仍旧会接收到原来提供服 务的媒体服务器发送来媒体数据。因此在实际应用中可能出现 IPTV用户终端同时收到两个 或多个媒体服务器发来重复数据的情况。 这种现象对于网络资源是一种极大的浪费， 而且 会给 IPTV 用户终端对媒体数据的接收和解析带来麻烦， 在 ADSL ( Asymmetric Digital Subscriber Line, 非同步数字用户专线） 接入的情况下， 还可能在下行链路上造成拥塞， 使 IPTV用户终端无法正常工作。 发明内容
本发明提供了一种播放切换方法、媒体服务器、用户终端和系统， 在实现了无缝切换的 同时解决了发生播放中断时播放切换而导致的数据冲突问题。 具体包括：
一种播放切换的方法， 包括：
收到网络电视 IPTV用户终端发送的切换请求，所述切换请求中包含第一媒体服务器的 标识；
根据所述标识向第一媒体服务器发送停止通知， 通知所述第一媒体服务器停止向所述
IPTV用户终端发送数据；
根据所述切换请求， 向所述 IPTV用户终端提供媒体数据。
一种播放切换的方法， 包括：
向第二媒体服务器发送切换请求， 请求所述第二媒体服务器通知第一媒体服务器停止 向网络电视 IPTV用户终端发送媒体数据， 以及请求所述第二媒体服务器向所述 IPTV用户 终端发送媒体数据；
接收所述第二媒体服务器提供的媒体数据。
一种媒体服务器， 所述媒体服务器包括以下模块：
接收模块： 用于接收 IPTV用户终端发送的切换请求， 所述切换请求中包含第一媒体服 务器的标识；
发送模块： 用于根据所述切换请求发送第一停止通知； 以及根据所述切换请求， 向所 述 IPTV用户终端提供媒体数据。
—种 IPTV用户终端， 包括：
发送模块， 用于向第二媒体服务器发送切换请求， 请求所述第二媒体服务器通知第一 媒体服务器停止向网络电视 IPTV用户终端发送媒体数据， 以及请求所述第二媒体服务器向 所述 IPTV用户终端发送媒体数据；
接收模块， 用于接收并播放媒体数据。
一种播放切换系统， 该系统包括若干第一媒体服务器和第二媒体服务器：
第二媒体服务器， 用于接收网络电视 IPTV用户终端发送的切换请求， 并根据所述切换 请求， 向所述第一媒体服务器发送停止通知， 通知其停止向所述 IPTV用户终端下发媒体数 据； 并向 IPTV用户终端下发媒体数据；
第一媒体服务器， 用于接收所述停止通知， 并根据所述停止通知， 停止向所述 IPTV用 户终端下发媒体数据；
本发明通过第二媒体服务器在收到终端发送的切换请求后， 根据所述切换请求向终端 发送媒体数据， 能够实现用户终端在接收第一媒体服务器的媒体数据中断后播放无缝切换， 进一步通过第二媒体服务器和第一媒体服务器间的交互， 避免了数据重复发送而导致用户 终端数据冲突的问题。整个切换操作仅在 IPTV用户终端和各个媒体服务器间， 无需第三方 的参与。
附图说明
图 1为本发明实施例提供的实现播放切换的系统结构图；
图 2为本发明实施例提供的媒体服务器结构示意图；
图 3为本发明实施例提供的 IPTV用户终端的结构示意图；
图 4为本发明实施例提供的播放切换的方法流程图；
图 5为本发明实施例播放切换的方法流程图。 具体实施方式
为了使本技术领域人员更好地理解本发明， 下面结合附图对本发明作进一步的详细说 明。
图 1为本发明实施例提供的实现播放切换的系统结构图。 如图 1所示， 所述的系统包 括： IPTV应用服务器 100， 和多个媒体服务器， 本实施例以两个为例， 包括第一媒体服务 器 101，第二媒体服务器 102。所述系统向 IPTV用户终端 103提供 IPTV业务并实现播放切 换。 本实施例中提供的媒体服务器都可以既作为第一媒体服务器， 也可以作为第二媒体服 务器。 此外， 在另外的实施例中该系统中也可以包括其他数量的媒体服务器， 具体工作原 理与本实施例相同。 其中：
IPTV应用服务器 100: 用于记录系统中所有媒体服务器 （包括第一媒体服务器， 第二 媒体服务器） 的状态信息， 如当前是否可用， 并对所述状态信息进行更新， 该更新可以是 实时更新或周期性的更新等。 所述的状态信息可以通过记录可用的媒体服务器的标识描述 以及对应的状态， 记录的方式可以是 IP地址列表等形式； 接收 IPTV用户终端 103发出的 播放业务申请，从所述状态信息中选择适合为该 IPTV用户终端 103提供服务的可用媒体服 务器， 并将所述可用媒体服务器的标识发送给所述 IPTV用户终端 103。此外， IPTV应用服 务器 100也可以主动对 IPTV用户终端 103中的可用媒体服务器标识进行更新。
第二媒体服务器 102: 用于接收 IPTV用户终端 103发送来的切换请求， 所述切换请求 中包含切换标识以及第一媒体服务器 101 的标识、 第一媒体服务器 101 与 IPTV用户终端 103的会话信息如会话 ID (Identity, 标号）。 所述第二媒体服务器 102根据请求中的信息， 向第一媒体服务器发送停止通知， 通知其停止向 IPTV用户终端 103发送媒体数据。 为了保 证所述第一媒体服务器 101 能够接收到停止通知， 停止通知的发送可以是多次的， 当多次 发送停止通知时， 所述第二媒体服务器 102可以在接收到第一媒体服务器发送来的停止确 认消息后， 停止停止通知的发送； 此外， 所述第二媒体服务器 102进一步根据 IPTV用户终 端 103的发送来的切换请求， 向该 IPTV用户终端 103提供媒体数据； 例如， 如果切换请求 消息中有播放状态信息， 如播放时间点信息或播放的起始帧号， 则根据该信息向该 IPTV用 户终端 103提供媒体数据； 也可以是在收到第一媒体服务器 101 的停止确认消息后， 再根 据 IPTV用户终端 103的发送来的请求， 向该 IPTV用户终端 103提供媒体数据。
在实际应用中， 由于网络或服务器自身原因， 基于 UDP (User Datagram Protocol, 用 户数据报协议） 的中止请求可能无法被媒体服务器接受， 则可能出现两台媒体服务器同时 向一个 IPTV应用终端发送媒体数据的情况， 因此第二媒体服务器 102还可以在接到 IPTV 用户终端 103发送的切换请求后，进一步判断该第二媒体服务器是否正在向该 IPTV用户终 端 103提供媒体数据， 如果是， 则暂停向该 IPTV用户终端 103发送媒体数据； 根据请求中 的信息， 如第一媒体服务器标识， 原会话信息等， 向第一媒体服务器 101 发送停止通知， 通知其停止向该 IPTV用户终端 103发送媒体数据， 然后继续向该 IPTV用户终端 103发送 媒体数据； 也可以是在收到第一媒体服务器 101的停止确认消息后， 再继续向该 IPTV用户 终端 103 发送媒体数据； 还可以进一步根据切换请求中的播放状态信息， 如可恢复时间点 信息向该 IPTV用户终端 103发送媒体数据。
第一媒体服务器 101 : 用于接收 IPTV用户终端 103发送的播放请求， 并根据所述播放 请求向所述的 IPTV用户终端 103提供媒体数据。当然，第一媒体服务器 101还可以向 IPTV 应用服务器 100 反馈其自身的可用状态， 其反馈方式可以是多种， 例如即时反馈或定期反 馈等； 第一媒体服务器 101中进一步可以存储媒体数据， 例如音视频数据；
此外， 第一媒体服务器 101还用于接收所述第二媒体服务器 102发送来的停止通知， 停止通知的接收可以通过监听相应的 UDP端口实现， 如 UDP 654端口。在接收到第二媒体 服务器 102的停止通知后， 根据停止通知中的信息， 如原会话信息， 可以是原会话 ID或者 其他标识信息， 停止该 ID对应的媒体播放的会话并停止向该 IPTV用户终端 103发送媒体 数据。
第一媒体服务器 101进一步可以向第二媒体服务器 102发送停止确认消息， 告知所述 第二服务器 102其自身已停止向 IPTV用户终端 103提供媒体数据。
在本发明的另一个实施例中播放切换的系统中也可以不包含 IPTV应用服务器 100， 由 第一媒体服务器 101和第二媒体服务器 102直接向 IPTV用户终端 103提供其自身的可用状 态信息。
图 2 为本发明实施例提供的媒体服务器结构示意图； 如图所示， 所述的媒体服务器包 括： 接收模块 201， 判断模块 202， 发送模块 203， 停止模块 204;
接收模块 201， 用于接收 IPTV用户终端 103发送的播放请求或切换请求， 所述切换请 求中包含第一媒体服务器的标识； 还可以用于接收第一停止确认消息以及接收第二停止通 知。
判断模块 202，用于在接收模块 201接收到所述切换请求后判断是否正在向所述的 IPTV 用户终端提供媒体数据；
发送模块 203 : 用于向 IPTV应用服务器 100或 IPTV用户终端反馈本媒体服务器可用 状态信息， 向 IPTV用户终端 103发送相应的媒体数据； 用于根据所述切换请求发送第一停 止通知； 以及根据所述切换请求， 向所述 IPTV用户终端提供媒体数据， 该模块也可以用以 发送第二停止确认消息。
停止模块 204: 根据所述第二停止通知停止向终端提供媒体数据。
此外， 如果判断模块 202判断是否正在向所述的 IPTV用户终端提供媒体数据， 发送模 块 203还可以用于根据当判断模块 202判断出正在向所述的 IPTV用户终端提供媒体数据 时， 暂停向所述的 IPTV用户终端提供媒体数据； 并在向所述的第一媒体服务器发送停止通 知后或收到所述第一媒体服务器的停止确认消息后向所述的 IPTV用户终端提供媒体数据。
此外， 发送模块 203 进一步还可以获取切换请求中的播放状态信息， 如中断时间点， 恢复时间点， 播放结束时间点， 中断的帧号， 结束的帧号等， 根据该播放状态信息选择出 IPTV用户终端 103所需要的媒体数据， 下发给所述 IPTV用户终端 103。
此外， 该发送模块 203进一步还可以在接收模块 201接收到第二媒体服务器发送的停 止通知后， 获取停止通知中所要结束的原连接信息， 可以是原会话信息， 例如原会话 ID， 停止该 ID对应的媒体播放的会话并停止向该 IPTV用户终端 103发送媒体数据。
图 3为本发明实施例提供的 IPTV用户终端的结构示意图。 如图所示， 所述 IPTV用户 终端包括接收模块 301和发送模块 302。
所述接收模块 301， 用于接收并播放媒体数据， 以及从 IPTV应用服务器或媒体服务器 获取可用媒体服务器的标识， 比如可用媒体服务器的 IP地址；并接收 IPTV应用服务器下发 的可用媒体服务器更新信息， 例如， 更新后的可用媒体服务器 IP地址列表；
所述发送模块 302， 用于向 IPTV应用服务器 100发送播放业务申请， 请求其下发一组 可用的媒体服务器信息， 例如， 可用媒体服务器的 IP地址； 向第一媒体服务器发送播放请 求， 或当发生播放中断或同时收到一个或多个媒体服务器发送的重复媒体数据而发生数据 冲突的时候， 向第二媒体服务器发送切换请求， 请求所述第二媒体服务器通知第一媒体服 务器停止向 IPTV用户终端发送媒体数据， 以及请求所述第二媒体服务器向所述 IPTV用户 终端发送媒体数据； 所述切换请求通过在 RTSP (Real Time Streaming Protocol,实时流传输协 议） 协议的 Play方法中增加新头域实现。
根据前述本发明实施例中 IPTV用户终端 103的功能， 该 IPTV用户终端 103的内部结 构除了如上述图 3 所示的实施例外， 还可以包括其他原理类似的以软件模块形式或者以硬 件形式实现的实施例，用以实现前述 IPTV应用终端 103的功能，具体原理与上述实施相同， 此处不再赘述。
本发明实施例给出了在第一媒体服务器发生播放中断的情况下播放切换的方法， 以下 结合附图 4对该无缝切换方法做进一步说明， 包括以下步骤：
步骤 401 : IPTV用户终端向 IPTV应用服务器发出播放业务申请，请求其提供可用媒体 服务器的标识。
步骤 402: IPTV应用服务器响应 IPTV用户终端发出的申请， 向其提供可用媒体服务器 的标识， 例如发送一组媒体服务器的 IP地址， 可以包括如前述的第一媒体服务器和第二媒 体服务器的 IP地址，也可以包括更多媒体服务器的 IP地址。在本发明另外的实施例中 IPTV 应用服务器还可以向其发送可用媒体服务器 IP地址的更新信息；
步骤 403 : IPTV用户终端向第一媒体服务器发出播放请求；
步骤 404: 第一媒体服务器收到 IPTV用户终端发送来的播放请求， 并根据播放请求， 如请求中的 IPTV用户终端标识，可以是 IPTV用户终端的 IP地址， 以及请求中播放状态信 息， 如媒体文件的名称， 编号， 向 IPTV用户终端发送其需要的媒体数据， 还可以进一步根 据请求中的播放状态信息， 如媒体播放起始时刻， 或播放的起始帧号等确定媒体数据； 步骤 405: 第一媒体服务器自身或其网络设备出现暂态或长期故障， 或 IP网络出现拥 塞现象， 媒体数据的传输出现中断；
步骤 406: 由于上述步骤 405中所述的故障或网络拥塞现象， IPTV用户终端将出现接 收不到其所需要的媒体数据， 此时， IPTV用户终端检测到播放中断现象， 并向第二媒体服 务器发送切换请求， 所述切换请求中可以携带以下参数， 如表一所示： 表
Figure imgf000009_0001
参数 702和参数 703可以在参数 701取值为 "Yes"的时候出现。
本实施例中建议对广泛应用的 RTSP (RFC 2326)进行扩展， 上述参数在该协议中的携 带方式建议如下：
RTSP：〃 ServerIP:Port/Path/Filename?switch=yes,origin_IP=* *, origin—Session:** 第二媒体服务器可以是从 IPTV应用服务器下发的可用媒体服务器标识中选择一个服务 器， 也可以进一步根据网络状况选择第二媒体服务器。
步骤 407: 第二媒体服务器根据所述切换请求向第一媒体服务器发送停止通知； 所述通 知中可以包括切换请求中的原连接信息， 可以是原会话信息， 例如原会话 ID， 第一媒体服 务器的标识以及端口信息等， 通知第一媒体服务器停止向 IPTV用户终端下发媒体数据； 在实际应用中， 由于网络或服务器自身原因， 基于 UDP (User Datagram Protocol, 用户 数据报协议） 的中止请求可能无法被媒体服务器接受， 则可能出现两台媒体服务器同时向 一个 IPTV应用终端发送媒体数据的情况， 因此在本发明另外的实施例中， 本步骤中第二媒 体服务器还可以在发送停止通知前， 进一步判断此时本第二媒体服务器是否在向所述 IPTV 用户终端下发相同的媒体数据， 若正在下发， 则先停止向该 IPTV用户终端下发媒体数据， 再向上述第一媒体服务器发送停止通知。
为了减轻服务器间交互的协议开销，提升交互效率，本实施例中建议媒体服务器间的交 互采用 UDP方式传输， 由于 UDP交互的可靠性较低， 因此本实施例进一步建议第二媒体 服务器向第一媒体服务器多次发送停止通知， 其发送的方式可以是以一定频率多次发送， 也可以是定期发送， 或根据网络的通信状况定制其发送的策略。
步骤 408: 第一媒体服务器收到第二媒体服务器发来的停止通知后， 根据所述通知中的 相关信息如原会话 ID， 停止相关会话， 停止向相关 IPTV用户终端发送媒体数据；
为了能够接收到第二媒体服务器发送的停止通知，本实施例中可以由第一媒体服务器在 启动后对指定的 UDP端口进行接收。例如用于监听的 UDP端口定义为 654。第一媒体服务 器在收到停止通知后根据其中信息， 如原会话 ID判断当前服务器中是否存在通知中所包含 的会话 ID,若存在则对所述 ID对应的会话进行停止， 若不存在则继续监听。
在本发明另外的实施例中，本步骤中所述第一媒体服务器还可以在停止相关会话后， 向 第二媒体服务器发送停止确认消息， 告知其已经停止向 IPTV用户终端发送媒体数据。
步骤 409: 第二媒体服务器， 根据切换请求中的播放状态信息， 例如： 要求播放的媒体 信息， 可以是媒体文件的名称， 编号， 也可以是媒体播放起始时刻， 媒体播放结束时刻， 播放的起始帧号， 播放的结束帧号等， 向 IPTV用户终端发送其所需要的媒体数据。
在本发明另外的实施例中，本步骤中所述第二媒体服务器还可以在收到所述第一媒体服 务器发送来的停止确认消息后， 再向 IPTV用户终端发送其所需要的媒体数据。
在实际应用中可能出现两台媒体服务器， 即第一媒体服务器和第二媒体服务器同时向
IPTV用户终端发送媒体数据的情况。 为了解决这一问题， 本实施例在 IPTV用户终端发现 第一媒体服务器和第二媒体服务器同时发送重复的媒体数据而发生数据冲突时， 再次向所 述第二媒体服务器发送切换请求， 请求其向第一媒体服务器发送停止通知。 此时的切换请 求中将携带发生数据冲突前的可恢复时间点， 例如发生数据冲突前正常播放的最后的时间 点， 也可以是发生数据冲突前正常播放的最后一帧的帧号， 这样所述第二媒体服务器将从 可恢复时间点开始向 IPTV用户终端开始发送媒体数据。
本实施例建议对广泛应用的 RTSP (RFC 2326) 进行扩展， 具体协议扩展建议如下： C->S: PLAY rtsp：〃 audio. example.com/twister. en RTSP/1.0
CSeq: 833
Session: 12345678
Switch: Yes
OutdatelP: IP of Media Server (本例中为第一媒体服务器的 IP地址）
OutdateSession: Session ID
Range: clock=[RecoveryPoint]- [EndPoint]
在 RTSP协议的 Play方法中增加新的头域—— Switch、 OutdatelP和 OutdateSession。 该 头域为可选头域。当发现数据冲突时， IPTV用户终端将向第一媒体服务器发送 Play方法（此 处 Play方法为一个切换请求）， 其中携带上述头域。 新增基于 RTSP协议的头域的具体描述 如表二所示， 其中：
表二
参数名称 参数说明 举例 501， Switch 是否需要进行切换操作的标识 YES/N0
502, OutdatelP 第一媒体服务器 IP地址,域名等 192.168.1.3 原会话 ID， 即终端与第一媒体服
503 , Outdate Session 12345678
务器之间的会话的 ID
需要媒体数据的范围， 包含可恢 Clock=[RecoveryPoint]-[EndP
504,Range
复时间点 oint]
501表示携带该头域的 Play方法是否需要第二媒体服务器向其他媒体服务器发送停止 通知。 502头域标识需要向哪台服务器发送停止通知（本发明中为第一媒体服务器的标识）。 503头域标识需要停止哪个会话。 仅当 501对应的头域赋值为 Yes时， 502和 503两个头域 才生效。 504头域标识需要媒体数据的范围， 包含可恢复时间点。 需要指出的是， 表二中给 出的参数值只是为了说明使用方式， 在实际应用中可以灵活定义。
在出现数据冲突的情况下， 无缝切换的方法流程如附图 5所示， 其中：
步骤 601 : IPTV用户终端同时接收到第一媒体服务器和第二媒体服务器发送来的媒体 数据， 发生了数据冲突的情况；
步骤 602: IPTV用户终端生成切换请求发送给第二媒体服务器。 所述切换请求中包含 切换标识以及第一媒体服务器的地址信息、第一媒体服务器与 IPTV用户终端的会话信息如 会话 ID,还可以包含 IPTV用户终端位置信息如 IPTV用户终端的 IP地址， 第一媒体服务器 的 IP标识， 以及端口信息;原连接信息， 或要求播放的媒体信息， 可以是媒体文件的名称， 编号;还有播放时间控制信息， 可以是媒体播放起始时刻和媒体播放结束时刻， 播放的起始 帧号， 播放的结束帧号等；
步骤 603 : 第二媒体服务器停止向所述 IPTV用户终端发送媒体数据；
步骤 604: 第二媒体服务器将停止通知发送给第一媒体服务器；
步骤 605: 第二媒体服务器继续向所述 IPTV用户终端发送媒体数据， 在本步骤中第二 媒体服务其也可以在接收到第一媒体服务器反馈的停止确认消息后，继续向所述 IPTV用户 终端发送媒体数据。
除了上述的实施方式以外，本发明所述播放切换方法还有其他实施方式，例如，当 IPTV 用户终端的数据冲突是由超过两台的媒体服务器同时向 IPTV用户终端发送数据而导致的， 这时表二 502头域标识将携带引起冲突的多个媒体服务的标识。 503头域标识中将携带分别 对应于多个媒体服务器的多个会话 ID。 这样接收到切换请求的媒体服务器将向导致数据冲 突的其他多个媒体服务器同时发送停止通知。
通过以上实施例的描述， 本领域的技术人员可以清楚地了解到本发明可借助软件加必 需的通用硬件平台的方式来实现， 当然也可以通过硬件， 但很多情况下前者是更佳的实施 方式。 基于这样的理解， 本发明实施例的技术方案本质上或者说对现有技术做出贡献的部 分可以以软件产品的形式体现出来， 该软件产品存储在一个存储介质中， 包括若干指令用 以使得移动设备 （可以是手机， 个人计算机， 媒体播放器等） 执行本发明各个实施例所述 的方法。 这里所称的存储介质， 如： ROM/RAM、 磁盘、 光盘等。
显然， 本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和 范围。 这样， 倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内， 则本发明也意图包含这些改动和变型在内。

Claims

权 利 要 求 书
1. 一种播放切换的方法， 其特征在于， 包括：
收到网络电视 IPTV用户终端发送的切换请求，所述切换请求中包含第一媒体服务器的 标识；
根据所述标识向第一媒体服务器发送停止通知， 通知所述第一媒体服务器停止向所述
IPTV用户终端发送数据；
根据所述切换请求， 向所述 IPTV用户终端提供媒体数据。
2. 根据权利要求 1所述方法， 其特征在于， 在向第一媒体服务器发送停止通知之后， 向所述 IPTV用户终端提供媒体数据之前， 所述方法还包括：
接收所述第一媒体服务器反馈的停止确认消息。
3. 根据权利要求 1 所述方法， 其特征在于， 所述停止通知通过用户数据报协议 UDP 交互通道发送。
4. 根据权利要求 1所述方法， 其特征在于， 收到网络电视 IPTV用户终端发送的切换 请求后， 向第一媒体服务器发送停止通知之前， 所述方法进一步包括：
判断是否正在向所述的 IPTV用户终端提供媒体数据；
如果是， 暂停向所述 IPTV用户终端提供媒体数据； 或
向第一媒体服务器发送停止通知之后， 向所述 IPTV用户终端提供媒体数据之前， 还包 括：
接收所述第一媒体服务器的停止确认消息。
5. 根据权利要求 1一 4中任一项所述的方法， 其特征在于，
所述的切换请求中携带可恢复时间点，根据所述可恢复时间点确定所述的向 IPTV用户 终端提供的媒体数据。
6. 一种播放切换的方法， 其特征在于， 包括：
向第二媒体服务器发送切换请求， 请求所述第二媒体服务器通知第一媒体服务器停止 向网络电视 IPTV用户终端发送媒体数据， 以及请求所述第二媒体服务器向所述 IPTV用户 终端发送媒体数据；
接收所述第二媒体服务器提供的媒体数据。
7. 根据权利要求 6所述方法， 其特征在于， 向第二媒体服务器发送切换请求之前， 所 述方法还包括： 从 IPTV应用服务器或媒体服务器获取可用媒体服务器的标识，根据所述可用媒体服务 器的标识选择第二媒体服务器。
8. 一种媒体服务器， 其特征在于， 所述媒体服务器包括以下模块：
接收模块 201 : 用于接收网络电视 IPTV用户终端发送的切换请求， 所述切换请求中包 含第一媒体服务器的标识；
发送模块 203 : 用于根据所述标识发送第一停止通知； 以及根据所述切换请求， 向所述 IPTV用户终端提供媒体数据。
9. 如权利要求 8所述的媒体服务器， 其特征在于， 所述接收模块 201还用于接收第二 停止通知； 所述媒体服务器还包括停止模块 204， 用于根据所述第二停止通知停止向 IPTV 用户终端提供媒体数据。
10. 如权利要求 8所述媒体服务器， 其特征在于，
所述发送模块 203还可以用于发送第二停止确认消息。
所述接收模块 201还可以用于接收第一停止确认消息。
11. 根据权利要求 9或 10所述媒体服务器， 其特征在于， 所述媒体服务器还包括： 判断模块 202， 用于判断是否正在向所述的 IPTV用户终端提供媒体数据；
所述发送模块 203用于当所述判断模块 202判断出正在向所述的 IPTV用户终端提供媒 体数据时， 暂停向所述的 IPTV用户终端提供媒体数据； 并发送第一停止通知；
或当所述接收模块 201接收到第一停止确认消息后向所述的 IPTV用户终端提供媒体数 据。
12. 一种 IPTV用户终端， 其特征在于：
发送模块 302， 用于向第二媒体服务器发送切换请求， 请求所述第二媒体服务器通知第 一媒体服务器停止向网络电视 IPTV用户终端发送媒体数据， 以及请求所述第二媒体服务器 向所述 IPTV用户终端发送媒体数据；
接收模块 301， 用于接收并播放媒体数据。
13. 如权利要求 12所述的 IPTV用户终端， 其特征在于：
所述接收模块 301进一步用于：从 IPTV应用服务器或媒体服务器获取可用媒体服务器 的标识。
14. 一种播放切换系统， 其特征在于： 该系统包括若干第一媒体服务器和第二媒体服 务器：
第二媒体服务器， 用于接收网络电视 IPTV用户终端发送的切换请求， 并根据所述切换 请求， 向所述第一媒体服务器发送停止通知， 通知其停止向所述 IPTV用户终端下发媒体数 据； 并向所述 IPTV用户终端下发媒体数据；
第一媒体服务器， 用于接收所述停止通知， 并根据所述停止通知， 停止向所述 IPTV用 户终端下发媒体数据。
15. 根据权利要求 14所述系统， 其特征在于： 该系统还包括：
IPTV应用服务器： 用于向所述 IPTV用户终端提供所述可用媒体服务器的标识。
PCT/CN2009/072694 2008-09-02 2009-07-09 一种播放切换方法、媒体服务器、用户终端和系统 WO2010025635A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810141751.X 2008-09-02
CN200810141751.XA CN101668193A (zh) 2008-09-02 2008-09-02 一种播放切换方法和系统

Publications (1)

Publication Number Publication Date
WO2010025635A1 true WO2010025635A1 (zh) 2010-03-11

Family

ID=41796732

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/072694 WO2010025635A1 (zh) 2008-09-02 2009-07-09 一种播放切换方法、媒体服务器、用户终端和系统

Country Status (2)

Country Link
CN (1) CN101668193A (zh)
WO (1) WO2010025635A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102298947B (zh) * 2011-08-23 2015-12-16 百度在线网络技术（北京）有限公司 一种用于在多媒体播放器间进行播放切换的方法与设备
CN102833591B (zh) * 2012-08-09 2015-08-12 中兴通讯股份有限公司 交互式网络电视系统中点播服务不中断的方法及装置
CN107360448B (zh) * 2017-08-11 2019-07-12 中广热点云科技有限公司 一种视频数据单播组播切换方法
CN112911335B (zh) * 2021-02-03 2022-05-27 烽火通信科技股份有限公司 一种基于视频编码的服务调度方法、视频服务器和机顶盒

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006285532A (ja) * 2005-03-31 2006-10-19 Fujitsu Frontech Ltd サービス提供方法、及びデータ処理装置
CN101051883A (zh) * 2007-05-11 2007-10-10 杭州华三通信技术有限公司 一种主用语音服务器故障恢复后的业务切换方法和系统
CN101068339A (zh) * 2007-06-01 2007-11-07 华为技术有限公司 一种视频点播类业务的实现方法、服务器及客户端
CN101202970A (zh) * 2005-11-15 2008-06-18 阿尔卡特公司 为呼叫服务器提供故障保护的集群呼叫服务器
CN101252546A (zh) * 2008-04-15 2008-08-27 中国科学技术大学 媒体流在线服务迁移的方法和装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006285532A (ja) * 2005-03-31 2006-10-19 Fujitsu Frontech Ltd サービス提供方法、及びデータ処理装置
CN101202970A (zh) * 2005-11-15 2008-06-18 阿尔卡特公司 为呼叫服务器提供故障保护的集群呼叫服务器
CN101051883A (zh) * 2007-05-11 2007-10-10 杭州华三通信技术有限公司 一种主用语音服务器故障恢复后的业务切换方法和系统
CN101068339A (zh) * 2007-06-01 2007-11-07 华为技术有限公司 一种视频点播类业务的实现方法、服务器及客户端
CN101252546A (zh) * 2008-04-15 2008-08-27 中国科学技术大学 媒体流在线服务迁移的方法和装置

Also Published As

Publication number Publication date
CN101668193A (zh) 2010-03-10

Similar Documents

Publication Publication Date Title
US9973812B2 (en) Multi-screen interaction method and system
EP2391086B1 (en) Method and apparatus for playing live content
JP5442766B2 (ja) サービス・レイヤにより支援する、マルチメディア・ストリーム・アクセス配信の変更
CN102685563B (zh) 互联网协议电视内容共享方法、装置以及终端设备
EP2640099B1 (en) Method, system and apparatus for providing stream media service
WO2012034373A1 (zh) 实现多终端断点续播节目的方法、装置及系统
WO2008101444A1 (fr) Système multimédia en flux, dispositif de transmission de signalisation et procédé d'envoi de multimédia en flux
WO2012122780A1 (zh) 一种多终端间数据内容实时切换的方法和系统
WO2009121259A1 (zh) 提供媒体内容的方法、装置和系统
JP2012515484A (ja) ネットワークにおける関連付けられたセッションの管理
US9826283B2 (en) Apparatus and method for inserting advertisement in a broadcasting system
WO2011143881A1 (zh) 实现移动终端电视互动的方法、系统及背靠背的用户代理
US8908853B2 (en) Method and device for displaying information
WO2010025635A1 (zh) 一种播放切换方法、媒体服务器、用户终端和系统
WO2009015539A1 (fr) Procédé de commande multidiffusion pour service de demande de contenu multimédia et son système
WO2008141542A1 (fr) Procédé, dispositif vidéo et système pour l'affichage d'informations au moment d'une commutation de canaux
US8762549B2 (en) System and method for IPTV node recovery
WO2011137718A1 (zh) 控制内容报告行为的方法、装置和系统
CN101989977A (zh) 富媒体实时业务实现的方法、设备、服务器和系统
WO2015168993A1 (zh) 一种基于内容提供商与服务提供商分离的控制方法及装置
WO2011036646A2 (en) Systems and methods for handling advertisements in conjunction with network-based bookmarking
WO2023246599A1 (zh) 非签约内容提供商的服务资源分发方法和视频服务系统
CN118890498A (zh) 一种数据传输方法、设备、介质及产品
WO2013097222A1 (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: 09811010

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

Country of ref document: EP

Kind code of ref document: A1