GB2500406A - Providing rapid channel changes, with client itself assessing technical environment and network connection parameters - Google Patents
Providing rapid channel changes, with client itself assessing technical environment and network connection parameters Download PDFInfo
- Publication number
- GB2500406A GB2500406A GB1204874.0A GB201204874A GB2500406A GB 2500406 A GB2500406 A GB 2500406A GB 201204874 A GB201204874 A GB 201204874A GB 2500406 A GB2500406 A GB 2500406A
- Authority
- GB
- United Kingdom
- Prior art keywords
- client
- server
- stream
- multicast
- 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.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 claims abstract description 47
- 239000000872 buffer Substances 0.000 claims abstract description 13
- 230000005540 biological transmission Effects 0.000 claims abstract description 7
- 230000000977 initiatory effect Effects 0.000 claims abstract description 3
- 230000007704 transition Effects 0.000 claims description 6
- 238000004891 communication Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 101100238304 Mus musculus Morc1 gene Proteins 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 230000009172 bursting Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000008092 positive effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000009738 saturating Methods 0.000 description 1
Classifications
-
- 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
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
-
- 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/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/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
-
- 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/6377—Control signals issued by the client directed to the server or network components directed to 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/65—Transmission of management data between client and server
- H04N21/658—Transmission by the client directed to the server
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
A method for initiating streaming media (AV content) delivery over a network from a server to a client (terminal) comprises the steps of: determination of the technical environment 16 (e.g., calculating an offset, and a delay before joining a multicast based on channel bit rate, line bandwidth and/or buffer size) and network connection parameters of the client through the client (itself); the client issuing 18 a command to the server to initiate streaming media delivery including a channel ID and stream position; and the server receiving the initiate delivery command and starting burst (high rate) transmission of media according to the channel ID and stream position. The client may also send a connect request to the server. Burst transmission may be terminated after a defined time, with streaming continuing at a nominal bitrate; circular buffers in the server may store the stream. Initially, a unicast stream may be transmitted; if it is determined that the client does not receive the unicast stream, a multicast join request can be issued. Lost packet re-transmission may be initiated. The method is applied to providing fast channel changes (FCC) in networked IPTV environments.
Description
Description
Title: Fast channel change algorithm [0001] This present application is directed at a method and a system for streaming media from a media server to client modules according to the preambles of the independent claims.
[0002] Traditional systems for delivering broadcast media to the consumer rely on the use of a physical tuner in a client module, for example in the form of a television set that tunes to and receives the media information. In such a model, a user can quickly change channels, resulting in a real time transition from one program to another, so that the user does not perceive a delay in the presentation of a new program upon tuning to a new program. However, this simple manner of operation does not work for streaming digital media information over a network as is the case for example in IPTY environments. In such environments, the client Is module, which can be either a set top box or a software module, has to buffer a certain amount of media information before it can begin playing the media information to the consumer. Buffering, however, requires a certain amount of time when the user first connects to a stream of media information. Furthermore, digital media information is commonly expressed as a series of key frames (e.g., T frames) and difference frames (e.g., B and P frames). Accordingly, a client module must wait for a key frame before it can begin presenting the media information to the consumer, resulting in a noticeable lag prior to the presentation of programs as the user switches from one channel to another.
[0003] Over time various methods were developed to reduce the effects of the problem in media streaming environments described above. According to these methods, the server infrastructure delivers an initial burst of media information, 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. After this initial burst, the server infrastructure delivers the media information to the client module at a regular data rate.
[0004] Generally, these methods including the bursts of media information are very demanding as regards required communication channels beyond that required to transmit the media information at its normal steady-state rate. This problem may be addressed by allocating extra bandwidth to implement the methods. However, many environments allocate a limited amount of bandwidth to the communication channels, which posts additional problems, so that the methods mentioned above have the potential of overburdening such a communication channel, particularly when multiple users in a household are consuming media information at the same time.
[0005] Other environments that are rate-limited may allocate a relatively large amount of bandwidth to the channels, thus reducing the potential of over-saturating the available channels.
[0006] A method to make such systems less costly, less error prone, and more efficient was disclosed in US 2009/0077255 Al to Microsoft Corp. which is included herein by reference.
[0007] What is described in this document is a method for delivering resource information to a client module, the method comprising the steps of delivering the Is resource information, using a first delivery technique, at above-nominal data rate levels during an initial burst period of data transmission to the client module; delivering the resource information at join interval data rate levels during a join interval following the burst period, wherein, following the join interval, the client module switches to a second delivery technique for providing the resource information; and responding to requests from the client module to supply parts of the resource information which the client module potentially missed during the join interval as a result of its receipt of the resource information at the join interval data rate levels.
[0008] The method described in this document has a number of advantages over prior methods. However, time has shown that there still is room for improvement.
In particular, in the method as described in US 2009/0077255 Al, it is a server that is driving the process, i.e. the server takes all the decisions regarding parameters like burst length and speed, non-burst length and speed, moment of joining multicast, filling of pre-multicast period by some unicast or not filling, etc. while the client just executes commands given by Server.
[0009] The disadvantage of this approach is that all the actual information regarding the environment of the client, such as connection speed, signal qualify, etc. remains unconsidered. If, for example, a Multicast Join command is issued by a clicnt to thc network, this command is cxccutcd with a vcry long delay, i.e. more than 10 seconds. In this ease, a method as described inUS 2009/0077255 Al would have little or no positive effect, as the server delivering the media content cannot know what is happening at the client's side. As a result a user might cxpcrienee problems while watching or switching to a particular channel, as after the burst was played, the video will stop as Multicast has not actually been joined and the rcspcctivc media stream has not arrived at the client yet.
[0010] This means that either very strict requirements for network quality would have to be imposed, or a user would have problems watching TV over the network.
[0011] Furthermore, if somc problems occur in some small part of the network regarding Multicast, users would have problems watching TV.
[0012] As a quick solution to this problem, one could substantially increase the burst period to values of one minute or two. This would not help in all cases, Is however, and, what is even more important, would increase the load on the network just as much, as bursting and unicast in general gcncratc heavy loads on a network.
[0013] Considering all of the above, there is a clear need for a method and/or system that overcomes the disadvantages as described above.
[0014] Accordingly, an approach is proposed in which the client is thc driving component and takes all the decisions regarding the time to Join Multicast, Burst, etc., while the Server just executes the commands issued by Client. According to this approach, and as a client knows its own cnvironmcnt such as connection speed and quality, and sees what is happening during the process of changing channels, a respective client may, for example, stay on Unicast forever, if the network experiences problems with Multicast, which leads to a much better user experience, since networks are used based on actual availability and capabilities instead of virtual server dcmand.
[0015] More specifically what is proposed is a method for initiating streaming media delivery over a network from a server to a client, comprising the steps of determination of the technical environment and network connection parameters of the client through the client, the client then issuing a command to the server to initiate streaming media delivery including a channel ID and stream position, and the server receiving the initiate delivery command and starting burst transmission of media according to channel ID and stream position. According to this method, it is the client that is in the drivers seat and taking all the decisions regarding when to start a stream and how to deliver the stream, taking into account all the environmental parameters of the client, in order to usc the available resources to its thllest, but also considering its limitations.
[0016] In case that the server and the client are within a TCP network, it is necessary that before the client issues the command to initiate streaming media delivery, the additional steps of the client sending a connect request to the server, and the server accepting the connect request are performed.
[0017] Preferably, there is an additional step of the server terminating the burst transmission after a defined time, and continuing streaming at a nominal bit rate, while circular buffers may be used in the server to store the stream.
[0018] According to another preferred embodiment of the invention, the step of determining the technical environment includes calculating an offset, and a delay before joining multicast based at least upon one of channel bit rate, line bandwidth, and/or buffer size.
[0019] The initial stream that is transmitted from the server to the client preferably is a unicast stream, wherein the client performs the additional step of determining whether a media stream is being received. Upon determination that the client does not receive a unicast stream, the client may issue a multicast join request in order to overcome the lack ofunicast media stream.
[0020] On the other hand, if the client does receive a unicast stream, it may wait for the delay to join multicast to end, and, upon reaching the end of the delay, issue a multicast join request to the server just as well, wherein until the first multicast packet arrives, the client receives the unicast stream, and upon arrival of the first multicast packet, stops receipt of the unicast stream.
[0021] To stop the unicast stream, the client may either issue a stop unicast command to the server, or, in the case of a TCP network, simply close the connection to the server.
[0022] Upon accomplishment of unicast to multicast transition, the client may perform another step of determining the existence of lost packets, or holes, in the multicast stream. Additionally, even during receipt of the multicast stream the client may continuously determine the existence of lost packets, or holes, in the multicast stream.
[0023] In both cases and upon determination that lost packets exist, the client can send a request to the server to retransmit any lost packets, in order to fill the holes in the multicast stream.
[0024] Furthermore, if the client upon determines that the multieast stream stops for longer than a predefincd time interval, the client may perform the step of sending a request to the server to reinitiate unieast streaming, which in essence will lead to a restart of the entire method as described above.
[0025] Further features and advantages may be taken from the following merely illustrative and in no way limiting description of a preferred embodiment of the invention with reference to the enclosed figures, showing: [0026] Fig. 1 a flowchart, showing the server side of the method; [0027] Fig. 2 a flowchart, showing the client side of the method; [0028] Fig. 3 a diagram to visualize the amount of data transmitted according to the invention.
[0029] According to Fig. 3 and for the sake of this description of a preferred embodiment of the invention, the following parameter eakulations are used: [0030] T -is the current time.
[00311 I -is the interval (offset) from where to start receiving the media stream.
This interval is calculated by the client, and depends upon on number of technical environment parameters of the client, such as but limited to line bandwidth, channel bit rate, buffer size, etc.. There may be many variations of calculating the I parameter. One basic formula, in which I is measured using bytes, is the following: I = minimal_amount + total_buffer_size * fetch_multiplier + reserved_amount wherein minimal_amount is a minimal required amount to be prefetched, total_buffer_size is the sum of sizes of all buffers involved in the receive/recovery/play system, that may cause a delay before the media stream reaches video/audio decoder module of the client, and fetch_multiplier is a paramctcr that dcscribcs how intcnsivc thc strcam data prcfctch is. This paramctcr may depend on many factors, in example it may differ for CBR (constant bit-rate) and VBR (variable bit rate) streams, because VBR streams may require more data to bc prcfctchcd due to its unsteady nature. In some examples thcrc may be found an optimal fetch multiplier of about 1.3-1.5 for CBR streams, and 1.8-2.0 for VBR streams. But this may be different for other examples.
[0032] Furthermore, reserved amount is an additional parameter that makcs systems more stable, as there may be instability of line bandwidth, or other factors that may cause temporary problems. Essentially, reserved_amount is a certain amount of prefetched additional data to savc buffers from running empty if something goes wrong at a later point in time.
[0033] OptimalTransitionTime -is the delay before joining multicast, calculated by the client, depending upon channel bitrate, line bandwidth, buffer size, or other parameters. There may be many variations of calculating the OptimalTransitionTime parameter, but for the sake of this description may be calculated as: OptimalTransitionTime = ((I x 8) / ((I + F) x Nominal)) + reserved delay whcrcin thc paramctcr I is cxprcsscd in bytcs in this formula and OptimalTransitionTime in seconds, wherein (1 + E) x Nominal is equal to line bandwidth in bits per second, and reserved_delay is the additional delay in seconds that makes the system morc stable when line bandwidth is unstablc.
[0034] I and (T -I) position parameters in the actual implementation may be measured by time units (seconds, milliseconds, etc.), or by information unit (bits, bytes, ctc.) [0035] Referring now to Fig. 1 the method as seen from the server side is described, wherein both the server and the client are located within a network in which a connection oriented protocol such as TCP is used.
[0036] In a first step 2, the server accepts the connection from client. In other nctworks using othcr protocols as a connection oricntcd protocol, cstablishing a connection may not be necessary.
[0037] In a second step 4, the server receives a command from client, the command containing information about thc channel ID, and the stream position from where to start burst at T -I. [0038] In the following step 6, the server starts streaming the burst at (1 + E) x Nominal, whereas in the following step 8, after the burst is over, the server continues streaming at a nominal bitrate, i.e. in live mode. This transition is performed without interruption, over the same unicast channel, wherein the server may use circular buffers to store the channel stream. Furthermore, the transition from burst mode to live mode is done in a natural way without any additional enforcement.
[0039] If and when at step 10 the server receives from the client the command to stop streaming or when the client closes the connection (if any), the server stops transmitting the stream and closes the connection channel (if any) from his side as well at step 12.
[0040] Otherwise the server will continue streaming in "live mode" at a nominal bitrate forever, or it may stop transmitting the stream after some predefined time interval has passed, or a traffic limit was reached.
[0041] Turning now to Fig. 2, a preferred embodiment of the method is described from the client side.
[0042] At step 14, the client establishes a connection to the server (again in case that a connection oriented protocol like TCP is used, otherwise the step of establishing connection may not be necessary).
[0043] In the following step 16, the client calculates the offset I according to the instructions above, as well as the OptimalTransitionTime, i.e. the delay before joining multicast.
[0044] In the following step 18, the client sends a command to the server that contains information about the channel ID and the stream position from where to start burst at time T -I. [0045] The client starts receiving a unicast stream, and optionally fills buffers, starts playing, etc., in step 20.
[0046] In step 22 the client determines, whether there is any problem in establishing connection to the server, whether the server is unable to execute the command rcccived from the client according to step 18, or whether the client does not receive the unicast stream for any reason. If there is a problem of this kind, the client proceeds to the next step 22, according to which it will try to use multicast functionality without the initial unieast burst by immediately going to step 26 and issuing a join multicast request. If no problems can be detected by the client, the method proceeds to step 24, with the client waiting for the OptimalTransitionTime, while still receiving a unicast stream and playing.
[0047] If the OptimalTransitionTime is over, the method proceeds to step 26, with the client issuing a multicast join request, while the client still receives a unicast stream and plays to the user according to step 28.
[0048] According to step 30, the client determines, whether any multicast packets start arriving. If no multicast packets arrive, the client will still continue receiving a unicast stream and playing, which may happen when the network multieast functionality is down or is experiencing any problems.
[0049] If first multicast packets arrive, the client will stop receiving the unieast stream according to step 32 either by issuing an appropriate command to the server, or by simply closing the connection (if any).
[0050] According to step 34, the client receives a multicast stream and plays the media to the user.
[0051] In another step 36 the client checks if there were any holes" i.e. lost packets in the stream when accomplishing unicast to multicast transition. If this is the case, the client will ask the server to retransmit any lost packets to fill the holes" . During the multieast stream reception client may ask the sewer to retransmit lost packets (if any).
[0052] According to step 38, if the multieast stream stops for longer than some predefined time interval, the client may decide to switch to the unicast stream. To do so the method returns to the step 1.
Claims (17)
- Claims 1. Method for initiating streaming media delivery over a network from a server to a client, comprising the steps of: Determination of the technical environment and network connection parameters of the client through the client, Client issuing a command to server to initiate streaming media delivery including a channel ID and stream position, Server receiving the initiate delivery command and starting burst transmission of media according to channel ID and stream position.
- 2. Method according to claim 1, wherein, before the client issues the command to initiate streaming media delivery, the additional steps of the client sending a connect request to the server, and the server accepting the connect request are performed.
- 3. Method according to claim I or 2, comprising the additional step of the server terminating the burst transmission after a defined time, and continuing streaming at a nominal bit rate.
- 4. Method according to any of the preceding claims, wherein circular buffers are used in the server to store the stream.
- 5. Method according to any of the preceding claims, wherein the step of determining the technical environment includes calculating an offset, and a delay before joining multicast based at least upon one of channel bit rate, line bandwidth, and/or buffer size.
- 6. Method according to any of the preceding claims, wherein the initial stream that is transmitted from the server to the client is a unicast stream.
- 7. Method according to any of the preceding claims, wherein the additional step of determining whether a media stream is bcing received by thc client is performed.
- 8. Method according to claim 7, wherein upon determination that the client does not receive a unicast stream, the client issues a multicast join request.
- 9. Method according to claim 7, wherein upon determination that the client does rcceive a unicast stream, thc clicnt waits for the delay to join multicast, and, upon reaching the delay, issues a multicast join request to the server.
- 10. Method according to claim 9, wherein until thc first multicast packct arrives, the client receives the unicast stream.
- 11. Method according to claim 10, wherein upon arrival of the first multicast packet, is the client stops receipt of the unieast stream.
- 12. Method according to claim II, wherein the client in stopping receipt of the unicast stream issues a stop unicast command to the server.
- 13. Method according to claim 11, wherein the client in stopping receipt of the unicast stream closes the connection to the server.
- 14. Method according to any of claims 11 to 13, wherein the client, upon accomplishment of unicast to multicast transition, performs the step of determining the existence of lost packets in the multicast stream.
- 15. Method according to any of claims 11 to 13, wherein during receipt of the multicast stream the client continuously determines the existence of lost packets in the multicast stream.
- 16. Method according to claim 14 or 15, wherein the client upon determination that lost packets exist, sends a request to the server to retransmit any lost packets.
- 17. Method according to claim 14 or 15, wherein the client upon dctcmiination that thc multicast stream stops for longer than a predetined time interval additionally performs the step of sending a request to the server to reinitiate unicast streaming.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB1204874.0A GB2500406A (en) | 2012-03-20 | 2012-03-20 | Providing rapid channel changes, with client itself assessing technical environment and network connection parameters |
PCT/EP2013/055721 WO2013139804A1 (en) | 2012-03-20 | 2013-03-19 | Fast channel change algorithm |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB1204874.0A GB2500406A (en) | 2012-03-20 | 2012-03-20 | Providing rapid channel changes, with client itself assessing technical environment and network connection parameters |
Publications (2)
Publication Number | Publication Date |
---|---|
GB201204874D0 GB201204874D0 (en) | 2012-05-02 |
GB2500406A true GB2500406A (en) | 2013-09-25 |
Family
ID=46052228
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
GB1204874.0A Withdrawn GB2500406A (en) | 2012-03-20 | 2012-03-20 | Providing rapid channel changes, with client itself assessing technical environment and network connection parameters |
Country Status (2)
Country | Link |
---|---|
GB (1) | GB2500406A (en) |
WO (1) | WO2013139804A1 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10531132B2 (en) | 2017-12-28 | 2020-01-07 | Stmicroelectronics International N.V. | Methods and techniques for reducing latency in changing channels in a digital video environment |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1182875A2 (en) * | 2000-07-06 | 2002-02-27 | Matsushita Electric Industrial Co., Ltd. | Streaming method and corresponding system |
WO2011152675A2 (en) * | 2010-06-04 | 2011-12-08 | Samsung Electronics Co., Ltd. | Method and apparatus for adaptive streaming based on plurality of elements for determining quality of content |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7650421B2 (en) * | 2002-12-30 | 2010-01-19 | Microsoft Corporation | Adaptable accelerated content streaming |
US7477653B2 (en) | 2004-12-10 | 2009-01-13 | Microsoft Corporation | Accelerated channel change in rate-limited environments |
WO2010096965A1 (en) * | 2009-02-27 | 2010-09-02 | 华为技术有限公司 | Method, terminal device and channel switching server for processing abnormality in channel switching |
US8161515B2 (en) * | 2009-05-13 | 2012-04-17 | Alcatel Lucent | Fast channel change handling of late multicast join |
US20110289544A1 (en) * | 2010-05-19 | 2011-11-24 | Goosen Hendrik A | Video streaming system including a fast channel change mechanism |
-
2012
- 2012-03-20 GB GB1204874.0A patent/GB2500406A/en not_active Withdrawn
-
2013
- 2013-03-19 WO PCT/EP2013/055721 patent/WO2013139804A1/en active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1182875A2 (en) * | 2000-07-06 | 2002-02-27 | Matsushita Electric Industrial Co., Ltd. | Streaming method and corresponding system |
WO2011152675A2 (en) * | 2010-06-04 | 2011-12-08 | Samsung Electronics Co., Ltd. | Method and apparatus for adaptive streaming based on plurality of elements for determining quality of content |
Also Published As
Publication number | Publication date |
---|---|
WO2013139804A1 (en) | 2013-09-26 |
GB201204874D0 (en) | 2012-05-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100898210B1 (en) | Method and apparatus for transferring digital signal and changing received streaming content channels, and computer readable medium | |
EP2369840B1 (en) | Channel switching method, device and system | |
US8474001B2 (en) | Near real time delivery of variable bit rate media streams | |
US8996719B2 (en) | System and method of adaptive transport of multimedia data | |
US8125901B2 (en) | Video streaming | |
EP3348069B1 (en) | Fast channel change in a multicast adaptive bitrate (mabr) streaming network using http download segment recovery in a dedicated bandwidth pipe | |
EP3348070B1 (en) | Fast channel change in a multicast adaptive bitrate (mabr) streaming network using http download segment recovery in a shared progressive abr download pipe | |
JP5421346B2 (en) | High-speed transmission method and apparatus for unicast stream in high-speed channel change | |
EP2415262B1 (en) | Methods and arrangements for system providing media via multicast distribution | |
WO2017042675A1 (en) | Fast channel change in a multicast adaptive bitrate (mabr) streaming network using multicast repeat segment bursts in a dedicated bandwidth pipe | |
KR20130005873A (en) | Method and apparatus for receiving contents in broadcast system | |
CN104427400A (en) | Streaming media transmission method and system, and streaming media server | |
JP5659791B2 (en) | Content distribution system, content distribution method and program | |
JP5610743B2 (en) | Content receiving method and apparatus | |
GB2500406A (en) | Providing rapid channel changes, with client itself assessing technical environment and network connection parameters | |
WO2013160042A1 (en) | System for packet loss recovery | |
CN105245946B (en) | Method, device and system for controlling flow of variable-code-rate media stream | |
KR101008356B1 (en) | Streaming Relay Apparatus, User Terminal Device, and Streaming Service Relay Method | |
US20240187466A1 (en) | Content delivery | |
EP2645671A1 (en) | Switching the playing out of information content beween end-user devices | |
KR20070092280A (en) | Delivering streaming data | |
WO2023052191A1 (en) | Content delivery | |
WO2023104514A1 (en) | Content delivery |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WAP | Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1) |