EP1670252B1 - Beschleunigter Kanalwechsel in datenratenbegrenzten Umgebungen - Google Patents

Beschleunigter Kanalwechsel in datenratenbegrenzten Umgebungen Download PDF

Info

Publication number
EP1670252B1
EP1670252B1 EP05111446A EP05111446A EP1670252B1 EP 1670252 B1 EP1670252 B1 EP 1670252B1 EP 05111446 A EP05111446 A EP 05111446A EP 05111446 A EP05111446 A EP 05111446A EP 1670252 B1 EP1670252 B1 EP 1670252B1
Authority
EP
European Patent Office
Prior art keywords
client module
media information
data rate
nominal
unicast
Prior art date
Legal status (The legal status 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 status listed.)
Not-in-force
Application number
EP05111446A
Other languages
English (en)
French (fr)
Other versions
EP1670252A2 (de
EP1670252A3 (de
Inventor
David C. c/o Microsoft Corporation Clifford
Dustin L. c/o Microsoft Corporation Green
Geoffrey R. c/o Microsoft Corporation Smith
Grant D. c/o Microsoft Corporation Mohr
James A. c/o Microsoft Corporation Baldwin
Michael D. c/o Microsoft Corporation Dodd
Peter T. c/o Microsoft Corporation Barrett
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
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 Microsoft Corp filed Critical Microsoft Corp
Priority to EP11001056A priority Critical patent/EP2373026A1/de
Publication of EP1670252A2 publication Critical patent/EP1670252A2/de
Publication of EP1670252A3 publication Critical patent/EP1670252A3/de
Application granted granted Critical
Publication of EP1670252B1 publication Critical patent/EP1670252B1/de
Not-in-force legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
    • 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23424—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for inserting or substituting an advertisement
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/23805—Controlling the feeding rate to the network, e.g. by controlling the video pump
    • 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2401—Monitoring of the client buffer
    • 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2404—Monitoring of server processing errors or hardware failure
    • 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/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H04N21/25833—Management of client data involving client hardware characteristics, e.g. manufacturer, processing or storage capabilities
    • 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/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/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
    • H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44016—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for substituting a video clip
    • 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/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • 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/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/4424—Monitoring of the internal components or processes of the client device, e.g. CPU or memory load, processing speed, timer, counter or percentage of the hard disk space used
    • 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/637—Control signals issued by the client directed to the server or network components
    • H04N21/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • 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
    • 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/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/6473—Monitoring network processes errors
    • 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6582—Data stored in the client, e.g. viewing habits, hardware capabilities, credit card number

Definitions

  • This subject matter relates to strategies for streaming media information to client modules in a manner which allows the client modules to quickly begin presenting the media information.
  • a physical tuner in a client module (e.g., a television set) that tunes to and receives the media information.
  • a user can quickly change channels, resulting in the virtual instantaneous transition from one program to another. And as such, the user does not typically perceive a delay in the presentation of a new program upon tuning to a new program.
  • this simple manner of operation does not apply to the delivery of digital media information in streaming fashion over a network.
  • the client module typically must store a prescribed amount of media information in a buffer before it begins to play the media information to the user. It requires a certain amount of time to fill up this buffer when the user first connects to a stream of media information.
  • digital media information is commonly expressed as a series of key frames (e.g., I frames) and difference frames (e.g., B and P frames).
  • key frames e.g., I frames
  • difference frames e.g., B and P frames.
  • ACC Accelerated Channel Change
  • the head-end infrastructure delivers an initial burst which feeds a large quantity of media information to the client module via a communication channel, enabling it to begin presentation of the media information on an expedited basis.
  • the head-end infrastructure delivers the media information to the client module at a regular data rate (e.g., at or below a specified nominal data rate).
  • the ACC strategies make additional demands on the communication channels beyond that required to transmit the media information at its normal steady-state rate.
  • a system can address these demands by allocating extra bandwidth to implement the ACC strategies.
  • many environments allocate a limited amount of bandwidth to the communication channels.
  • the application of ACC strategies in these kinds of environments may present various challenges. For example, there is a potential that the ACC strategies can overburden the communication channels, leading to their over-saturation. Such over-saturation of the channels can result in a poor quality of media presentation (e.g., due to the loss of an unacceptable number of media packets). Such over-saturation can also possibly result in the streams being dropped. For example, consider a household that includes various media presentation units that all "feed off' of a single communication channel. The ACC strategies have the potential of overburdening such a communication channel, particularly when multiple users in the household happen to be consuming media information at the same time (and also potentially invoking the ACC behavior at the time).
  • EP 1294193 A1 discloses an apparatus and method in which a buffer receives a first content stream carrying a content channel signal.
  • the first content stream carries the content channel signal at a rate substantially greater than the streaming content playout rate, for initially loading the buffer.
  • the buffer switches its reception of the content channel signal from the first content stream to a second content stream.
  • the second content stream is at a rate substantially the same as the streaming content playout rate. Generally, this switch occurs when some predefined threshold of the content channel signal is buffered.
  • HARI KALVA ET AL "Techniques for Improving the Capacity of Video-On-Demand Systems" PROCEEDINGS OF THE ANNUAL HAWAII INTERNATIONAL CONFERENCE ONSYSTEM SCIENCES, vol. 2, 3 January 1996 (1996-01-03 ), discloses two techniques to improve the capacity of video on demand systems.
  • Video on demand is an electronic video rental system in which clients request and play videos on-demand.
  • Video on demand system can be implemented over an existing cable TV network or an upgraded ADSL network.
  • the two techniques used to improve the capacity of video on-demand systems are segmentation and multicasting. Segmentation consists of dividing the video into several fixed length segments, and then transmitting the segments at regular intervals instead of transmitting the entire video continuously.
  • Multicasting assumes that each subscriber has a limited storage space, so same video segments can be multicast to subscribers simultaneously. Results of a comprehensive simulation study presented in the paper show a significant improvement in the capacity of the system when these two techniques are applied. In evaluating video on-demand systems we considered the following parameters: the number of users supported, the number of videos played per day, and the number of requests rejected per day.
  • US 2004/098748 A1 discloses an end-to-end congestion control, in an MPEG-4 live unicast video streaming system in a wireless network, a streaming server provides real-time video-streaming to a client by using an RTP/UDP protocol.
  • RTP/RTCP transport engines handle the segmentation/desegmentation and the packetization/depacketization of data as well as the transmission/retransmission of packets.
  • a bitrate adaptation protocol and a network bandwidth polling protocol can automatically and dynamically adjust the data-bitrate/transmission-bitrate according to the available network bandwidth. Therefore, the continuous live video-streaming service is promised.
  • US 2004/128396 A1 discloses an adaptable accelerated content streaming allows data to be streamed from a server to a client over a network at an accelerated rate for an amount of time before reducing the rate.
  • the accelerated rate is prohibited from exceeding a threshold amount, which is based at least in part on both a total bandwidth of the server and an amount of bandwidth currently being used by the server.
  • the data can be streamed to the client at up to an adaptable accelerated rate.
  • US 2002/143499 A1 relates to a method wherein in response to receiving a transmit request REQ1 from a first client apparatus, the server transmits a group address INF1 to the first client apparatus.
  • the server first transmits the first block X1, which is selected from blocks X1 to X4 that were subdivided from the requested information with the group address, via the network.
  • the server receives a transmit request REQ2 from a second client apparatus after transmitting block X1 to the first client apparatus, the server transmits a group address INF2 to the second client apparatus. Further, the server transmits the second, third and fourth blocks (X2 to X4) with the group addresses INF1 and INF2 via the network. The transmission process is completed after the server has transmitted the first block X1 with the group address INF2 via the network.
  • DE 102 06 076 A1 discloses a method which involves transmitting a data stream via multiple transmission channels, starting at a time t1s.
  • the stream comprises multiple data units.
  • a further data stream is transmitted via at least some of the transmission channels at a start time t2s.
  • a sub-group of data units is formed from some of the data units and transmitted to a receiver.
  • US 2002/002708 A1 relates to multicasting transmission of multimedia information.
  • PHILIP A CHOU ET AL relates to: "Error Control for Receiver-Driven Layered Multicast of Audio and Video" IEEE TRANSACTIONS ON MULTIMEDIA, IEEE SERVICE CENTER, PISCATA-WAY, NJ, US, vol. 3, no. 1, 1 March 2001 (2001-03-01 ).
  • EP 1 361 690 A2 relates to a method and apparatus for retransmitting data packets based on channel conditions.
  • US 2002/010938 A1 relates to resource allocation in multi-stream IP network for optimized quality of service.
  • US 6 691 312 B1 relates to multicasting video.
  • WO 01/74076 A1 relates to distributed cooperative memory for interactive and scalable video-on-demand system.
  • Series 100 numbers refer to features originally found in Fig. 1
  • series 200 numbers refer to features originally found in Fig. 2
  • series 300 numbers refer to features originally found in Fig. 3 , and so on.
  • the first mode of delivery uses a server module to provide a unicast stream of media information delivered at burst data rate levels
  • the second mode of delivery uses multicast functionality to provide a multicast stream of the media information at nominal data rate levels.
  • the strategy described herein can be invoked when a user wishes to commence the presentation of a stream of media information, such as when the user switches from one first program to another program.
  • the first mode of delivery uses the server module to provide the unicast stream at the burst-data rate levels
  • the second model of delivery also uses the server module to provide the unicast stream, but at the nominal data rate levels.
  • the strategy described herein confers a number of benefits.
  • the strategy is particularly advantageous in those environments characterized as "rate-limited environments.” These environments allocate the client module (or group of client modules) a prescribed amount of bandwidth to receive one or more streams of media information. By maintaining the amount of consumed bandwidth below the prescribed data rate level, the strategy accommodates the use of an accelerated channel change burst without exceeding the capacity of the communication channel. This, in turn, reduces the chances that one or more streams of resource information will be dropped (or otherwise degraded) as a result of the accelerated channel change behavior.
  • this disclosure sets forth the strategy by first explaining the application of the strategy to an environment that delivers resource information at a constant data rate to client modules using a hybrid unicast/multicast ACC technique. Further, some examples assume that the amount of excess capacity provided by the communication channel is less than a nominal data rate of the resource information (so that two full nominal data rate streams cannot "fit" onto the communication channel at the same time). As to the issue of bit rate, the constant data rate implementation provides a convenient pedagogical vehicle for visualizing the functional interdependencies involved in the strategy.
  • the different stages in the transition from the first mode of delivery to the second mode delivery can be depicted as rectangular blocks on a bandwidth-versus-time graph.
  • the strategy can also be applied to other types of environments. For instance, the analysis also applies to worst-case assumptions for the case of capped variable bit rate (VBR) delivery (where the resource information is delivered at the maximum data rate permitted).
  • VBR variable bit rate
  • the strategy can be applied to environments that allocate a relatively large amount of bandwidth (such as two times the nominal data rate or greater). Data rate limitations may not present a significant design challenge in these environments, but such environments can benefit from the efficiency at which the ACC strategy transitions from one mode of delivery to another, as well as other merits of the strategy.
  • the strategy can also be applied to communication channels that allocate a relatively large amount of excess capacity, including excess capacity equal to or greater than the nominal bit rate of the stream which corresponds to a total capacity equal to or greater than two times the nominal bit rate of the stream (not covered by the claimed subject-matter).
  • excess capacity equal to or greater than the nominal bit rate of the stream which corresponds to a total capacity equal to or greater than two times the nominal bit rate of the stream (not covered by the claimed subject-matter).
  • the use of large levels of excess capacity to deliver resource information can reduce (or eliminate) the amount of missed packets caused by the transition from the first mode of delivery to the second mode of delivery, and therefore may reduce the need for retries following the transition from the first mode to the second mode.
  • the strategy can be applied to other environments which transition between other kinds of modes of delivery, such as in the unclaimed case of the pure unicast delivery model described above (where the different modes correspond to two different delivery phases of the same unicast delivery mechanism).
  • resource information refers to any data represented in electronic form that can be consumed by a user.
  • the resource information may include, or may omit, interactive content.
  • a specific class of resource information may pertain to media information.
  • the media information can include any information that conveys audio and/or video information, such as audio resources (e.g., music, etc.), still picture resources (e.g., digital photographs, etc.), moving picture resources (e.g., audiovisual television programs, movies, etc.), computer programs (e.g., games, etc.), and so on.
  • stream refers to the representation of the resource information as time-sequenced flow of the resource information.
  • a client module can consume a stream of resource information in piecemeal fashion as it is received, as opposed to requiring the client module to receive the entire body of the resource information (e.g., as a single file) before consuming the resource information.
  • the term "communication channel” broadly refers to the resources that a system uses for handling communication between a particular source module and a particular client module.
  • the term “unicast” refers to the delivery of resource information between a server module and a client module in one-to-one fashion, where specific resources are allocated to the unicast delivery for that particular client module.
  • the term “multicast” refers to the delivery of resource information to potentially multiple client modules in a manner that does not require per-client allocation of communication resources (and particularly, does not require per-client allocation of server resources).
  • IP Internet Protocol
  • IGMP Internet Group Management Protocol
  • the term “multicast” is generally synonymous with the term “broadcast.”
  • accelerated channel change refers to any paradigm for allowing a client module to begin presenting a stream of resource information on an expedited basis.
  • rate-limited ACC refers to the novel strategy summarized above, which permits a client module to switch between first delivery functionality and second delivery functionality in a manner which does not exceed prescribed bandwidth limitations.
  • rate-limited hybrid unicast/multicast ACC refers to the specific application of the rate-limited ACC strategy to the task of switching from a unicast stream delivered by unicast delivery functionality to a multicast stream delivered by multicast delivery functionality.
  • a stream encoder may create the resource information such that it can be continuously delivered and presented while utilizing no more than the nominal bit-rate for delivery, and without interruption of presentation of the resource information, assuming the client module presents resource information no earlier than the time specified by the stream.
  • data rate levels can refer to a series of constant or varying data rates that conform to some pattern or criterion.
  • the second mode of delivery provides the resource information at "second data rate levels,” meaning generally herein that it delivers the resource information at levels conforming to a nominal data rate.
  • the second data rate levels might describe the "flat" delivery of the resource information at the nominal data rate itself.
  • the second data rate levels will be permitted to vary below a ceiling defined by the nominal data rate.
  • maximum rate or “MaxRate” refers to a total amount of bandwidth that a channel allocates to handling information exchange.
  • excess data rate or "excess capacity” refers to available bandwidth in a communication channel that can be used to handle the special provisions involved in the ACC strategy. For example, a channel might devote a maximum data rate of MaxRate to handling all information exchange over the communication channel. At a given time, the steady-state consumption of a multicast stream of resource information might be ActualCurrentMulticastRate. The excess data rate is then MaxRate - ActualCurrentMulticastRate. That excess data rate can be used for handling the special provisions of the ACC strategy, such as handling retries to account for the packets lost when transitioning from the first mode of delivery to the second mode delivery. For constant data rate delivery, the excess capacity can be represented as a constant amount.
  • the excess capacity will vary (because the amount of bandwidth consumed by the steady-state delivery will vary).
  • the term "excess data rate” or “excess capacity” refers to excess data rate in units of information quantity per time unit.
  • the excess data rate can also be expressed as a fraction E of the nominal data rate (also referred to as the "fractional excess capacity” or “fractional excess data rate” herein).
  • a "primary mode of delivery" of resource information refers to a mode used to deliver the bulk of the resource information being consumed by a client module at any given time.
  • the client module may be receiving a stream of resource information from a multicast mode of delivery, while still relying on a unicast mode of delivery to receive missing packets in response to retry requests.
  • the multicast mode of delivery would comprise the primary mode of delivery, since it provides the bulk of the stream of resource information.
  • the ACC strategy described herein involves the transition from one primary mode of delivery to another.
  • Section A describes an exemplary system for implementing the rate-limited ACC strategy.
  • Section B describes the manner of operation of the system of Section A.
  • Section C describes variations to the implementations described in Sections A and B.
  • Section D describes an exemplary computer environment for implementing aspects of the systems of Section A.
  • any of the functions described with reference to the figures can be implemented using software, hardware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations.
  • logic, “module” or “functionality” as used herein generally represents software, hardware, or a combination of software and hardware.
  • logic, module, or “functionality” represents program code that performs specified tasks when executed on a processing device or devices (e.g., CPU or CPUs).
  • the program code can be stored in one or more computer readable memory devices.
  • the illustrated separation of logic, modules and functionality into distinct units may reflect an actual physical grouping and allocation of such software and/or hardware, or can correspond to a conceptual allocation of different tasks performed by a single software program and/or hardware unit.
  • the illustrated logic, modules and functionality can be located at a single site (e.g., as implemented by a processing device), or can be distributed over plural locations.
  • first functionality and second functionality can correspond to different physical mechanisms for delivering resource information, or the same physical mechanism operating under different conditions.
  • the system 100 shown in Fig. 1 represents one exemplary and non-limiting system that can be used to implement the rate-limited ACC strategy, corresponding generally to functionality developed by Microsoft Corporation to deliver media information (such as television programs, movies, pictures, audio resources, etc.) in streaming fashion to users.
  • the rate-limited ACC strategy can be implemented on many other types of systems.
  • the rate-limited ACC strategy described herein can be employed in any system that involves a source module (referred to herein as a server module) which delivers resource information to a target module (referred to as a client module) in streaming fashion.
  • the examples developed in Section A pertain particularly to the delivery of resource information at a constant data rate.
  • the analysis also applies to worst-case assumptions for the case of capped variable bit rate (VBR) delivery (where the resource information is delivered at the maximum data rate permitted).
  • Section C describes variations of the concepts developed herein.
  • the system 100 includes head-end functionality 102, which comprises acquisition functionality 104 for delivering resource information to a collection of client modules 106 via a coupling mechanism 108.
  • the acquisition functionality 104 can receive information from one or more sources.
  • the sources can represent any kind of entity which produces or provides information, such as conventional cable or satellite television providers, one or more Video-On-Demand (VOD) suppliers of information, one or more publishing houses of information, one or more library sources of information, any kind of Internet-enabled repository of information, and so on.
  • the sources can supply live information or prerecorded information. Live information corresponds to information that captures a current state of an ongoing event (such as a sporting event which is being televised live).
  • Prerecorded information corresponds to information that has already been recorded. (The information may have been recorded in its entirety, before it is delivered to the client modules, or the information may be recorded as it is being delivered, there being a time lag between recordation and delivery.)
  • the acquisition functionality 104 itself can comprise one or more server computers, dedicated hardware, or other mechanism dedicated to the task of retrieving the resource information and (optionally) storing the resource information prior to dissemination to the server modules 106.
  • the system 100 can use any kind of coupling mechanism 108 to couple the head-end functionality 102 to the client modules 106.
  • the coupling mechanism 108 can include any kind of network (or combination of networks), such as a wide area network (e.g., the Internet), an intranet, Digital Subscriber Line (DSL) network infrastructure, point-to-point coupling infrastructure, and so on.
  • the coupling mechanism can use or involve any kind of protocol or combination of protocols, such as the Internet Protocol (IP), the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), the HyperText Transfer Protocol (HTTP), the Simple Object Access Protocol (SOAP), the Real Time Transport Protocol (RTP), Real Time Streaming Protocol (RTSP), and many potential others.
  • IP Internet Protocol
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • HTTP HyperText Transfer Protocol
  • SOAP Simple Object Access Protocol
  • RTP Real Time Transport Protocol
  • RTP Real Time Transport Protocol
  • RTSP Real Time Streaming Protocol
  • the coupling mechanism 108 can include various hardwired and/or wireless links, routers, gateways, name servers, and so on.
  • the coupling mechanism 108 can utilize the services, in part, of telephone coupling infrastructure and DSL processing functionality.
  • the rate-limited ACC solutions described herein are not technology-dependent, meaning that these techniques can "sit on top" of different protocols and technologies, or otherwise integrate and interact with such protocols and technologies.
  • the head-end functionality 102 relies on a combination at least two different delivery systems to deliver the resource information supplied by the acquisition functionality 104 (or supplied by some other source). (Although, as will be described in Section C, the ACC strategy can also be performed using a single delivery mechanism.)
  • First delivery functionality comprises a collection of server modules 110 for delivering a first stream of resource information to the client modules 106.
  • Second delivery functionality comprises multicast functionality 112 for delivering a second stream of the resource information to the client modules 106.
  • the construction and cooperative operation of the server modules 110 and multicast functionality 112 are explained in greater detail below.
  • Each client module can interact with the head-end functionality via a communication channel.
  • the term "communication channel" represents the resources that the system 100 uses for handling the communication between a particular client module and the head-end functionality 102.
  • the resources that comprise the communication channel may include functionality supplied by the head-end functionality 102, resources provided by the coupling mechanism 108, and/or functionality provided by the client modules 106 themselves.
  • the system 100 is a rate-limited environment. This means that there are threshold limits that restrict the amount of resources that the system 100 allocates to each communication channel, which place restrictions on the bandwidth of each communication channel.
  • client module A is coupled to the head-end functionality 102 by a collection of system resources that define a communication channel as broadly used herein.
  • the system 100 imposes a limit on the amount of resource information in a single stream that can be fed to module A.
  • client module A has the capacity to display plural streams of resource information at the same time (which might be the case, for example, where client module A has the capacity to provide a picture-in-picture presentation). In this case, the system 100 imposes a limit on the combined amount of information supplied by plural streams of resource information that can be consumed at any time.
  • the system 100 can implement its rate constraints by allocating a certain amount of bandwidth over an amount of bandwidth required to deliver the stream in a steady-state condition.
  • a communication channel allocates a total amount MaxRate of bandwidth to a communication channel.
  • the system 100 allocates a total amount of bandwidth of (1 + E ) *Nominal to the communication channel, where E represents the fractional amount of excess capacity of the communication channel above and beyond what is required to deliver the resource information in the steady-state condition ( Nominal ).
  • E represents the fractional amount of excess capacity of the communication channel above and beyond what is required to deliver the resource information in the steady-state condition ( Nominal ).
  • the nominal data rate ( Nominal ) refers to the peak data rate at which the stream is expected to be delivered in the steady-state condition.
  • the system 100 can select the parameter E in different ways.
  • the system 100 can be pre-provisioned to operate using a prescribed value for E .
  • Different values of E may be appropriate for different streaming environments, depending on various technical and business considerations.
  • E can be selected such that each communication channel is configured to operate at approximately 30 percent over the nominal rate which is required to present a stream of resource information in normal conditions. Many other values can be selected for E . If E is set at 100 percent, then the system can accommodate two complete versions of the stream at the same time.
  • E is less that 1.0 has certain consequences which will be set forth in detail below. As will be described in Section C, E can also be greater than 1.0, with the consequences set forth in that section.
  • the system 100 can automatically determine the level E .
  • a client module can progressively increase the data rate at which it interacts with the head-end functionality 102.
  • the communication channel has certain limitations regarding how much data it can stream to the client module. This means that the system 100 will perform progressively worse near the limits of the channel's capacity. Namely, the communication channel will begin to "drop" packets.
  • the client module will send retry requests to the head-end functionality 102 to ask for the missing packets.
  • the system 100 may be unable to fill in the missing packets using this retry mechanism before the packets are consumed by the client module's decoder.
  • the missing packets are referred to as "holes" herein. The consumption of resource information with "holes" produces a presentation having poor quality.
  • the operation of sending retry requests to a server module and supplying retry packets to the client module itself obviously consumes the resources of the communication channel, potentially overtaxing the communication channel yet further. If the data rate increases to a certain level beyond the capacity of the communication channel, the loss of packets and the consequent flood of retry information can cause a deleterious feedback loop, leading to a state referred to as a packet storm. Such a condition can completely disable the presentation of the stream.
  • the client module can determine the level E by iteratively increasing the data rate, determining the level of packet loss at each data rate, and selecting the value E at which the level of packet loss is acceptable, but beyond which becomes unacceptable.
  • the floor for the value E is effectively 0 percent, which yields the nominal rate of the stream.
  • the main objective of the system 100 is to supply resource information to the client modules 106 in a manner which does not exceed the prescribed rate limits.
  • the system 100 must ensure that the streams of resource information supplied by the server modules 110 and the multicast functionality 112 are combined in such a manner that the aggregate demand on communication resources never exceeds the prescribed data rate limit. This provision is advantageous because it prevents the system 100 from inundating the communication channels with too much resource information. It therefore prevents too many packets from being dropped, and the consequent degradation in resource presentation when the decoder consumes such resource information having holes. It further helps prevent the extreme case where one or more streams are simply dropped altogether because the system 100 becomes too overburdened.
  • the server modules 110 can include one or more server computers (e.g., a so-called "farm" of computer devices) or other mechanisms.
  • the server modules 110 can each basically perform the same functions. Routing functionality and/or load balancing functionality (not shown) can assign any of one of the server modules 110 to provide services to any one of the client modules 106. Due to use of redundant components at the head-end functionality 102, the following discussion will often revert to the singular when discussing the server modules 110. Indeed, it should be noted that the system 100 can function with even one server module.
  • the server modules 110 perform two basic roles: (1) sending a burst of resource information upon commencement of the stream; and (2) handling retry requests from the client modules 106.
  • these server modules 110 are responsible for supplying the resource information to the client modules 106 when the client modules first "tune to" resource information.
  • Such initial events occur when the user turns on a client module to consume whatever program happens to be presented on an initial channel; such initial events also occur when the user switches channels, thereby tuning to a new program.
  • the goal of the server modules is to feed a client module resource information on an expedited basis when the client module first tunes to a stream of the resource information. This, in turn, enables the client module to present the resource information more quickly, e.g., hopefully fast enough so that the user will not experience a delay when changing channels.
  • a server module performs the expedited buffer-fill operation by streaming the resource information to a client module at the full capacity of the communication channel that couples the server module to the client module.
  • the server module sends an initial burst of resource information at a level (1+ E ) *Nominal , meaning that the burst is performed at the normal nominal rate of the stream plus some fractional rate E times the nominal rate of the stream.
  • the server module supplies this burst to the client module in a unicast fashion, meaning that the server module generally devotes resources to communicate with the client module on a one-to-one basis.
  • the unicast can be performed using "datagram" connectionless style communication, such as UDP.
  • the unicast can alternatively be performed using TCP, or some other protocol or mechanism.
  • the server module also starts the unicast burst at a key frame of the resource information. This allows the client module to immediately begin presenting the resource information (because, without this provision, the client module would otherwise have to wait until it received a key frame if it initially received a series of difference frames).
  • Fig. 1 generally illustrates the unicast coupling between a server module and a client module by the unicast stream 114.
  • This stream 114 has two components. The larger of the two arrows represents the transmission of a stream of resource information to the client module in unicast fashion.
  • the stream can comprise a plurality of packets, each containing pieces of the resource information (e.g., one or more frames of audio-video information).
  • the resource information can be expressed using any standard, such as MPEG-2, among many other standards.
  • the client module that receives the stream of resource information can reconstruct the resource information based on the received packets.
  • the smaller of the two arrows represents any commands and other information that are transmitted by the client module to the server module. For example, the client module can send retry requests to the server module.
  • the client module will generate retry requests when it determine that it has missed one or more packets in the stream of information supplied by the server module based on holes in the received information. (Alternatively, as will be described in Section C, the client module can rely on another entity to receive missing packets.)
  • the second role performed by the server module is to honor such retry requests (if possible) by supplying any packets of missing resource information to the requesting client module.
  • the server module can place the retry packets into the stream of resource information that it supplies to the client module, although, in one exemplary implementation, the retry packets are not otherwise distinct from new (first-transmitted) packets in the stream. (In an alternative exemplary implementation, the retry packets are distinct from the first-transmitted packets.)
  • the client module can insert them into their proper location in the client module's buffer. The client module can order the packets based on sequence numbers associated with the packets.
  • the multicast functionality 112 performs the basic role of delivering resource information to the client modules 106 in a multicast mode.
  • the term multicast refers to the transmission of resource information to a client module in any manner that does not require one-to-one allocation of head-end resources to the client module.
  • One kind of multicast functionality 112 can be implemented using the Internet Group Management Protocol (IGMP).
  • IGMP functionality can supply resource information to a group of recipients by a tree of distribution nodes which receive the resource information from an ultimate source.
  • a new client module can join the ongoing multicast by tapping into the multicast distribution; it can perform this task by locating an appropriate distribution node within the tree of such nodes. Indeed, in the system 100 of Fig.
  • both the server modules 110 themselves and the client modules 106 can couple to a multicast distribution framework which ultimately receives resource information from the acquisition functionality 104.
  • the IGMP protocol is merely one non-limiting strategy for sending resource information in a multicast fashion to the client modules.
  • the term multicast transmission should be construed to encompass any kind of broadcast (non-unicast) transmission of resource information, including, for instance, broadcast satellite transmission of resource information.
  • a single head-end infrastructure can supply logic which implements both the server modules 110 and the multicast functionality 112.
  • two different infrastructures can be devoted to implementing the server modules 110 and the multicast functionality 112.
  • These server modules 110 and multicast functionality 112 can be maintained and operated by the same commercial entity, or different respective commercial entities.
  • Fig. 1 generally illustrates the multicast coupling between the multicast functionality 112 and one of the client modules 106 by the multicast stream 116.
  • This stream 116 has two components. The larger of the two arrows represents the transmission of a stream of resource information to the client module in multicast fashion.
  • the stream can comprise a plurality of packets, each containing pieces of the resource information (e.g., one or more frames of audio-video information).
  • the client module that receives the stream of resource information can reconstruct the resource information based on the received packets.
  • the smaller of the two arrows represents any commands or information that is transmitted by the client module to the multicast functionality 112. For example, the client module can issue a join request via this route to ask the multicast functionality 112 if the client module may join an ongoing multicast stream.
  • the head-end functionality 102 presents the unicast stream 114 and the multicast stream 116 in such a manner so as not to exceed the rate limit, e.g., (1+ E ) *Nominal .
  • a server module comes into action by sending a burst of unicast resource information at the exemplary rate of (1+ E ) *Nominal . This burst rapidly fills up the buffer of the client module and then terminates. Near the end of the burst, the server module will instruct the client module to switch to the multicast stream 116.
  • the client module will comply by sending a request to the multicast functionality 112, asking to connect to the multicast stream 116. When this connection is established, the client module then receives the multicast stream from the multicast functionality 112 at less than or equal to the nominal data rate ( Nominal ). (That is, this section assumes that the multicast rate remains steady at Nominal , but it need not. In other cases, the multicast rate will vary but will be capped at the Nominal rate. Section C sets forth an implementation which takes advantage of this fact by dynamically computing the excess capacity in the channel due to the varying multicast data rate.)
  • the ACC strategy therefore has the effect of transitioning from a first mode of delivery of the resource information (e.g., unicast via the server module) to a second mode of delivery of the resource information (e.g., multicast via the multicast functionality 112).
  • a first mode of delivery of the resource information e.g., unicast via the server module
  • a second mode of delivery of the resource information e.g., multicast via the multicast functionality 112
  • the use of the terms "unicast stream” 114 and "multicast stream” 116 should not obscure the fact that these streams contain the same pieces of data delivered using different delivery techniques.
  • join interval between the end of the unicast burst 114 and the start of the multicast stream 116.
  • the client module is attempting to establish a connection to the multicast functionality 112.
  • the join interval may depend, in part, on a delay in router(s) handling the IGMP join request.
  • the join interval may depend, in part, on a time required to switch the client module's tuner (not shown) to a new transponder (to receive the broadcast). Still other solutions are possible, each having its own respective "join behavior.”
  • the server module continues to transmit at the burst rate up until the time it issues a request for the client module to switch over to the multicast stream 116.
  • the server module can continue to transmit at the burst rate beyond this point up until the minimum time period in which the client module can successfully satisfy the server module's request that it join the multicast stream 116.
  • the second scenario will shorten the length of the join interval.
  • the general goal in the rate-limited environment is to prevent two full-rate streams from being received simultaneously, because this may exceed the (1+ E ) *Nominal capacity threshold (where E is understood as being less than 1 in this exemplary and non-limiting example).
  • the server module that is servicing the client module sends no resource information to the client module in this join interval. This would mean that the below-nominal rate is 0.
  • the server module transmits resource information taken from unicast stream 114 at a below-nominal rate.
  • the server module sends the client module resource information at the rate of E*Nominal .
  • the value of E can be fixed in advance.
  • the excess capacity can fluctuate depending on the time-varying excess capacity (as will be described in Section C).
  • it is useful to send at least some data from the unicast stream 114 during the join interval because this allows the client module's buffer to receive at least some resource information in what would otherwise be a "dead" period.
  • the client module will generally miss some of the packets that would have been transmitted during this interval (that is, if there was no break in the full-rate transmission). Stated another way, there will be holes in the received information caused by the join interval. Without corrective measures, the client module's output will suffer degradation if the client module consumes the resource information containing the holes. Such degradation could manifest itself in various artifacts, or possibly the complete failure of the presentation (e.g., where the system 100 effectively drops the stream).
  • the client module can overcome the problems that would be caused by the holes by sending retry requests to the server module. These retry requests ask the server module to supply any packets that the client module has identified as missing.
  • the client module can identify missing packets by ordering the received packets according to their sequence numbers. A discontinuity in the sequence numbers suggests that a packet has been lost (or, if corrupted, effectively lost).
  • some transports such as UDP
  • the client module may assess a loss of packets only when the packets are not received within a prescribed amount of time.
  • the client module can make its retry requests in one or more submissions to the server module.
  • the client module can make these requests after the join interval, when the multicast stream 116 is already being received.
  • the server module responds by supplying the missing packets requested by the client module. Again, the server module supplies the missing packets simultaneously with the presentation of the multicast stream. So as not to exceed the overall limitations on data rate, the server module will supply the retry packets at a rate that, when combined with the actual or nominal bandwidth requirements of the multicast stream, does not exceed the (1+ E ) *Nominal threshold requirements.
  • the effect of receiving the retry packets after the join interval is to supply the client module with any missing information before this missing information negatively impacts the performance of the client module. In other words, the retry packets fill in the holes in the received stream before these holes are consumed by the client module's decoder.
  • Another aspect of the strategy pertains to the manner in which the system 100 is configured in order to successfully achieve the above-described rate-limited ACC streaming behavior. Namely, a number of different parameters govern the behavior of the rate-limited streaming. Exemplary such parameters include:
  • the selection of one parameter generally impacts other parameters.
  • the general goal in configuring the system 100 is to select a combination of such parameters that yields the desired rate-limited ACC behavior.
  • One exemplary configuration tool allows a designer to define various combinations of parameters that will provide desired rate-limited ACC behavior by ensuring that the ratio ( T burst / T join ) is related to some function of the fractional excess capacity E in a defined way, where T burst describes the length of time of the unicast burst, and T join describes the amount of time required to join the multicast stream 116. Calculation of this nature can be performed by any of the "actors" within the system 100, such as any of the server modules 110 and/or any of the client modules 106.
  • the system 100 may employ a separate configuration tool 118 to make any of the computations described herein.
  • the configuration tool 118 can comprise a computer device, which can be either a stationary or portable computer device. Further, the computer device 118 can be either a stand-alone or networked computer device.
  • the configuration tool 118 can rely on a human operator to manually input relevant parameters, or can automatically extract relevant parameters from the system 100.
  • the system 100 can rely on a human operator to implement the recommendations of the configuration tool. Or the configuration tool 118 can automatically supply its recommendations to the relevant actors in the system 100, and these actors can automatically reconfigure themselves based on the recommendations.
  • the rate-limited ACC strategy described above achieves the benefits of rapidly supplying the client modules 106 with resource information upon channel change events, to thereby improve user experience (by not subjecting the user to annoying delays when he or she changes channels).
  • the rate-limited ACC strategy does not demand that the system 100 devote large bandwidth capacity to accommodate this feature.
  • the system eliminates the need to provide a bandwidth that can accommodate the concurrent presentation of two full-rate streams (e.g., a full-rate unicast stream at the same time as a full-rate multicast stream).
  • the strategy staggers the burst-rate unicast stream 114 and the multicast steam 116 in series, with a join interval in between; any packets that are missed due to this join interval can be filled in by retry requests, where the retry activity takes place concurrently with the presentation of the stream and reception of the multicast stream (because the multicast stream 116 takes place at or below the nominal rate, allowing some excess capacity for retry activity).
  • the system is therefore suitable for those environments where there are significant constraints on bandwidth due to any number of technical and/or business-related reasons.
  • Fig. 2 describes the rate-limited ACC functionality on a next level of detail by showing more information regarding any of the exemplary server modules 106 and client modules 110 that appear in Fig. 1 .
  • Fig. 2 shows an exemplary server module 202 which interacts with an exemplary client module 204 via a communication channel 206 to deliver resource information.
  • a constant bit rate or worst-case capped VBR is assumed, although, as will be described in Section C, the principles described herein can be extended to other environments.
  • the server module 202 can be implemented as any kind of computer device with hardware and/or software that enables it to function in the role of a supplier of services to client modules.
  • the server module 202 can include any array of conventional hardware (not shown), such as one or more processor devices (CPUs), RAM memory, ROM memory, various media drives and associated media (e.g., hard drives and associated hard disc), various buses to couple the components together, various communication interfaces, various input/output functionality, and so forth.
  • the client module 204 can include any kind of equipment for interacting with the server module 202 (and for interacting with the multicast functionality 112).
  • the client module 204 can correspond to set-top boxes, game-type consoles (such as Microsoft Corporation's XboxTM game consoles), software and/or hardware functionality integrated into the associated presentation devices, general purpose or special purpose computer devices, and so forth.
  • the client module 204 can include at least the basic hardware identified above with respect to server module 202, as well as any additional hardware specifically targeted to its role as a consumer (rather than supplier) of resource information.
  • Fig. 2 shows that the client module 204 comprises processing functionality 208 for processing resource information received from the server module 202, as well as presentation functionality 210 that outputs the processed resource information to a consumer.
  • the client processing functionality 208 can correspond to a set-top box
  • the presentation functionality 210 can correspond to a television unit which couples to the set-top box.
  • the client processing functionality 208 can correspond to a general purpose computer and the presentation functionality 210 can correspond to a computer monitor which couples to the computer.
  • Fig. 2 illustrates the rate-limited channel 206 by showing a bandwidth 212 that is allocated to steady-state "normal" streaming of the resource information at a nominal peak rate, and an excess bandwidth 214 which is added to the nominal bandwidth 212.
  • the extra bandwidth 214 can be expressed as a bit rate or as a fractional value E .
  • the channel 206 is rate-limited in the sense that the instantaneous data rate should not exceed the ceiling threshold defined by the aggregate of the nominal bandwidth 212 and the extra bandwidth 214, that is, in aggregate, (1 + E ) of the nominal bandwidth.
  • rate restrictions can be parsed out in fractional fashion to apply individually to component streams supplied to a single client module (or supplied to multiple client modules which feed off of the same communication channel).
  • rate restrictions apply to the case where a single client module is presenting a single stream of resource information.
  • the server module 202 includes server functionality 216 which enables server module 202 to function in the manner described herein.
  • the server functionality 216 includes: logic (hardware and/or software) for receiving resource information from the acquisition functionality 104 (or elsewhere); logic for supplying a burst of unicast resource information to a client module 204 in response to a channel change event; logic for optionally transmitting a below-nominal rate unicast stream to the client module 204 during the join interval (when the client module is switching from unicast delivery to multicast delivery); logic for receiving requests from the client module 204 to supply missing packets, and so forth.
  • the server module 202 maintains a buffer 218.
  • the buffer 218 can comprise a sliding circular buffer.
  • the buffer 218 stores recently received resource information (from the acquisition functionality 104), including the resource information that will populate: the initial unicast burst; the below-nominal unicast transmission during the join interval; and the information that will be used to satisfy the client module 204's retry requests (if possible).
  • the buffer 218 comprises a FIFO-type buffer; it stores new resource information that is supplied by the acquisition functionality 104 by generally deleting the oldest resource information within the buffer 218.
  • the server module 202 can also function as a forwarder of information that it stores in advance.
  • the server module 202 can stream video on demand (VOD) information that it stores in its memory.
  • Fig. 1 represents this scenario by the bubble labeled "VOD Source" associated with the topmost exemplary server module.
  • the server module 202 can employ a static buffer 218' to delivery the VOD assets, rather than the sliding circular buffer 218 shown in Fig. 2 .
  • Section C provides additional information regarding the delivery of VOD assets.
  • the server module 202 will send the burst for a prescribed amount of time, referred to as T burst .
  • T burst a prescribed amount of time
  • the server module 202 will reach back to pull an appropriate amount of resource information from the buffer 218 to compose the burst having the duration T burst .
  • Fig. 2 illustrates a segment of resource information 220 that is presented in the exemplary unicast burst. This segments may generally correspond to resource information that was received by the acquisition functionality 104 about 10 seconds prior to current time.
  • the minimum amount of excess buffer that the server module must maintain is equal to T delay *Nominal (which is the same as E*T burst *Nominal ).
  • the resource information sent by the server module 202 can be expressed in various formats.
  • the resource information comprises video information.
  • the video information is composed of a series of key frames (also referred to as I frames, random access points, etc.) which contain complete video frames that are independently decodable and don't depend on previous resource information in order to decode to a complete video frame that can be displayed to the user.
  • the video information can also include a variety of difference frames ( ⁇ ) which represent a video frame for different times by expressing how the video information differs from one or more other frames.
  • MPEG-2 uses this approach by presenting a combination of 1-frames, B frames and P frames (where the I frames constitute key frames and the B and P frames constitute difference frames).
  • the server module 202 will select the segment of resource information to be sent to the client module 204 in the burst so that it begins at a key frame. This is beneficial because the client module 204 cannot begin rendering resource information until it receives a key frame. By forcing the server module 202 to start its transmission with a key frame, the client module 204 will not have to receive a series of difference frames before receiving a key frame. (Note that, while Fig. 2 and the other figures represent the resource information as a series of frames to facilitate discussion, it is important to note that the server module 202 will break this information up into a series of packets and transmit the information to the client module 204 in units of packets, not frames.)
  • this module 204 includes client functionality 222 which enables the client module 204 to function in the manner described herein.
  • the client functionality 222 includes: logic (hardware and/or software) for establishing a connection with the server module 202 as well as the multicast functionality 112; logic for receiving and rendering the unicast stream 114 and the multicast stream 116; and logic for sending retry requests to the server module 202.
  • the client module 204 maintains a client buffer 224 (if so equipped).
  • the client buffer 224 stores a prescribed amount of resource information received from the server module 202.
  • the client functionality 222 draws from the client buffer 224 when it presents the resource information.
  • the maximum amount of extra buffer required is T delay *Nominal.
  • the client module 204 should be pre-provisioned with a buffer that can store T delay *Nominal amount of information (which is the same as E*T burst *Nominal ).
  • the client module 204 can communicate its capabilities to the server module 202 on its own initiative, or when queried by the server module 202. If the server module 202 determines that the client module 204 has insufficient buffer capacity, it can refrain from using the rate-limited ACC technique when communicating with the client module 204, or can use another kind of accelerated start technique that the client module 204 can accommodate.
  • the client module 208 can immediately start playing resource information upon receipt of the resource information (e.g., without requiring any preliminary buffering). This solution may result in some unsteady performance when first tuning to a channel.
  • the client module 208 can require that a prescribed amount of information be buffered prior to the presentation of the video information. This will result in a short presentation delay, but such a delay is reduced by virtue of the use of the ACC initial burst.
  • the client module 208 can display the initial key frame as soon as it is received, then buffer a prescribed amount before beginning full-motion playback.
  • Fig. 2 shows a series of timelines 226 that illustrate the manner in which the client module 204 consumes resource information.
  • Many protocols tag video information using two separate time stamps: a delivery timestamp and a presentation timestamp.
  • a delivery timestamp associated with a packet describes when that packet is intended to be delivered to a receiver.
  • the presentation timestamp describes when the decoded version of that packet should actually end up on the presentation functionality 210 (e.g., a television screen).
  • the maximum gap permitted between the delivery and presentation timestamps is a configurable parameter of an encoder, referred to as the "max PCR/PTS delay.”
  • a series of delivery timestamps defines a delivery timeline.
  • the first timeline in the group of timelines 226 shows a delivery timeline.
  • a series of presentation timestamps defines a presentation timeline.
  • the second timeline in the group of timelines 226 shows a presentation timeline.
  • the arrows connecting the delivery timeline and the presentation timeline illustrate how packets in the delivery timeline correspond to the same packets in the presentation timeline. The arrows are skewed because the packets are intended to be presented some time after their respective delivery times.
  • Fig. 2 also shows that the packets are evenly spaced on the delivery timeline, but are bunched up on the presentation timeline.
  • video information is delivered at a constant rate (the nominal rate of the stream) in this exemplary and non-limiting case (and therefore satisfies the worst-case for the steady-state stream bandwidth), but the video information is not consumed at a constant rate (e.g., the key frames are much larger than the difference frames, but are presented on a display for the same amount of time).
  • the group of timelines 226 also shows a third timeline that describes when the packets are actually presented (as opposed to when they were intended to be presented).
  • the arrows connecting the presentation timeline and the actual timeline illustrate how packets in the presentation timeline correspond to the same packets in the actual timeline.
  • the arrows are skewed because the packets are actually presented some time after they were intended to be presented. Namely, the large buffer 224 used by the client module 204 imposes a delay in the presentation of the video information (because there will typically be some amount of time between when the packet is placed in the buffer 224 and when it is actually output to the presentation functionality 210).
  • Different client modules may have different mechanisms (e.g., buffer capacities) for delaying the presentation of the video information; hence, different client modules may follow different respective actual presentation timelines.
  • Other reasons that the client modules may have different actual presentation timelines include: (a) client modules tuning to the stream at slightly different times; and (b) client modules requiring different amounts of delay relative to a live state for smooth playback, depending on the loss rate of the channel; and (c) client modules requiring different amounts of delay relative to a live state for smooth playback, depending on the delivery time jitter of the channel.
  • the delivery timestamp serves as an authoritative clock reference.
  • One exemplary implementation of the present system uses a shared clock to control playback of the video information.
  • the system can use a Network Time Protocol (NTP) clock reference as the shared clock.
  • NTP Network Time Protocol
  • the client module 204 determines the offset between the presentation timestamp information in the video stream and the shared clock, and then attempts to maintain this offset throughout the reception of the video information.
  • the delivery timestamp also serves as floor threshold when performing the rate-limited ACC technique. Namely, as will be explored in detail below, the rate-limited ACC technique will attempt to feed video information to the client module 204 in such a way that the client module 204 never falls behind on the delivery timeline (as shown in the first timeline of the group 226 of Fig. 2 ).
  • Fig. 5 is an exemplary series of operations that explain the interaction between the exemplary client module 204 (introduced in Fig. 2 ) and, on one hand, the exemplary server module 202 (introduced in Fig. 2 ), and, on the other hand, the multicast functionality 112 (introduced in Fig. 1 ).
  • the order and nature of the operations are exemplary.
  • Other implementations of the rate-limited ACC strategy can apply the operations in somewhat different order, and/or can include additional types of operations, and/or can omit one or more operations shown in Fig. 3 .
  • operation (1) when the client module 204 initiates the presentation of a stream of resource information, it sends a request to the server module 202.
  • the head-end functionality 102 may assign the client module 204 to one of its server modules 110 using any kind of assignment algorithm (such as a fixed assignment, a load-balancing assignment, and so forth).
  • Operation (1) may generally correspond to an event in which a user changes channels to receive a new program, or otherwise performs any act which prompts the client module 240 to request connection to a new program (or a new part of a same program, such as in response to a fast-forward command, etc.).
  • the server module 202 responds by setting up a unicast to the client module 204.
  • a unicast involves a one-to-one allocation of prescribed server resources to the client module 204.
  • the server module 202 then initiates the stream by first sending an initial burst of the resource information at a rate of (1+ E ) *Nominal , where Nominal defines the nominal rate of the stream, and E defines some prescribed fractional amount over the nominal rate (such as approximately 20 percent). This transmission defines the start of the unicast stream 114 introduced in Fig. 1 .
  • the client module 204 can optionally inform the server module 202 of its buffer capacity.
  • the client module 204 might not have any extra buffer, or may have only a limited amount of extra buffer. If the server module 202 determines that the client module 204 cannot accommodate the rate-limited ACC technique described herein, it will not send the burst in operation (2). It may simply forward the resource information at the nominal rate (which will incur a delay before the resource information can be presented), or it will use some other ACC technique that makes fewer demands on the buffer capacity of the client module 204.
  • the server module 202 Presuming that the client module 204 does have the requisite buffer capacity, then, for the case of live delivery of resource information, the server module 202 sends a unicast burst that is offset by a delay time of T delay in presentation timeline terms. This burst is also configured to start at a key frame.
  • Similar provisions apply to the delivery of pre-stored VOD assets. More specifically, in the VOD case, it is generally possible to perform the burst by starting from a point that is as "far back" as desired in the stream, since all the resource information is available for distribution at the server module 202. But the client module 204's buffer has a limited capacity, and there is limited need for buffering based on the characteristics of the network. In view of these factors, one exemplary strategy (for VOD) is to provide a burst having a duration ( T delay / E ) that is sufficient to allow enough time for retries to be requested and sent well before the resource information is needed, even if the same packet is missed, for example, one or two times. In extremely lossy networks, it may be desirable to allow for enough time to attempt retry more than twice. In order to do this, T delay can be made larger, which makes the burst last longer.
  • the client module 204 begins presenting the resource information a short time after receiving the start of the initial burst. This time is brief enough so that the user will not perceive an unacceptable delay in presentation upon changing channels.
  • the server module sends a command to the client module 204 to join the multicast stream 116.
  • the client module 204 responds to the request of the server module 202 by making its own request to the multicast functionality 112 to set up the multicast stream 116. As described above, this may constitute issuing an IGMP join command. This command will prompt the multicast functionality 112 to connect the client module 204 to an appropriate node in which it can receive an ongoing multicast transmission. As described above, in one case, the server modules 110 themselves may receive the resource information using a multicast distribution scheme from the ultimate source defined by the acquisition functionality 104. The join operation in this case would entail connecting the client module 204 to this same ongoing multicast stream 116.
  • the multicast functionality 112 forwards its first multicast packet to the client module 204.
  • the ensuing multicast stream is received at a data rate that is less than or equal to the nominal data rate.
  • the server module 202 sends no unicast information in the join interval.
  • the server module 202 starts sending the unicast stream at a rate of E*Nominal .
  • the failure to send streaming information at the full (nominal) data rate will have the effect of creating "holes" in the resource information received in the client module 204's buffer 224. These holes define packets that have been lost, because they never were received or have been received but are corrupted. These holes will lead to degradation of the output presentation if they are not filled in by the time the client module 204 decodes this resource information.
  • the client module 204 determines what holes are present in the received resource information. It can do this by ordering the received packets according to their sequence numbers and then noting any discontinuities in the sequence numbers; the discontinuities define holes.
  • the client module 204 sends a command to the server module 202 that requests the server module 202 to send the missing packets.
  • the client module 204 can send multiple commands for each respective missing packet or can send commands that each identify several of the missing packets.
  • the server module 202 After receipt of the retry request(s), the server module 202 prepares the missing packets for transmission to the client module 204 (if it can). The server module 202 performs this task by pulling the missing packets from its buffer 216 (if they are still present). In operation (6), the server module 202 sends the missing packets to the client module 204. As will be apparent in the discussion of the next figure, the server module 202 sends the retry information as a normal stream of packets at a data rate of E*Nominal , concurrently with the receipt of the multicast stream at or below the nominal data rate, such that the total bandwidth is again (1+ E ) *Nominal .
  • the retry packets are "normal packets" in the sense that they are not specifically earmarked as retry packets.
  • the client module 204 can identify retry packets because it has requested them; they are identified upon receipt by their sequence numbers.
  • Section C describes variations on this protocol, in which the server module 202 can take advantage of dips in the data rate of the multicast stream by sending additional retry information (such that the server module 202 sends information at a rate of MaxRate - ActualCurrentMulticastRate , which can be expressed also as E*Nominal + ( Nominal - ActualCurrentMulticastRate )).
  • Fig. 4 shows a bandwidth-vs.-time depiction 400 that illustrates how the operations described in Fig. 3 correspond to different utilizations of bandwidth at different times.
  • the horizontal axis of this depiction 400 corresponds to time.
  • the vertical dimension any of the rectangles shown in the depiction 400 corresponds to the amount of bandwidth that is being consumed.
  • the largest encompassing rectangle has a vertical height corresponding to the maximum bit rate permitted by the rate-limited environment, namely (1+ E ) *Nominal .
  • the dimensions of the other rectangles shown within the larger rectangle may not be drawn to scale; namely, the dimensions of some of the rectangles may be expanded or compressed to facilitate illustration and discussion.
  • Section C describes how this analysis can be extended for other scenarios.
  • the enumerated operations shown in Fig. 4 correspond to the same numbered operations shown in Fig. 3 , thus there is no need to repeat their description in the context of Fig. 4 .
  • the focus in Fig. 4 will center on the relative timing of various events, and the amount of information transmitted at different junctures in the streaming operation.
  • the unicast burst 402 fills up all of the available bandwidth, e.g., (1+ E ) *Nominal .
  • the multicast 404 occurs at or below the nominal rate ( Nominal ).
  • the rectangle 406 denotes a period of time between the unicast burst 402 and the multicast 404 having a horizontal dimension equal to the join interval T join . This defines the period of time that the system 100 is attempting to establish a multicast connection to the multicast functionality 112.
  • a first optional rectangle 408 corresponds to a unicast stream transmitted by the server module 202 at the rate E*Nominal . This stream is optional because the server module 202 can alternatively transmit 0 data in this region. Also, the server may choose to additionally use any portion of Nominal left unused by the multicast. In any event, the "empty" join rectangle 406 will lead to holes in the received stream of resource information. To address these holes, the client module 204 will send retry requests to the server module 202, asking the server module 202 for packets that have been assessed as lost due to the empty join box 406.
  • the small rectangle 410 represents the small amount of bandwidth consumed by the request operation itself.
  • the following retry rectangle 412 corresponds to the resultant the flow of unicast retry information from the server module 202 to the client module 204. That is, the retry information contains the missing packets requested by the client module 204, transmitted at the rate of E*Nominal (for the case of constant data rate).
  • the area of the rectangle 412 is equal to or approximated by the area of rectangle 406 minus the area of rectangle 408. More intuitively stated, this means that the length of the join interval and the amount of data that is sent in the join interval determine the area of rectangle 412. If no unicast information is transmitted during the join interval, then rectangle 412 will have a correspondingly greater area.
  • this technique permits ACC to be performed, thereby quickly supplying a program to user upon switching to it, within an environment that has significant limitations on bandwidth.
  • Fig. 5 provides yet further information regarding the operation of the system 100.
  • This figure particularly shows the contents of the client module 204's buffer 224 at three junctures, labeled X, Y and Z, which are also identified in Fig. 4 .
  • the contents are shown arranged on the presentation timeline, not according to when the contents are received.
  • This figure particularly illustrates the buffer contents in terms of frames because this form of representation is instructive. It should be noted, however, that the buffer 224 will contain packets of information, and that the packets will themselves include parts of the stream of frames. As another simplification, the buffer 224 will typically include more information than is shown in Fig. 5 .
  • the horizontal time scale of the presentation timeline 224 is appropriately compressed and expanded in Fig. 5 to facilitate illustration and discussion.
  • the client module's buffer 224 is empty.
  • the buffer 224 has a state shown by the topmost depiction in Fig. 5 .
  • Location X corresponds to the juncture at which the entire unicast burst 402 has been sent.
  • Location X also marks the start of the join interval 406.
  • the entire span of the buffer (A+B) corresponds to the amount of resource information that has been received by the burst 402.
  • the vertical line 502 demarcates region A from region B.
  • Region A corresponds to the amount of information that would have been received if the server module 202 had transmitted at the nominal rate, instead of at the excess rate of (1+ E ) *Nominal .
  • Region B defines the amount of extra information that has been transmitted due to the rate of E*Nominal .
  • (A + B)/A E .
  • the line 502 also marks the location where the client module 204 is consuming packets from the perspective of the delivery timeline (again refer to the timelines shown in grouping 226 of Fig. 2 ).
  • the buffer has a state shown in the middle part of Fig. 5 .
  • Location Y corresponds to a juncture at which the unicast transmission at the rate of E*Nominal has just come to an end.
  • the span of presentation timeline formed by the aggregate of segments C and D corresponds to the join interval ( T join ), namely, the amount of time required to set up the multicast stream 116.
  • the C segment of the presentation timeline represents information the server module 202 sent at the rate of E*Nominal .
  • the amount of information transmitted in segment C is T join *E*Nominal .
  • This segment takes a time of T join to be delivered.
  • Fig. 5 shows that the client module 204 has received a complete key frame during the unicast transmission at the rate of E*Nominal , although this is merely representative.
  • the segment D marks the amount of information that has been lost due to the failure to transmit at the nominal bit rate during the join interval.
  • the quantity of information lost during the join interval is denoted by T join (1 -E ) *Nominal .
  • the hole defined by segment D has been shown as a continuous block of missing data; but the hole can be comprised of a general span having a mixture of received packets and lost packets. Again, the horizontal span of presentation timeline illustrated in Fig. 5 may not be drawn to proportion.
  • the vertical line 504 again represents the current point of consumption from the perspective of the delivery timeline.
  • the span of time 506 stretches from the current consumption time 504 to the beginning of the hole (represented by segment D). This segment 506 represents the amount of time that the client module 204 has to fill in the hole. In other words, the client module 204 must fill in the hole before the current consumption time 504 reaches the hole.
  • the information 508 denotes the receipt of the first multicast packets from the multicast stream 116.
  • the buffer 224 has a state shown at the bottom part of Fig. 5 .
  • Location Z corresponds to a juncture at which the retry packets have all been received in response to a request (or plural requests) by the client module 204.
  • the retry information has successfully filled in the hole denoted by span D.
  • the retry was also successful in the sense that the hole has been filed in before the current point of consumption 510 (from the perspective of the delivery timeline) has reached the start of the hole. Then, after what was once the hole, the client module 204 receives the remainder of the resource information via the multicast stream 116.
  • the behavior of the system 100 shown in Fig. 1 is governed by a combination of several interrelated parameters.
  • an appropriate combination of parameters must be selected.
  • the above subsection A.1 enumerated several exemplary parameters that can be taken into account when configuring the system, various combinations of which can achieve the desired retry behavior that has been described.
  • This section particularly describes mathematical analyses for deriving relationships between the amount of time in the initial burst ( T burst ), the amount of time required by the join interval ( T join ), and the amount of excess capacity E .
  • the relationships define combinations of these variables that will yield the desired retry behavior. More specifically, Figs. 6-10 describe the computation of such mathematical relationships for different retry-related assumptions. Any functionality can be used to perform the computations described herein, such as the configuration tool 118 introduced in Fig. 1 . Again note that the simplifying case of constant bit rate is assumed (which also applies to the worst-case scenario of capped VBR). Section C describes how this analysis can be extended for other scenarios.
  • Fig. 6 corresponds to the case where the client module 204 demands that it completely fill in the hole of missing packets with retries before the consumption point (from the perspective of the delivery timeline) reaches the end of the information provided by the initial burst alone. Stated in other terms, this condition specifies that the client module 204 must completely fill in region D shown in Fig. 5 before the consumption arrow (e.g. 504) reaches the end of region B.
  • the top graph in Fig. 6 shows a scenario in which the above-defined condition has been reached.
  • the bottom graph in Fig. 6 shows a scenario in which the above-defined condition has not been reached.
  • the vertical axis defines an amount of information received by the client module 204, and the horizontal axis defines progressing time.
  • the thick diagonal line 602 describes the client module 204's demand for the resource information.
  • the area beneath the demand curve 602 defines an underflow region 604.
  • This underflow region 604 corresponds to an operational domain in which the client module 204 will experience the insufficient flow of resource information. If the operational state enters this region, the buffer 224 will develop holes that will be consumed by the client module 204's decoder, resulting in degraded performance.
  • the demand curve is actually assuming the maximum data usage.
  • the actual demand curve, for any particular piece of content may be lower than this "worst-case" demand curve. But because the described scheme works for the worst-case scenario, it works for all variable bit rate cases of lower demand.
  • the first segment 606 of scenario 1-A describes the receipt of resource information during the initial unicast burst at rate (1+ E ) *Nominal . Note that the slope of segment 606 extends at a steeper angle than the demand curve 602, and thereby progressively extends away from the demand curve 602. This separation equates to desirable extra resource information that client module 204's buffer 224 accumulates during the initial burst, which reaches a maximum amount at the end of the first segment 606.
  • the second segment 608 graphically describes what happen when the server module 202 transmits at the rate of E*Nominal following the initial burst. This transmission lasts for the length of the join interval T join .
  • the server module 202 can optionally transmit 0 amount of information in this period, whereupon the second segment 608 would have a slope of zero.
  • the third segment 610 graphically describes what happens during the combination of events corresponding to: (a) the receipt of the multicast stream 116 from the multicast functionality 112; and (b) the request for and the receipt of retry information (where the server module 202 sends the retry information in unicast fashion).
  • the aggregate bit rate of this combined activity is (1+ E ) *Nominal , and therefore has the same slope as the first segment 606.
  • the last segment 612 graphically describes what happens when the server module 202 finishes sending the retry information, whereupon the client module 204 continues to receive only the multicast stream 116 at the nominal rate.
  • scenario 1-B confirms the above conclusion. All of the line segments 606-612 have the same meaning as described above in connection with scenario 1-A, although these segments may trace a different path than the segments shown in scenario 1-A. Of principal note in scenario 1-B is that the dotted line 612 now extends into the underflow region 604, signaling that the stated conditions have not been met.
  • the constraint identified in Fig. 6 is a particularly conservative one, as information continues to be received during the join interval. This additional information can be used to extend the deadline at which all holes must be filled in.
  • Fig. 7 presents two scenarios (scenario 2-A and scenario 2-B) that adopt the more liberal constraint that all holes created by the join period be filled in before running out of resource information collected during both: (a) the initial burst period; and (b) the join interval itself.
  • the server module 202 optionally transmits unicast information at rate E*Nominal during the join interval.
  • this constraint means that the client module 204 must fill the gap D before the consumption timeline 504 reaches the end of segment C (because segment C represents the amount of information, T join *E*Nominal ) that was acquired during the join interval.
  • Fig. 8 presents two other scenarios (scenario 3-A and scenario 3-B) that adopt a yet more liberal constraint that stipulates that the current point of consumption must simply not overtake any part of the buffer 224 with holes in it.
  • This more liberal assumption can be satisfied based on resource information received as a result of any of: (a) the initial burst period; (b) the join interval; and (c) retry activity following the join interval.
  • T burst the amount of time in the initial unicast burst
  • T join the amount of time required by the multicast join
  • E the amount of extra capacity allocated to the communication channel
  • the constraint imposed is that the amount of excess buffer attributed to the initial burst itself, combined with the E*Nominal unicast stream transmitted during the join interval, be sufficient to fill in all of the holes.
  • the following analysis derives the mathematical relationship between T burst , T join and E for this constraint.
  • the constraint imposed is that the amount of excess buffer attributed to the initial burst itself, combined with the E*Nominal unicast stream, and also combined with any retry information received thereafter, be sufficient to fill in all of the holes.
  • the constraint is simply that the current point of consumption (from the perspective of the delivery timeline) keep abreast of any holes in the client module 204's buffer 224.
  • the following analysis derives the mathematical relationship between T burst , T join and E for this constraint.
  • This derivation starts in a similar way to the derivation for Fig. 9 .
  • the significant difference is that, instead of using the straight "buffered after join" as the allowable retry time, the present derivation takes account of the fact that extra data is still arriving. Because the extra data is arriving from the beginning of the hole, and is arriving at the rate of E , the amount of time the buffer has to survive is the original time, divided by (1 - E ).
  • Figs. 9 and 10 together describe the operation of the functionality of the preceding figures in flow chart form. To facilitate discussion, certain operations are described as constituting distinct steps performed in a certain order. Such implementations are exemplary and non-limiting. Certain steps described herein can be grouped together and performed in a single operation, and certain steps can be performed in an order that differs from the order employed in the examples set forth in this disclosure.
  • Figs. 9 and 10 restate the operations already described in the context of Fig. 5 in flowchart form. As this material has already been carefully set forth, the discussion of Figs. 9 and 10 will serve as a summary; the reader is referred back to the discussion of Fig. 5 for a more complete explanation of the subject matter. Again note that the simplifying case of constant bit rate is assumed (which also applies to the worst-case scenario of capped VBR). Section C describes how the procedures can be extended for other scenarios.
  • Fig. 9 is a procedure 900 which defines operations performed by the server module 202 when a channel change event occurs (or when some other event associated with the start up of a stream occurs).
  • the server module 202 receives a request from the client module 204 to receive the initial burst to facilitate start up.
  • this initial period can also involve an investigation of what kind of excess buffer is required by the client module 204, and a determination of whether the client module 204 can satisfy such a requirement.
  • step 904 the server module 202 starts the burst at the rate of (1+ E ) *Nominal .
  • step 906 the server module 202 sends a join mcast instruction to the client module 204, which instructs the client module 204 to join the multicast stream 96.
  • the server module 202 also begins transmitting at the rate of E*Nominal (and continues at this rate for the ensuring join interval).
  • step 908 the server module 202 receives a request from the client module 204 to stop streaming altogether (because the client module 204 has successfully connected to the multicast stream 116). In this step 908, the server module 202 also receives retry requests from the client module 204 corresponding to holes that occurred due to the join interval.
  • step 910 the server module 110 sends the retry packets to the client module 204 in response to the retry requests.
  • Fig. 10 is a procedure 1000 that defines activities performed by the client module 204, and is the counterpart of the server-based activities of Fig. 9 .
  • step 1002 the client module 204 sends a join request to the server module 202, requesting that the server module 202 commence the transmission of the stream.
  • step 1004 the client module 204 starts receiving the server module 202's burst at rate (1+ E ) *Nominal , and shortly thereafter, begins playing the resource information in the stream.
  • the client module 204 receives a join mcast instruction from the server module 202, which instructs the client module 204 to join the multicast stream 116 enabled by the multicast functionality 112.
  • the client module 204 also receives the last of the unicast burst, followed by a unicast stream at rate E*Nominal .
  • step 1008 the client module 204 responds to the server module 202's instruction by sending its own join request to the multicast functionality 112.
  • step 1010 in response to the client module 204's request, the client module 204 begins receiving multicast information from the multicast functionality 112. This event marks the end of the join interval.
  • step 1012 the client module 204 determines the identity of any holes that have occurred in the steam due to the below-nominal stream transmission during the join interval. In this step 1012, the client module 204 sends a retry request to the server module 202 that asks the server module 202 to supply the missing packets.
  • step 1014 the client module 204 receives the missing packets from the server module 202. This has the effect of filling in the holes created by the join interval. If the holes can be filled in prior to the consumption of these holes, then the procedure is deemed successful.
  • E was less than 1.0. However, in other cases, E can be set as equal to or greater than 1.0. This means that the communication channel can accommodate at least two nominal data rate streams at the same time.
  • Fig. 11 shows a representation 1100 of a hybrid unicast/multicast ACC strategy in which E ⁇ 1.0. More specifically, as before, a unicast burst 1102 is followed by a multicast stream 1104. The burst 1102 occurs at a MaxRate level that is at least two times the nominal rate of the stream. A join interval 1106 separates the unicast burst 1102 from the multicast stream 1104. In the join interval, the server module 202 (of Fig. 2 ) can deliver unicast resource information at some rate, such as 0, or E*Nominal (for the constant data rate or capped VBR case). In the former case, the join interval will cause packets to be missed.
  • some rate such as 0, or E*Nominal (for the constant data rate or capped VBR case). In the former case, the join interval will cause packets to be missed.
  • These packets can be provided concurrently with the multicast stream 1104 at a rate of E*Nominal.
  • a unicast stream 1108 of E*Nominal can supply data throughout the join interval. Since the unicast stream now remains at a nominal rate or above in the join interval, there is potentially no loss of packets due to the join interval.
  • VBR variable bit rate
  • Delivery that is governed by a capped variable bit rate maintains the data rate so that it remains below the maximum rate level (i.e., the cap level) of the stream.
  • Fig. 12 shows a representation of a channel 1200 that supports a variable bit rate. Namely, at any given time, the steady-state transmission of resource information consumes an actual amount 1202 of a total allotted data rate MaxRate, leaving, at any given time, a variable extra capacity 1204.
  • the ACC strategy can utilize the extra capacity 1204 to accomplish the transition between the first mode of delivery to the second mode of delivery. For example, in a first phase, the ACC strategy can pack as much additional information as it can into the unicast burst. In a second phase, the ACC strategy can pack as much unicast data as it can during the join interval.
  • the ACC strategy can pack as much retry data (either supplied from a unicast source or a multicast source) as it can, concurrently with its supply of the multicast stream.
  • the ACC strategy can actively monitor the amount of bandwidth consumed by the multicast stream, ActualCurrentMulticastRate.
  • the extra capacity at any given time available for handling retries is MaxRate - ActualCurrentMulticastRate .
  • the ACC strategy can measure the available capacity in different ways.
  • any actor within the system 100 can report the data rate that is currently being used to delivery resource information over a particular communication channel.
  • any actor (such as a client module) can actively probe the available capacity by increasing the data rate at which it receives information, and noting when the communication channel becomes saturated.
  • the ACC strategy can be applied in environments that do not impose any MaxRate limitations.
  • Fig. 13 shows a system 1300 in which the server module 202 delivers VOD assets 1302 to the client module 204 using a pure unicast mode of delivery.
  • the server module 202 bursts the VOD assets at an above-nominal data rate 1304.
  • the server module 202 sends the VOD assets at or below a nominal data rate 1306.
  • T join may be zero in the above-described case of pure unicast.
  • T join may not be zero.
  • the delivery is constrained at all times by a maximum data rate MaxRate.
  • Fig. 13 shows the case of constant data rates to facilitate discussion, but the system 1300 can also deliver VOD assets using a variable data rate scheme.
  • the multicast functionality 112 can perform this task, some other multitask functionality (not shown) can perform this task (providing the retry packets in a separate multicast stream), or some other actor (not shown) can perform this task.
  • Fig. 14 provides information regarding an exemplary computer environment 1400 that can be used to implement any such computer devices.
  • the acquisition functionality 104 can be implemented by a server type computer device
  • each of the server modules 110 can be implemented by a server type computer device
  • the configuration tool 118 can be implemented by any kind of computer device
  • each of the computer modules 106 can be implemented as any kind of computer device, etc.
  • the computing environment 1400 includes a general purpose or sever-type computer 1402 and a display device 1404.
  • the computing environment 1400 can include other kinds of computing equipment.
  • the computer environment 1400 can include hand-held or laptop devices, set top boxes, game consoles, mainframe computers, etc.
  • Fig. 14 shows elements of the computer environment 1400 grouped together to facilitate discussion.
  • the computing environment 1400 can employ a distributed processing configuration. In a distributed computing environment, computing resources can be physically dispersed throughout the environment.
  • Exemplary computer 1402 includes one or more processors or processing units 1406, a system memory 1408, and a bus 1410.
  • the bus 1410 connects various system components together. For instance, the bus 1410 connects the processor 1406 to the system memory 1408.
  • the bus 1410 can be implemented using any kind of bus structure or combination of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures.
  • Computer 1402 can also include a variety of computer readable media, including a variety of types of volatile and non-volatile media, each of which can be removable or non-removable.
  • system memory 1408 includes computer readable media in the form of volatile memory, such as random access memory (RAM) 1412, and non-volatile memory, such as read only memory (ROM) 1414.
  • ROM 1414 includes an input/output system (BIOS) 1416 that contains the basic routines that help to transfer information between elements within computer 1402, such as during start-up.
  • BIOS input/output system
  • RAM 1412 typically contains data and/or program modules in a form that can be quickly accessed by processing unit 1406.
  • Computer storage media include a hard disk drive 1418 for reading from and writing to a non-removable, non-volatile magnetic media, a magnetic disk drive 1420 for reading from and writing to a removable, non-volatile magnetic disk 1422 (e.g., a "floppy disk"), and an optical disk drive 1424 for reading from and/or writing to a removable, non-volatile optical disk 1426 such as a CD-ROM, DVD-ROM, or other optical media.
  • the hard disk drive 1418, magnetic disk drive 1420, and optical disk drive 1424 are each connected to the system bus 1410 by one or more data media interfaces 1428.
  • the hard disk drive 1418, magnetic disk drive 1420, and optical disk drive 1424 can be connected to the system bus 1410 by a SCSI interface (not shown), or other coupling mechanism.
  • the computer 1402 can include other types of computer readable media, such as magnetic cassettes or other magnetic storage devices, flash memory cards, CD-ROM, digital versatile disks (DVD) or other optical storage, electrically erasable programmable read-only memory (EEPROM), etc.
  • the above-identified computer readable media provide non-volatile storage of computer readable instructions, data structures, program modules, and other data for use by computer 1402.
  • the readable media can store the operating system 1430, application-specific functionality 1432, other program modules 1434, and program data 1436.
  • the computer environment 1400 can include a variety of input devices.
  • the computer environment 1400 includes the keyboard 1438 and a pointing device 1440 (e.g., a "mouse") for entering commands and information into computer 1402.
  • the computer environment 1400 can include other input devices (not illustrated), such as a microphone, joystick, game pad, satellite dish, serial port, scanner, card reading devices, digital or video camera, etc.
  • Input/output interfaces 1442 couple the input devices to the processing unit 1406. More generally, input devices can be coupled to the computer 1402 through any kind of interface and bus structures, such as a parallel port, serial port, game port, universal serial bus (USB) port, etc.
  • USB universal serial bus
  • the computer environment 1400 also includes the display device 1404.
  • a video adapter 1444 couples the display device 1404 to the bus 1410.
  • the computer environment 1400 can include other output peripheral devices, such as speakers (not shown), a printer (not shown), etc.
  • Computer 1402 operates in a networked environment using logical connections to one or more remote computers, such as a remote computing device 1446.
  • the remote computing device 1446 can comprise any kind of computer equipment, including a general purpose personal computer, portable computer, a server, etc.
  • Remote computing device 1446 can include all of the features discussed above with respect to computer 1402, or some subset thereof.
  • Any type of network 1448 can be used to couple the computer 1402 with remote computing device 1446, a LAN, etc.
  • the computer 1402 couples to the network 1448 via network interface 1450, which can utilize broadband connectivity, modem connectivity, DSL connectivity, or other connection strategy.
  • the computing environment 1400 can provide wireless communication functionality for connecting computer 1402 with remote computing device 1446 (e.g., via modulated radio signals, modulated infrared signals, etc.).
  • case A or case B a number of examples were presented in this disclosure in the alternative (e.g., case A or case B).
  • this disclosure encompasses those cases which combine alternatives in a single implementation (e.g., case A and case B), even though this disclosure may not have expressly mention these conjunctive cases in every instance.

Landscapes

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

Claims (21)

  1. Verfahren zum Liefern von Medieninformationen an ein Klientenmodul (106), umfassend:
    automatisches Bestimmen einer Überschussdatenratenhöhe E*Nominal durch iteratives Vergrößern eines Wertes E in Datenrate (1+E)*Nominal, wobei Nominal eine nominelle Datenrate ist und 0<E<1, Bestimmen einer Paketverlusthöhe bei jeder Datenrate und Auswählen des Werts E, bei dem die Paketverlusthöhe noch akzeptabel ist;
    Liefern (904) der Medieninformationen unter Verwendung einer Unicast-Lieferfunktionalität mit Datenrate (1+E)*Nominal während einer anfänglichen Burstperiode einer Datenübertragung an das Klientenmodul (106);
    Liefern (906) der Medieninformationen unter Verwendung eines Unicaststroms mit Datenrate E*Nominal während eines Verbindungsintervalls im Anschluss an die Burstperiode, wobei im Anschluss an das Verbindungsintervall das Klientenmodul (106) auf eine Multicast-Lieferfunktionalität zum Bereitstellen der Medieninformationen umschaltet (1010);
    Liefern der Medieninformationen an das Klientenmodul (106) unter Verwendung der Multicast-Lieferfunktionalität bei Datenratenhöhen kleiner oder gleich der Datenrate Nominal, wobei die Unicast- und die Multicast-Lieferfunktionalität dieselben Datenstücke liefern; und
    während der Multicast-Lieferfunktionalität, Antworten (910) auf Anfragen vom Klientenmodul (106), Teile der Medieninformationen zu beschaffen, die das Klientenmodul (106) während des Verbindungsintervalls infolge seines Empfangs der Medieninformationen mit den Verbindungsintervall-Datenratenhöhen verpasste, wobei die Teile der Medieninformationen, die das Klientenmodul (106) verpasste, unter Verwendung der Unicast-Lieferfunktionalität mit Datenrate E*Nominal übertragen werden.
  2. Verfahren nach Anspruch 1, wobei eine aggregierte Menge an Medieninformationen, die unter Verwendung der Unicast- und der Multicast-Lieferfunktionalität geliefert wird, nicht eine vorgeschriebene Datenratengrenze überschreitet.
  3. Verfahren nach Anspruch 2, wobei die Medieninformationen unter Verwendung der Unicast-Lieferfunktionalität geliefert werden in Reaktion auf ein Beginnereignis, wobei das Beginnereignis eine Änderung durch das Klientenmodul (106) von einem vorherigen Zustand in einen neuen Zustand ist, und wobei der neue Zustand eine Auswahl eines neuen Programms umfasst, das bereitstellt, dass die Medieninformationen vom Klientenmodul (106) konsumiert werden.
  4. Verfahren nach Anspruch 3, wobei das Beginnereignis eine Änderung durch das Klientenmodul (106) von einem alten Programm ist, das zum vorherigen Zustand gehört, in ein neues Programm, das zum neuen Zustand gehört.
  5. Verfahren nach Anspruch 1, wobei die Medieninformationen Video-auf-Abruf, VOD, ist.
  6. Verfahren nach Anspruch 2, wobei die Datenratenhöhen, mit denen die Medieninformationen unter Verwendung der Unicast- und der Multicast-Lieferfunktionalität geliefert werden, konstante jeweilige Datenraten definieren.
  7. Verfahren nach Anspruch 2, wobei die Datenratenhöhen, mit denen die Medieninformationen unter Verwendung der Unicast- und der Multicast-Lieferfunktionalität geliefert werden, variierende jeweilige Datenraten definieren.
  8. Verfahren nach Anspruch 2, wobei eine Länge des Verbindungsintervalls auf einer Menge von Zeit basiert, die vom Klientenmodul (106) benötigt wird, um sich an die Multicast-Lieferfunktionalität zu koppeln, um die Medieninformationen zu empfangen.
  9. Verfahren nach Anspruch 8, wobei das Verbindungsintervall auf eine minimale Menge von Zeit verkürzt wird, die vom Klientenmodul (106) benötigt wird, um sich an die Multicast-Lieferfunktionalität zu koppeln, wobei die Unicast-Lieferfunktionalität fortfährt die Medieninformationen in einer Zeitperiode zu liefern, die durch diese minimale Menge an Zeit definiert ist.
  10. Verfahren nach Anspruch 2, wobei die Datenrate des Verbindungsintervalls dynamisch variiert auf der Grundlage einer zeitvariierenden Menge an Überschusskapazität, die verfügbar ist, um Medieninformationen zu liefern.
  11. Verfahren nach Anspruch 1, wobei die Lieferung der fehlenden Teile mit Datenraten durchgeführt wird, die dynamisch variieren auf der Grundlage einer zeitvariierenden Menge an Überschusskapazität, die verfügbar ist, um die fehlenden Teile zu liefern.
  12. Verfahren nach Anspruch 1, wobei die Menge an Medieninformationen, die während der anfänglichen Burstperiode bereitgestellt wird, ausgewählt wird, um die fehlenden Teile der Medieninformationen auszufüllen, die durch das Verbindungsintervall verursacht wurden, mit erneuten Übertragungen, bevor die Konsumierung durch den Decoder des Klientenmoduls (106) das Ende der Medieninformationen erreicht, die durch die anfängliche Burstperiode bereitgestellt werden.
  13. Verfahren nach Anspruch 1, wobei die Menge an Medieninformationen, die während der anfänglichen Burstperiode zusammen mit der Menge an Medieninformationen, die während des Verbindungsintervalls bereitgestellt wird, ausgewählt wird, um vollständig die fehlenden Teile der Medieninformationen aufzufüllen, die vom Verbindungsintervall verursacht werden, mit erneuten Übertragungen bevor die Konsumierung durch den Decoder des Klientenmoduls (106) das Ende der Medieninformationen erreicht, die durch die anfängliche Burstperiode und das Verbindungsintervall bereitgestellt werden.
  14. Verfahren nach Anspruch 2, wobei eine Vielzahl von Parametern das Verhalten der Lieferung in der ratenbegrenzten Umgebung steuern, und ferner umfassend ein Konfigurieren eines oder mehrerer der Parameter, um sicherzustellen, dass die aggregierte Menge an Medieninformationen, die unter Verwendung der Unicast- und der Multicastlieferfunktionalität geliefert wird, beschränkt ist, so dass sie unter der vorgeschriebenen Datenrategrenze bleibt.
  15. Verfahren nach Anspruch 14, wobei die Parameter wenigstens die folgenden Parameter umfassen:
    eine Überschussmenge an Kapazität, die verfügbar ist;
    eine Länge an Zeit Tburst der anfänglichen Burstperiode; und
    eine Länge an Zeit Tjoin des Verbindungsintervalls.
  16. Verfahren nach Anspruch 2, ferner umfassend ein Bestimmen, ob das Klientenmodul (106) ausreichende Pufferressourcen hat, um die Medieninformationen vor einem Liefern der Medieninformationen unter Verwendung der Unicast-Lieferfunktionalität zu empfangen.
  17. Maschinenlesbares Medium, das maschinenlesbare Instruktionen zum Implementieren des Verfahrens eines der vorhergehenden Ansprüche enthält.
  18. Servermodul, das Logik umfasst, die ausgelegt ist, das Verfahren eines der Ansprüche 1 bis 17 zu implementieren.
  19. Verfahren zum Empfangen von Medieninformationen bei einem Klientenmodul (106), umfassend:
    automatisches Bestimmen einer Überschussdatenratenhöhe E*Nominal durch iteratives Vergrößern eines Wertes E in Datenrate (1+E)*Nominal, wobei Nominal eine nominelle Datenrate ist und 0<E<1, Bestimmen einer Paketverlusthöhe bei jeder Datenrate und Auswählen des Werts E, bei dem die Paketverlusthöhe noch akzeptabel ist;
    Empfangen (1004) über eine Unicast-Lieferfunktionalität von Medieninformationen mit Datenratenhöhen (1+E)*Nominal während einer anfänglichen Burstperiode einer Datenübertragung;
    Empfangen (1006) der Medieninformationen unter Verwendung eines Unicaststroms mit Datenrate E*Nominal während eines Verbindungsintervalls im Anschluss an die Burstperiode;
    Empfangen (1010) über eine Multicast-Lieferfunktionalität der Medieninformationen im Anschluss an das Verbindungsintervall, wobei die Unicast- und die Multicast-Lieferfunktionalität dieselben Datenstücke liefern;
    Anfragen (1012) nach Teilen der Medieninformationen, die das Klientenmodul (106) während des Verbindungsintervalls infolge seines Empfangs der Medieninformationen mit den Verbindungsintervall-Datenratenhöhen verpasste; und
    Empfangen (1014) der fehlenden Teile von Medieninformationen gleichzeitig mit dem Empfang der Medieninformationen über die Multicast-Lieferfunktionalität, wobei die Teile der Medieninformationen, die das Klientenmodul verpasste, unter Verwendung der Unicast-Lieferfunktionalität mit Datenrate E*Nominal empfangen werden.
  20. Maschinenlesbares Medium, das maschinenlesbare Instruktionen zum Implementieren des Verfahrens von Anspruch 19 enthält.
  21. Klientenmodul (106), das Logik umfasst, die ausgelegt ist, das Verfahren von Anspruch 19 zu implementieren.
EP05111446A 2004-12-10 2005-11-29 Beschleunigter Kanalwechsel in datenratenbegrenzten Umgebungen Not-in-force EP1670252B1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP11001056A EP2373026A1 (de) 2004-12-10 2005-11-29 Beschleunigter Kanalwechsel in Umgebungen mit beschränkter Rate

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/010,200 US7477653B2 (en) 2004-12-10 2004-12-10 Accelerated channel change in rate-limited environments

Related Child Applications (1)

Application Number Title Priority Date Filing Date
EP11001056.8 Division-Into 2011-02-09

Publications (3)

Publication Number Publication Date
EP1670252A2 EP1670252A2 (de) 2006-06-14
EP1670252A3 EP1670252A3 (de) 2010-07-21
EP1670252B1 true EP1670252B1 (de) 2013-04-03

Family

ID=35673675

Family Applications (2)

Application Number Title Priority Date Filing Date
EP11001056A Withdrawn EP2373026A1 (de) 2004-12-10 2005-11-29 Beschleunigter Kanalwechsel in Umgebungen mit beschränkter Rate
EP05111446A Not-in-force EP1670252B1 (de) 2004-12-10 2005-11-29 Beschleunigter Kanalwechsel in datenratenbegrenzten Umgebungen

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP11001056A Withdrawn EP2373026A1 (de) 2004-12-10 2005-11-29 Beschleunigter Kanalwechsel in Umgebungen mit beschränkter Rate

Country Status (4)

Country Link
US (2) US7477653B2 (de)
EP (2) EP2373026A1 (de)
CA (2) CA2841284C (de)
MX (1) MXPA05013345A (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8462847B2 (en) 2006-02-27 2013-06-11 Cisco Technology, Inc. Method and apparatus for immediate display of multicast IPTV over a bandwidth constrained network
US8588077B2 (en) 2006-09-11 2013-11-19 Cisco Technology, Inc. Retransmission-based stream repair and stream join
US8769591B2 (en) 2007-02-12 2014-07-01 Cisco Technology, Inc. Fast channel change on a bandwidth constrained network
US8787153B2 (en) 2008-02-10 2014-07-22 Cisco Technology, Inc. Forward error correction based data recovery with path diversity

Families Citing this family (148)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7523482B2 (en) * 2002-08-13 2009-04-21 Microsoft Corporation Seamless digital channel changing
US8397269B2 (en) * 2002-08-13 2013-03-12 Microsoft Corporation Fast digital channel changing
US7516232B2 (en) 2003-10-10 2009-04-07 Microsoft Corporation Media organization for distributed sending of media data
US7444419B2 (en) * 2003-10-10 2008-10-28 Microsoft Corporation Media stream scheduling for hiccup-free fast-channel-change in the presence of network chokepoints
US8782654B2 (en) 2004-03-13 2014-07-15 Adaptive Computing Enterprises, Inc. Co-allocating a reservation spanning different compute resources types
WO2005089241A2 (en) 2004-03-13 2005-09-29 Cluster Resources, Inc. System and method for providing object triggers
US8443038B2 (en) 2004-06-04 2013-05-14 Apple Inc. Network media device
US8797926B2 (en) 2004-06-04 2014-08-05 Apple Inc. Networked media station
US20070110074A1 (en) * 2004-06-04 2007-05-17 Bob Bradley System and Method for Synchronizing Media Presentation at Multiple Recipients
US20080229335A1 (en) * 2004-06-04 2008-09-18 Apple Computer, Inc. Network media device
US10972536B2 (en) 2004-06-04 2021-04-06 Apple Inc. System and method for synchronizing media presentation at multiple recipients
US20070266388A1 (en) 2004-06-18 2007-11-15 Cluster Resources, Inc. System and method for providing advanced reservations in a compute environment
US8176490B1 (en) 2004-08-20 2012-05-08 Adaptive Computing Enterprises, Inc. System and method of interfacing a workload manager and scheduler with an identity manager
US7640352B2 (en) * 2004-09-24 2009-12-29 Microsoft Corporation Methods and systems for presentation of media obtained from a media stream
US7720652B2 (en) * 2004-10-19 2010-05-18 Microsoft Corporation Modeling location histories
US8271980B2 (en) 2004-11-08 2012-09-18 Adaptive Computing Enterprises, Inc. System and method of providing system jobs within a compute environment
EP1820336A4 (de) * 2004-12-06 2010-04-28 Thomson Licensing Mehrfache untertitelflüsse und kundenzugang in digitalen netzwerken
US20090064242A1 (en) * 2004-12-23 2009-03-05 Bitband Technologies Ltd. Fast channel switching for digital tv
US8434117B2 (en) * 2005-02-14 2013-04-30 Microsoft Corporation Tunerless media presentation unit and methods of use
WO2006091886A2 (en) * 2005-02-23 2006-08-31 Arroyo Video Solutions, Inc. Playout-dependent unicast streaming of digital video content
US8863143B2 (en) 2006-03-16 2014-10-14 Adaptive Computing Enterprises, Inc. System and method for managing a hybrid compute environment
US8631130B2 (en) 2005-03-16 2014-01-14 Adaptive Computing Enterprises, Inc. Reserving resources in an on-demand compute environment from a local compute environment
US9225663B2 (en) 2005-03-16 2015-12-29 Adaptive Computing Enterprises, Inc. System and method providing a virtual private cluster
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
CA2603577A1 (en) 2005-04-07 2006-10-12 Cluster Resources, Inc. On-demand access to compute resources
US8595323B2 (en) * 2005-04-14 2013-11-26 Accenture Global Services Limited Providing excess resources as a service
US7680038B1 (en) * 2005-04-25 2010-03-16 Electronic Arts, Inc. Dynamic bandwidth detection and response for online games
US8054849B2 (en) * 2005-05-27 2011-11-08 At&T Intellectual Property I, L.P. System and method of managing video content streams
US8001217B1 (en) * 2005-10-13 2011-08-16 Sprint Communications Company L.P. Prediction-based adaptive content broadcasting over a network
US7472197B2 (en) * 2005-10-31 2008-12-30 Ut Starcom, Inc. Method and apparatus for automatic switching of multicast/unicast live TV streaming in a TV-over-IP environment
US8099756B2 (en) * 2005-11-10 2012-01-17 Versteeg William C Channel changes between services with differing bandwidth in a switched digital video system
US20070107024A1 (en) * 2005-11-10 2007-05-10 Scientific-Atlanta, Inc. Atomic channel changes in a switched digital video system
US20070106782A1 (en) * 2005-11-10 2007-05-10 Scientific-Atlanta, Inc. Bandwidth management in each network device in a switched digital video environment
US7873760B2 (en) * 2005-11-11 2011-01-18 Versteeg William C Expedited digital signal decoding
US8135040B2 (en) * 2005-11-30 2012-03-13 Microsoft Corporation Accelerated channel change
US8340098B2 (en) * 2005-12-07 2012-12-25 General Instrument Corporation Method and apparatus for delivering compressed video to subscriber terminals
US8774602B1 (en) * 2006-02-10 2014-07-08 Tp Lab, Inc. Method to record a media file
FR2898236A1 (fr) * 2006-03-03 2007-09-07 Thomson Licensing Sas Procede de transmission de flux audiovisuels en anticipant les commandes de l'utilisateurs, recepteur et emetteur pour la mise en oeuvre du procede
US20090307732A1 (en) * 2006-03-07 2009-12-10 Noam Cohen Personalized Insertion of Advertisements in Streaming Media
US8218654B2 (en) * 2006-03-08 2012-07-10 Cisco Technology, Inc. Method for reducing channel change startup delays for multicast digital video streams
US8160065B2 (en) * 2006-04-12 2012-04-17 Alcatel Lucent Device and method for dynamically storing media data
US20070280235A1 (en) * 2006-06-01 2007-12-06 Qualcomm Incorporated System and method for acquisition and delivery of services to devices in a wireless multicast communication system
US8185435B2 (en) * 2006-06-16 2012-05-22 At&T Intellectual Property I, L.P. Methods, systems, and computer program products for facilitating content-based selection of long-tail business models and billing
US20080022320A1 (en) * 2006-06-30 2008-01-24 Scientific-Atlanta, Inc. Systems and Methods of Synchronizing Media Streams
US7877660B2 (en) * 2006-07-07 2011-01-25 Ver Steeg William C Transmitting additional forward error correction (FEC) upon request
US7899046B2 (en) 2006-07-07 2011-03-01 Ver Steeg William C Determining strategy for multicast and/or unicast transmission to correct forward errors
US8250618B2 (en) * 2006-09-18 2012-08-21 Elemental Technologies, Inc. Real-time network adaptive digital video encoding/decoding
US20080077701A1 (en) * 2006-09-27 2008-03-27 George Philip Kongalath Synchronized data content delivery
US7870465B2 (en) * 2006-10-18 2011-01-11 Versteeg William C Reducing channel-change time
US20080109557A1 (en) * 2006-11-02 2008-05-08 Vinay Joshi Method and system for reducing switching delays between digital video feeds using personalized unicast transmission techniques
US20080181256A1 (en) * 2006-11-22 2008-07-31 General Instrument Corporation Switched Digital Video Distribution Infrastructure and Method of Operation
US7779142B1 (en) * 2007-01-23 2010-08-17 Juniper Networks, Inc. Bandwidth allocation to support fast buffering
US7937531B2 (en) * 2007-02-01 2011-05-03 Cisco Technology, Inc. Regularly occurring write back scheme for cache soft error reduction
US7940644B2 (en) * 2007-03-14 2011-05-10 Cisco Technology, Inc. Unified transmission scheme for media stream redundancy
US20080244667A1 (en) * 2007-03-27 2008-10-02 Osborne Jason C Bandwidth sensitive switched digital video content delivery
US8370889B2 (en) * 2007-03-28 2013-02-05 Kanthimathi Gayatri Sukumar Switched digital video client reverse channel traffic reduction
US20080253369A1 (en) 2007-04-16 2008-10-16 Cisco Technology, Inc. Monitoring and correcting upstream packet loss
US20080263130A1 (en) * 2007-04-23 2008-10-23 Nir Michalowitz Apparatus, system and method of digital content distribution
US7761902B2 (en) * 2007-05-11 2010-07-20 At&T Intellectual Property I, L.P. System and method of providing video content
US20080294663A1 (en) * 2007-05-14 2008-11-27 Heinley Brandon J Creation and management of visual timelines
JP5132766B2 (ja) * 2007-05-31 2013-01-30 テレフオンアクチーボラゲット エル エム エリクソン（パブル） メディア伝送プロトコルの選択
CN101690118B (zh) 2007-06-20 2013-08-28 艾利森电话股份有限公司 用于改进的媒体会话管理的方法和设备
US9712787B2 (en) * 2007-07-02 2017-07-18 At&T Intellectual Property I, L.P. System and method of delivering video content
US20090025052A1 (en) * 2007-07-18 2009-01-22 General Instrument Corporation Method and Apparatus for Controlling the Bandwidth of SDV Programming Supplied to an Edge Device in a n SDV System
US8832766B2 (en) * 2007-07-27 2014-09-09 William C. Versteeg Systems and methods of differentiated channel change behavior
US8776160B2 (en) * 2007-07-27 2014-07-08 William C. Versteeg Systems and methods of differentiated requests for network access
US8793750B2 (en) * 2007-07-31 2014-07-29 Sirius Xm Radio Inc. Methods and systems for fast channel change between logical channels within a transport multiplex
US8184715B1 (en) 2007-08-09 2012-05-22 Elemental Technologies, Inc. Method for efficiently executing video encoding operations on stream processor architectures
US8001575B2 (en) * 2007-08-21 2011-08-16 Alcatel Lucent Method of distributing video-on-demand over an internet protocol network infrastructure
US20090051314A1 (en) * 2007-08-21 2009-02-26 Puthalath Koroth Raghuprasad Self-powered magnetic generator
US20090052450A1 (en) * 2007-08-22 2009-02-26 Mockett Gregory P Apparatus, system, and method for video delivery using dual multicast streams with one being delayed
US8554941B2 (en) * 2007-08-30 2013-10-08 At&T Intellectual Property I, Lp Systems and methods for distributing video on demand
US8209728B2 (en) 2007-08-31 2012-06-26 At&T Intellectual Property I, L.P. System and method of delivering video content
US8041773B2 (en) 2007-09-24 2011-10-18 The Research Foundation Of State University Of New York Automatic clustering for self-organizing grids
US8121197B2 (en) 2007-11-13 2012-02-21 Elemental Technologies, Inc. Video encoding and decoding using parallel processors
US8468571B2 (en) * 2007-12-21 2013-06-18 General Instrument Corporation Enabling trick plays during VBR playback of a CBR transmitted media file
US8700792B2 (en) * 2008-01-31 2014-04-15 General Instrument Corporation Method and apparatus for expediting delivery of programming content over a broadband network
EP2093951B1 (de) * 2008-02-21 2012-12-19 Nokia Siemens Networks Oy Verfahren und Vorrichtung zur Verarbeitung von Multimediadaten und Kommunikationssystem mit einer derartigen Vorrichtung
US8077736B2 (en) * 2008-02-25 2011-12-13 Newport Media, Inc. Fast audio/visual reception in DVB-H systems
US8281369B2 (en) * 2008-03-12 2012-10-02 Avaya Inc. Method and apparatus for creating secure write-enabled web pages that are associated with active telephone calls
US7991927B2 (en) * 2008-03-31 2011-08-02 Lsi Corporation Reduction of latency in store and forward architectures utilizing multiple internal bus protocols
EP2272206A1 (de) * 2008-04-24 2011-01-12 Telefonaktiebolaget L M Ericsson (PUBL) Systeme und verfahren zur medienverteilung
US8752092B2 (en) 2008-06-27 2014-06-10 General Instrument Corporation Method and apparatus for providing low resolution images in a broadcast system
US8014393B1 (en) * 2008-08-05 2011-09-06 Cisco Technology, Inc. Bandwidth optimized rapid channel change in IP-TV network
US7886073B2 (en) * 2008-08-08 2011-02-08 Cisco Technology, Inc. Systems and methods of reducing media stream delay
US8015310B2 (en) * 2008-08-08 2011-09-06 Cisco Technology, Inc. Systems and methods of adaptive playout of delayed media streams
US20110185018A1 (en) * 2008-10-09 2011-07-28 Toru Osuga Content delivery system, content delivery method and computer program
US20100115566A1 (en) * 2008-10-30 2010-05-06 Raziel Haimi-Cohen Fast Channel Change Request Processing
CN101753973B (zh) * 2008-12-12 2013-01-02 华为技术有限公司 一种频道切换方法、装置和系统
US8879464B2 (en) 2009-01-29 2014-11-04 Avaya Inc. System and method for providing a replacement packet
US9525710B2 (en) * 2009-01-29 2016-12-20 Avaya Gmbh & Co., Kg Seamless switch over from centralized to decentralized media streaming
US8239739B2 (en) * 2009-02-03 2012-08-07 Cisco Technology, Inc. Systems and methods of deferred error recovery
US8238335B2 (en) 2009-02-13 2012-08-07 Avaya Inc. Multi-route transmission of packets within a network
US7936746B2 (en) * 2009-03-18 2011-05-03 Avaya Inc. Multimedia communication session coordination across heterogeneous transport networks
US20100254462A1 (en) * 2009-04-07 2010-10-07 Cisco Technology, Inc. Method for reducing memory usage with accelerated channel changes
US20100265834A1 (en) * 2009-04-17 2010-10-21 Avaya Inc. Variable latency jitter buffer based upon conversational dynamics
US8094556B2 (en) * 2009-04-27 2012-01-10 Avaya Inc. Dynamic buffering and synchronization of related media streams in packet networks
US20100312780A1 (en) * 2009-06-09 2010-12-09 Le Chevalier Vincent System and method for delivering publication content to reader devices using mixed mode transmission
US8553849B2 (en) * 2009-06-17 2013-10-08 Avaya Inc. Personal identification and interactive device for internet-based text and video communication services
CN101964716B (zh) * 2009-07-21 2015-04-29 华为技术有限公司 一种实现流业务的方法及通信系统以及相关设备
US8800049B2 (en) * 2009-08-26 2014-08-05 Avaya Inc. Licensing and certificate distribution via secondary or divided signaling communication pathway
US8150993B2 (en) * 2009-10-29 2012-04-03 At&T Intellectual Property I, Lp Synchronization of clients to maximize multicast opportunities
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US10877695B2 (en) 2009-10-30 2020-12-29 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US9357244B2 (en) * 2010-03-11 2016-05-31 Arris Enterprises, Inc. Method and system for inhibiting audio-video synchronization delay
US9168946B2 (en) * 2010-03-19 2015-10-27 Javad Gnss, Inc. Method for generating offset paths for ground vehicles
US20110289544A1 (en) * 2010-05-19 2011-11-24 Goosen Hendrik A Video streaming system including a fast channel change mechanism
US8771064B2 (en) 2010-05-26 2014-07-08 Aristocrat Technologies Australia Pty Limited Gaming system and a method of gaming
CN102143130B (zh) 2010-06-30 2013-11-06 华为技术有限公司 一种快速频道切换时获取关键信息的方法、装置和系统
US9363574B1 (en) * 2010-12-08 2016-06-07 Verint Americas Inc. Video throttling based on individual client delay
GB2490659A (en) 2011-05-04 2012-11-14 Nds Ltd Fast channel change using channel packs comprising independently decodable frame segments having differing qualities
US8819264B2 (en) * 2011-07-18 2014-08-26 Verizon Patent And Licensing Inc. Systems and methods for dynamically switching between unicast and multicast delivery of media content in a wireless network
US8959313B2 (en) 2011-07-26 2015-02-17 International Business Machines Corporation Using predictive determinism within a streaming environment
US9148495B2 (en) 2011-07-26 2015-09-29 International Business Machines Corporation Dynamic runtime choosing of processing communication methods
US8990452B2 (en) 2011-07-26 2015-03-24 International Business Machines Corporation Dynamic reduction of stream backpressure
US9838089B2 (en) 2011-10-07 2017-12-05 Futurewei Technologies, Inc. System and method for multiple point transmission in a communications system
US20130088960A1 (en) 2011-10-07 2013-04-11 Futurewei Technologies, Inc. System and Method for Information Delivery with Multiple Point Transmission
US9015555B2 (en) 2011-11-18 2015-04-21 Cisco Technology, Inc. System and method for multicast error recovery using sampled feedback
US9405553B2 (en) 2012-01-30 2016-08-02 International Business Machines Corporation Processing element management in a streaming data system
GB2500406A (en) 2012-03-20 2013-09-25 Qarva Ltd Providing rapid channel changes, with client itself assessing technical environment and network connection parameters
US9146775B2 (en) 2012-04-26 2015-09-29 International Business Machines Corporation Operator graph changes in response to dynamic connections in stream computing applications
US8432808B1 (en) * 2012-06-15 2013-04-30 Viasat Inc. Opportunistically delayed delivery in a satellite network
CN102833591B (zh) * 2012-08-09 2015-08-12 中兴通讯股份有限公司 交互式网络电视系统中点播服务不中断的方法及装置
US9866886B2 (en) * 2012-10-23 2018-01-09 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for distributing a media content service
US9930081B2 (en) 2012-11-13 2018-03-27 International Business Machines Corporation Streams optional execution paths depending upon data rates
US10097989B2 (en) 2012-12-21 2018-10-09 E*Trade Financial Corporation Dynamic communication
US9992306B2 (en) * 2012-12-21 2018-06-05 E*Trade Financial Corporation Dynamic execution
KR20140103569A (ko) * 2013-02-18 2014-08-27 한국전자통신연구원 적응적 계층 선택을 위한 장치 및 방법, 이를 구비한 서버
US9154436B2 (en) 2013-03-14 2015-10-06 Viasat Inc. Delaycast queue prioritization
US9521177B2 (en) 2013-09-11 2016-12-13 Cisco Technology, Inc. Network-based adaptive rate limiting
US10158868B2 (en) * 2013-10-15 2018-12-18 Nvidia Corporation Systems and methods to limit lag between a client and a server for remote computing
US20150134846A1 (en) * 2013-11-14 2015-05-14 Qualcomm Incorporated Method and apparatus for media segment request retry control
DE102014220372A1 (de) * 2014-10-08 2016-04-14 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Vorrichtung und verfahren zum schneiden von mehreren kodierten videoströmen ohne vorherige dekodierung
US10735823B2 (en) * 2015-03-13 2020-08-04 Telefonaktiebolaget Lm Ericsson (Publ) System and method for optimized delivery of live ABR media
US10432688B2 (en) 2015-03-13 2019-10-01 Telefonaktiebolaget Lm Ericsson (Publ) System and method for optimized delivery of live ABR media
US20190191212A1 (en) * 2015-05-20 2019-06-20 Nxt Solutions Ag Iptv in managed networks
US9826261B2 (en) 2015-09-09 2017-11-21 Ericsson Ab Fast channel change in a multicast adaptive bitrate (MABR) streaming network using multicast repeat segment bursts in a dedicated bandwidth pipe
US9826262B2 (en) 2015-09-09 2017-11-21 Ericsson Ab Fast channel change in a multicast adaptive bitrate (MABR) streaming network using multicast repeat segment bursts in a shared progressive ABR download pipe
US10708349B2 (en) 2015-10-09 2020-07-07 Telefonaktiebolaget Lm Ericsson (Publ) Offloading a distribution server task to a media gateway
US10972878B2 (en) * 2015-10-13 2021-04-06 Samsung Electronics Co., Ltd. Method and apparatus for providing unicast based multimedia service
EP3160147A1 (de) * 2015-10-19 2017-04-26 Thomson Licensing Verfahren für schnellen kanalwechsel, entsprechende anordnung und vorrichtung
US11297369B2 (en) 2018-03-30 2022-04-05 Apple Inc. Remotely controlling playback devices
US10993274B2 (en) 2018-03-30 2021-04-27 Apple Inc. Pairing devices by proxy
US10783929B2 (en) 2018-03-30 2020-09-22 Apple Inc. Managing playback groups
US10614857B2 (en) 2018-07-02 2020-04-07 Apple Inc. Calibrating media playback channels for synchronized presentation
KR102654716B1 (ko) * 2019-02-11 2024-04-04 한화비전 주식회사 요청된 영상 재생시점에 따라 영상을 재생하는 방법 및 그 장치
US11431773B2 (en) 2019-06-13 2022-08-30 Caffeine Inc. Multicast broadcast network architcture
US11943125B2 (en) * 2022-01-26 2024-03-26 Dish Network Technologies India Private Limited Discontinuity detection in transport streams

Family Cites Families (102)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2127347A1 (en) 1993-07-07 1995-01-08 Donald F. Hooper Segmented video on-demand system
US5473362A (en) 1993-11-30 1995-12-05 Microsoft Corporation Video on demand system comprising stripped data across plural storable devices with time multiplex scheduling
CA2135681C (en) 1993-12-30 2000-01-18 Srinivas V. Makam System and method for directly accessing long-term memory devices
CA2140850C (en) 1994-02-24 1999-09-21 Howard Paul Katseff Networked system for display of multimedia presentations
US5461415A (en) 1994-03-15 1995-10-24 International Business Machines Corporation Look-ahead scheduling to support video-on-demand applications
US5583868A (en) 1994-07-25 1996-12-10 Microsoft Corporation Method and system for combining data from multiple servers into a single continuous data stream using a switch
JPH0879685A (ja) 1994-08-31 1996-03-22 Sony Corp ニア・ビデオ・オン・デマンドシステムにおけるプログラム再生装置
JP3855282B2 (ja) 1995-02-06 2006-12-06 ソニー株式会社 受信装置および受信方法
US5742892A (en) 1995-04-18 1998-04-21 Sun Microsystems, Inc. Decoder for a software-implemented end-to-end scalable video delivery system
US5724646A (en) 1995-06-15 1998-03-03 International Business Machines Corporation Fixed video-on-demand
US6138147A (en) 1995-07-14 2000-10-24 Oracle Corporation Method and apparatus for implementing seamless playback of continuous media feeds
US5732217A (en) 1995-12-01 1998-03-24 Matsushita Electric Industrial Co., Ltd. Video-on-demand system capable of performing a high-speed playback at a correct speed
US5936659A (en) 1996-01-31 1999-08-10 Telcordia Technologies, Inc. Method for video delivery using pyramid broadcasting
US5631694A (en) 1996-02-01 1997-05-20 Ibm Corporation Maximum factor selection policy for batching VOD requests
US6222886B1 (en) 1996-06-24 2001-04-24 Kabushiki Kaisha Toshiba Compression based reduced memory video decoder
US6721952B1 (en) 1996-08-06 2004-04-13 Roxio, Inc. Method and system for encoding movies, panoramas and large images for on-line interactive viewing and gazing
US6564262B1 (en) 1996-09-16 2003-05-13 Microsoft Corporation Multiple multicasting of multimedia streams
US6047317A (en) 1997-03-28 2000-04-04 International Business Machines Corporation System and method for enabling a user to rapidly access images in cyclically transmitted image streams
US5963202A (en) 1997-04-14 1999-10-05 Instant Video Technologies, Inc. System and method for distributing and managing digital video information in a video distribution network
US5892915A (en) 1997-04-25 1999-04-06 Emc Corporation System having client sending edit commands to server during transmission of continuous media from one clip in play list for editing the play list
US6728965B1 (en) 1997-08-20 2004-04-27 Next Level Communications, Inc. Channel changer for use in a switched digital video system
US6310886B1 (en) 1997-08-28 2001-10-30 Tivo, Inc. Method and apparatus implementing a multimedia digital network
US6118498A (en) 1997-09-26 2000-09-12 Sarnoff Corporation Channel scanning and channel change latency reduction in an ATSC television receiver
US6078594A (en) 1997-09-26 2000-06-20 International Business Machines Corporation Protocol and procedure for automated channel change in an MPEG-2 compliant datastream
AU5551299A (en) 1998-08-13 2000-03-06 Trustees Of The University Of Pennsylvania, The Method of identifying proteins
US7334044B1 (en) 1998-11-17 2008-02-19 Burst.Com Method for connection acceptance control and optimal multi-media content delivery over networks
US6637031B1 (en) 1998-12-04 2003-10-21 Microsoft Corporation Multimedia presentation latency minimization
US6691312B1 (en) * 1999-03-19 2004-02-10 University Of Massachusetts Multicasting video
US6842724B1 (en) 1999-04-08 2005-01-11 Lucent Technologies Inc. Method and apparatus for reducing start-up delay in data packet-based network streaming applications
US6560754B1 (en) * 1999-05-13 2003-05-06 Arc International Plc Method and apparatus for jump control in a pipelined processor
US6418473B1 (en) 1999-05-20 2002-07-09 Nortel Networks Limited Multimedia clent and server
US6876668B1 (en) 1999-05-24 2005-04-05 Cisco Technology, Inc. Apparatus and methods for dynamic bandwidth allocation
US6330286B1 (en) 1999-06-09 2001-12-11 Sarnoff Corporation Flow control, latency control, and bitrate conversions in a timing correction and frame synchronization apparatus
US7992163B1 (en) 1999-06-11 2011-08-02 Jerding Dean F Video-on-demand navigational system
SE521181C2 (sv) 1999-07-01 2003-10-07 Telia Ab Förfarande och system för policystyrd distribution av strömmande media i ett IP-nät
EP1081967B1 (de) 1999-09-02 2011-01-19 Panasonic Corporation Aufnahmeanlage und Kodieranlage
WO2001026271A2 (en) 1999-10-07 2001-04-12 World Multicast.Com, Inc. Multiple buffered channel ip multicast
US7191462B1 (en) 1999-11-08 2007-03-13 Kendyl A. Román System for transmitting video images over a computer network to a remote receiver
IL132859A (en) 1999-11-10 2008-07-08 Nds Ltd Data stream processing system
WO2001043442A2 (en) 1999-12-09 2001-06-14 Liberate Technologies, Morecom Division, Inc. Method and apparatus for two-way internet access over network a catv with channel tracking
AU4338800A (en) 1999-12-22 2001-07-03 General Instrument Corporation Video compression for multicast environments using spatial scalability and simulcast coding
US8584182B2 (en) 2000-01-27 2013-11-12 Time Warner Cable Enterprises Llc System and method for providing broadcast programming, a virtual VCR, and a video scrapbook to programming subscribers
GB2359209A (en) 2000-02-09 2001-08-15 Motorola Ltd Apparatus and methods for video distribution via networks
DE10009503A1 (de) * 2000-02-29 2001-08-30 Roche Diagnostics Gmbh Verfahren zur Immobilisierung von Konjugaten in diagnostischen Tests
EP1361690B1 (de) * 2000-03-02 2006-01-11 Matsushita Electric Industrial Co., Ltd. Verfahren und Vorrichtung zur auf Kanalzustand basierten Wiederholung von Datenpaketen
BRPI0001810B1 (pt) * 2000-03-28 2015-06-23 Coppe Ufrj Coordenação Dos Programas De Pós Graduação De Engenharia Da Universidade Fed Do Rio De Ja Memória cooperativa distribuída para sistema de vod interativo e escalável
US20020092015A1 (en) * 2000-05-26 2002-07-11 Sprunk Eric J. Access control processor
US7260826B2 (en) * 2000-05-31 2007-08-21 Microsoft Corporation Resource allocation in multi-stream IP network for optimized quality of service
US6751713B1 (en) 2000-06-05 2004-06-15 Sony Corporation Method and system for scheduled activation of system information tables in digital transport streams
US7003794B2 (en) 2000-06-27 2006-02-21 Bamboo Mediacasting, Inc. Multicasting transmission of multimedia information
JP4337244B2 (ja) 2000-07-25 2009-09-30 ソニー株式会社 Ｍｐｅｇ画像ストリームのデコード装置およびデコード方法
ATE326097T1 (de) 2000-08-25 2006-06-15 Cit Alcatel Verfahren zur bereitstellung einer bidirektionellen verbindung in einem netz für die mehrfachübertragung von datenströmen mit verwendung vom internetprotokoll und netz für die anwendung des verfahrens
US7107606B2 (en) 2000-08-30 2006-09-12 The Chinese University Of Hong Kong System and method for highly scalable video on demand
JP3631123B2 (ja) 2000-10-03 2005-03-23 三洋電機株式会社 デジタル放送受信装置
US7240358B2 (en) 2000-12-08 2007-07-03 Digital Fountain, Inc. Methods and apparatus for scheduling, serving, receiving media-on demand for clients, servers arranged according to constraints on resources
WO2002049359A1 (en) 2000-12-13 2002-06-20 The Chinese University Of Hong Kong Method and system for delivering media selections through a network
US20020143499A1 (en) * 2001-01-12 2002-10-03 Graphin Co., Ltd Methods and apparatus for communicating information via a network
US8458754B2 (en) 2001-01-22 2013-06-04 Sony Computer Entertainment Inc. Method and system for providing instant start multimedia content
US6859840B2 (en) 2001-01-29 2005-02-22 Kasenna, Inc. Prefix caching for media objects
US20050039214A1 (en) 2001-02-21 2005-02-17 Lorenz Kim E. System and method for providing direct, context-sensitive customer support in an interactive television system
US6973667B2 (en) 2001-03-01 2005-12-06 Minerva Networks, Inc. Method and system for providing time-shifted delivery of live media programs
EP1386492A2 (de) 2001-03-23 2004-02-04 Popwire.com Verfahren und vorrichtung für streaming-video
US20020144276A1 (en) 2001-03-30 2002-10-03 Jim Radford Method for streamed data delivery over a communications network
US20020147991A1 (en) 2001-04-10 2002-10-10 Furlan John L. W. Transmission of panoramic video via existing video infrastructure
US20060117343A1 (en) 2001-04-17 2006-06-01 Digeo, Inc. Apparatus and methods for advertising in a sequential manner and based upon user preference
WO2002087235A1 (en) 2001-04-19 2002-10-31 Vividon, Inc. System for applying metric to multimedia files over network
US7219145B2 (en) 2001-05-30 2007-05-15 Qualcomm Incorporated Method and apparatus for individually estimating time required to download application programs to remote modules over wireless network
EP1423927B1 (de) 2001-09-06 2008-05-07 Gilat Satellite Networks Ltd. Doppelkanal-zweiwege-satellitenkommunikation
US20030048808A1 (en) 2001-09-12 2003-03-13 Stahl Thomas Anthony Method and apparatus for changing received streaming content channels
US6738980B2 (en) 2001-11-15 2004-05-18 Industrial Technology Research Institute Methods and systems for video streaming with VCR functionality
US7236177B2 (en) 2001-12-04 2007-06-26 Qualcomm Incorporated Processing digital video data
DE10206076A1 (de) * 2002-02-13 2003-08-21 Tellique Kommunikationstechnik Verfahren und Vorrichtung zur adaptiven Übertragung von Dateneinheiten eines Datenstroms
US20030159143A1 (en) 2002-02-21 2003-08-21 Peter Chan Systems and methods for generating a real-time video program guide through video access of multiple channels
KR101108661B1 (ko) 2002-03-15 2012-01-25 노키아 코포레이션 비디오 시퀀스에서의 움직임 부호화 방법
US7406034B1 (en) 2002-04-01 2008-07-29 Cisco Technology, Inc. Methods and apparatus for fibre channel frame delivery
EP1493269A2 (de) 2002-04-08 2005-01-05 Thomson Licensing S.A. Vorrichtung und verfahren zur datenzwischenspeicherung zur reduzierung der kanalwechselverzögerung
US7248781B2 (en) 2002-04-24 2007-07-24 Thomson Licensing Live picture presentation while digital video recording
US6751129B1 (en) 2002-05-21 2004-06-15 Sandisk Corporation Efficient read, write methods for multi-state memory
US8745689B2 (en) 2002-07-01 2014-06-03 J. Carl Cooper Channel surfing compressed television sign method and television receiver
US6772508B2 (en) * 2002-07-24 2004-08-10 The Boeing Company Fastener delivery and installation system
US8397269B2 (en) 2002-08-13 2013-03-12 Microsoft Corporation Fast digital channel changing
US7523482B2 (en) 2002-08-13 2009-04-21 Microsoft Corporation Seamless digital channel changing
SG111978A1 (en) * 2002-11-20 2005-06-29 Victor Company Of Japan An mpeg-4 live unicast video streaming system in wireless network with end-to-end bitrate-based congestion control
DE60330992D1 (de) 2002-11-27 2010-03-04 Rgb Networks Inc Ildung und optimierten einteilung von datenpaketen
US7650421B2 (en) * 2002-12-30 2010-01-19 Microsoft Corporation Adaptable accelerated content streaming
US20040128694A1 (en) 2002-12-30 2004-07-01 International Business Machines Corporation Fast selection of media streams
GB0300361D0 (en) 2003-01-07 2003-02-05 Koninkl Philips Electronics Nv Audio-visual content transmission
US20040160974A1 (en) 2003-02-13 2004-08-19 Read Christopher Jensen Method and system for rapid channel change within a transport stream
US6721962B1 (en) * 2003-02-19 2004-04-20 Michael Polaire Hat with brim light
US7076717B2 (en) * 2003-06-13 2006-07-11 Microsoft Corporation Time-aware best-effort hole-filling retry method and system for network communications
US7603689B2 (en) 2003-06-13 2009-10-13 Microsoft Corporation Fast start-up for digital video streams
US7142255B2 (en) 2003-10-08 2006-11-28 Silicon Laboratories Inc. Transport stream and channel selection system for digital video receiver systems and associated method
US7443791B2 (en) 2003-10-10 2008-10-28 Microsoft Corporation Priority mechanism for distributed sending of media data
US7562375B2 (en) 2003-10-10 2009-07-14 Microsoft Corporation Fast channel change
US7614071B2 (en) 2003-10-10 2009-11-03 Microsoft Corporation Architecture for distributed sending of media data
US7545812B2 (en) 2003-10-10 2009-06-09 Microsoft Corporation Scheduling scheme for distributed sending of media data
US7444419B2 (en) 2003-10-10 2008-10-28 Microsoft Corporation Media stream scheduling for hiccup-free fast-channel-change in the presence of network chokepoints
US7516232B2 (en) 2003-10-10 2009-04-07 Microsoft Corporation Media organization for distributed sending of media data
US7398547B2 (en) 2004-01-13 2008-07-08 Pace Plc. High-bandwidth digital content protection during rapid channel changing
US7430222B2 (en) * 2004-02-27 2008-09-30 Microsoft Corporation Media stream splicer
US20060089935A1 (en) 2004-10-26 2006-04-27 Microsoft Corporation Failover and load balancing for server clusters
US8135040B2 (en) 2005-11-30 2012-03-13 Microsoft Corporation Accelerated channel change

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8462847B2 (en) 2006-02-27 2013-06-11 Cisco Technology, Inc. Method and apparatus for immediate display of multicast IPTV over a bandwidth constrained network
US8588077B2 (en) 2006-09-11 2013-11-19 Cisco Technology, Inc. Retransmission-based stream repair and stream join
US9083585B2 (en) 2006-09-11 2015-07-14 Cisco Technology, Inc. Retransmission-based stream repair and stream join
US8769591B2 (en) 2007-02-12 2014-07-01 Cisco Technology, Inc. Fast channel change on a bandwidth constrained network
US8787153B2 (en) 2008-02-10 2014-07-22 Cisco Technology, Inc. Forward error correction based data recovery with path diversity

Also Published As

Publication number Publication date
US7944863B2 (en) 2011-05-17
EP1670252A2 (de) 2006-06-14
US20090077255A1 (en) 2009-03-19
EP1670252A3 (de) 2010-07-21
CA2841284A1 (en) 2006-06-10
CA2529563A1 (en) 2006-06-10
CA2529563C (en) 2014-08-19
US20060126667A1 (en) 2006-06-15
US7477653B2 (en) 2009-01-13
MXPA05013345A (es) 2006-06-14
EP2373026A1 (de) 2011-10-05
CA2841284C (en) 2016-11-29

Similar Documents

Publication Publication Date Title
EP1670252B1 (de) Beschleunigter Kanalwechsel in datenratenbegrenzten Umgebungen
US10764642B2 (en) Managed multiplexing of video in an adaptive bit rate environment
US8474001B2 (en) Near real time delivery of variable bit rate media streams
US10194181B2 (en) Fast channel change in a multicast adaptive bitrate (MABR) streaming network using multicast repeat segment bursts in a dedicated bandwidth pipe
EP2122841B1 (de) Verfahren und vorrichtung zur skalabilität von kanalwechselanfragen in einem geschalteten digitalvideosystem
US8135040B2 (en) Accelerated channel change
US9826262B2 (en) Fast channel change in a multicast adaptive bitrate (MABR) streaming network using multicast repeat segment bursts in a shared progressive ABR download pipe
US20180027039A1 (en) Client Feedback Enhanced Methods and Devices for Efficient Adaptive Bitrate Streaming
JP5108763B2 (ja) ピア・ツー・ピアコミュニティのためのマルチソース且つ復元力のあるビデオ・オン・デマンドストリーミングシステム
US20180262439A1 (en) Excess bitrate distribution based on quality gain in sabr server
US20070220577A1 (en) Method and media manager client unit for optimising network resources usage
US8356109B2 (en) Network streaming of a video stream over multiple communication channels
US9276976B2 (en) Apparatus and a method for data streaming applications
Baik et al. VSync: Cloud based video streaming service for mobile devices
US11622135B2 (en) Bandwidth allocation for low latency content and buffered content
Shuai Dynamic adaptive video streaming with minimal buffer sizes
Haimi-Cohen et al. Flexible and robust video delivery based on self-contained multimedia segments
Won et al. Effect of VBR traffic smoothing on broadband wireless Internet
WO2009103346A1 (en) Method and apparatus for obtaining media over a communications network

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

RIC1 Information provided on ipc code assigned before grant

Ipc: H04N 5/00 20060101ALI20100616BHEP

Ipc: H04N 7/24 20060101ALI20100616BHEP

Ipc: H04N 7/173 20060101AFI20060210BHEP

17P Request for examination filed

Effective date: 20110121

AKX Designation fees paid

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20110505

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 605364

Country of ref document: AT

Kind code of ref document: T

Effective date: 20130415

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602005038860

Country of ref document: DE

Effective date: 20130529

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 605364

Country of ref document: AT

Kind code of ref document: T

Effective date: 20130403

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

REG Reference to a national code

Ref country code: NL

Ref legal event code: VDEP

Effective date: 20130403

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130714

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

Ref country code: BE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130803

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130704

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130703

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

26N No opposition filed

Effective date: 20140106

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602005038860

Country of ref document: DE

Effective date: 20140106

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20131130

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20131130

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20131129

REG Reference to a national code

Ref country code: DE

Ref legal event code: R082

Ref document number: 602005038860

Country of ref document: DE

Representative=s name: OLSWANG GERMANY LLP, DE

REG Reference to a national code

Ref country code: GB

Ref legal event code: 732E

Free format text: REGISTERED BETWEEN 20150115 AND 20150121

REG Reference to a national code

Ref country code: DE

Ref legal event code: R081

Ref document number: 602005038860

Country of ref document: DE

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, REDMOND, US

Free format text: FORMER OWNER: MICROSOFT CORP., REDMOND, WASH., US

Effective date: 20130408

Ref country code: DE

Ref legal event code: R082

Ref document number: 602005038860

Country of ref document: DE

Representative=s name: OLSWANG GERMANY LLP, DE

Effective date: 20150126

Ref country code: DE

Ref legal event code: R081

Ref document number: 602005038860

Country of ref document: DE

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, REDMOND, US

Free format text: FORMER OWNER: MICROSOFT CORP., REDMOND, WASH., US

Effective date: 20150126

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20051129

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20131129

REG Reference to a national code

Ref country code: FR

Ref legal event code: TP

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, US

Effective date: 20150724

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 11

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130403

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 12

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 13

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 14

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20181113

Year of fee payment: 14

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20181128

Year of fee payment: 14

Ref country code: FR

Payment date: 20181011

Year of fee payment: 14

Ref country code: IT

Payment date: 20181122

Year of fee payment: 14

REG Reference to a national code

Ref country code: DE

Ref legal event code: R082

Ref document number: 602005038860

Country of ref document: DE

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602005038860

Country of ref document: DE

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20191129

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200603

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20191130

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20191129

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20191129